Ensure Storage Account Access Keys are Periodically Regenerated

Overview

For increased security, regenerate storage account access keys periodically.

Rationale

When a storage account is created, Azure generates two 512-bit storage access keys, which are used for authentication when the storage account is accessed. Rotating these keys periodically ensures that any inadvertent access or exposure does not result in the compromise of the keys.

Cryptographic key rotation periods will vary depending on your organization's security requirements and the type of data being stored in the Storage Account. For example, PCI DSS mandates that cryptographic keys be replaced or rotated 'regularly' and advises that keys for static data stores be rotated every 'few months.'

For the purposes of this recommendation, 90 days will be prescribed for the reminder. Review and adjustment of the 90-day period is recommended and may even be necessary. Your organization's security requirements should dictate the appropriate setting.

Impact

Regenerating access keys can affect Azure services and the organization's applications dependent on the storage account. All clients that use the access key to access the storage account must be updated to use the new key.

Default Value

By default, access keys are not regenerated periodically.

Remediation guidance

Azure Portal

Open the storage account in the Azure Portal using the Open in Azure button.
Click Rotate key next to the outdated key, then click Yes to the prompt confirming that you want to regenerate the access key.

After Azure regenerates the Access Key, you can confirm that Access keys reflects a Last rotated date of (0 days ago).

Azure CLI

Update the connection strings in your application to reference the secondary access key for the storage account.
Call the az storage account keys renew command to regenerate the primary access key, as shown in the following example:

az storage account keys renew \
  --resource-group <resource-group> \
  --account-name <storage-account> \
  --key primary

Update the connection strings in your application to reference the new primary access key.
Regenerate the secondary access key in the same manner. To regenerate the secondary key, use secondary as the key name instead of primary.

Multiple Remediation Paths

Azure

SERVICE-WIDE (RECOMMENDED when many resources are affected): Assign Azure Policy initiatives at management group/subscription scope and trigger remediation tasks.

az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>

ASSET-LEVEL: Apply the resource-specific remediation steps above to the listed non-compliant resources.

PREVENTIVE: Embed Azure Policy checks into landing zones and IaC workflows to block or auto-remediate drift.

References for Service-Wide Patterns

Azure Policy overview: https://learn.microsoft.com/en-us/azure/governance/policy/overview
Azure Policy remediation: https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources
Azure Policy initiative structure: https://learn.microsoft.com/en-us/azure/governance/policy/concepts/initiative-definition-structure

Operational Rollout Workflow

Use this sequence to reduce risk and avoid repeated drift.

1. Contain at Service-Wide Scope First (Recommended)

Azure: assign policy initiatives at management group/subscription scope and run remediation tasks.

az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>

2. Remediate Existing Affected Assets

Execute the control-specific Console/CLI steps documented above for each flagged resource.
Prioritize internet-exposed and production assets first.

3. Validate and Prevent Recurrence

Re-scan after each remediation batch.
Track exceptions with owner and expiry date.
Add preventive checks in IaC/CI pipelines.

Query logic

These are the stored checks tied to this control.

Storage account access keys are periodically regenerated

Connectors

Microsoft Azure

Covered asset types

StorageAccount

Expected check: eq []

{StorageAccountsWithOldKeys{...AssetFragment}}