In December 2024, Datadog Security Labs showed that Azure's built-in Key Vault Contributor role, which Microsoft's documentation said "does not allow you to access secrets, keys, or certificates", could in fact read every secret in many key vaults. The role includes the Microsoft.KeyVault/vaults/write permission, and on key vaults that use the older access policy permission model, that permission lets a holder add themselves to the vault's access policy with full rights. Anyone with the role, or an attacker who compromised an account holding it, could then read the API keys, passwords, storage SAS tokens and certificates the vault protects. Microsoft said the behaviour "is not a vulnerability", updated its documentation to warn that such users "can grant themselves data plane access", and recommends the RBAC permission model instead. No exploitation in the wild has been reported.
Key takeaways
- Datadog found that the Key Vault Contributor role could grant itself access to all secrets, keys and certificates in key vaults using access policies, contrary to the role's documentation at the time.
- The escalation works through the vaults/write permission, which allows editing access policies, the legacy way Key Vault controls data access.
- Microsoft said this "is not a vulnerability" but updated its docs within a week of the report and recommends the Azure RBAC permission model.
- This was research, not a breach; no real-world exploitation has been reported.
- The identity lesson: a secrets store is only as safe as every role that can change who reads it, and management permissions can quietly become data permissions.
At a glance
| Organisations | Microsoft Azure (Key Vault); Azure customers using key vaults with the access policy permission model |
|---|---|
| When | Reported to Microsoft 25 October 2024; documentation updated 31 October 2024; published by Datadog 16 December 2024 |
| Attacker | None known. Found by Katie Knowles of Datadog Security Labs |
| Entry point | An account holding the Key Vault Contributor role, or any role with Microsoft.KeyVault/vaults/write, over a key vault that uses access policies |
| Identities abused | Key Vault access policies; the secrets, keys, SAS tokens and certificates stored in affected vaults |
| Impact | Potential read and modify access to all data in affected key vaults; no confirmed real-world victims |
| Category | NHI. Incident class: vulnerability found by researchers (vulnerability, no confirmed breach) |
What happened
Azure Key Vault can control access to its data in two ways: Azure role-based access control (RBAC), or the older Key Vault access policies. Microsoft's built-in role documentation said the Key Vault Contributor role could "manage key vaults, but does not allow you to assign roles in Azure RBAC, and does not allow you to access secrets, keys, or certificates." Datadog's researchers asked whether "manage key vaults" included editing access policies.
It did. A test user with only the Key Vault Contributor role had no direct access to data in a vault configured with access policies, but could view and add to those policies, including granting itself permission to list, read and update everything in the vault. "Users with the Key Vault Contributor role can escalate their privileges to read and modify Key Vault contents for any key vault that uses access policies as the access control mechanism," Datadog wrote. In its example, an attacker who phished a systems administrator with this role could add themselves to a key vault's access policy and read an application's API key. Datadog noted that vault contents "commonly" include API keys, passwords, Azure Storage SAS tokens and authentication certificates.
Datadog reported the issue to Microsoft's Security Response Center on 25 October 2024. Microsoft updated the role's documentation on 31 October, and on 11 November said the configuration "is not a vulnerability" because "key vault contributors have the ability to manage the key vault access policies." Microsoft's current guidance says: "With the Access Policy permission model, users with the Contributor, Key Vault Contributor, or any role that includes Microsoft.KeyVault/vaults/write permissions can grant themselves data plane access by configuring a Key Vault access policy." It recommends the RBAC model, which "restricts permission management to only the 'Owner' and 'User Access Administrator' roles." Datadog published its research on 16 December 2024.
Timeline
| Date | Event |
|---|---|
| 25 October 2024 | Datadog reports the behaviour to Microsoft's Security Response Center. |
| 31 October 2024 | Microsoft updates the Key Vault Contributor documentation with a warning about access policies. |
| 11 November 2024 | Microsoft responds that the configuration "is not a vulnerability". |
| 16 December 2024 | Datadog Security Labs publishes its research. |
How it happened: the identity attack path
- Management role assigned. A user or service principal holds Key Vault Contributor, believed not to grant data access.
- Account compromised. In Datadog's scenario, an attacker phishes the account and takes over its session.
- Access policy edited. Using vaults/write, the attacker adds themselves to the vault's access policy with full permissions.
- Secrets read. The attacker lists and reads secrets, keys and certificates, such as application API keys.
- Onward access. Stolen secrets give access to the applications and services they protect.
Impact
- Potential: any key vault using access policies could be read by holders of Key Vault Contributor or Contributor roles.
- Confirmed exploitation: none reported.
- Change: Microsoft documentation now warns of the risk and recommends RBAC.
What this means for NHI governance
Secrets vaults hold the credentials of other non-human identities: API keys, service passwords, SAS tokens and certificates. The access model around the vault therefore decides who can become every one of those identities. Here, a role granted to manage vaults, often to operations teams and automation, could quietly grant itself read access, and administrators relying on the documentation would not have known.
The fix is structural. Moving vaults to the RBAC permission model separates managing a vault from reading its contents. Reviewing who holds Contributor-type roles over vaults, monitoring access policy changes and rotating secrets in vaults where unexpected policy entries appear closes the gap for vaults that cannot move yet. See our Secrets Management Guide and Cloud PAM and CIEM Guide.
Recommendations
- Move key vaults to the Azure RBAC permission model. Microsoft recommends it; only Owner and User Access Administrator can then change permissions. See our Secrets Management Guide.
- Review who holds Contributor and Key Vault Contributor over vaults. Treat these roles as able to read secrets where access policies are still used. See the Cloud PAM and CIEM Guide.
- Alert on access policy changes. Any new entry in a vault's access policy should be reviewed.
- Enable Key Vault diagnostic logging. Logs show which secrets were read, so you know what to rotate.
- Rotate secrets after unexpected policy changes. See the Leaked Credential Response Playbook.
Frequently asked questions
Can the Key Vault Contributor role read secrets?
On key vaults that use access policies, yes. The role can edit access policies and grant itself read access to secrets, keys and certificates. On vaults using the Azure RBAC model it cannot.
Did Microsoft fix the Key Vault Contributor issue?
Microsoft said it is not a vulnerability because the role is meant to manage access policies. It updated its documentation to warn about the risk and recommends switching to the RBAC permission model.
Was this exploited in the wild?
No exploitation has been reported. It is a research finding by Datadog Security Labs.
Related NHI Mgmt Group resources
Microsoft SAS Token Exposure · Storm-2949 Azure Breach · Secrets Management Guide · Cloud PAM and CIEM Guide · Active Directory and Entra ID Hardening Guide
How NHI Mgmt Group can help
Secrets stores are only as strong as the permissions around them. We help teams review vault access models, find roles that can escalate to secrets and plan migrations to safer permission models. See our NHI and AI agent security training.
References
- Datadog Security Labs (Katie Knowles): Escalating privileges to read secrets with Azure Key Vault access policies (16 December 2024)
- Microsoft Learn: Azure role-based access control (Azure RBAC) vs. access policies, current version (24 March 2026)
- Microsoft Learn: Azure built-in roles for Security, current version (1 July 2026)