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

At a glance

What this is: This is a guide to Azure Key Vault’s architecture, access model, and operational limits for storing secrets, keys, and certificates.

Why it matters: It matters because IAM and NHI teams need to know where native cloud vault controls help, where they create blast-radius risk, and when cross-platform governance becomes necessary.

By the numbers:

• 73% of organizations now run a hybrid cloud setup.

👉 Read Infisical's complete guide to Azure Key Vault and secrets management

Context

Azure Key Vault is often treated as the default answer for Azure-native secrets management, but the more useful question is where that default fits and where it does not. The key governance issue is not storage alone, but how access, rotation, and object scope behave once secrets, keys, and certificates start supporting real workloads.

For identity teams, Key Vault sits squarely in NHI governance because it manages the credentials and cryptographic objects that applications, pipelines, and managed identities rely on at runtime. The article’s core message is that native integration reduces friction inside Azure, while the access model and lifecycle choices still need deliberate control design.

The distinction matters most when organisations operate beyond a single cloud. A vault that looks complete in one environment can create fragmentation elsewhere, which is why lifecycle and access governance have to be designed around the full estate, not just the platform default.

Key questions

Q: How should security teams govern Azure Key Vault access for applications?

A: Security teams should scope access to the specific object a workload needs and avoid granting vault-wide visibility by default. Azure RBAC is the better fit for least privilege because it can limit access to one secret, key, or certificate. That reduces blast radius and makes access reviews more meaningful.

Q: Why do managed identities matter for Key Vault integrations?

A: Managed identities remove the need to store a bootstrap credential for Azure-to-Azure access. That matters because the secret zero problem often becomes the first governance failure in pipelines, Kubernetes workloads, and app services. When authentication is built into the platform, teams reduce manual secret handling and lower exposure.

Q: When does Azure Key Vault become insufficient on its own?

A: Key Vault becomes insufficient when governance must span multiple clouds or on-premises systems. Native Azure integration works well inside the platform, but it does not solve cross-environment consistency for access models, rotation workflows, or audit views. At that point, teams need a broader secrets and identity governance layer.

Q: What should teams review before relying on Key Vault for rotation?

A: Teams should review how each object type is rotated and who owns the downstream update path. Certificates and keys can lean on platform support, but secrets often require separate automation to regenerate and distribute the new value. Without that workflow, rotation exists in policy but not in practice.

Technical breakdown

How Azure Key Vault separates secrets, keys, and certificates

Azure Key Vault combines three different identity security primitives behind one service: secrets, cryptographic keys, and certificates. That consolidation reduces platform sprawl, but the objects are not interchangeable. Secrets are runtime credentials, keys are used for signing or encryption without exposing private material, and certificates combine trust material with lifecycle handling. The operational model differs for each, which is why a single vault can still need different ownership, review cadence, and downstream integration patterns. The architecture is convenient, but governance has to stay object-aware rather than vault-aware.

Practical implication: scope ownership and access by object type, not by vault-wide convenience.

Azure RBAC versus access policies for least privilege

The access model is the article’s most important control point. Legacy access policies grant broad vault-level access, which can expose more secrets than a workload needs and directly expand blast radius. Azure RBAC improves that by allowing object-level permissions for secrets, keys, and certificates, so a workload can be limited to the exact object it touches. In practice, the difference is not cosmetic. Vault-level access turns every request into a potential privilege escalation path, while object-level scoping keeps authorisation aligned to actual runtime need.

Practical implication: default to Azure RBAC and avoid vault-level permissions except where legacy constraints force them.

Managed identities, secret zero, and Key Vault automation limits

Managed identities solve the secret zero problem by letting Azure resources authenticate without storing a bootstrap secret or certificate in code or configuration. That is a strong fit for Azure-to-Azure access, including Kubernetes and pipeline integrations. But the automation story differs by object type. Certificates and keys can use built-in lifecycle handling, while secrets often require custom rotation logic, typically through functions or other orchestration. That means the vault can remove one class of bootstrap risk while still leaving operational work around renewal, syncing, and downstream update choreography.

Practical implication: use managed identities wherever possible, then design a separate rotation path for long-lived secrets.

NHI Mgmt Group analysis

Azure Key Vault is an NHI control plane, not just a storage service. The article makes clear that the real security value sits in the access model, object scoping, and lifecycle handling around runtime credentials. That places Key Vault in the same governance category as other NHI systems, where the question is how access is bounded and audited rather than where the bytes are stored. Practitioners should treat the vault as part of identity architecture, not as a passive repository.

Vault-level access is a blast-radius problem dressed up as convenience. Access policies that grant a requester the whole vault assume the workload needs broad visibility just to reach one object. That assumption breaks least privilege at the identity layer and turns a single compromised workload into a wider credential-exposure event. The practitioner takeaway is to recognise object scope as a governance boundary, not an implementation detail.

Secret rotation remains the operational weak point because the platform does not close the loop for you. Certificates and keys have built-in lifecycle support, but secrets often still depend on external automation to renew and propagate changes. That leaves organisations with a split governance model in which some NHI objects are lifecycle-managed natively and others are only partially automated. The implication is that mature teams need to classify credential types by renewal mechanism before they can claim consistent control.

Multi-cloud reality turns native vault convenience into governance fragmentation. The article’s own 73% hybrid-cloud figure is the key signal: once workloads span clouds or on-premises, platform-native vault controls stop being sufficient as a single operating model. That does not make Azure Key Vault weak, but it does make single-cloud assumptions brittle. Practitioners should expect cross-environment identity governance to require a separate abstraction layer.

Identity lifecycle discipline is the missing connective tissue between storage and control. Key Vault works best when provisioning, rotation, expiry, and offboarding are treated as one lifecycle rather than separate tasks. The moment teams manage secrets in one process, certificates in another, and keys somewhere else, they create blind spots in ownership and review. The practical conclusion is that lifecycle governance has to be applied consistently across all three object classes.

From our research:

• 69% of organisations now have more machine identities than human ones, according to The Critical Gaps in Machine Identity Management report.
• Only 38% have automated certificate lifecycle management in place, which leaves most teams dependent on manual renewal and tracking.
• For lifecycle discipline across identities, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Identity teams should expect cloud-native vaults to remain necessary but not sufficient. As hybrid estates keep growing, the governance problem shifts from choosing a vault to standardising access, lifecycle, and audit behaviour across environments. The practical benchmark is whether the same entitlement logic can survive beyond one cloud’s default model.

Secret zero controls will keep moving closer to platform identity. Managed identities and workload identity patterns are becoming the baseline for Azure access because they remove bootstrap secrets from code and pipelines. Teams that still rely on embedded credentials should treat that as a migration debt, not a stable operating model.

Secrets, keys, and certificates should be governed as one lifecycle family. The operational risk is not only leakage, but uneven renewal maturity across object types. Teams that align object ownership and lifecycle review to the OWASP Non-Human Identity Top 10 will usually spot the control gaps faster than teams managing each credential class in isolation.

For practitioners

• Use Azure RBAC for all new vaults Assign permissions at the object level so a workload gets access to only the specific secret, key, or certificate it needs. Reserve access policies for the narrow legacy cases where Azure DevOps or private-endpoint constraints still require them.
• Replace bootstrap secrets with managed identities Use managed identities for Azure-to-Azure authentication so you do not create a secret zero problem in VMs, App Service, AKS, or pipeline integrations. This removes a stored bootstrap credential and simplifies renewal.
• Separate secrets rotation from certificate rotation Treat secrets as a custom renewal workflow and certificates or keys as platform-managed lifecycles. Build the automation before you accumulate long-lived credentials, because retrofitting renewal after scale is where drift usually appears.
• Keep configuration out of the vault Use App Configuration for endpoints, flags, and other non-sensitive settings, and keep Key Vault focused on secrets, keys, and certificates. This reduces accidental overuse of the vault and makes auditing clearer.
• Plan for multi-cloud identity governance early If any workload may move beyond Azure, define how secrets, keys, certificates, and audit views will be governed across platforms before teams standardise on the native vault model. Hybrid estates need a shared control approach, not parallel one-off patterns.

Key takeaways

• Azure Key Vault reduces secret sprawl inside Azure, but its governance value depends on object-level access and lifecycle discipline.
• Broad vault access, uneven rotation automation, and multi-cloud fragmentation are the main reasons native vault controls stop short of full NHI governance.
• Teams should pair managed identities, Azure RBAC, and explicit renewal workflows if they want Azure Key Vault to support a durable identity programme.

Key terms

• Azure RBAC for Key Vault: Azure role-based access control for Key Vault is the permission model that assigns access at the object level rather than exposing the whole vault. It supports tighter least privilege by separating secrets, keys, and certificates into distinct authorisation boundaries that can be reviewed and revoked independently.
• Managed identity: A managed identity is an Entra ID identity that Azure creates and rotates for a resource such as a VM, App Service, or Kubernetes workload. It lets the workload authenticate without storing a bootstrap secret, which reduces secret zero exposure and simplifies service-to-service access.
• Secret zero: Secret zero is the bootstrap credential problem that appears when a system must use a secret to retrieve or manage other secrets. It is a common identity failure mode because it forces teams to protect a credential that exists only to authenticate the mechanism meant to eliminate credentials.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• CLI examples for creating, reading, and managing secrets, keys, and certificates in Azure Key Vault
• Azure DevOps variable group configuration for pulling secrets at pipeline runtime
• Terraform resource patterns for key vault objects and the state-file caveats that come with them
• Practical integration notes for AKS, External Secrets Operator, and the Secrets Store CSI Driver

👉 Infisical's full guide covers the CLI, Terraform, AKS, and Azure DevOps implementation details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.