How encryption at rest works
Encryption at rest scrambles stored data so it is unreadable without a key. Two layers of keys are common: a data encryption key (DEK) actually encrypts the data, and a key encryption key (KEK), often derived from a password or held in a TPM, protects the DEK. Because re-encrypting terabytes is expensive, most systems never change the DEK; they protect and, when needed, destroy it.
Implementations vary in a way that matters for disposal. Hardware full-disk encryption lives in the drive itself (covered in depth in the self-encrypting drive explainer). Software encryption such as BitLocker, LUKS, or FileVault runs in the operating system. File-level encryption protects specific files rather than the whole volume. Each changes what a key deletion actually accomplishes.
Why deleting the key can equal erasure
Cryptographic erase works by destroying the key so the ciphertext can never be decrypted. When every byte on the medium was encrypted from first use and every copy of the key is gone, what remains is indistinguishable from random data, and NIST treats that key destruction as a Purge. The appeal is speed and scale: a single key operation sanitizes an entire drive in seconds, which is why it is attractive for large flash fleets and cloud storage.
The conditions that make it valid, and the traps that void it
Cryptographic erase is only as good as its preconditions, and each one is a place teams get burned.
- Encryption must have been on from first write. If encryption was enabled after data already existed, the earlier plaintext may persist in remapped or over-provisioned areas. Deleting the key does nothing to that residue, so crypto-erase alone is insufficient.
- Every copy of the key must be destroyed. Escrowed keys, backup copies, recovery keys in a directory service, and cloud key-management copies all defeat the erasure if any survive. You are only as erased as your most-forgotten key backup.
- The implementation must be trustworthy. A weak or flawed encryption implementation undermines the assurance. FIPS-validated implementations raise confidence; unknown ones lower it.
- You must be able to prove the above. If you cannot demonstrate the encryption history and key destruction, an auditor cannot accept crypto-erase as your control.
When any of these is uncertain, the defensible decision is to fall back to physical destruction rather than trust a key deletion you cannot substantiate.
When destruction is still the right call
For the highest-sensitivity data, for drives whose encryption history you cannot prove, for media that was not encrypted from first write, and for anything leaving your custody where you need unambiguous evidence, physical destruction remains the strongest option. Encryption and destruction are not either-or; encryption reduces risk during the drive's life and can enable a fast Purge, while destruction closes out the medium with the highest assurance. Many programs use crypto-erase or an SSD secure erase for redeployed drives and hard drive shredding for drives that leave the building, a split that regulated regimes such as HIPAA media disposal, PCI DSS media disposal, and CMMC media sanitization all accommodate. This is general guidance, not legal advice; confirm your obligations with counsel.
Key points
- Encryption at rest protects a DEK with a KEK, and cryptographic erase destroys the key rather than the data.
- NIST recognizes cryptographic erase as a Purge when the conditions are met.
- It is valid only if encryption was on from first write, every key copy is destroyed, and the implementation is trustworthy.
- Encryption turned on after data existed, or surviving key backups, void the erasure.
- For unprovable history or highest-sensitivity data leaving custody, physical destruction is still the right call.
Data Destruction Inc. helps you decide when a cryptographic erase is defensible and when a drive should be destroyed, then executes and documents whichever path applies. Where crypto-erase is valid we verify the conditions; where it is not, we destroy the media under tamper-evident chain of custody handled by trained, bonded, background-checked operators, with a serialized Certificate of Destruction provided within 24 hours after the destruction event is complete. To review an encrypted fleet, call (866) 850-7977.
FAQ
Is deleting the encryption key enough to erase a drive?
Only if the drive was encrypted from first write, every copy of the key is destroyed, and the encryption implementation is trustworthy. When those hold, NIST treats it as a Purge; when any is uncertain, deleting the key leaves recoverable data.
Does turning on BitLocker or FileVault make destruction unnecessary?
Not by itself. If encryption was enabled after data already existed, earlier plaintext can persist in hidden areas, and any surviving recovery key defeats the erasure. Software encryption reduces risk but does not automatically replace destruction.
What if encryption was turned on after data was already written?
Then cryptographic erase is not sufficient on its own, because the pre-encryption plaintext may remain in remapped or over-provisioned regions that deleting the key does not touch. Use a firmware sanitize command or physical destruction.
Are key backups a problem for cryptographic erase?
Yes. Escrowed keys, directory-service recovery keys, and cloud key-management copies all allow decryption if they survive. Cryptographic erase requires destroying every copy of the key.
When is destruction still required despite encryption?
For the highest-sensitivity data, for drives whose encryption history cannot be proven, for media not encrypted from first write, and for anything leaving custody where you need unambiguous audit evidence.
—