2.1.3.4. Design for Secrets, Certificates, and Keys (Azure Key Vault)
2.1.3.4. Design for Secrets, Certificates, and Keys (Azure Key Vault)
💡 First Principle: A secret is only as safe as the most privileged path to it, so the design has to settle three things together: how strongly the key material is protected, who can grant access to it, and what happens when it expires or is deleted.
Scenario: You are designing encryption for a regulated workload. Azure Storage uses customer-managed keys that must live in hardware security modules, the application reads database credentials and a TLS certificate, and auditors want proof that vault administrators cannot quietly give themselves access to production secrets.
Azure Key Vault offers two container types: vaults (Standard and Premium tiers), which store keys, secrets and certificates, and Managed HSM pools, which store HSM-backed keys only.
Choosing the container:
| Key Vault Standard | Key Vault Premium | Managed HSM | |
|---|---|---|---|
| Stores | Keys, secrets, certificates | Keys, secrets, certificates | Keys only |
| Key protection | Software-protected (FIPS 140-2 Level 1) | Software-protected or HSM-protected; new HSM key versions use FIPS 140-3 Level 3 validated HSMs | HSM-protected, FIPS 140-3 Level 3 validated |
| Tenancy | Multitenant | Multitenant | Single-tenant, isolated by a customer-specific security domain |
| Data-plane authorization | Azure RBAC (recommended) or access policies | Azure RBAC (recommended) or access policies | Managed HSM local RBAC |
| Choose it when | App secrets and certificates, no HSM mandate | Customer-managed keys must be HSM-protected, alongside secrets and certificates | A dedicated HSM is mandated, or key administrators must be isolated from subscription roles |
Microsoft describes vaults as the low-cost, multitenant option suitable for most scenarios, and Managed HSM as the choice for high-value keys and the strictest compliance requirements (About keys).
Authorization: use Azure RBAC, not access policies. Microsoft recommends the Azure RBAC permission model for the data plane and, from API version 2026-02-01, makes it the default for new vaults. The reason is privilege escalation. Under the legacy access policy model, anyone holding Microsoft.KeyVault/vaults/write, which includes Key Vault Contributor and Contributor, can add an access policy that grants themselves data access. Under Azure RBAC, granting data access needs role-assignment rights (Owner, User Access Administrator, or the scoped Key Vault Data Access Administrator role), and Key Vault Contributor stays a control-plane-only role.
| Built-in role | Grants |
|---|---|
| Key Vault Secrets User | Read secret contents: what an application's managed identity usually needs |
| Key Vault Secrets Officer | Manage secrets, but not permissions |
| Key Vault Crypto Service Encryption User | Read key metadata and wrap/unwrap keys: the role for a service's identity using a customer-managed key |
| Key Vault Crypto Officer | Manage keys, including rotation policies |
| Key Vault Administrator | All data-plane operations, but cannot manage role assignments |
The recommended layout is one vault per application per environment, with roles assigned at vault scope. Assignments on individual secrets are for narrow exceptions and do not isolate application teams inside a shared vault, because vault-level administration still exposes everything in it. Switching an existing vault to Azure RBAC invalidates its access policies, so assign the equivalent roles first.
Rotation works differently for each asset type (Understanding autorotation):
| Asset | Mechanism |
|---|---|
| Keys | A rotation policy creates a new key version on a schedule (minimum seven days) and can raise a near-expiry Event Grid event. Services must reference a versionless key URI to pick up the new version |
| Secrets | An expiration date plus the SecretNearExpiry Event Grid event, which triggers an Azure Functions app that creates the new credential at the source and writes a new secret version |
| Certificates | Auto-renewal at a percentage of the lifetime or a number of days before expiry, through an integrated CA such as DigiCert or GlobalSign, or self-signed |
Prefer managed identities wherever the target service supports Microsoft Entra authentication: rotation is only needed for the credentials you cannot eliminate.
Deletion protection (soft delete): soft delete is on by default for new vaults, keeps deleted vaults and objects recoverable for 7 to 90 days (90 by default, set at creation), and cannot be turned off once enabled. Purge protection is off by default; when it is on, nothing in the deleted state can be purged until the retention period passes. Most services that use customer-managed keys, such as Azure Storage, require purge protection.
⚠️ Exam Trap: a CanNotDelete resource lock does not protect the keys inside a vault. Locks apply only to control-plane operations, and deleting or purging a key is a data-plane operation. Purge protection is the control that stops a key from being destroyed.
⚠️ Common Pitfall: Choosing Managed HSM "for maximum security" when the requirement also includes secrets or certificates. Managed HSM stores keys only, so the design still needs a vault alongside it.
Key Trade-Offs:
- Isolation vs. Cost and Simplicity: Managed HSM gives you a single-tenant HSM with its own local RBAC, but it stores only keys. Premium gives HSM-protected keys in the lower-cost multitenant service that also holds secrets and certificates.
Reflection Question: For a workload that needs HSM-protected customer-managed keys, application secrets and a TLS certificate, which Key Vault container, permission model and rotation mechanism would you choose for each asset, and what stops a privileged administrator from permanently destroying the key?
