Applies toAzure Key Vault (Standard, Premium), Azure Key Vault Managed HSM, customer-managed keys for Storage, SQL, Disks and other services
1. Vault granularity
| Approach | Pros | Cons |
|---|---|---|
| One vault per application per environment | Small blast radius, clear ownership, simple RBAC | More vaults to govern |
| Shared vault per team/subscription | Fewer resources | Broad access, noisy logs, throttling shared |
| One central vault for everything | Looks tidy | Huge blast radius, throttling, ownership confusion |
A common recommendation: one vault per app per environment per region, created by the landing zone/app template with standard settings.
2. Access model
- Use Azure RBAC (not legacy access policies) for new vaults: roles like Key Vault Secrets User, Key Vault Crypto User, Key Vault Certificates Officer.
- Applications: managed identity with read access to secrets/keys they need, scoped to the vault (or a single secret when warranted).
- Humans: no standing data-plane access in prod; PIM-eligible roles for break-glass reads.
- Separate who manages the vault (control plane) from who reads secrets (data plane).
3. Standard, Premium or Managed HSM
| Option | Keys protected by | When |
|---|---|---|
| Key Vault Standard | Software | Secrets, certificates, software keys |
| Key Vault Premium | Multi-tenant HSM-backed keys | HSM-protected keys at low cost |
| Managed HSM | Single-tenant HSM pools, you control the security domain | Strict regulatory requirements, full key-custody control, high key operation rates |
Managed HSM adds operational duties: security domain backup, quorum keys held by named people, and its own RBAC. Don't choose it without owners ready for those.
4. Customer-managed keys (CMK): where it's worth it
| Pros | Costs |
|---|---|
| Control to revoke access to data | Key or vault loss = data loss / outage (see the encrypted VM Sev1 post) |
| Meets some regulatory requirements | Rotation, monitoring and DR of keys per service |
| Separation of duties | Some features unavailable or more complex with CMK |
Use CMK where policy or regulation requires it; platform-managed keys already encrypt data at rest everywhere. When you use CMK:
- Purge protection and soft delete on (required by most services).
- Key in the same region as the data; DR plan for the vault in the secondary region.
- Automatic key rotation where the service supports versionless keys.
5. Network
- Private endpoint and public access disabled for production vaults.
- Allow "trusted Microsoft services" only when a service integration needs it, and know which ones.
- Pipelines that write secrets reach the vault via self-hosted agents in the VNet or approved IP ranges.
6. Rotation and expiry
- Certificates: issuer integration (DigiCert/GlobalSign) or ACME automation; auto-renew lifetime action.
- Secrets: rotation via Event Grid "near expiry" events → Function that rotates and updates the secret.
- Alerts on near-expiry events for everything that can't rotate automatically.
7. Operability
- Diagnostic logs (
AuditEvent) to Log Analytics; alert on access denied spikes and unusual readers. - Watch throttling limits for high-traffic apps; cache secrets in the app instead of reading per request.
- Recovery: soft-delete retention days set; runbook for restoring deleted secrets (see the Key Vault Sev1 post).
Warning
Purge protection can't be turned off once enabled, and soft-deleted vault names stay reserved for the retention period. Plan naming so a rebuild doesn't collide with a soft-deleted vault.
Checklist
- Vault per app/env/region via template
- RBAC with least privilege; no standing human data access in prod
- Tier chosen; Managed HSM only with owners for security domain
- CMK only where required, with DR and rotation plans
- Private endpoints; trusted services reviewed
- Rotation, near-expiry alerts, audit logs, recovery runbook