A self encrypting drive (SED) is a storage drive that encrypts everything written to it in hardware, automatically, with no software to install and typically limited performance overhead. On paper, it is the easiest security win in computing: the encryption engine lives in the drive controller, media encryption keys are generally managed within the drive, and the user never notices any of it.
The last part of that sentence is also the problem. On most deployed SEDs, nobody notices the encryption, including an adversary, because the drive unlocks during normal startup and presents its data to whoever powered the machine on. The encryption is real. The protection depends entirely on what stands between power-on and data access, and by default, very little does.
This article explains how SEDs actually work, what the TCG Opal specification standardizes, the specific gap between an encrypted drive and a protected one, and what closes that gap, which for classified programs is defined precisely by the two-layer requirement of CSfC for data at rest.
A self encrypting drive is a drive, SSD or hard disk, with an onboard cryptographic engine that encrypts all data as it is written and decrypts it as it is read, transparently and continuously. The media encryption key is generated inside the drive and never leaves it, the encryption runs at the controller’s full speed, and the host system does not need to do anything for the encryption to happen, which is exactly what self means in the name.
Three properties follow from that design, and all three are genuinely valuable. Performance is effectively free, because dedicated hardware does the work. The drive-level encryption may operate transparently, but effective access protection still depends on configuration, because it is always on. And cryptographic erase becomes possible: destroy the key inside the drive and encrypted data becomes computationally inaccessible when all relevant keys are securely destroyed in an instant, a property that verified sanitization processes aligned with NIST SP 800-88 Rev. 2 build on.
What the design does not include, by itself, is any opinion about who gets access. That is a separate mechanism, and it is where most SED deployments quietly fail.
The direct answer: an SED manages two kinds of secrets, and the relationship between them is the entire security model. The media encryption key encrypts the data and never leaves the drive. An authentication credential, when one is configured and enforced, is what the drive requires before it will use that key to decrypt anything.
The Trusted Computing Group’s Opal specification, widely implemented as TCG Opal 2.0, is the industry standard for how drives expose this machinery to management software: how locking is enabled, how the drive is divided into lockable ranges, how credentials are set and presented, and how keys are managed and destroyed. Opal is why a fleet of SEDs from different manufacturers can be managed consistently, and an Opal-capable drive is the normal foundation for serious SED deployment.
The thing to be precise about: Opal standardizes the interface for locking, not the fact of it. An Opal drive with locking never enabled, or with authentication handled weakly, behaves like an unencrypted drive to anyone holding the hardware. The specification gives deployers excellent tools and no obligation to use them.
Here is the assumption that costs organizations their data: the drive is encrypted, so the data is safe if the device is lost. The assumption fails because of when a typical SED unlocks, which is at power-on, during normal startup, before anyone has proven who they are.
Walk the loss scenario through. A laptop with an SED is left in a vehicle, seized at a border, or captured with a platform. The adversary powers it on. The drive, doing exactly what it was configured to do, unlocks and presents decrypted data to the boot process. Every block was encrypted at rest with AES-256, and none of that mattered, because the question was never whether the data was encrypted. The question was what the drive demanded before decrypting, and the answer was nothing.
This is the same category of gap covered in FIPS is not CSfC: a validation that the cryptography is implemented correctly, FIPS 140-2 or 140-3, says nothing about whether anything enforces authentication before that cryptography unlocks. And it is compounded by a harder truth from published research into drive firmware, covered in encrypted is a claim: implementations vary, flaws have been found in fielded drives, and an architecture that trusts a single encryption mechanism trusts a single point of failure. The full comparison of where each encryption approach fails alone is in hardware encryption vs software encryption.
The answer is enforcement before the operating system exists. Pre-Boot Authentication is a small, dedicated environment that runs when the machine powers on, before any OS loads, and requires validated credentials, with multifactor options such as smart card plus PIN, before access to protected storage is enabled.
The ordering is what makes it work. Because PBA runs before the operating system, there is a reduced exposure to attacks against a running operating system, no login screen to bypass, and pre-boot firmware and authentication components still require appropriate security controls. The drive holds its key until the PBA validates the user, so a stolen machine stops at an authentication prompt and a removed drive is ciphertext in any other system. The useful mental model: the SED is the safe, and PBA is the lock. A safe without a lock is a container.
One precision point that classified programs cannot afford to blur: the drive and its PBA together form one layer of protection, the outer layer. The PBA is the hardware layer’s enforcement mechanism, not an independent second layer. Architectures that count drive plus PBA as two layers have one, and are a single flaw away from exposure.
For classified data at rest, the standard is explicit. The NSA’s CSfC applicable Data at Rest Capability Package requires two independent encryption layers, and in the architecture Cigent supports, they are:
Independence is the design’s whole point: no single vulnerability, in a drive firmware, a software stack, or an implementation, exposes the data, because breaking one layer still leaves the adversary facing a second built on different machinery. Note also that eligibility matters at the component level: not every SED qualifies, and the ones that do are listed on the NSA CSfC Components List in the hardware full drive encryption category, checkable in minutes on the public register.
For organizations below the classified threshold, the same logic scales down sensibly: an SED with enforced PBA is the difference between an encrypted drive and a protected device, and it is the configuration worth insisting on for any client fleet that leaves controlled space.
Cigent and Curtiss-Wright PacStar have collaborated on data-at-rest protection for rugged tactical edge systems. The public case study describes layered protection and Pre-Boot Authentication; exact component versions, solution registration, and the complete encryption-layer configuration should be confirmed before making deployment-specific claims.
Why it worked: the design never relied on the drive’s encryption alone. The hardware assumed it would someday be held by the wrong hands, and the architecture made that event survivable, which is the correct way to deploy a self encrypting drive and the only defensible way to deploy one carrying classified data.
A self encrypting drive gives you always-on, hardware-speed AES-256 encryption and cryptographic erase when properly implemented and verified, and those are real, valuable properties. What it does not give you, by default, is any control over who the drive decrypts for, and in the loss scenarios that actually happen, lost laptops, seized devices, captured platforms, that is the only property that matters.
Enforced Pre-Boot Authentication converts the encrypted drive into a protected one, and for classified data, the drive-plus-PBA outer layer is then paired with an independent software encryption inner layer per the CSfC DAR requirement. One layer of the pair, not two, is what the SED and its PBA provide, and programs that count correctly are the ones whose data survives capture, which is also, not incidentally, how they clear authorization.
If you are deciding whether your platforms meet that standard, the CSfC DAR Assessment maps your systems against the two-layer requirement in minutes and shows which layer your current drives actually cover.
What is a self encrypting drive? A self encrypting drive (SED) is a storage drive with an onboard cryptographic engine that encrypts all written data and decrypts it on read, automatically and at full speed. Media encryption keys are generally generated and protected within the drive, so encryption is always on and requires no host software.
Only if authentication is enforced before the drive unlocks. A typical SED unlocks during normal startup, so a thief who powers the machine on receives decrypted data. With enforced Pre-Boot Authentication, the drive withholds its encryption key until credentials are validated, which is the protection that matters.
TCG Opal is the Trusted Computing Group’s specification for managing self encrypting drives. It standardizes how drives expose locking, lockable ranges, credentials, and key management to software, so SEDs from different manufacturers can be managed consistently. Opal defines the interface for locking; deployments still have to enforce it.
They answer different questions. An SED describes architecture, encryption in the drive’s hardware. FIPS 140-2 or 140-3 validation certifies that a cryptographic module implements its cryptography correctly. A drive can be both, and neither property controls access: without enforced pre-boot authentication, either unlocks at power-on.
Pre-Boot Authentication (PBA) is a dedicated environment that runs before any operating system loads and requires validated credentials, including multifactor options such as smart card plus PIN, before access to protected storage is enabled. Because it runs pre-OS, authentication occurs before the main operating system loads, reducing exposure to attacks against that environment.
Not alone. The CSfC applicable Data at Rest Capability Package requires two independent encryption layers. A CSfC-listed SED with enforced PBA forms the outer layer, one layer, and independent software full drive encryption forms the inner. The drive and its PBA never count as two layers.
No in any practical sense. The encryption engine is dedicated silicon in the drive controller, designed to run at the interface’s full throughput, so reads and writes proceed at the drive’s rated speed. Always-on hardware encryption is one of the few security controls with effectively limited performance overhead.
Yes, and faster than conventional wiping. Cryptographic erase destroys the media encryption key inside the drive, rendering every stored block unreadable ciphertext when the operation completes successfully. Verified sanitization aligned with NIST SP 800-88 Rev. 2 pairs that with confirmation that the erase completed across all addressable storage.
No. Eligibility is specific: components used in CSfC solutions must be listed on the NSA CSfC Components List in the relevant category, hardware full drive encryption for the outer layer. The listing reflects NIAP Common Criteria evaluation and an agreement with NSA, and it is publicly checkable.
With enforced locking and PBA, the drive presents only ciphertext: access to protected data remains locked until required authentication succeeds, in any machine. Without enforced authentication, a removed drive can behave like an open one, which is precisely the gap this architecture exists to close.
Conner Crisafulli is a solutions engineer and cybersecurity professional at Cigent with a unique background bridging elite military operations and advanced data security. Before joining Cigent, Conner served six years as a U.S. Air Force Combat Controller, where he specialized in high-stakes mission planning, communication systems, and joint operations coordination/execution. Drawing from his experience in complex, contested environments, Conner now helps federal agencies and enterprise clients strengthen their data-at-rest protection strategies. At Cigent, he focuses on practical applications of self-encrypting drives (SEDs), pre-boot authentication (PBA), and various CSfC (commercial solutions for classified) technologies to safeguard sensitive data against evolving cyber threats.
