Notifications
Clear all
Topic starter
08/07/2026 6:55 pm
TL;DR: Azure Key Vault centralises secrets, keys, and certificates behind one access model, but its access-policy history, object-scoping choices, and rotation gaps can widen blast radius or add automation burden, according to Infisical. For IAM and NHI teams, the real decision is not whether Key Vault works in Azure, but where its governance model stops being sufficient.
NHIMG editorial — based on content published by Infisical: Azure Key Vault and secrets management guide
By the numbers:
- 73% of organizations now run a hybrid cloud setup.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Separate secrets rotation from certificate rotation Treat secrets as a custom renewal workflow and certificates or keys as platform-managed lifecycles.
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
👉 Read Infisical's complete guide to Azure Key Vault and secrets management →
Azure Key Vault governance gaps: what IAM teams should review?
Explore further
08/07/2026 7:17 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Azure Key Vault’s limits for secrets, keys, and certificates
