Securing Azure is mostly about customer-side settings: an Owner role granted at subscription scope, a storage account that accepts anonymous or key-based requests, a virtual machine with RDP open to the internet, or a vault whose backups the attacker can delete. This list ranks the ten Azure resource misconfigurations that most often turn one stolen credential into data exposure or a destroyed environment, with how to check each one and how to fix it. Fixes reference Microsoft's own documentation and the Microsoft cloud security benchmark (MCSB). It is written for Azure platform engineers, cloud security teams and security leads. Microsoft 365 and Entra tenant settings are covered in the Top 10 Microsoft 365 Security Misconfigurations; the full Azure control set is in the Microsoft Azure Security Guide.
This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.
The Top 10 at a glance
| # | Misconfiguration | What it enables | Setting or service to check |
|---|---|---|---|
| 1 | Too many Owners and broad role scopes | One compromised account controls whole subscriptions | Azure RBAC role assignments, PIM |
| 2 | Service principals with secrets instead of managed identities | Long-lived credentials that leak and never expire | App registrations, managed identities |
| 3 | Anonymous blob access allowed | Data readable by anyone with the URL | AllowBlobPublicAccess |
| 4 | Shared Key and long-lived SAS tokens | Account-wide access that bypasses Entra ID and Conditional Access | AllowSharedKeyAccess, SAS expiration policy |
| 5 | RDP and SSH open to the internet | Brute force and exploitation of management ports | NSG inbound rules, Azure Bastion, just-in-time VM access |
| 6 | PaaS public endpoints open to all networks | Data services reachable from anywhere a key works | Public network access, firewall rules, private endpoints |
| 7 | Key Vault on legacy access policies or without purge protection | Privilege escalation to every secret; permanent key deletion | Permission model, purge protection |
| 8 | No diagnostic settings or log export | No evidence of data access or control-plane changes | Diagnostic settings, Activity log export |
| 9 | No guardrails: Azure Policy and Defender for Cloud unused | Every misconfiguration on this list comes back | Policy assignments, Defender plans, secure score |
| 10 | Backups an attacker can delete | Ransomware with no way back | Immutable vault, soft delete, multi-user authorisation |
The ranking is our judgement of how directly each setting leads to compromise or loss,. Items 1 and 2 come first because almost every Azure intrusion uses an identity; items 3 to 6 are how data leaves; items 7 to 10 decide whether you can see and recover.
1. Too many Owners and broad role scopes
The misconfiguration: Owner or Contributor granted to individuals at subscription or management group scope, permanent rather than eligible, plus custom roles that use wildcard actions.
Why it matters: an attacker who compromises any of these accounts can create resources, read data and grant themselves more roles (MITRE ATT&CK T1098.003 Additional Cloud Roles). Keep cloud administrator accounts separate from on-premises admin accounts, with phishing-resistant MFA on both.
How to check: list role assignments for Owner, Contributor, User Access Administrator and Role Based Access Control Administrator at management group and subscription scope, separating permanent from eligible assignments.
How to fix: Microsoft's Azure RBAC best practices recommend a maximum of three subscription Owners, assigning job function roles instead of privileged administrator roles, using the narrowest scope, assigning roles to groups rather than users, avoiding wildcards in custom roles, and using Privileged Identity Management for just-in-time access. Add conditions to roles that can create role assignments. See the Azure RBAC and Service Principals Guide and the Privileged Identity Management (PIM) Guide.
2. Service principals with secrets instead of managed identities
The misconfiguration: workloads that run in Azure authenticate with an app registration's client secret stored in configuration, often with a two-year expiry and Contributor rights, when a managed identity would do; pipelines that use stored secrets instead of workload identity federation.
Why it matters: client secrets leak through code, logs and build artefacts, and attackers add their own credentials to existing apps for persistence (T1098.001 Additional Cloud Credentials). Alert on new credentials added to existing apps and on new app role assignments.
How to check: inventory service principals holding Azure RBAC roles, their credential type, expiry, owner and last sign-in; search repositories and pipeline variables for client secrets.
How to fix: use system-assigned or user-assigned managed identities for Azure-hosted workloads and workload identity federation for CI/CD and external workloads; where a secret is unavoidable, use a certificate, keep lifetime short and store it in Key Vault. See the Azure Managed Identities Security Guide and How to replace Azure app secrets with federated credentials.
3. Anonymous blob access allowed
The misconfiguration: a storage account where anonymous access is permitted at account level and a container is set to the Container or Blob access level, usually for a website asset that later gained other files.
Why it matters: anyone who finds the URL can read or list the data with no credentials (T1530 Data from Cloud Storage, T1619 Cloud Storage Object Discovery).
How to check: query the AllowBlobPublicAccess property across subscriptions with Azure Resource Graph or Azure Policy, and review container access levels where it is true. Microsoft notes that anonymous access is prohibited by default for Azure Resource Manager storage accounts, so any account with it on was changed deliberately or is old.
How to fix: set AllowBlobPublicAccess to False on every account that does not serve public content, and enforce it with Azure Policy. Serve genuinely public content through a CDN or a dedicated account that holds nothing else. See the Azure Storage Security Guide.
4. Shared Key and long-lived SAS tokens
The misconfiguration: applications and people use storage account keys and account SAS tokens with long or no practical expiry; Shared Key authorisation is left enabled.
Why it matters: an account key grants full access to the account's data and is not subject to Entra ID Conditional Access. Microsoft documents that AllowSharedKeyAccess is not set by default and that requests authorised with Shared Key are permitted when it is null or true. Keep SAS tokens short-lived and narrowly scoped, and never commit them to a repository.
How to check: find accounts where AllowSharedKeyAccess is null or true; review storage logs for requests authorised with Shared Key or account SAS; check whether a SAS expiration policy is set.
How to fix: move clients to Entra ID authorisation, then set AllowSharedKeyAccess to false. Where a SAS is needed, Microsoft recommends a user delegation SAS, secured with Entra credentials instead of the account key. Configure a SAS expiration policy to recommend or enforce a maximum validity interval, and rotate account keys on a schedule while they still exist. See the Azure SAS Tokens Security Guide.
5. RDP and SSH open to the internet
The misconfiguration: network security group inbound rules that allow TCP 3389 or 22 from Any or the Internet service tag, often added "temporarily" during a build, on virtual machines with public IP addresses.
Why it matters: internet-exposed management ports are scanned within minutes and attacked with password spraying and exploits (T1133 External Remote Services, T1021.001 Remote Desktop Protocol). See the Exposed RDP Compromise Guide.
How to check: list NSG rules with source Any, 0.0.0.0/0 or Internet and destination port 22, 3389 or a range containing them; list VMs with public IP addresses.
How to fix: remove the rules and public IPs. Azure Bastion provides RDP and SSH to virtual machines over TLS on port 443 without the VM needing a public IP address, and Defender for Cloud's just-in-time VM access keeps deny rules on the chosen ports and opens them only for an approved user's IP address for a set time (availability: a Microsoft Defender for Servers Plan 2 feature). See Azure Bastion and the Azure Virtual Network Security Guide.
6. PaaS public endpoints open to all networks
The misconfiguration: storage, SQL, Cosmos DB, Key Vault and other PaaS services left with public network access enabled from all networks, relying on keys or passwords alone.
Why it matters: when a key or connection string leaks, nothing at the network layer stops its use from anywhere. Microsoft states that storage accounts allow connections from any network by default. Adding a private endpoint does not by itself close the public endpoint: Microsoft notes that private endpoints do not necessarily restrict public network access.
How to check: query publicNetworkAccess and network rule default actions across PaaS resources; for SQL, review server firewall rules that allow broad ranges or all Azure services.
How to fix: use private endpoints for data services reached from virtual networks, then disable public network access or set the firewall default to deny with only named virtual network, IP or resource instance rules. Enforce with Azure Policy. See the Azure SQL and Cosmos DB Security Guide.
7. Key Vault on legacy access policies or without purge protection
The misconfiguration: vaults still using the vault access policy permission model, with management-plane roles such as Key Vault Contributor granted widely; and vaults holding encryption keys without purge protection.
Why it matters: under the access policy model, a principal that can write the vault's configuration can grant itself data-plane access to every secret. Treat management-plane roles on such vaults as secret access. Without purge protection, an attacker with enough rights can permanently delete keys that encrypt your data (T1485 Data Destruction).
How to check: list vaults by permission model (enableRbacAuthorization), who holds Key Vault Contributor or Owner on them, and whether purge protection is enabled.
How to fix: migrate vaults to the Azure RBAC permission model with data-plane roles such as Key Vault Secrets User granted per vault, restrict management roles, enable purge protection on vaults holding keys (Microsoft notes soft delete is on by default for new vaults and cannot be disabled once enabled, while purge protection is optional and not enabled by default), and restrict network access. See the Azure Key Vault Security Guide.
8. No diagnostic settings or log export
The misconfiguration: resource logs (storage reads, Key Vault access, SQL audit, NSG flow data) never enabled because each needs a diagnostic setting; the subscription Activity log not exported, so it is kept only for its default retention.
Why it matters: without resource logs you cannot tell which blobs or secrets were read after a key leak, and without exported control-plane logs a slow intrusion outlives its evidence. Attackers who reach Owner can also remove diagnostic settings (T1685 Disable or Modify Tools).
How to check: report resources without diagnostic settings, and confirm the Activity log for every subscription is sent to a Log Analytics workspace or SIEM.
How to fix: deploy diagnostic settings at scale with Azure Policy (DeployIfNotExists), export the Activity log for every subscription, and alert on deletion of diagnostic settings. See the Azure Monitor, Activity Log and Diagnostic Settings Guide.
9. No guardrails: Azure Policy and Defender for Cloud unused
The misconfiguration: fixes applied by hand with no Azure Policy assignments to prevent regression; Defender for Cloud running only free posture management with recommendations unread; new subscriptions created outside the management group hierarchy.
Why it matters: manual fixes drift back within months, and subscriptions outside the hierarchy inherit none of your controls.
How to check: review policy assignments and compliance at the root management group, secure score trends, enabled Defender plans, and subscriptions outside the intended hierarchy.
How to fix: assign the MCSB initiative and deny or modify policies for items 3 to 8 at management group scope, start in audit effect, then move to deny once exceptions are known. Place every subscription in the landing zone hierarchy. See the Azure Policy and Management Groups Guide and the Azure Landing Zones Security Guide.
10. Backups an attacker can delete
The misconfiguration: Recovery Services vaults in the same subscription and administered by the same accounts as production, without immutability, with soft delete weakened, and with no second approval for destructive operations.
Why it matters: ransomware operators delete or disable backups before encrypting (T1490 Inhibit System Recovery).
How to check: for each vault, check immutability state (enabled or locked), soft delete settings, whether multi-user authorisation with a Resource Guard is configured, and who holds Backup Contributor or Owner.
How to fix: Microsoft describes an immutable vault that blocks operations that could lead to loss of recovery points and can be locked to make the setting irreversible; multi-user authorisation uses a Resource Guard, ideally in a separate subscription or tenant, so critical operations need a second authorised person. Soft delete keeps deleted backup data recoverable. Test restores. See the Azure Backup and Recovery Services Vault Security Guide and the Top 10 Backup and Recovery Mistakes.
Detection: what to alert on
| Activity log or resource log operation | Misconfiguration it exposes |
|---|---|
| Microsoft.Authorization/roleAssignments/write at subscription or management group scope | 1 |
| Add service principal credentials; Update application (certificates and secrets) in Entra audit logs | 2 |
| Microsoft.Storage/storageAccounts/write changing allowBlobPublicAccess, allowSharedKeyAccess or network rules | 3, 4, 6 |
| Microsoft.Storage/storageAccounts/listKeys/action by an unusual principal | 4 |
| Microsoft.Network/networkSecurityGroups/securityRules/write with source Any or Internet | 5 |
| Microsoft.KeyVault/vaults/write (access policy or network changes); SecretGet bursts in Key Vault logs | 7 |
| Microsoft.Insights/diagnosticSettings/delete | 8 |
| Microsoft.Authorization/policyAssignments/delete or exemptions/write | 9 |
| Backup item stop protection with delete data; vault immutability or soft delete changes | 10 |
Measure progress with five numbers: subscriptions with more than three Owners; service principals with secrets that hold Azure roles; storage accounts with anonymous access or Shared Key enabled; NSG rules exposing 22 or 3389 to the internet (target zero); and percentage of Tier 1 vaults immutable and locked with multi-user authorisation.
Common failure patterns
- Fixing the portal default, not the estate: new storage accounts are secure by default, but old accounts and those created by templates from years ago keep their old settings. Query, do not assume.
- Private endpoint added, public endpoint left open: the network diagram shows private access while the public endpoint still accepts traffic.
- Rotating the key but keeping Shared Key on: the next key leaks the same way. Remove the key path, not just the key.
- Policies stuck in audit: the compliance dashboard is red for a year and nothing is denied.
- Backups in the blast radius: the account that owns production also owns the backup vault and the Resource Guard, so one compromise removes both.
Mapping to ATT&CK and NIST
| Item | MITRE ATT&CK | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|---|
| 1. Owners and scopes | T1098.003, T1078.004 | AC-6, AC-2 | PR.AA-05 |
| 2. Service principal secrets | T1098.001, T1552.001 | IA-5, AC-2 | PR.AA-01 |
| 3. Anonymous blob access | T1530, T1619 | AC-3, AC-21 | PR.DS-01 |
| 4. Shared Key and SAS | T1530 | IA-5, AC-3 | PR.AA-05 |
| 5. Open RDP and SSH | T1133, T1021.001 | SC-7, AC-17 | PR.IR-01 |
| 6. Public PaaS endpoints | T1190, T1530 | SC-7 | PR.IR-01 |
| 7. Key Vault model and purge protection | T1485 | SC-12, AC-6 | PR.DS-01 |
| 8. Logging | T1685 | AU-2, AU-12 | PR.PS-04, DE.CM-09 |
| 9. Guardrails | All of the above | CM-6, CM-7, CA-7 | PR.PS-01 |
| 10. Deletable backups | T1490 | CP-9 | PR.DS-11 |
Where to start
- Week one: run Azure Resource Graph queries or Defender for Cloud recommendations across all subscriptions for items 3, 4, 5 and 7, read-only, and record the baseline.
- Week one: close internet-facing 3389 and 22 rules (item 5) and anonymous blob access on accounts that do not serve public content (item 3).
- Weeks two to four: cut subscription Owners to three or fewer, move the rest to eligible PIM assignments, and inventory service principals with secrets (items 1 and 2).
- Month two: lock down backup vaults with immutability and multi-user authorisation, migrate Key Vaults to the RBAC model with purge protection, and roll out diagnostic settings by policy (items 7, 8, 10).
- Month three: remove Shared Key and close PaaS public endpoints service by service (items 4 and 6), then switch the matching policies from audit to deny (item 9).
- Roll back safely: change one setting per resource group at a time, watch application logs for authorisation failures, and revert by policy exemption with an expiry rather than by removing the policy.
Practitioner checklist
- No more than three Owners per subscription; privileged roles eligible through PIM; no wildcard custom roles.
- Azure-hosted workloads use managed identities; pipelines use workload identity federation.
- AllowBlobPublicAccess false on every account except dedicated public-content accounts.
- Shared Key disabled where clients support Entra ID; SAS expiration policy set; user delegation SAS preferred.
- No NSG rule allows 22 or 3389 from the internet; Bastion or just-in-time access in place.
- Data services on private endpoints with public network access disabled or default deny.
- Key Vaults on the RBAC permission model with purge protection where keys are held.
- Diagnostic settings deployed by policy; Activity log exported for every subscription.
- MCSB initiative assigned at the root management group; key policies in deny effect.
- Backup vaults immutable and locked, soft delete on, multi-user authorisation configured, restores tested.
Standards and references
- Microsoft Learn: Microsoft cloud security benchmark
- Microsoft Learn: Best practices for Azure RBAC
- Microsoft Learn: Remediate anonymous read access to blob data
- Microsoft Learn: Prevent Shared Key authorization for an Azure Storage account
- Microsoft Learn: Configure an expiration policy for shared access signatures
- Microsoft Learn: What is Azure Bastion?
- Microsoft Learn: Immutable vault for Azure Backup
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Microsoft Azure Security Guide · Azure Security Checklist · Azure Subscription Compromise Playbook · Azure Managed Identities Security Guide · Top 10 Microsoft 365 Security Misconfigurations