How to manage encryption keys on Azure

Why this matters

Azure encrypts data at rest by default with platform-managed keys. That covers the basic need. Customer-managed keys move control into your subscription. You decide who can use the key, where it lives and when it rotates. You also take on the failure modes.

In Azure, Key Vault holds the keys. Services call Key Vault to wrap and unwrap data keys. Storage accounts, managed disks, Azure SQL Database and other services each have their own setting for customer-managed keys. The names differ. A storage account uses an encryption key URI. A disk uses a disk encryption set. SQL uses a TDE protector. Treat each as a separate integration.

The risk is availability, not just theft. If an app loses permission to the key, reads and writes can fail. If someone purges a key, data can be unrecoverable. Key management is a production dependency. Give it an owner, a backup path and an alert.

Before you start

Inventory every resource that will use customer-managed keys. List the service setting that points to Key Vault and the team that owns it. Include non-production resources. A short spreadsheet beats a guess. Note which resources can use a versionless key URI and which pin a key version. That affects rotation later.

Choose the vault type. Standard Key Vault stores software-protected keys. Premium adds HSM-backed keys. Managed HSM is a single-tenant HSM pool for stricter separation. Most teams start with Premium Key Vault. Choose Managed HSM when policy or a customer requires a dedicated HSM and you can operate it.

Decide the access model. Key Vault supports vault access policies and Azure RBAC. Pick one and write it down. Azure RBAC is easier to audit across the subscription. Create separate roles for key admins, key users and service identities. Plan a break-glass group.

Turn on soft delete and purge protection before you add keys. Set retention long enough for recovery. Plan private endpoints and firewall rules if apps cannot use public endpoints. Decide where diagnostic logs go. Check that the services you plan to use support your region and key type.

How to do it

Build a small key hierarchy. One vault per environment and region is a common start. Separate production from development. Use different keys for different data classes or workloads. Do not share one key across every service just because it is easier. A shared key widens the blast radius and makes rotation a group project.

Create the vault with protection on. Use the Azure portal, Azure CLI or Bicep. Set the permission model at creation. Add private endpoint and firewall rules before you store production keys. Turn on diagnostic settings to a Log Analytics workspace. Send AuditEvent logs, not just metrics.

Grant access with managed identities. For a service that uses customer-managed keys, the identity needs get on key metadata and wrapKey and unwrapKey. It does not need create, delete or purge. Give people the Key Vault Crypto Officer role only if they manage keys. Give auditors the Reader role and log access.

Create keys with a purpose in the name, such as storage-prod-eastus-01. Set a rotation policy and decide how the consumer picks up new versions. Test with a non-production resource first. Record the key URI and the resource setting that uses it.

1. Inventory customer-managed key resources. Use Azure Resource Graph Explorer to list storage accounts, disks, SQL servers and other services that support customer-managed keys. Record the current encryption setting and owner for each. Mark which ones already point at Key Vault.
2. Create or confirm the vault. Create the vault in the same region as the data where possible. Enable soft delete and purge protection. Choose Premium if you need HSM-backed keys.
3. Set the permission model and roles. Pick Azure RBAC or vault access policies at creation. Assign Key Vault Crypto Officer to the key admins. Assign Key Vault Crypto Service Encryption User to the service identity that wraps and unwraps data keys.
4. Add network and logging controls. Create a private endpoint and turn off public access if your apps run in a virtual network. Add diagnostic settings that send AuditEvent logs to Log Analytics. Alert on key delete, purge and role changes.
5. Create keys and a rotation policy. Create one key per workload and environment. Set an activation date and a rotation policy with a notice period. Decide whether the consuming service uses a versionless key URI or a pinned version.
6. Bind a test resource to the key. Point a non-production storage account or disk encryption set at the key. Confirm the service can read and write. Check that the identity has only wrap and unwrap rights.
7. Rotate and test recovery. Rotate the key and confirm the test resource still works. Restore a backed-up key or vault item in a safe test. Record the steps and the owner.

How to check it worked

Check each resource, not just the vault. In the portal, open the storage account Encryption blade. It should show Customer-managed key and the correct vault and key. For disks, open the disk encryption set and the disk. For SQL, check the TDE protector. A vault with keys in it proves nothing if the resource still uses platform-managed keys.

Read the logs. Key Vault diagnostic logs should show wrap and unwrap calls from the expected identity. Look for failures. Check that no unexpected principal has key management rights. In Azure RBAC, review role assignments at the vault scope, not just the subscription.

Test rotation on a canary resource. Rotate the key, then read and write data. For versionless references, confirm the service moved to the new version. For pinned versions, confirm the update path is documented and worked. Check alerts by disabling a key in a test vault, not production.

Check protection settings and backups. Confirm soft delete is on, purge protection is on, and retention matches your plan. Confirm the vault or Managed HSM backup exists and that someone has restored one. Review key expiry dates. Check private endpoint connection state and that public access is off if required.

Mistakes to avoid

One vault and one key for everything feels tidy. It turns one permission mistake into an outage across workloads. Split by environment, region and data class. Keep names boring and clear.

Giving the app key management rights is a common shortcut. A service that only needs to wrap and unwrap should not be able to delete or rotate keys. Use a managed identity and the narrow role. Do not put key admin rights in a shared deployment service principal.

Skipping purge protection leaves a gap. Soft delete helps only until someone purges the key. Purge protection blocks that during the retention period. Turn it on before production keys exist. Also avoid pinning old key versions forever. Plan the rotation path.

Forgetting the region and the exit path causes trouble later. Key Vault is regional. A resource that depends on a key in another region has a longer failure path. Decide how you will operate if the vault is unavailable. Test restore. Document who can approve a break-glass use. If you want an outside read, the Cloud security review is a fixed price package at $6,500. It checks identity, network exposure, encryption and logging across up to five subscriptions. It sits alongside an internal review or a specialist key management audit, not instead of daily ownership.

Frequently asked questions