Get familiar with the new concept of Crypto-Shredding

Crypto-shredding is the technique of permanently destroying the encryption key that protects a dataset, rather than deleting the data itself, so the data becomes unrecoverable in practice. It matters because it lets organizations satisfy “right to erasure” requests (GDPR Article 17) across backups and replicas without hunting down every copy. Recommended action: use your cloud KMS’s native key-destruction workflow with a deliberate waiting period, and pair it with strong encryption so the technique is actually sound.

Published: August 2021. Updated: August 2026. Reviewed by Encryption Consulting’s Cloud Key Management Team.

For how GDPR’s broader compliance obligations apply across cloud environments beyond key destruction alone, see our post Cloud Security Compliance Standards – PCI DSS and GDPR. For how the underlying KMS differs across providers, see AWS KMS Vs Azure Key Vault Vs GCP KMS.

What Is Crypto-Shredding?

Crypto-shredding is the technique of discarding the encryption key for a dataset without zeroizing or deleting the encrypted data itself, which makes that data permanently undecipherable in practice. Data protection has become a headline issue as breaches and stricter regulation have made encryption the default posture across industries, but encrypting everything creates a second problem: managing what happens to encrypted data once it needs to be destroyed.

Encrypted data generally falls into two categories. Active encrypted data is in current use by applications and handled within the normal security ecosystem. Passive encrypted data is not actively used and is a candidate for destruction, whether because a retention period expired or a data subject exercised a right to erasure. Crypto-shredding is the practical answer for the passive category.

Why Is Deleting Data for GDPR’s Right to Erasure So Difficult?

Data destruction is genuinely difficult to execute correctly when it is exercised as an individual’s right, particularly under data protection regulations such as GDPR Article 17. To honor the right to erasure literally, an organization has to locate every reference to a specific individual’s data across production databases, logs, backups, data warehouses, and any downstream export, then delete each copy. That is not a straightforward task: backups are often immutable by design for exactly the ransomware-resistance reasons that make them valuable, logs may be subject to a separate retention requirement, and a downstream analytics export may have already propagated the data somewhere the original system has no visibility into.

How Does Crypto-Shredding Solve the Data-Destruction Problem?

Crypto-shredding sidesteps the search-and-delete problem entirely. Since the data was encrypted before it was written anywhere, destroying the key makes every copy of that data (production, backup, log, export) undecipherable at once, without ever needing to locate each copy individually. If the encryption key is destroyed and no other copy of it exists, the data that key protected cannot be decrypted by anyone, anywhere it happens to still physically reside.

Two conditions have to hold for this to actually be sound. First, no other copy of the key can exist; a key escrowed in a second system, cached in an application process, or backed up separately defeats the entire technique. Second, the encryption algorithm itself has to remain unbroken; if the cipher protecting the data were breakable, it would already be marked deprecated by NIST or another standards body and should not have been in use to begin with, so this is a reasonable assumption for any currently approved algorithm (AES-256, for example). Given both conditions, crypto-shredding is functionally equivalent to deleting or zeroizing the data itself, even though the ciphertext bytes are still physically present on disk.

Practically, this changes what a “delete” request means at the infrastructure layer. When new data is created and is going to be stored, backed up, or replicated, it gets encrypted first, under a key scoped to that data (per-tenant, per-user, or per-record, depending on granularity requirements). When that data needs to be destroyed, the system does not search its infrastructure for every copy; it deletes the encryption key.

How Does Native vs. External Key Control Affect Crypto-Shredding?

Where the key lives determines how fast, how auditable, and how reversible a crypto-shredding operation actually is.

Key-control model	How destruction works	Best fit
Native cloud-managed (AWS KMS, Azure Key Vault, Google Cloud KMS)	The cloud provider enforces a mandatory waiting period before permanent destruction (see table below), during which the operation can be canceled.	Most workloads. Balances a genuine safety net against accidental/malicious deletion with an eventual, provider-enforced permanent destruction.
BYOK (customer-supplied key material, cloud-hosted)	Same provider-managed destruction workflow as native keys, but the organization retains its own copy of the original key material outside the cloud, which must also be destroyed for crypto-shredding to be complete.	Organizations that need to prove key provenance or portability but are comfortable with the cloud provider’s HSM custody day to day.
HYOK / external key manager (Cloud EKM, AWS External Key Store, Azure Managed HSM with an external root)	The cloud’s KMS key is a pointer to a key held by an external key manager; destroying the key at the external system takes effect immediately and is independent of the cloud’s own retention window.	Highly regulated data where an organization needs to demonstrate that it, not the cloud provider, held ultimate control over the destruction event, and where an immediate, provider-independent shred is a stated requirement.

Most organizations should rely on native cloud-managed key destruction with its built-in waiting period; it is auditable, reversible during the window, and requires no additional infrastructure. Move to an external/HYOK model only when a specific regulatory or contractual requirement calls for destruction that does not depend on the cloud provider’s own process.

How Should IAM Govern Who Can Destroy a Key?

Destroying a key is one of the few cryptographic operations with no undo once its waiting period expires, so its IAM model should be stricter than ordinary key-use permissions.

1. Separate “use the key” permissions (encrypt/decrypt) from “schedule destruction of the key” permissions; almost no identity needs both.
2. Require a documented, ticketed justification (a specific erasure request ID, a retention-policy expiration) before any key destruction is scheduled.
3. Use a second-approver or break-glass workflow for destruction requests on any key protecting more than one data subject’s records, since a mistaken bulk-key destruction is a data-loss incident, not just a privacy win.
4. Grant scheduled-destruction cancellation rights broadly (a security admin should always be able to stop an in-flight destruction quickly) even while destruction-initiation rights stay narrow.
5. Log every schedule, cancel, and completed-destruction event to a system the destroying identity cannot itself modify.

How Does Key Rotation Interact With Crypto-Shredding?

Rotation and crypto-shredding are opposite operations that are easy to conflate. Rotation creates a new active key version while intentionally preserving old versions so previously encrypted data stays decryptable; none of the three major cloud KMS products destroy old key versions automatically on rotation. Crypto-shredding is the deliberate, opposite action: destroying a specific key version on purpose so the data it protects becomes permanently unrecoverable.

The two interact in per-tenant or per-record encryption architectures: if a system rotates a shared key across many tenants’ data, an individual tenant’s crypto-shred request cannot destroy that shared key without also destroying every other tenant’s access. Fine-grained crypto-shredding requires fine-grained key architecture (one key, or one key version, per erasure-eligible unit of data) decided at design time, not retrofitted after the first erasure request arrives.

What Should You Log for Crypto-Shredding to Hold Up in an Audit?

• The erasure request that triggered destruction: the specific right-to-erasure ticket, retention-policy rule, or incident that justified the action.
• Schedule and cancellation events: who scheduled the destruction, when, and whether it was canceled before the waiting period expired.
• Completed-destruction confirmation: the timestamp the key became permanently unrecoverable, which is the evidentiary record for a completed erasure request.
• Mapping from key to data scope: which records, tenants, or data subjects that specific key protected, so an auditor can verify the destruction actually covered the erasure request’s scope.

What Does Crypto-Shredding Cost?

Crypto-shredding itself is not separately priced by any major cloud KMS; scheduling and completing key destruction is included in standard KMS operations. The real cost driver is architectural: supporting fine-grained crypto-shredding (one key per tenant or per record, rather than one shared key for an entire dataset) multiplies the number of active keys a KMS has to manage, and per-key or per-HSM-partition pricing (particularly for HSM-backed keys) scales with that count. A design that needs to crypto-shred individual customer records, not just entire datasets, should budget for a materially larger key inventory than a single-key-per-dataset design.

The encrypted data itself is not deleted by crypto-shredding, so storage costs for that now-permanently-inaccessible ciphertext continue until a separate storage-lifecycle policy removes it. Factor that ongoing storage cost into a retention policy rather than assuming crypto-shredding alone closes out the cost of retaining the data.

What Does Multi-Cloud Crypto-Shredding Architecture Look Like?

Each major cloud implements native key destruction with a similar shape but different specifics, which matters for an organization trying to run one consistent erasure process across all three.

Cloud	Default waiting period	Configurable range
AWS KMS	30 days	7-30 days
Azure Key Vault (soft-delete)	90 days	7-90 days, set only at vault creation
Google Cloud KMS	30 days	Customizable per key at creation; organizations can enforce a minimum via an org policy constraint

A multi-cloud erasure workflow (a single customer’s data spread across AWS, Azure, and GCP) has to account for the fact that Azure’s default retention window is three times longer than AWS’s or GCP’s, which matters when reporting a completion date for a GDPR erasure request that spans clouds. Standardize on the shortest compliant window your risk tolerance allows across all three, rather than reporting three different completion dates to the same data subject.

What Are the Limitations of Crypto-Shredding?

• It only works if the encryption was strong and no key escrow or backup copy exists; a weak cipher or an overlooked key backup makes the “destruction” cosmetic.
• The encrypted data itself still occupies storage and still requires its own lifecycle/retention decision.
• No major standards body (NIST included) currently prescribes crypto-shredding as a certified data-sanitization method; NIST SP 800-88 Rev. 1 remains the reference standard for media sanitization, and organizations that need a certifiable sanitization claim should evaluate against that standard directly rather than relying on crypto-shredding alone.
• Fine-grained (per-record) crypto-shredding requires the key architecture to be designed for it up front; it cannot be cleanly retrofitted onto a system built around one shared key.

Decision Checklist: Implementing Crypto-Shredding

1. Confirm every dataset that might need individual erasure is encrypted under its own key or key version, not a dataset-wide shared key.
2. Choose native cloud-managed key destruction as the default; reserve external/HYOK destruction for cases with a specific provider-independence requirement.
3. Require a second approver and a documented justification for every key-destruction request.
4. Log the erasure request, the schedule/cancel events, and the completed-destruction confirmation as the audit trail for the erasure.
5. Pair key destruction with a separate storage-lifecycle policy so the now-undecipherable ciphertext does not linger indefinitely.

What Would Encryption Consulting Recommend?

The organizations that get burned by crypto-shredding are almost always the ones that designed their encryption architecture around one shared key per dataset, then discovered at the first individual erasure request that they could not shred one record without breaking every other record under the same key. Encryption Consulting’s Cloud Key Management services design the per-tenant or per-record key architecture, the destruction-approval workflow, and the audit trail needed to make a crypto-shredding-based erasure process defensible, and our HSM-as-a-Service offering gives that key inventory hardware-backed custody without the operational overhead of running HSMs directly.

Frequently Asked Questions

Is crypto-shredding an officially recognized data-sanitization standard?

No. There is no standard from NIST, GDPR, or another authority that formally prescribes crypto-shredding as a certified sanitization method. NIST Special Publication 800-88 Revision 1 remains the reference document for media sanitization generally, and organizations needing a certifiable claim should evaluate against that standard directly.

Does crypto-shredding satisfy GDPR’s right to erasure?

It is widely used as a practical mechanism to satisfy Article 17 requests, particularly across backups and replicas that would otherwise require locating and deleting every copy individually. It is a technical control, not a legal guarantee; whether it satisfies a specific regulator’s expectations depends on the encryption strength and the absence of any surviving key copy.

Can I crypto-shred a single customer’s data if it shares a key with other customers?

Not without destroying every other customer’s access to data under that same key. Fine-grained crypto-shredding requires a per-tenant or per-record key architecture designed in from the start.

How long does it take for a key to be permanently destroyed on AWS, Azure, or GCP?

AWS KMS defaults to a 30-day waiting period (configurable 7-30 days), Azure Key Vault’s soft-delete defaults to 90 days (configurable 7-90 days, set at vault creation), and Google Cloud KMS defaults to 30 days, adjustable per key and subject to any organization-policy minimum.

What happens to the encrypted data after the key is destroyed?

It stays exactly where it was, still occupying storage, but is permanently unreadable. Crypto-shredding does not delete or move the ciphertext; a separate storage-lifecycle policy is needed to eventually remove it.

Need help designing a key architecture that can actually support per-record crypto-shredding? Talk to Encryption Consulting’s Cloud Key Management team.

Resources

NIST SP 800-88 Rev. 1: Guidelines for Media Sanitization