Customer Managed Keys in Azure

What customer-managed keys actually do

By default, Azure encrypts data at rest using platform-managed keys — keys that Microsoft generates, stores, and rotates automatically. You never see these keys, have no control over them, and if Microsoft wanted to rotate them, they could. For most organisations and most data, this is entirely acceptable.

Customer-managed keys change this arrangement. You create a key in Azure Key Vault — or import one you generated yourself — and configure an Azure service (say, your storage account) to use that key for encryption. The service uses your key to protect the data encryption key (DEK), which is what actually encrypts the data. This is sometimes called envelope encryption: the DEK encrypts the data, and your CMK encrypts the DEK.

The practical effect is that Microsoft cannot decrypt your data without your key. If you revoke the key, or delete the vault, or restrict access to it, the Azure service can no longer decrypt anything — including your data. This is the control that CMKs provide, and it is also the risk.

When do you actually need CMKs

CMKs are not a security upgrade that every organisation should apply. Platform-managed keys use the same AES-256 algorithm and are managed in dedicated, audited hardware by a team whose entire job is key security. The question is not whether CMKs are “more encrypted” — the encryption strength is identical — but whether your specific situation requires you to control the keys.

The most common reasons to use CMKs:

• Regulatory compliance. Some frameworks and contracts explicitly require that the customer maintain control of encryption keys. HIPAA Business Associate Agreements sometimes include this. Financial services regulations in certain jurisdictions do too. If your compliance framework or customer contracts specifically require customer-controlled keys, CMKs satisfy that requirement.
• Data sovereignty requirements. In some jurisdictions, regulations require that cryptographic keys for certain data cannot be held by a third party. If you must demonstrate that only your organisation can decrypt data, CMKs with keys held in a vault only your team can access satisfies this.
• Right to make data permanently inaccessible. With CMKs, you can make data cryptographically inaccessible by deleting the key — without deleting the underlying data or the storage account. This is useful when you need to definitively end access to a dataset (for example, at the end of a customer relationship where you are required to destroy their data).
• Audit requirements for key usage. Key Vault logs every time a service accesses your CMK. If your security team needs to demonstrate that encryption key access is audited and attributable, CMKs with Key Vault logging provides that.

How the access chain works

When you configure CMKs for an Azure service, you set up an access chain that the service follows every time it needs to read or write data. Understanding this chain is important because a break anywhere in it stops the service from accessing your data.

The chain works like this:

1. Your Azure service (a storage account, for example) is assigned a managed identity.
2. That managed identity is granted permission to use the key in Key Vault — specifically the Key Vault Crypto Service Encryption User role, or equivalent access policy permissions (wrapKey, unwrapKey, get).
3. When the storage service needs to write data, it generates a data encryption key (DEK), uses your CMK to wrap (encrypt) that DEK via Key Vault, and stores the wrapped DEK alongside the data.
4. When the storage service needs to read data, it retrieves the wrapped DEK, asks Key Vault to unwrap it using your CMK, and uses the unwrapped DEK to decrypt the data.

Notice that the CMK itself is never used to directly encrypt your data — it encrypts the DEK. This means that rotating your CMK does not require re-encrypting all your data. Key Vault simply wraps the same DEK with the new key version, which is a fast operation regardless of how much data you have stored.

# Create a key in Key Vault
az keyvault key create \
  --vault-name my-vault \
  --name my-cmk \
  --kty RSA \
  --size 2048

# Get the key ID
KEY_ID=$(az keyvault key show \
  --vault-name my-vault \
  --name my-cmk \
  --query key.kid \
  --output tsv)

# Assign the managed identity of a storage account the Crypto Service Encryption User role
STORAGE_PRINCIPAL=$(az storage account show \
  --name mystorageaccount \
  --resource-group my-rg \
  --query identity.principalId \
  --output tsv)

VAULT_ID=$(az keyvault show \
  --name my-vault \
  --resource-group my-rg \
  --query id \
  --output tsv)

az role assignment create \
  --assignee $STORAGE_PRINCIPAL \
  --role "Key Vault Crypto Service Encryption User" \
  --scope $VAULT_ID

# Configure the storage account to use CMK
az storage account update \
  --name mystorageaccount \
  --resource-group my-rg \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault https://my-vault.vault.azure.net/ \
  --encryption-key-name my-cmk

Key rotation

One of the operational responsibilities you take on with CMKs is key rotation — periodically creating a new key version so that the encryption material changes. Azure Key Vault supports automatic rotation policies that create a new key version on a schedule and notify you (or automatically update the service) when this happens.

For services like Azure Storage, you can configure automatic key version updates so that when Key Vault rotates the key, the storage account automatically picks up the new version. For other services, you may need to update the CMK reference manually after rotation.

# Set an automatic rotation policy on a key (rotate every 180 days)
az keyvault key rotation-policy update \
  --vault-name my-vault \
  --name my-cmk \
  --value '{
    "lifetimeActions": [
      {
        "trigger": { "timeAfterCreate": "P180D" },
        "action": { "type": "Rotate" }
      },
      {
        "trigger": { "timeBeforeExpiry": "P30D" },
        "action": { "type": "Notify" }
      }
    ],
    "attributes": {
      "expiryTime": "P2Y"
    }
  }'

After rotation, old key versions remain in Key Vault in a disabled or expired state. Do not delete old key versions immediately — the previous version is still needed to decrypt any data that was encrypted before the rotation. Azure manages which version to use for existing data automatically; you only need to ensure old versions remain accessible (not purged) until you are certain all data has been re-wrapped with the new version.

What can go wrong: a real scenario

The risk of CMKs is concrete, and it has caught teams off guard. Here is an example of how it happens.

A team configures their production Azure SQL Database to use a CMK stored in a Key Vault named prod-keys-vault. Six months later, an infrastructure engineer is cleaning up resources before a billing review. The Key Vault appears in the list of resources. The engineer does not recognise it — the team that set up the CMK has since changed — and there is no resource tag explaining what it is used for. The engineer deletes it.

At this point, Azure SQL immediately begins failing. The service can no longer unwrap the DEK, so all database operations fail. The error messages reference a key vault that no longer exists. The production application is down.

If soft-delete was enabled (the default) and purge protection was also enabled, the vault is in a deleted-but-recoverable state. The engineer can run:

# List soft-deleted vaults
az keyvault list-deleted --resource-type vault

# Recover the vault
az keyvault recover --name prod-keys-vault

The vault and all its keys come back. Azure SQL resumes functioning within a few minutes once it can access the key again. The team is shaken but the data is intact.

If purge protection was not enabled, the engineer might have also run az keyvault purge —name prod-keys-vault to clean up the soft-deleted resource — at which point the key is permanently gone. The database is encrypted with a key that no longer exists. Every byte of data in that database is now cryptographically inaccessible. There is no recovery path. Microsoft cannot help because they never had a copy of the key.

This is not a hypothetical. The lesson: if you use CMKs, enable purge protection on the Key Vault, tag it clearly (something like purpose: cmk-for-prod-sql-db, delete-policy: never), and use resource locks to prevent accidental deletion.

# Apply a resource lock to prevent vault deletion
az lock create \
  --name do-not-delete \
  --resource-group my-rg \
  --resource-name prod-keys-vault \
  --resource-type Microsoft.KeyVault/vaults \
  --lock-type CanNotDelete \
  --notes "This vault stores CMKs for prod SQL database. Deleting it makes all data inaccessible."

The responsibilities you take on

When you enable CMKs, you accept several ongoing operational responsibilities that do not exist with platform-managed keys:

• Key availability. The Azure service needs to be able to reach Key Vault at all times. Network restrictions, expired credentials, removed role assignments, or an outage in the Key Vault region can all interrupt data access.
• Key retention. You must not delete key versions that are still in use. Old versions are needed to decrypt data that was written under that version.
• Access control on the vault. The managed identity that Azure uses to access the key must always have the correct permissions. If someone removes the role assignment — even inadvertently — the service stops functioning.
• Disaster recovery. Your Key Vault and its keys should be part of your DR plan. Key Vault supports geo-redundancy within a region pair by default, but you should verify that your vault is accessible from your failover region if you use geo-redundant services.
• Key rotation operations. Rotating keys requires coordination — ensuring services pick up the new version and that old versions are not prematurely deleted.