Knowing how to protect data at rest starts with one uncomfortable assumption: the device will not stay in your hands. Laptops leave secure facilities. Servers sit in contested locations. Drives come out of unmanned platforms that did not come back. In federal and defense environments, protecting stored data means protecting it from the adversary who is holding the hardware.
That assumption changes the answer. Commercial guidance about data at rest tends to focus on cloud configurations, compliance checklists, and employee training. Those measures have their place, but none of them survives the moment a drive is removed from a captured device and connected to an adversary’s forensic workstation.
This article covers what actually protects data at rest under that threat model: the two-layer architecture the NSA’s Commercial Solutions for Classified (CSfC) program requires, why common approaches fall short of it, and how to close out the data lifecycle with sanitization you can verify.
Data at rest is data stored on a physical medium rather than moving across a network or being processed in memory. On federal and defense systems, that means the contents of SSDs and other storage in laptops, workstations, servers, vehicles, industrial control systems, and unmanned platforms.
The term causes confusion because commercial cloud security uses it differently. In cloud contexts, “data at rest” usually means objects in a storage bucket or database, and protecting it means configuring the provider’s encryption. In defense contexts, the data sits on hardware your program owns and your people carry, which means the protection has to live on the device itself. This article addresses the second meaning. If your requirement involves classified or sensitive mission data on physical systems, the standard that governs you is the NSA’s CSfC Data at Rest Capability Package, currently version 5.1.0.
An adversary who wants data in transit has to intercept it. An adversary who wants data at rest just has to take the device, and devices are increasingly where the mission puts them: forward-deployed, vehicle-mounted, airborne, or unattended.
Three scenarios dominate the federal threat model. The first is loss and theft, the laptop that disappears in transit or the drive that goes missing from a facility. The second is capture, the unmanned system or vehicle that ends up in adversary hands with its storage intact, mission data, flight logs, sensor captures and all. The third is end-of-life leakage, the retired or RMA’d drive that leaves custody with recoverable data still on it.
In each scenario, the adversary has time, physical possession, and forensic tooling. Network defenses are irrelevant. Whatever protection exists must already be on the drive, and it must not depend on the operating system, because the adversary will not boot your operating system.
The NSA’s answer to this threat model is architectural. The CSfC Data at Rest Capability Package requires two independent layers of encryption between the adversary and the data:
Layer one is hardware: an encrypted drive with pre-boot authentication. The drive encrypts everything it stores with AES-256 hardware encryption. Pre-boot authentication (PBA) is what makes that encryption meaningful. Before the operating system loads, before the drive releases its encryption key, the user must authenticate. Think of the drive as a safe and the PBA as the lock. A safe without a lock is a storage box. For a deeper treatment, see the critical role of pre-boot authentication.
Layer two is software: independent full drive encryption. A software FDE layer encrypts the data again, with its own authentication and its own cryptography, implemented with a different cryptographic library than the hardware layer. That independence is the point. If a vulnerability is ever found in one layer’s implementation, the second layer stands on different code, so one flaw cannot expose the data.
Two details in that design deserve emphasis, because they are the two things most often gotten wrong. First, the drive and the PBA are not separate layers; together they form the hardware layer, the locked safe. Second, the layers must be genuinely independent, in cryptographic implementation and in authentication, or the redundancy is an illusion. The full reasoning is laid out in why classified data at rest requires a CSfC architecture.
Operating-system encryption tools protect against casual access, but the unlock path runs through the operating system on the same machine, and it constitutes a single layer. An adversary with physical possession and time attacks that one path. This is why software-only encryption, whatever the product, does not satisfy the two-layer requirement on its own. The specifics are covered in the risk of relying on BitLocker for classified data at rest.
FIPS 140-2 and 140-3 validation means a drive’s cryptographic module was tested and validated by NIST’s Cryptographic Module Validation Program. That matters, but it validates the cryptography, not the security outcome. A self-encrypting drive without enforced pre-boot authentication unlocks during normal startup; power it on in the right conditions and the encryption is transparently bypassed, valid cryptography and all. A FIPS drive is a validated cryptographic library, not a data protection solution. The label answers “was the crypto tested,” not “is the data safe when the device is captured.”
Some programs treat possession as protection: the device stays in the vault, the vehicle, the secured facility. Custody fails exactly when protection matters most, because the loss scenarios above are, by definition, losses of custody. Custody is a compensating control until the day it isn’t, and the data has no second chance.
Within the two-layer architecture, authentication strength determines how much the layers are worth. A single credential is a single point of compromise, which is why multifactor approaches matter at the pre-boot stage, not just at the operating system login. Smart card plus PIN authentication at PBA means an adversary needs the physical credential and the knowledge factor before the hardware layer will release a key.
Zero-trust principles extend this inside the drive itself. Capabilities such as hidden partitions keep designated data ranges encrypted and invisible until step-up authentication unlocks them, so even an authenticated session does not expose everything the drive holds. Tamper-evident, encrypted access logs preserve the forensic record of what was touched, which matters both for insider-threat response and for demonstrating to an Authorizing Official that access is controlled and auditable.
How to protect data at rest is also a question about the end of the data’s life. Drives get retired, repurposed, returned under warranty, and left behind. Data that was encrypted for years can still leak in an afternoon if the drive leaves custody unsanitized.
The governing reference is NIST Special Publication 800-88 Rev. 2, which defines media sanitization methods including cryptographic erase and block erase. The gap in most sanitization practice is verification: issuing an erase command is not the same as confirming that every addressable block was actually erased. Firmware-level verification, which reads back the state of the media after sanitization, turns “we sent the erase command” into “we can demonstrate the data is gone,” which is the difference an assessor cares about. The mechanics are covered in using storage firmware to verify complete drive erasure.
For high-volume environments, sanitization that can be executed locally, remotely, or automatically also changes the economics of decommissioning, because verified erasure allows drives to be safely repurposed rather than physically destroyed.
Protection at this standard is procurable, not theoretical. Cigent’s approach implements both CSfC DAR layers as one integrated solution: AES-256 hardware-encrypted storage with enforced pre-boot and multifactor authentication as the hardware layer, and independent software full drive encryption as the software layer, with verified data sanitization closing the lifecycle.
The validation trail is public. Cigent components are listed on the NSA CSfC Components List for protecting classified data at rest, with security functionality validated through NIAP Common Criteria evaluation and cryptographic algorithms validated under NIST programs. Cigent solutions have been tested and validated by organizations including MITRE, NIST, NSA, NIAP, and the U.S. Air Force, and are deployed across U.S. Intelligence agencies, U.S. Defense services, and the defense industrial base. Availability spans client, enterprise, and embedded form factors, from M.2 and 2.5 inch SATA through U.2 and E3.S, so the same architecture covers laptops, servers, and unmanned platforms.
Protecting data at rest on federal and defense systems means designing for the day the hardware is in the wrong hands. That standard rules out single-layer answers: software encryption alone, a FIPS label alone, custody alone. What meets it is the architecture the CSfC Data at Rest Capability Package requires, an encrypted drive that will not unlock without pre-boot authentication, wrapped by an independent software encryption layer, finished by sanitization you can verify.
The practical question for any program is where its current approach stands against that standard. The fastest way to find out is the CSfC for DAR assessment, a short evaluation that maps your platform and requirement against the two-layer architecture and shows where the gaps are.
Data at rest is data stored on physical media such as SSDs, rather than moving across a network or being processed in memory. In federal environments it means the contents of drives in laptops, servers, vehicles, and unmanned systems, where the primary threat is an adversary gaining physical access to the device.
Encrypt it in two independent layers and control who can unlock each one. The NSA CSfC approach pairs a hardware-encrypted drive gated by pre-boot authentication with independent software full drive encryption, so the data stays protected even if the device is lost, stolen, or captured.
Data in transit moves across a network and is protected by transport encryption such as TLS or VPNs. Data at rest sits on storage media and is protected by encryption on the device itself. The two face different adversaries: interception in transit, physical access at rest.
Because encryption only protects data while it is locked. A self-encrypting drive without pre-boot authentication releases its key during normal startup, so an adversary with the device can simply power it on. Authentication before boot, plus an independent second layer, is what makes the encryption hold.
Pre-boot authentication (PBA) requires the user to authenticate before the operating system loads and before the drive releases its encryption key. It removes the operating system from the trust chain, so an adversary cannot bypass protection by booting different software or moving the drive to another machine.
The CSfC DAR Capability Package, currently version 5.1.0, requires two independent encryption layers for protecting classified data at rest: a hardware full drive encryption layer with pre-boot authentication, and a software full drive encryption layer, implemented with independent cryptography so no single vulnerability affects both.
Not by itself. FIPS validation confirms the drive’s cryptographic module was tested under NIST’s validation program. It does not add authentication or a second layer. Without enforced pre-boot authentication, a FIPS-validated self-encrypting drive still unlocks during normal startup, which is why CSfC requires the layered architecture.
Following NIST SP 800-88 Rev. 2, using cryptographic erase or block erase appropriate to the media and data sensitivity, and then verifying the result. Firmware-level verification that reads back every addressable block confirms the erasure actually completed, which allows drives to be repurposed or retired with evidence.
Custody reduces exposure but is not protection, because the scenarios that matter, loss, theft, and capture, are all failures of custody. Programs operating at the tactical edge should assume the device can leave their control and rely on layered encryption that keeps working after it does.
Any platform that stores mission data and can leave your control: servers and NAS in forward locations, manned and unmanned vehicles, industrial control systems, and embedded systems. Unmanned platforms deserve particular attention because capture is a designed-for scenario rather than an edge case.
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.
