A storage customer-managed key lets an organization use its own key for storage encryption at rest instead of relying only on Microsoft-managed keys. The data is still encrypted by Azure Storage, but the key material and lifecycle live under customer control in Azure Key Vault or Managed HSM. This matters for compliance, separation of duties, key rotation, and evidence. It also creates responsibility: if the storage account cannot reach the key, data access and operations can be disrupted.
Azure Storage customer-managed key, storage CMK, customer-managed key for storage
Difficulty
fundamentals
CLI mappings
5
Last verified
2026-05-26
Microsoft Learn
A storage customer-managed key is a key in Azure Key Vault or Managed HSM that a customer controls for Azure Storage encryption at rest. Azure Storage still performs encryption, but the customer manages key ownership, access, rotation, purge protection, and lifecycle accountability.
Technically, customer-managed keys connect a storage account to a Key Vault or Managed HSM key through managed identity and encryption settings. The storage account records the key source, key vault URI, key name, optional key version, and identity used to access the key. Azure Storage encrypts supported services at rest, while Key Vault controls key permissions, purge protection, soft delete, auditing, and rotation. In architecture, the term spans security, identity, storage control plane, compliance governance, disaster recovery, and operational readiness for key lifecycle events.
Why it matters
Customer-managed keys matter because encryption responsibility shifts from default platform management to an auditable customer-owned process. Regulated workloads may need proof that the organization controls key creation, access, rotation, and retirement. CMK can satisfy that need, but it also introduces a dependency between storage availability and key vault availability, permissions, identity, and protection settings. A disabled key, deleted vault, broken managed identity, or premature key-version retirement can affect storage access. The term helps architects explain both sides: stronger control and accountability, plus the operational discipline required to keep the key reachable and recoverable. That balance must be explicit in architecture decisions and runbooks.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In the storage account Encryption blade, key management shows Microsoft-managed keys or customer-managed keys with Key Vault details, identity configuration, and key status during audits.
Signal 02
In CLI output, encryption.keySource, keyVaultProperties, identity, and key-vault user identity fields reveal how the account reaches the configured encryption key during audit exports and rotations.
Signal 03
In Key Vault access reviews, the storage account managed identity appears with permissions or RBAC roles needed to use the encryption key during rotation and audits.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Meet regulatory requirements that demand customer ownership and auditability of encryption keys for storage data at rest.
Use Key Vault or Managed HSM to centralize key lifecycle, rotation, purge protection, and separation of duties.
Prove storage encryption posture during audits by exporting key source, identity, vault, and key version evidence.
Rotate encryption keys safely without recreating the storage account or reencrypting all data manually.
Detect and remediate broken CMK dependencies before disabled keys, deleted vaults, or permission changes affect storage access.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Aerospace supplier proves encryption control for contract renewal
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
An aerospace parts supplier stored design files and inspection records in Azure Storage. A contract renewal required customer control over encryption keys and evidence that key administrators were separate from storage operators.
🎯Business/Technical Objectives
Move regulated storage accounts to customer-managed keys without recreating accounts.
Use Key Vault purge protection and managed identity for key access.
Separate storage administration from key administration duties.
Produce contract evidence for encryption posture and rotation readiness.
✅Solution Using Storage customer-managed key
The security team created a dedicated Key Vault with soft delete, purge protection, diagnostic logs, and a key rotation policy. Platform engineers enabled system-assigned identities on the storage accounts and granted only the required key permissions. CMK settings were applied with CLI, using automatic key-version updates for the approved key. Evidence captured encryption.keySource, key vault URI, managed identity, and vault protection settings. A rotation drill created a new key version, waited for storage to pick it up, and confirmed old versions were not disabled prematurely.
📈Results & Business Impact
Twenty-four regulated storage accounts moved to CMK in two planned release windows.
Contract evidence preparation dropped from three weeks to four days.
No design-file access incidents occurred during the first rotation drill.
Separation-of-duty findings were closed before the customer renewal deadline.
💡Key Takeaway for Glossary Readers
Storage CMK provides real compliance value only when identity, vault protection, rotation, and evidence are operated as one control.
Case study 02
Pharmaceutical research avoids key-rotation outage
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A pharmaceutical research platform used CMK for trial data storage. During a previous rotation, an operator disabled an old key version too quickly and nearly blocked access to encrypted research exports.
🎯Business/Technical Objectives
Create a safe key rotation procedure for trial data storage.
Prevent premature disabling of old key versions.
Monitor storage and Key Vault signals during rotation.
Give researchers a predictable maintenance window.
✅Solution Using Storage customer-managed key
Cloud operations switched the process from manual portal changes to scripted CLI checks. Before rotation, the runbook exported storage encryption settings, key version behavior, managed identity, and Key Vault protection state. A new key version was created, and the team waited for the storage account to adopt it before any old version was disabled. Alerts watched Key Vault denied operations, storage account errors, and research export failures. The change board required CLI evidence for both the current and previous key versions before closing the maintenance window.
📈Results & Business Impact
Rotation validation time fell from two business days to three hours.
Denied key operations stayed at zero during two subsequent rotations.
Research export availability remained above the 99.9 percent internal target.
The emergency rollback section shrank from nine manual steps to three verified commands.
💡Key Takeaway for Glossary Readers
A customer-managed key is reliable only when rotation timing and old-key retirement are treated as production operations.
Case study 03
Public sector SaaS isolates tenant-owned encryption keys
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A public sector SaaS provider hosted document archives for agencies that required tenant-owned encryption keys. The provider needed a repeatable pattern without giving agency staff control over storage accounts.
🎯Business/Technical Objectives
Support agency-controlled keys while the provider operated storage accounts.
Keep managed identity and Key Vault access auditable for each tenant.
Prevent one tenant key issue from affecting other tenant archives.
Reduce onboarding time for new agency environments.
✅Solution Using Storage customer-managed key
Architects implemented a per-tenant storage account and Key Vault mapping. Each storage account used a user-assigned managed identity with access only to that tenant’s vault key. Onboarding automation validated purge protection, key permissions, encryption.keySource, and vault logging before the tenant environment was marked ready. The support model included a key-health dashboard and a playbook for tenant-side key disablement, so staff could explain impact without touching another tenant’s configuration. Policy blocked any production storage account that lacked the approved CMK metadata tags.
📈Results & Business Impact
New agency onboarding time dropped from 18 days to six days using the repeatable CMK workflow.
Tenant key-health checks found four permission issues before any archive data was loaded.
No cross-tenant storage access incidents were recorded during the first year.
Compliance evidence packages were generated automatically for 31 tenant environments.
💡Key Takeaway for Glossary Readers
CMK can support tenant trust boundaries when each key relationship is isolated, validated, and monitored from the start.
Why use Azure CLI for this?
I use CLI for customer-managed keys because CMK is a chain of settings, not one checkbox. I need to see the storage account identity, encryption key source, key vault URI, key name, key version behavior, and Key Vault protection state together. CLI makes that review repeatable and scriptable across subscriptions. It also prevents partial portal changes where a key is selected but identity permissions or purge protection are wrong. In production, CMK evidence has to survive audits and incident reviews, so I want commands that export exact JSON before rotation, after rotation, and before any vault access change. Those exports make key ownership visible beyond the security team.
CLI use cases
Inspect the active storage encryption configuration before an audit, migration, or key rotation window.
Enable or validate the storage account managed identity used to access the Key Vault key.
Configure CMK with automatic key version updates by leaving the key version empty where the policy allows it.
Check Key Vault soft delete and purge protection before attaching a key to production storage.
Review key metadata and versions before disabling an old version or changing vault access controls.
Before you run CLI
Confirm tenant, subscription, resource groups, storage account, key vault, key name, and whether cross-tenant design is involved.
Verify the storage account identity has least-privilege access to the key before changing encryption settings.
Ensure Key Vault soft delete and purge protection are enabled because accidental key loss can become a storage incident.
Decide whether automatic key version updates or manual key-version pinning matches the compliance policy.
Capture current encryption JSON and Key Vault protection settings before rotation, permission, or firewall changes.
What output tells you
encryption.keySource shows whether the account uses Microsoft-managed keys or Microsoft.Keyvault customer-managed keys.
keyVaultProperties identifies the vault URI, key name, and optional key version used for storage encryption.
identity output tells you which system-assigned or user-assigned managed identity the storage account uses.
Key Vault soft delete and purge protection output confirms whether the key has required deletion safeguards.
A blank key version in the right context indicates automatic key-version update behavior rather than manual pinning.
Mapped Azure CLI commands
Storage customer-managed key CLI commands
direct
az storage account show --name <account-name> --resource-group <resource-group> --query "{identity:identity,encryption:encryption}"
az storage accountdiscoverStorage
az storage account update --name <account-name> --resource-group <resource-group> --identity-type SystemAssigned
az keyvault key show --vault-name <vault-name> --name <key-name>
az keyvault keydiscoverStorage
az keyvault show --name <vault-name> --resource-group <resource-group> --query "{softDelete:properties.enableSoftDelete,purgeProtection:properties.enablePurgeProtection}"
az keyvaultdiscoverStorage
Architecture context
Architecturally, a storage customer-managed key is part of the security and compliance control plane for storage data. I use it when a workload requires customer control over encryption keys, tenant separation, Managed HSM assurance, or documented key rotation. The design must include a managed identity for the storage account, Key Vault or HSM permissions, purge protection, soft delete, logging, key rotation policy, and emergency access. It also needs a failure model: what happens if the key is disabled, the vault firewall changes, or the identity loses access. CMK is not just stronger encryption; it is a dependency that must be operated carefully.
Security
Security impact is direct and significant. CMK gives the organization control over key ownership, access policy or RBAC, rotation, deletion protection, and audit evidence. It can support compliance requirements that Microsoft-managed keys alone do not satisfy. The risk is mismanagement: overly broad key permissions, disabled purge protection, unmonitored key changes, or shared operator access can undermine the control. Teams should use managed identities, least-privilege Key Vault permissions, soft delete, purge protection, diagnostic logs, and separation of duties. Key rotation should be planned and verified so security improvement does not become an availability incident. Evidence should connect each key to a named workload and owner.
Cost
CMK can add direct and indirect cost. Key Vault or Managed HSM usage, key operations, premium HSM requirements, logging, monitoring, and operational review all carry cost. The storage account itself may not charge extra simply because CMK is configured, but compliance-grade key management is not free. Manual rotation, audits, emergency access design, and incident readiness require staff time. On the savings side, CMK can enable workloads to remain in Azure when regulatory requirements would otherwise force a more expensive platform. FinOps should connect CMK cost to compliance scope, key count, rotation policy, and the value of control. That mapping keeps controls proportionate instead of ceremonial.
Reliability
Reliability impact is high because storage encryption depends on continued access to the configured key. Azure Storage keeps data encrypted, but operations can be affected if the key is disabled, deleted, purged, inaccessible, or locked behind a misconfigured vault firewall or identity permission. Rotating a key version should be tested, and old versions should not be disabled until the storage account has picked up the new version safely. Key Vault availability, regional design, purge protection, and monitoring all matter. Reliable CMK design treats the key as a production dependency with alerts, runbooks, and recovery drills. Drills should include both planned rotation and accidental key disablement.
Performance
Performance impact is usually not visible on normal storage reads and writes because Azure Storage handles encryption operations at scale. The bigger performance concern is operational: key configuration, permission checks, rotation, and failed key access can slow deployments or incident response. Managed HSM or Key Vault behavior matters during configuration and key lifecycle operations, not every blob transaction. A poorly planned rotation can delay releases while teams wait for evidence that the new key version is active. Performance reviews should focus on deployment speed, key-operation health, alert latency, and storage availability rather than expecting CMK to speed up data access.
Operations
Operators manage storage CMK by checking encryption settings, validating managed identity permissions, confirming Key Vault soft delete and purge protection, reviewing key version behavior, and documenting rotation windows. Common work includes enabling CMK, switching between automatic and manual key versions, testing key rotation, exporting evidence, and investigating access failures after vault or identity changes. Operations teams should monitor Key Vault logs, storage account encryption status, policy compliance, and denied key operations. Every CMK change needs rollback thinking because a seemingly small key permission update can create a storage availability incident. Ownership records should name both storage and key administrators. and safety responsibilities.
Common mistakes
Configuring CMK before the storage account identity has permission to use the Key Vault key.
Disabling or deleting an old key version before confirming the storage account has moved to the new version.
Forgetting Key Vault purge protection and creating a compliance finding or key recovery risk.
Treating CMK as a one-time setup and not monitoring key access, rotation, or vault firewall changes.
Using broad Key Vault permissions for operators instead of separating key administration from storage administration.