I disable shared key access on Azure Storage and switch to Entra ID

In a lot of the environments I review, Azure Storage shared key authentication is still in active use, mostly out of habit rather than need. With compliance requirements getting stricter and security expectations going up, this old approach has turned into a liability. Disabling shared key access on Azure Storage is more than flipping a setting, though. You may have to rethink the access model, the way apps get onboarded and a few legacy workflows along with it.

Shared keys and SAS tokens carry a real risk

The main problem is that the account key gives full access to everything in the storage account. Whoever holds the key can create account SAS tokens, frequently with wide permissions and long lifetimes, and those tokens end up hardcoded in scripts, handed to automation or even passed on to third parties. You can barely audit them, you can't scope them finely, and if one leaks you have to rotate the keys completely. In a large organization that rotation is a disruptive event.

Data plane RBAC with Entra ID, on the other hand, gives you real granular control and auditability. Assigning roles such as Storage Blob Data Reader or Storage Blob Data Contributor to users, groups or managed identities is a very different thing from giving out the account's master key. The Microsoft documentation on Entra ID authorization describes the options and recommended practices.

Practical tip: While you're still in transition, keep rotating your account keys on a regular schedule, particularly as long as legacy apps or scripts haven't been migrated.

You should detect shared key usage before you block it

Before you set AllowSharedKeyAccess to false and shut off shared key authentication on the account, you need to know who and what still depends on it. Plenty of tools (Azure Storage Explorer is the usual suspect), scripts and even some Microsoft services can rely on shared keys without making it obvious.

Azure Monitor metrics and logs will tell you what's happening, and this Microsoft Learn article explains the setup. For a quick check, open storage account → Monitoring → Metrics in the Azure portal, select the "Transactions" metric and use "Apply splitting" on the "Authentication" dimension. The "AccountKey" value represents shared key requests. If you want to know exactly who is calling, enable the StorageRead, StorageWrite and StorageDelete categories for "blob" under Monitoring → Diagnostic settings, send them to a Log Analytics workspace, and then run a KQL query under Logs:

StorageBlobLogs
| where AuthenticationType == "AccountKey"
| summarize Count = count() by AccountName, CallerIpAddress, UserAgentHeader

The output shows you which users and IP addresses still authenticate with shared key, so you can plan remediation case by case.

The diagram below shows the basic difference between shared key and Entra ID (RBAC) for storage access:

flowchart TD
  user["User/Tool"] --> sharedkeyauth["Shared Key Auth"]
  sharedkeyauth --> allaccess["Full Storage Access"]
  user --> entraauth["Entra ID Auth"]
  entraauth --> rbacroles["RBAC Roles (e.g. Reader)"]
  rbacroles --> containeraccess["Scoped Container/Blob Access"]

Figure: Shared key compared with Entra ID RBAC for storage access.

RBAC roles, user delegation SAS and managed identities replace the key

After the move to Entra ID authentication, all data access should go through suitable RBAC roles. Applications should use managed identities wherever possible. They fetch short-lived tokens on their own, and there are no shared secrets to manage. For users, or for apps that can't use a managed identity, user delegation SAS tokens fill the gap. They are short-lived, auditable and limited to the rights the user actually has. Have a look at the CLI documentation for user delegation SAS for details.

This is how I create a user delegation SAS for a blob with Azure CLI:

az storage blob generate-sas \
  --account-name <storageaccount> \
  --container-name <container> \
  --name <blob> \
  --as-user \
  --auth-mode login \
  --permissions r \
  --expiry 2024-06-30T23:59Z

That way you can hand out specific access for a limited time, and the account key never leaves the account.

The switch to disable shared key has side effects

AllowSharedKeyAccess is the setting that matters here. As soon as it's set to false, only Entra ID and user delegation SAS-based access will work. Legacy tools (Azure Storage Explorer in default mode included) and some older Microsoft services will break. From what I've seen, there's no way around testing the affected workflows one by one and updating or replacing them where necessary. Tell the people involved early, and be prepared to run both models in parallel for a while to keep disruption low. If you want to get ahead of the problem, Azure Policy can already audit or enforce AllowSharedKeyAccess=false on new deployments, which keeps new risk from piling up.

Secure storage is simply good hygiene in my view

Turning off shared key on Azure Storage is no longer a nice-to-have security improvement. It has become a requirement, much like moving Azure Key Vault to RBAC. With some planning, proper monitoring and good stakeholder management, the change is entirely manageable, even in complex organizations. If you do it now, you spare yourself audit trouble, incidents and rushed key rotations later.