An SSD can store ciphertext, lock when powered off, request a password, and report that encryption is enabled. None of those behaviors, by themselves, prove that the drive’s encryption has been implemented securely.
For organizations that design, manufacture, integrate, maintain, or deploy mission systems, that distinction matters. Tactical compute systems, ground control stations, manned and unmanned platforms, vehicle and weapon systems, rugged workstations, servers, and embedded devices can operate as part of National Security Systems and carry sensitive or classified mission data. If one of those systems is lost, captured, abandoned, or removed from authorized control, the storage device can become a direct target for forensic analysis.
That is the central lesson of a new technical white paper from CPR Tools, a leading storage forensics and data recovery laboratory, When “Encrypted” Isn’t: Specification Noncompliance and Vulnerability in Self-Encrypting Drives. The paper examines documented weaknesses in widely deployed self-encrypting drives (SEDs), explains how CPR Tools engineers reproduced the findings in their own forensic lab, and considers what those weaknesses mean for data-at-rest protection, media sanitization, procurement, and lifecycle management.
The conclusion is not that organizations should abandon hardware full-drive encryption. Properly implemented and evaluated SEDs establish an important security boundary below the operating system. The lesson is that “hardware encrypted” describes a capability, not proof that the drive’s key management, firmware, and complete security architecture provide the required assurance.
A self-encrypting drive uses a cryptographic engine inside the storage device to encrypt data written to the media and decrypt it when authorized. The model depends on more than a strong algorithm such as AES. It also depends on how the media-encryption key is generated, stored, protected, and made available.
One especially important assumption is that the key protecting the data is cryptographically bound to the user’s credentials. If that relationship is missing or weak, the password may function as little more than an access check. The drive can still behave normally, while an attacker capable of manipulating its controller may be able to bypass that check or recover the key without the password.
In that situation, AES has not been broken. The implementation around AES has failed. Functional checks can confirm that encryption is enabled. They cannot establish that the underlying key-management design is cryptographically sound.
The CPR Tools paper builds on research presented by Carlo Meijer and Bernard van Gastel at the 2019 IEEE Symposium on Security and Privacy. The researchers reverse-engineered SSD firmware from several major manufacturers and demonstrated recovery of user data without knowledge of the password on multiple products sold between 2014 and 2018.
The documented failure modes included encryption keys that were not cryptographically tied to user credentials, keys wrapped with an empty or zero password, older key material recoverable from wear-leveled flash, and vendor-specific locking schemes that did not securely govern access to the media key. CERT/CC Vulnerability Note VU#395981 documents the findings, affected products, and related CVEs.
These were not simple remote attacks. Exploitation generally required physical access, controller-level techniques, vendor diagnostic capabilities, or forensic-lab expertise. That distinction narrows the threat, but it does not make the findings irrelevant. Physical capture and prolonged access are realistic concerns for mission systems that may operate outside secure facilities or continuous physical control.
CPR Tools reports that its engineers reproduced the findings in its own forensic lab. That validation carries particular weight because CPR Tools brings extensive expertise in storage forensics, data recovery, and the analysis of storage-device behavior at the hardware and firmware level. Its engineers did not simply summarize previously published research; they reproduced the findings using forensic-lab techniques and evaluated their implications for real-world storage systems. That operational validation is what makes the paper particularly useful: It connects published research to real procurement, recovery, and sanitization decisions. The documented products were specific models and configurations, and the findings do not establish that every SED is vulnerable. They demonstrate why a technology label or feature claim cannot substitute for evidence about the exact product, firmware, and configuration being trusted.
Mission systems often operate where network connectivity and continuous physical control cannot be assured. If a platform, tactical server, ground control station, or rugged endpoint is lost, captured, or abandoned, an adversary may gain unrestricted access to the complete system. Data protection must travel with the device and remain effective without relying on a remote response.
For organizations that design, build, maintain, and deploy these systems, the objective cannot be merely to include an encrypted SSD. Effective protection requires a verified hardware-encryption boundary, meaningful authentication before storage becomes available, and an independent second layer that prevents one component from becoming a single point of failure.
The benefit is straightforward: Loss of the hardware does not have to mean loss of the mission data. Even if an adversary controls the device, removes its storage, attempts an alternate boot, or studies it in a forensic lab, the architecture can continue placing independent barriers between the adversary and the protected information.
The findings also show how one component’s assumptions can propagate through a larger system. At the time, Windows BitLocker could delegate encryption to a drive that reported hardware-encryption support. On an affected SED, BitLocker could therefore rely on the drive’s vulnerable implementation instead of creating an independent software-encryption layer.
Microsoft responded with Security Advisory ADV180028 and changed Windows defaults in 2019 so that newly encrypted BitLocker volumes use software encryption unless policy specifies otherwise. The change did not retroactively re-encrypt volumes that had already been configured to use hardware encryption.
The lesson extends beyond BitLocker. When one product delegates protection to another, the system can inherit the trusted component’s weakness. That is one security boundary presented through two interfaces, not defense in depth. For mission systems, BitLocker should not be treated as a substitute for a layered CSfC Data-at-Rest architecture. The broader architectural lesson still applies. If the host, boot environment, or integrator trusts a drive solely because it reports encryption support, the complete mission system inherits that unverified assumption.
SED assurance affects more than protection while a device is deployed. It also affects what can be claimed when the device is sanitized. Cryptographic erase is intended to make stored data unrecoverable by sanitizing the keys needed to decrypt it. This assurance relies on proper key generation and protection, comprehensive coverage of all key copies, and confirmation that the target data cannot be feasibly recovered.
If key management is unclear or key material can be recovered from other sources, destroying the expected key does not guarantee data is unrecoverable. Sanitization must match the data’s sensitivity and the level of assurance for the specific drive and firmware, following NIST SP 800-88 Revision 2.
The practical response is not to abandon hardware full-drive encryption. It is to stop treating hardware encryption as a complete data-protection architecture. For organizations protecting sensitive and classified mission data, the following practices provide a stronger foundation:
The posture recommended by CPR Tools closely aligns with the architecture Cigent provides for protecting sensitive and classified mission data. Rather than treating an encrypted SSD as a complete solution, Cigent combines hardware encryption, authentication, and an independent software-encryption layer into an integrated Data-at-Rest protection architecture.
For classified National Security Systems, NSA’s Commercial Solutions for Classified Data-at-Rest Capability Package formalizes a defense-in-depth architecture using evaluated commercial components. The architecture separates the Encryption Engine (EE), which encrypts the data, from Authorization Acquisition (AA), which controls the authorization required to unlock it. It also uses independent outer and inner encryption layers to reduce reliance on any single implementation.
Cigent addresses these requirements through three complementary components:
Cigent Secure SSDs, Cigent PBA, and Cigent Software FDE are included on the NSA CSfC Components List for their applicable HWFDE and SWFDE roles. In approved configurations, these components support the independent outer and inner protection layers defined by the NSA for classified data at rest.
This gives mission-system manufacturers, integrators, program offices, and operators a coordinated path to layered protection using components designed to perform distinct security functions within the same architecture.
The CPR Tools white paper demonstrates why a drive’s encryption claim alone is not enough. For U.S. defense programs protecting classified data at rest, the practical path is to use NIAP-validated, NSA CSfC-listed components configured according to the CSfC Data-at-Rest Capability Package. This provides an independently evaluated foundation for high-assurance DAR and reduces reliance on vendor claims alone.
For sensitive and classified mission data, this approach combines validated hardware encryption, pre-boot access control, and an independent software-encryption layer within a defined architecture.
A mission system may be lost, captured, or removed from authorized control. Its data does not have to become accessible with it.
Download the complete CPR Tools white paper, When “Encrypted” Isn’t: Specification Noncompliance and Vulnerability in Self-Encrypting Drives, for the documented failure classes, affected drive models, testing context, and recommended actions.
To learn how Cigent combines secure SSDs, Pre-Boot Authentication, and Software Full Drive Encryption for layered mission-data protection, explore Cigent’s full-stack Data-at-Rest solution.
Kelvin Quezada is a Product Marketing Manager at Cigent, where he leads strategy, positioning, and go-to-market efforts for the company’s Data-at-Rest protection solutions. With more than a decade of experience across cybersecurity deployments, product marketing, and technical enablement, he translates complex technical concepts into clear, mission-focused value for defense programs.
