{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/azure-storage-shared-key-migration/", "item": { "id": "https://update.dsesecurity.com/updates/azure-storage-shared-key-migration/", "slug": "azure-storage-shared-key-migration", "url": "https://update.dsesecurity.com/updates/azure-storage-shared-key-migration/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/azure-storage-shared-key-migration.md", "json": "https://update.dsesecurity.com/api/v1/posts/azure-storage-shared-key-migration/" }, "title": "Disable Azure Storage Shared Key only after every caller identifies itself", "summary": "Disallowing Shared Key rejects account-key and dependent SAS authorization while allowing supported Microsoft Entra authorization, so caller discovery and migration must precede enforcement.", "format": { "slug": "playbook", "name": "Playbook" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-08-25T21:34:58+00:00", "modified_at": "2026-08-25T21:43:55+00:00", "reviewed_on": "2026-08-25", "reading_minutes": 3, "word_count": 497, "potentially_affected": "Azure Storage accounts used by applications, Azure services, scripts, portals, Azure Files, or clients that may depend on account keys or Shared Key-based SAS.", "dse_recommendation": "Inventory authorization type per caller, migrate supported workloads to Entra identities or user-delegation SAS, isolate incompatible Azure Files workloads, and deny Shared Key through staged policy.", "primary_source": { "name": "Prevent Shared Key authorization for an Azure Storage account", "url": "https://learn.microsoft.com/en-us/azure/storage/common/shared-key-authorization-prevent", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Bottom line: Azure Storage can reject requests authorized with the account key by setting AllowSharedKeyAccess to false. That blocks direct Shared Key use and Shared Key-backed service or account SAS. Supported Microsoft Entra authorization and Blob user-delegation SAS follow different paths. Discover every caller before enforcement or applications and Azure services may lose data access.

\n

Source fact: what Microsoft documents

\n

Microsoft’s Shared Key prevention guide says a storage account permits Shared Key when AllowSharedKeyAccess is true or unset. When the property is false, requests authorized with the account key are rejected. Microsoft recommends Entra authorization where supported.

\n

The source distinguishes SAS types. Account SAS and service SAS depend on Shared Key and are rejected when Shared Key is disallowed. A Blob user-delegation SAS is authorized through Entra and can continue under documented conditions. Microsoft warns that logs and metrics do not always make SAS type easy to distinguish. It also documents compatibility issues: some Azure services and tools use Shared Key, and Azure Files requires careful identity and portal behavior review. Microsoft proposes detection, remediation, audit, and governance, including Azure Policy in audit before deny.

\n

What the source does not establish

\n

Disabling Shared Key does not make all storage access least privilege, remove existing Entra role assignments, prevent anonymous access where separately enabled, or rotate data-encryption keys. A successful Entra request does not prove the identity has only necessary permissions. Metrics showing SAS use do not by themselves identify whether it is service, account, or user-delegation SAS.

\n

Applicability questions

\n\n

DSE recommendation: controlled next steps

\n

The following steps are DSE recommendations based on the cited source.

\n
    \n
  1. Inventory storage accounts and set the built-in policy to audit. Treat an unset property as allowing Shared Key, consistent with Microsoft’s documentation.
    2. \n
  2. Use logs, metrics, code search, secret inventory, and application-owner interviews to identify authorization per caller. Validate ambiguous SAS traffic directly.
    3. \n
  3. Migrate supported callers to managed identity or another Entra identity with narrow data-plane roles; use user-delegation SAS where appropriate.
    4. \n
  4. Separate incompatible Azure Files or service dependencies rather than leaving a broad mixed-use account permanently exposed.
    5. \n
  5. Set AllowSharedKeyAccess false in a pilot, monitor 403 failures, then move policy from audit to deny after successful migration.
    6. \n
\n

Verification and evidence

\n\n

Official references

\n", "content_text": "Bottom line: Azure Storage can reject requests authorized with the account key by setting AllowSharedKeyAccess to false. That blocks direct Shared Key use and Shared Key-backed service or account SAS. Supported Microsoft Entra authorization and Blob user-delegation SAS follow different paths. Discover every caller before enforcement or applications and Azure services may lose data access.\nSource fact: what Microsoft documents\nMicrosoft’s Shared Key prevention guide says a storage account permits Shared Key when AllowSharedKeyAccess is true or unset. When the property is false, requests authorized with the account key are rejected. Microsoft recommends Entra authorization where supported.\nThe source distinguishes SAS types. Account SAS and service SAS depend on Shared Key and are rejected when Shared Key is disallowed. A Blob user-delegation SAS is authorized through Entra and can continue under documented conditions. Microsoft warns that logs and metrics do not always make SAS type easy to distinguish. It also documents compatibility issues: some Azure services and tools use Shared Key, and Azure Files requires careful identity and portal behavior review. Microsoft proposes detection, remediation, audit, and governance, including Azure Policy in audit before deny.\nWhat the source does not establish\nDisabling Shared Key does not make all storage access least privilege, remove existing Entra role assignments, prevent anonymous access where separately enabled, or rotate data-encryption keys. A successful Entra request does not prove the identity has only necessary permissions. Metrics showing SAS use do not by themselves identify whether it is service, account, or user-delegation SAS.\nApplicability questions\n\nWhich applications, scripts, users, managed identities, Azure services, and third parties call the account?\nDo they use account keys, account SAS, service SAS, user-delegation SAS, Entra OAuth, anonymous access, SFTP local users, or SMB identity?\nDoes the account host Azure Files, and can each file-access and portal scenario use supported identity authorization?\nWhich callers can migrate, which need a separate account, and which are vendor-blocked?\nWho can list account keys or change AllowSharedKeyAccess after enforcement?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\n\nInventory storage accounts and set the built-in policy to audit. Treat an unset property as allowing Shared Key, consistent with Microsoft’s documentation.\nUse logs, metrics, code search, secret inventory, and application-owner interviews to identify authorization per caller. Validate ambiguous SAS traffic directly.\nMigrate supported callers to managed identity or another Entra identity with narrow data-plane roles; use user-delegation SAS where appropriate.\nSeparate incompatible Azure Files or service dependencies rather than leaving a broad mixed-use account permanently exposed.\nSet AllowSharedKeyAccess false in a pilot, monitor 403 failures, then move policy from audit to deny after successful migration.\n\nVerification and evidence\n\nPreserve caller inventory, authorization type, migration owner, RBAC assignments, exceptions, and approval.\nQuery the account property and prove it returns false after enforcement.\nDemonstrate Entra-authorized test access succeeds while an account-key or service-SAS test is rejected.\nMonitor policy compliance and failed authorization after rollout; investigate any reenablement.\n\nOfficial references\n\nPrevent Shared Key authorization for an Azure Storage account — Microsoft", "content_markdown": "Bottom line: Azure Storage can reject requests authorized with the account key by setting AllowSharedKeyAccess to false. That blocks direct Shared Key use and Shared Key-backed service or account SAS. Supported Microsoft Entra authorization and Blob user-delegation SAS follow different paths. Discover every caller before enforcement or applications and Azure services may lose data access.\n\n## Source fact: what Microsoft documents\n\nMicrosoft’s [Shared Key prevention guide](https://learn.microsoft.com/en-us/azure/storage/common/shared-key-authorization-prevent) says a storage account permits Shared Key when AllowSharedKeyAccess is true or unset. When the property is false, requests authorized with the account key are rejected. Microsoft recommends Entra authorization where supported.\n\nThe source distinguishes SAS types. Account SAS and service SAS depend on Shared Key and are rejected when Shared Key is disallowed. A Blob user-delegation SAS is authorized through Entra and can continue under documented conditions. Microsoft warns that logs and metrics do not always make SAS type easy to distinguish. It also documents compatibility issues: some Azure services and tools use Shared Key, and Azure Files requires careful identity and portal behavior review. Microsoft proposes detection, remediation, audit, and governance, including Azure Policy in audit before deny.\n\n## What the source does not establish\n\nDisabling Shared Key does not make all storage access least privilege, remove existing Entra role assignments, prevent anonymous access where separately enabled, or rotate data-encryption keys. A successful Entra request does not prove the identity has only necessary permissions. Metrics showing SAS use do not by themselves identify whether it is service, account, or user-delegation SAS.\n\n## Applicability questions\n\n- Which applications, scripts, users, managed identities, Azure services, and third parties call the account?\n\n- Do they use account keys, account SAS, service SAS, user-delegation SAS, Entra OAuth, anonymous access, SFTP local users, or SMB identity?\n\n- Does the account host Azure Files, and can each file-access and portal scenario use supported identity authorization?\n\n- Which callers can migrate, which need a separate account, and which are vendor-blocked?\n\n- Who can list account keys or change AllowSharedKeyAccess after enforcement?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\n- Inventory storage accounts and set the built-in policy to audit. Treat an unset property as allowing Shared Key, consistent with Microsoft’s documentation.\n\n- Use logs, metrics, code search, secret inventory, and application-owner interviews to identify authorization per caller. Validate ambiguous SAS traffic directly.\n\n- Migrate supported callers to managed identity or another Entra identity with narrow data-plane roles; use user-delegation SAS where appropriate.\n\n- Separate incompatible Azure Files or service dependencies rather than leaving a broad mixed-use account permanently exposed.\n\n- Set AllowSharedKeyAccess false in a pilot, monitor 403 failures, then move policy from audit to deny after successful migration.\n\n## Verification and evidence\n\n- Preserve caller inventory, authorization type, migration owner, RBAC assignments, exceptions, and approval.\n\n- Query the account property and prove it returns false after enforcement.\n\n- Demonstrate Entra-authorized test access succeeds while an account-key or service-SAS test is rejected.\n\n- Monitor policy compliance and failed authorization after rollout; investigate any reenablement.\n\n## Official references\n\n- [Prevent Shared Key authorization for an Azure Storage account](https://learn.microsoft.com/en-us/azure/storage/common/shared-key-authorization-prevent) — Microsoft" }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/azure-storage-shared-key-migration/", "url": "https://update.dsesecurity.com/updates/azure-storage-shared-key-migration/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-08-25" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/azure-storage-shared-key-migration/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Disable Azure Storage Shared Key only after every caller identifies itself", "item": "https://update.dsesecurity.com/updates/azure-storage-shared-key-migration/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/azure-storage-shared-key-migration/#article", "identifier": "https://update.dsesecurity.com/updates/azure-storage-shared-key-migration/", "url": "https://update.dsesecurity.com/updates/azure-storage-shared-key-migration/", "headline": "Disable Azure Storage Shared Key only after every caller identifies itself", "description": "Disallowing Shared Key rejects account-key and dependent SAS authorization while allowing supported Microsoft Entra authorization, so caller discovery…", "abstract": "Disallowing Shared Key rejects account-key and dependent SAS authorization while allowing supported Microsoft Entra authorization, so caller discovery and migration must precede enforcement.", "articleBody": "Bottom line: Azure Storage can reject requests authorized with the account key by setting AllowSharedKeyAccess to false. That blocks direct Shared Key use and Shared Key-backed service or account SAS. Supported Microsoft Entra authorization and Blob user-delegation SAS follow different paths. Discover every caller before enforcement or applications and Azure services may lose data access.\nSource fact: what Microsoft documents\nMicrosoft’s Shared Key prevention guide says a storage account permits Shared Key when AllowSharedKeyAccess is true or unset. When the property is false, requests authorized with the account key are rejected. Microsoft recommends Entra authorization where supported.\nThe source distinguishes SAS types. Account SAS and service SAS depend on Shared Key and are rejected when Shared Key is disallowed. A Blob user-delegation SAS is authorized through Entra and can continue under documented conditions. Microsoft warns that logs and metrics do not always make SAS type easy to distinguish. It also documents compatibility issues: some Azure services and tools use Shared Key, and Azure Files requires careful identity and portal behavior review. Microsoft proposes detection, remediation, audit, and governance, including Azure Policy in audit before deny.\nWhat the source does not establish\nDisabling Shared Key does not make all storage access least privilege, remove existing Entra role assignments, prevent anonymous access where separately enabled, or rotate data-encryption keys. A successful Entra request does not prove the identity has only necessary permissions. Metrics showing SAS use do not by themselves identify whether it is service, account, or user-delegation SAS.\nApplicability questions\n\nWhich applications, scripts, users, managed identities, Azure services, and third parties call the account?\nDo they use account keys, account SAS, service SAS, user-delegation SAS, Entra OAuth, anonymous access, SFTP local users, or SMB identity?\nDoes the account host Azure Files, and can each file-access and portal scenario use supported identity authorization?\nWhich callers can migrate, which need a separate account, and which are vendor-blocked?\nWho can list account keys or change AllowSharedKeyAccess after enforcement?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\n\nInventory storage accounts and set the built-in policy to audit. Treat an unset property as allowing Shared Key, consistent with Microsoft’s documentation.\nUse logs, metrics, code search, secret inventory, and application-owner interviews to identify authorization per caller. Validate ambiguous SAS traffic directly.\nMigrate supported callers to managed identity or another Entra identity with narrow data-plane roles; use user-delegation SAS where appropriate.\nSeparate incompatible Azure Files or service dependencies rather than leaving a broad mixed-use account permanently exposed.\nSet AllowSharedKeyAccess false in a pilot, monitor 403 failures, then move policy from audit to deny after successful migration.\n\nVerification and evidence\n\nPreserve caller inventory, authorization type, migration owner, RBAC assignments, exceptions, and approval.\nQuery the account property and prove it returns false after enforcement.\nDemonstrate Entra-authorized test access succeeds while an account-key or service-SAS test is rejected.\nMonitor policy compliance and failed authorization after rollout; investigate any reenablement.\n\nOfficial references\n\nPrevent Shared Key authorization for an Azure Storage account — Microsoft", "datePublished": "2026-08-25T21:34:58+00:00", "dateModified": "2026-08-25T21:43:55+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/azure-storage-shared-key-migration/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/azure-storage-shared-key-migration/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Disable Azure Storage Shared Key only after every caller identifies itself" }, "articleSection": [ "Cybersecurity", "IT", "Microsoft 365 & Identity" ], "keywords": [ "Cybersecurity", "IT", "Microsoft 365 & Identity", "Playbook", "Important priority" ], "genre": "Playbook", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "wordCount": 497, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Prevent Shared Key authorization for an Azure Storage account", "url": "https://learn.microsoft.com/en-us/azure/storage/common/shared-key-authorization-prevent" } } ] } }