Self-Encrypting Drives Explained: SED, OPAL and Crypto Erase

A self-encrypting drive performs encryption in hardware on the drive itself, using a controller built into the device. Every write is encrypted and every read decrypted, always, with no software involvement.

How it works

The drive holds a media encryption key generated on the device and never leaving it. All data on the platters or flash is encrypted with that key from the factory onwards — there is no "enable encryption" step that rewrites existing data.

What changes when you enable security is that the media key is itself encrypted with an authentication key derived from a password or supplied by the platform. Without that, the drive will not release the media key and the stored data is unreadable.

Two consequences follow, and both are exam points.

Enabling encryption is instant. Nothing is re-encrypted; only the key wrapping changes. Compare this with software full-disk encryption, which must read and rewrite every block — hours on a large drive.

There is no performance penalty. The encryption happens in dedicated silicon in the data path at line rate, and the CPU does no work. Software encryption uses CPU cycles, though AES-NI instructions have narrowed that gap considerably.

Cryptographic erase

The feature that most often makes SEDs worth buying, and a reliable exam answer.

Because all data is encrypted with the media key, destroying that key renders the entire drive unreadable instantly. There is no overwriting, no multi-hour secure wipe, no degaussing.

This matters for three reasons. It takes seconds rather than hours, which is decisive when decommissioning a rack of servers. It works on SSDs, where overwriting is unreliable because wear levelling means you cannot be certain you have overwritten every physical cell. And it allows drives to be returned under warranty or sold on without physical destruction.

The related term is instant secure erase. If a question asks how to sanitise an SSD quickly and reliably, cryptographic erase is the answer — and note that degaussing does not work on SSDs, since there are no magnetic domains to disrupt.

The standards

TCG Opal is the Trusted Computing Group specification for self-encrypting client drives, defining how the drive is managed, how ranges are locked, and how pre-boot authentication works. Opal 2.0 is the current common version.

Microsoft eDrive builds on Opal so that BitLocker can hand encryption to the drive rather than doing it in software. When it works, you get BitLocker's management with the drive's performance.

Enterprise SSC is the data centre variant, oriented to whole-drive locking rather than user-managed ranges.

Opal also supports locking ranges — independently protected regions of the drive, so a pre-boot authentication area can be readable while the rest stays locked.

SED versus software encryption

Aspect	SED	Software FDE
Initial encryption	Instant	Hours
CPU cost	None	Some, reduced by AES-NI
Secure erase	Seconds, crypto erase	Full overwrite
Portability	Tied to that drive	Works on any drive
Auditability	Implementation is opaque	Open implementations available

The trust point is worth knowing. Several SED implementations have been found to have flawed key handling, and because the firmware is proprietary the weakness is not discoverable by inspection. Some organisations therefore run software encryption on top of an SED, accepting the performance cost for an auditable implementation.

What it does and does not protect

An SED protects data at rest against physical theft of the drive. Removed and put in another machine, it is unreadable.

It does not protect a running system. Once the drive is unlocked at boot, it decrypts transparently for anyone with access to the running operating system — including malware and any logged-in user. An SED is not a substitute for access control, and that limitation is frequently tested.

It also does nothing for data in transit or data in use.

Operational considerations

Key and password management is the real burden: a forgotten authentication key means the data is gone, so enterprise deployments use centralised key management with recovery. Pre-boot authentication is required to unlock before the OS loads. And drives must be tracked through disposal, with cryptographic erase performed and evidenced.

What to remember

An SED encrypts in hardware with a media key that never leaves the drive, so enabling protection is instant and costs no CPU. Cryptographic erase destroys the key and sanitises the drive in seconds — the correct method for SSDs, where degaussing does nothing. Opal is the governing standard. An SED protects against physical theft only; once booted, data is readable to the running system.

Related reading: Data retention and disposal · NTFS, EFS and BitLocker · M.2 SSDs