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

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

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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

+ firewall.

• "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

• Key Vault overview: https://learn.microsoft.com/azure/key-vault/general/overview
• Security features: https://learn.microsoft.com/azure/key-vault/general/security-features
• RBAC guide: https://learn.microsoft.com/azure/key-vault/general/rbac-guide
• Soft delete + purge protection: https://learn.microsoft.com/azure/key-vault/general/soft-delete-overview
• Private endpoints: https://learn.microsoft.com/azure/key-vault/general/private-link-service
• Key Vault references in App Service: https://learn.microsoft.com/azure/app-service/app-service-key-vault-references
• Managed HSM: https://learn.microsoft.com/azure/key-vault/managed-hsm/overview
• Defender for Key Vault: https://learn.microsoft.com/azure/defender-for-cloud/defender-for-key-vault-introduction