CMK revocation: what is the guaranteed SLA for DEK cache expiry after key deletion/disable?

Priyanka Gaikwad 40 Reputation points
2026-04-01T10:27:34.2866667+00:00 
We are implementing Customer-Managed Keys (CMK/BYOK) for Azure Storage using a 
cross-tenant setup (multi-tenant App Registration + User-Assigned Managed Identity 
+ federated credential) where the Key Vault is in the customer tenant and the 
Storage Account is in the service provider tenant.

During revocation testing, we observed that after deleting/disabling the CMK key 
in Key Vault, existing blobs remain accessible for an extended period. We understand 
that Azure Storage caches DEKs (Data Encryption Keys) internally and does not call 
Key Vault on every read operation.

We need the following clarified with official documentation or contractual SLA:

1. What is the exact TTL / maximum duration of the DEK cache in Azure Storage?

2. After a CMK key is deleted or disabled in Key Vault, what is the guaranteed 
   maximum time before all existing blob read/write operations start failing?

3. Does this TTL differ between:
   a. Same-tenant CMK
   b. Cross-tenant CMK (our scenario)
   c. Key disable vs key delete vs key purge

4. Is there any mechanism to force immediate DEK cache invalidation without 
   waiting for TTL expiry?

5. Is this revocation window documented anywhere for compliance purposes? 
   Our auditors (SOC2 / ISO27001) require a defined revocation SLA.

We have tested this with:
- Storage Account with CMK encryption (cross-tenant, federated identity)
- Key deleted from customer tenant Key Vault
- Blobs uploaded before key deletion remain downloadable for extended period
- Key Vault audit logs show no unwrapKey calls during this window, confirming 
  the read is served from cache

Please provide official documentation or a written statement on the revocation 
SLA that can be shared with compliance auditors.
Azure Disk Encryption
Azure Disk Encryption

An Azure service for virtual machines (VMs) that helps address organizational security and compliance requirements by encrypting the VM boot and data disks with keys and policies that are controlled in Azure Key Vault.

Answer accepted by question author
Ganesh Patapati 12,170 Reputation points Microsoft External Staff Moderator
2026-04-08T14:23:35.6733333+00:00

Hello Priyanka Gaikwad

  1. Microsoft documents the mechanism (wrap/unwrap via Key Vault permissions such as get, unwrapKey, wrapKey) and that Storage uses Key Vault for unwrapping during operations but does not publish an exact TTL / maximum duration for Azure Storage’s internal cache of encryption keys (DEK/AEK unwrapping results) in the official Storage CMK docs.

MS docs: What is Customer-managed keys for Azure Storage encryption?

  1. There is no guaranteed maximum time officially documented for “all existing blob reads/writes must fail by X time” after Key Vault key disable/delete.

MS docs: How Azure Storage encrypted for data at rest

  1. Microsoft Officially confirms cross‑tenant CMK is supported, including a federated identity workflow across two Entra tenants. But Microsoft does not document any difference in “cache TTL” behavior between same‑tenant and cross‑tenant scenarios. However, Microsoft documents Key Vault soft delete & purge protection semantics: deleted objects can remain recoverable for 7–90 days; purge permanently deletes the object. However, that Key Vault lifecycle documentation still does not provide a Storage‑side revocation SLA.

MS Docs: Configure cross-tenant customer-managed keys for an storage account

Azure Key Vault: soft-delete overview

  1. Azure Storage allows you to change the CMK configuration, including updating the key, rotating it, or switching key versions as part of regular management. Cross-tenant configuration is supported as well. However, the Azure Storage documentation does not describe any way to immediately force a flush or invalidate cached DEK/unwrap results.

NOTE: CMK protects data‑at‑rest encryption, but revocation timing is not guaranteed to be instantaneous due to internal key caching. CMK disablement or deletion should be treated as a cryptographic safeguard, not a real‑time data access kill‑switch.

I hope this has been helpful!

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.

please don’t forget to close the thread by clicking Accept the answer wherever the information provided helps you, as this can be beneficial to other community members.

Was this answer helpful?

1 person found this answer helpful.
Answer accepted by question author
Ravi Varma Mudduluru 12,540 Reputation points Microsoft External Staff Moderator
2026-04-01T15:02:37.35+00:00

Hello @Priyanka Gaikwad,

Thanks for reaching out to Microsoft Q&A.
Azure Storage’s server-side encryption with CMK caches the Data Encryption Key (DEK) for performance, and that cache lives beyond the moment you disable or delete the Key Vault key. Unfortunately:

  1. Microsoft doesn’t publish (and thus doesn’t SLA) a specific TTL for that DEK cache in Azure Storage.
  2. In practice you’ll see cached DEKs stay valid anywhere from a few minutes up to multiple hours, and reads/writes will continue to succeed until the cache expires.
  3. We’ve seen no difference in cache behaviour between same-tenant vs. cross-tenant CMK, nor between disabling vs. deleting vs. purging the key. All of those simply make the key unavailable for new unwrapKey calls but cached DEKs still work until they expire.
  4. There is no user-exposed “flush cache now” API or knob for Azure Storage CMKs. The only way to force immediate revocation is to rotate the storage account to point at a completely new key (which forces a fresh wrap/unwrap).
  5. There’s no formal revocation window documented in any public SLA or compliance guide for Storage DEK caching so you won’t find a contractual number to hand off to auditors.

If the answer is helpful, please click "upvote" it. If you have extra questions about this answer, please click "Comment".

Was this answer helpful?

0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-04-01T10:28:27.5233333+00:00

    Azure Storage does not expose or document a DEK cache TTL or a contractual SLA for how quickly cached DEKs expire after a customer‑managed key (CMK) is disabled, deleted, or purged.

    From the available documentation, only the following behaviors are guaranteed and supported:

    1. How to revoke access when using CMK

    For a storage account encrypted with customer‑managed keys, revocation is performed by disabling the key in Azure Key Vault:

    • To revoke access, disable the key currently being used in the key vault.
    • After the key has been disabled, clients cannot call operations that read from or write to a blob or its metadata.
    • Attempts to call these operations will fail with HTTP 403 (Forbidden) for all users.
    • Data remains encrypted but is inaccessible until the key is re‑enabled.

    This behavior is documented for:

    • Same‑tenant CMK
    • Cross‑tenant CMK for existing accounts
    • Cross‑tenant CMK for new accounts

    The documentation does not differentiate behavior or timing guarantees between same‑tenant and cross‑tenant CMK configurations.

    1. Documented effect of revocation

    The documented effect of disabling the CMK key is:

    • “After the key has been disabled, clients can't call operations that read from or write to a resource or its metadata. Attempts to call these operations will fail with error code 403 (Forbidden) for all users.”

    However, the documentation does not specify:

    • Any DEK cache TTL value.
    • Any maximum propagation time between key disable/delete and the point at which all read/write operations fail.
    • Any difference in behavior between key disable vs. key delete vs. key purge.
    1. Answers to specific questions based on documentation
    1. Exact TTL / maximum duration of the DEK cache in Azure Storage
    • No DEK cache TTL or maximum duration is documented.
    1. Guaranteed maximum time before all blob read/write operations fail after CMK deletion/disable
    • Documentation states that once the key is disabled, read/write operations fail with 403, but does not provide a time‑bound SLA or maximum delay.
    1. Differences by scenario (same‑tenant vs cross‑tenant, disable vs delete vs purge)
    • Documentation for revocation is identical in wording for:
      • Same‑tenant CMK
      • Cross‑tenant CMK (new and existing accounts)
    • No separate behavior, timing, or TTL is documented for:
      • Same‑tenant vs cross‑tenant
      • Disable vs delete vs purge
    1. Mechanism to force immediate DEK cache invalidation
    • No mechanism is documented to force immediate DEK cache invalidation.
    • The supported and documented method is to disable the key in Key Vault; any internal caching behavior and timing are not exposed.
    1. Documentation / revocation window for compliance purposes
    • The documentation provides a functional statement: disabling the CMK key causes read/write operations to fail with 403 and data remains encrypted but inaccessible until the key is re‑enabled.
    • No explicit revocation window, DEK cache TTL, or contractual SLA is documented that can be cited as a time‑bound guarantee.

    For a formal, auditor‑ready statement or any non‑public SLA details, the supported path is to open a support request with Microsoft so that the product group or support engineering can provide written guidance specific to the environment and compliance needs.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.