| name | azure-key-vault |
| description | Guidance for Azure Key Vault — securely storing and managing secrets, keys, and certificates with RBAC, network isolation, managed identity access, soft delete / purge protection, and rotation. Covers when to use standard Key Vault vs Managed HSM (FIPS 140-3 Level 3), one-vault-per-app blast radius principle, and Key Vault references in App Service / Functions. WHEN: Azure Key Vault, store secrets, manage certificates, encryption keys, secret rotation, Key Vault RBAC, purge protection, soft delete, private endpoint Key Vault, managed identity access secrets, Managed HSM, Key Vault references, BYOK CMK. DO NOT USE for certificate authority design (use pki-design), entra app credentials only (use entra-id), or PaaS networking topology (use azure-network-security-design). |
| metadata | {"author":"Microsoft","version":"0.1.0","category":"development","source":{"repository":"https://github.com/vinayaklatthe/microsoft-security-skills","path":"skills/azure-key-vault","license_path":"LICENSE","commit":"15f16df4ae50261328da8b82f3f0964cac0899ae"}} |
Azure Key Vault
Azure Key Vault centrally and securely stores secrets, keys, and certificates, providing
RBAC-based access control, network isolation, logging, and lifecycle automation - so
applications never embed credentials and crypto material has a managed lifecycle.
When to use
Managing application secrets, encryption keys (including customer-managed keys / BYOK), and
TLS certificates. Use this skill to pick standard vs Managed HSM, design access, and plan
rotation.
Do not use this skill for CA design (pki-design), Entra app credentials only
(entra-id), or PaaS networking topology (azure-network-security-design).
Pick the vault type and access model
| Requirement | Choice | Notes |
|---|
| Application secrets, TLS certs, software-protected keys | Standard Key Vault | Default; FIPS 140-2 Level 2 |
| Single-tenant HSM with FIPS 140-3 Level 3 keys (CMK, root CA) | Managed HSM | Regulated workloads |
| Per-app, per-environment isolation | One vault per app per environment | Limits blast radius |
| App reading secrets at runtime | Managed identity + RBAC (Key Vault Secrets User) | No secrets in code |
| App Service / Functions secret in config | Key Vault references in app settings | No code change |
| Customer-managed key for Storage / SQL | Key in Key Vault (or HSM) + identity grant | Rotate independently |
Rule of thumb: one vault per app per environment (dev / test / prod). Don't share a
vault across apps - a compromise of one app's identity reads all the others' secrets. Use
Managed HSM only when the regulator or CMK boundary requires FIPS 140-3 Level 3.
Approach
-
Use Azure RBAC for the data plane — Switch the vault to RBAC permission model (not
legacy access policies). Assign least-privilege roles (Key Vault Secrets User,
Key Vault Crypto User) to managed identities, not user accounts.
Verify: vault enableRbacAuthorization = true; no users with Key Vault Administrator
in prod.
-
App access via managed identity + Key Vault references — App authenticates with a
system-assigned or user-assigned managed identity, fetches secrets at runtime.
For App Service / Functions, use Key Vault references in app settings -
@Microsoft.KeyVault(SecretUri=...) - no SDK code change.
Verify: source code contains no plaintext secrets; managed identity has only the
secrets role on the target vault.
-
Enable soft delete + purge protection — Soft delete is on by default; turn on
purge protection to make accidental or malicious key deletion non-recoverable for
90 days. Required for CMK and most compliance scenarios.
Verify: softDeleteRetentionInDays >= 7; enablePurgeProtection = true.
-
Restrict network access — For sensitive vaults, disable public network access and
use private endpoint in the workload VNet. Firewall the rest with service tags or
selected networks.
Verify: publicNetworkAccess = Disabled; private endpoint resolves; public IP test
from internet = blocked.
-
One vault per app per environment — Per-app blast radius. Cross-app reads are then a
role grant, audited. Don't lump secrets into a shared vault.
-
Automate rotation + monitor expiry — Set expiry on secrets / certs; use rotation
policies for certificate auto-renewal from issuer; for secrets, use Event Grid → Logic
App / Function to rotate at the source and update the secret.
Verify: no secret in production has a NULL expiry; alerts fire 60 days before any cert
or secret expires.
-
Monitor + Defender — Enable diagnostic logs to Log Analytics; turn on Defender for
Key Vault for anomalous access detection.
Guardrails
- One vault per app per environment limits blast radius and simplifies access control.
Shared vaults are an over-permission anti-pattern.
- Purge protection is irreversible once on - required for CMK and many compliance
scenarios. Turn it on knowingly.
- Never store secrets in source / config; use managed identity + Key Vault references.
Code-stored secrets leak via repo, logs, env-var dumps.
- Disable public network access for sensitive vaults. Open-to-internet Key Vault is a
brute-force / credential-spray target.
- RBAC, not access policies. RBAC is the modern model with proper inheritance and
PIM-eligible roles.
- Don't grant
Key Vault Administrator to apps. Apps need read on secrets / keys, not
admin.
Common anti-patterns
- "Shared 'enterprise' Key Vault for all apps" - Compromise of one app reads everyone's
secrets. Per-app per-environment.
- "Access policies because we've always used them" - Legacy; harder to audit. Use RBAC.
- "No purge protection - we might need to delete" - First malicious / accidental purge
= data loss. Turn it on; deal with the irrevocability.
- "Public network access on for convenience" - Internet exposure. Private endpoint
- "Secrets in App Service application settings as plaintext" - Visible to anyone with
config read. Use Key Vault references.
- "No expiry / no rotation" - Long-lived secrets are a perpetual liability. Expiry +
rotation policy.
- "Same vault for app + CA root key" - Mix of blast radii. CA / HSM keys in Managed
HSM, separate from app secret vault.
Example prompts
Set up Azure Key Vault with RBAC, purge protection, and a private endpoint.
Configure an App Service to read secrets via managed identity and Key Vault references.
When should I use Managed HSM instead of standard Key Vault?
Plan one-vault-per-app-per-environment for our microservices estate.
Automate certificate rotation in Key Vault with a 60-day expiry alert.
Review my Key Vault access model for least privilege.
Microsoft Learn