Azure Key Vault: secrets, keys, certificates, access control and rotation
In short: Azure Key Vault is a managed store for secrets, cryptographic keys and certificates. Applications reach it with managed identities instead of stored passwords, Azure RBAC controls who can read or manage each item, and soft delete, purge protection, private endpoints, logging and rotation keep it safe.
Why a vault?
Passwords and API keys hard-coded in source code, config files or pipeline variables are one of the most common causes of breaches. Once a secret is in Git history, it is very hard to remove. A vault keeps secrets in one controlled place, so code holds only a reference, access is logged, and changing a secret does not mean redeploying everything.
| Option | Protection | Use when |
|---|---|---|
| Key Vault Standard | Software-protected keys | Most secrets and certificates |
| Key Vault Premium | Adds HSM-protected keys | Keys needing hardware protection |
| Managed HSM | Dedicated single-tenant HSM pool | Strict regulatory or key-sovereignty needs |
Access control
Key Vault separates the management plane (creating the vault, changing network settings) from the data plane (reading a secret, signing with a key). For the data plane there are two permission models: the older vault access policies, and Azure RBAC, which Microsoft recommends. With RBAC you can grant narrow built-in roles such as Key Vault Secrets User (read secret values) or Key Vault Crypto User, at vault level or even on a single secret.
A managed identity gives an Azure resource its own identity in Entra ID with no secret to store or rotate. Grant that identity a data-plane role and the app fetches what it needs at run time:
az role assignment create --assignee <managed-identity-principal-id> --role "Key Vault Secrets User" --scope /subscriptions/<subscription-id>/resourceGroups/rg-app/providers/Microsoft.KeyVault/vaults/<your-vault>Protecting the vault
- Soft delete is always on: deleted vaults and items can be recovered during a retention period of 7 to 90 days.
- Purge protection stops anyone, including admins, permanently deleting items before the retention period ends. Turn it on for production.
- Disable public network access and use a private endpoint.
- Send diagnostic logs (AuditEvent) to Log Analytics and alert on unusual reads or failed access.
- Use separate vaults per application and environment, so one compromised app cannot read another's secrets.
- Turn on Defender for Key Vault for anomaly detection.
Rotation and expiry
- Set expiry dates on secrets and keys so nothing lives forever.
- Give keys a rotation policy so Key Vault creates new versions automatically.
- For certificates, link to a supported certificate authority and set auto-renewal before expiry.
- For secrets such as database passwords, use the near-expiry event in Event Grid to trigger a function that rotates the password and stores the new version.
- Make apps read the latest version rather than pinning an old one.
Tip: the same pattern exists on other clouds, for example AWS Secrets Manager and Google Cloud Secret Manager. See secrets management for container workloads.
Practice
Why use a managed identity instead of a client secret for an app to reach Key Vault?
What does purge protection add on top of soft delete?
Which built-in role lets an app read secret values but not manage the vault?
Key takeaways
- Key Vault stores secrets, keys and certificates centrally.
- Use Azure RBAC and managed identities for data-plane access.
- Enable purge protection, private endpoints and audit logging.
- Use separate vaults per app and environment.
- Set expiry and rotate automatically.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.