Azure Key Vault’s limits for secrets, keys, and certificates

At a glance

What this is: This is an analysis of Azure Key Vault as a unified store for secrets, keys, and certificates, with the central finding that its governance model can become too broad for some IAM and NHI use cases.

Why it matters: It matters because IAM and NHI practitioners need to know when a native cloud vault is enough, and when object-level access, rotation workflows, and multi-environment governance need a different control model.

Context

Azure Key Vault is Microsoft’s native service for storing secrets, keys, and certificates, and that consolidation is the article’s main governance question. The issue is not whether the service works inside Azure, but how far one access model and one audit trail can stretch before object scoping, rotation, and environment separation become separate design problems.

For IAM and NHI programmes, the practical gap is between centralisation and control. A vault can reduce secret sprawl, yet still leave teams with broad vault-level access, separate workflows for keys versus secrets, and manual rotation work when the environment extends beyond Azure or requires more than native patterns.

The article also distinguishes native convenience from operational completeness. Key Vault fits well when workloads stay in Azure and object ownership is simple, but the model becomes harder to govern when teams need finer-grained entitlements, repeatable automation, or a multi-cloud control layer.

Key questions

Q: When does Azure Key Vault access become too broad for least privilege?

A: Access becomes too broad when a single assignment exposes an entire vault instead of the one object a workload actually needs. That usually happens with legacy access policies or careless RBAC scoping. Teams should treat object-level boundaries as the default and only broaden scope when the operational need is explicit and defensible.

Q: Why do managed identities reduce secrets risk in Azure workloads?

A: Managed identities reduce risk because the workload authenticates to Entra ID without storing a client secret or certificate in code, a pipeline, or a manifest. That removes the bootstrap credential and makes compromise harder to translate into persistent access. The remaining control problem is authorisation scope, not initial authentication.

Q: What breaks when secrets rotation is left to manual processes?

A: Manual rotation breaks consistency, timing, and downstream updates. Secrets can expire or be replaced in the vault, but applications and pipelines do not update themselves, so teams end up with stale credentials, hidden outages, or delayed revocation after exposure. The control failure is lifecycle orchestration, not storage.

Q: How should security teams compare Azure Key Vault alternatives for secrets governance?

A: Security teams should compare alternatives by lifecycle coverage, not just storage and encryption features. The decisive questions are whether the platform can issue, rotate, audit, and revoke secrets across applications, vendors, and workloads without creating duplicate stores or manual exceptions. If those workflows are fragmented, the organisation is buying convenience, not governance.

Technical breakdown

Vault-level access vs object-scoped RBAC

Azure Key Vault supports two access models, but they do not create the same governance outcome. Access policies work at the vault level, so anyone who needs one secret can inherit broad visibility across the vault. Azure RBAC improves that by allowing object-level scoping, which lets a workload read one secret, use one key, or access one certificate without inheriting unrelated objects. That distinction matters because Key Vault stores multiple asset types behind one interface, but the security requirement is usually specific to a single object. The article’s technical point is that consolidation does not remove the need for least privilege; it changes where privilege has to be enforced.

Practical implication: Use object-scoped RBAC for Key Vault access and reserve vault-level access only for narrow legacy cases.

Managed identities and the secret zero problem

Managed identities let Azure resources authenticate to Key Vault without storing a bootstrap secret in code, configuration, or a pipeline. The resource obtains a token from Entra ID, then Key Vault authorises the request based on RBAC and object scope. That removes the secret zero problem, meaning the initial credential needed to access the system that holds other credentials. This is especially important for service-to-service access, Kubernetes workloads, and DevOps integrations, where a static client secret often becomes the weakest part of the chain. The model is stronger operationally because it separates workload identity from stored credentials.

Practical implication: Prefer managed identities wherever Azure services need to read Key Vault objects.

Why rotation is different for secrets, keys, and certificates

The three object types in Key Vault share a surface area, but not the same lifecycle tooling. Keys and certificates can use built-in rotation policies and renewal workflows, while secrets have no native rotation engine that updates downstream systems automatically. That forces teams to build their own automation, often with Azure Functions or Event Grid, if they want expiry and replacement to happen without manual intervention. The article also highlights that secrets can be expiring objects, but expiry alone does not equal rotation. In governance terms, the vault can store the secret, yet the surrounding lifecycle remains a separate control problem.

Practical implication: Design an external rotation workflow for secrets before the credential estate becomes too large to retrofit.

Threat narrative

Attacker objective: The objective is to turn one authorised foothold into access to a much larger set of secrets, keys, and certificates than the workload should have been able to reach.

1. Entry occurs through overly broad Key Vault access, especially where a vault-level policy or over-scoped role lets one workload or contractor see more than its needed object set.
2. Credential access then expands because the same principal can retrieve unrelated secrets, keys, or certificates once it has access to the vault or an overly permissive scope.
3. Escalation follows when access to one credential type reveals additional operational trust paths, such as signing keys, deployment tokens, or downstream service credentials.
4. Impact is a widened blast radius, where compromise of one workload or identity can expose multiple sensitive objects rather than the single item the workload actually needed.

Breaches seen in the wild

• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Azure Key Vault’s biggest governance challenge is not storage, it is scope. When secrets, keys, and certificates live behind one service, the control question shifts from where the data is stored to how precisely access is bounded. Vault-level permissions flatten that distinction and make least privilege much harder to maintain. The practitioner implication is that consolidation only helps if entitlement boundaries remain narrow enough to preserve object-level accountability.

Rotation asymmetry creates a hidden lifecycle gap. Keys and certificates can be rotated with built-in policy, but secrets still depend on external orchestration. That means a unified vault can look complete while leaving the most common credential class on a separate operational track. The implication is that teams need to treat secret rotation as a governed workflow, not as a feature inherited from the vault.

Managed identity removes secret zero, but not governance responsibility. Using managed identities avoids hardcoded bootstrap credentials, yet the underlying problem moves to how roles are assigned, how objects are scoped, and how downstream access is audited. Identity teams should read this as a reminder that authentication quality and authorisation quality are different controls. The practical conclusion is to govern workload identity separately from object entitlements.

Object consolidation is helpful inside Azure, but it becomes a control boundary outside Azure. The article makes clear that native convenience does not scale cleanly across AWS, GCP, and on-premises environments. Once the estate spans multiple platforms, separate access models and audit views reappear, and homegrown glue becomes part of the risk. The implication is that platform-native vaults remain useful, but they are not automatically a complete governance architecture.

Centralised vaulting can reduce sprawl while increasing blast radius if teams stop at platform convenience. The deeper issue is not whether a vault exists, but whether the operating model keeps pace with object type, environment, and lifecycle differences. Practitioners should treat Key Vault as one layer in a broader identity and secrets control stack, not as a substitute for it.

From our research library:

• Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
• 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to the 2024 State of Secrets Management Survey.
• Read next: Secrets Management Buyer's Guide

What this signals

Object scope is the real control boundary: Key Vault can centralise sensitive material, but broad vault-level access still turns one workload into a path to many credentials. Teams should review whether their role model protects individual secrets, keys, and certificates rather than the vault as a whole.

Rotation design has to be planned outside the vault: the service can support expiry and renewal for keys and certificates, but secrets still need an orchestration path that updates dependent systems. That makes lifecycle governance a programme decision, not a vault setting.

For practitioners

• Use object-scoped Azure RBAC Grant each workload the narrowest Key Vault role for the exact secret, key, or certificate it uses, rather than assigning vault-wide access.
• Replace client secrets with managed identities Use managed identities for Azure-to-Azure authentication so workloads do not need bootstrap credentials to reach the vault.
• Build a secrets rotation workflow Create an automated path for secret replacement, downstream updates, and expiry handling because Key Vault does not provide native secrets rotation.
• Separate configuration from secrets Keep non-sensitive settings in Azure App Configuration and reserve Key Vault for credentials, keys, and certificates so the vault stays focused on sensitive objects.

Key takeaways

• Azure Key Vault simplifies storage, but the governance problem shifts to how narrowly access is scoped across different object types.
• The article’s core risk is blast-radius expansion when teams rely on vault-level access or leave secrets rotation to manual work.
• IAM and NHI teams should treat managed identities, object-level RBAC, and external rotation workflows as separate controls, not as features bundled into one service.

Key terms

• Azure Key Vault: Azure Key Vault is a secret management service for storing credentials, API keys, certificates, and other sensitive material. It centralizes access to secrets and works best when paired with managed identities, so applications can retrieve what they need at runtime without hard-coding sensitive values in source files or configuration.
• Managed Identity: A cloud-provider-managed identity assigned to a compute resource, allowing it to authenticate to cloud services without storing credentials in application code.
• Secret Zero: Secret zero is the first credential needed to reach a secrets store, identity broker, or protected system. It is the root trust dependency that often survives even when everything else is rotated. If that initial credential is exposed, the rest of the secret model can collapse very quickly.
• Tool-Level Scoping: Tool-level scoping limits an AI agent or client to specific functions rather than broad system access. It is a practical control for MCP and agentic identity because it reduces overreach, supports least privilege, and makes consent and audit logs more precise when an autonomous system calls external tools.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.