Commercial Solution for Classified Data at Rest
Protect Classified Data with Layered Commercial Security
Protection of classified information on edge devices is essential for maintaining mission integrity. The NSA Commercial Solutions for Classified (CSfC) program establishes the specific architectural requirements needed to secure Data at Rest (DAR) on modern endpoints.
Learn about the importance of data at rest security, NSA CSfC for DAR requirements, and best practices for meeting compliance and protecting classified data.
When selecting a vendor, note that they must satisfy strict criteria and complete extensive testing before appearing on the NSA CSfC Components List. Systems that properly implement layered CSfC Data at Rest protection are authorized to store classified information up to the Top Secret level.
Data at Rest
What is Data at Rest?
- Data in use: data on a device that is powered-on and authenticated.
- Data in transit: data being transmitted across networks, between systems, or to the cloud.
- Data at rest: data stored on a device that is powered off or pre-authentication.
Why is protecting DAR important?
What devices require protection?
- PCs and Workstations
- Servers
- Manned and Unmanned Vehicle
- Industrial Control Systems
Commercial Solution for Classified
What is NSA Commercial Solution for Classified?
The program focuses on secure, flexible, and cost-effective architectures that can be deployed more rapidly than traditional government-developed systems.
Key aspects of the program:
- Layered Security: CSfC DAR solutions rely on a "defense-in-depth" approach, requiring at least two independent layers of commercial encryption using National Security Agency (NSA)-approved algorithms (Commercial National Security Algorithm or CNSA Suite).
- Capability Packages (CPs): The NSA develops and publishes vendor-agnostic solution designs called Capability Packages (CPs). These documents provide the architectural and configuration guidance necessary for implementing secure solutions for specific use cases, such as Mobile Access, Campus Wireless LAN, Multi-Site Connectivity, and Data at Rest.
- Approved Components List: Only commercial products that have undergone rigorous security evaluations (via the National Information Assurance Partnership, or NIAP, using international Common Criteria standards) and are listed on the CSfC Components List can be used in a CSfC solution.
- Faster Deployment: By leveraging readily available commercial technology, the CSfC program significantly reduces the time it takes to field secure solutions.
- Trusted Integrators: While not mandatory, the NSA strongly encourages clients to work with vetted "Trusted Integrators" who specialize in designing, building, and testing CSfC-compliant solutions in accordance with the CPs.
CSfC for DAR Architecture
Recommended CSfC for DAR Architecture
While the Data-at-Rest Capability Package (v5.0) supports several valid combinations of encryption technologies, the most robust and widely adopted architecture for modern classified endpoints consists of Hardware Full Drive Encryption (HWFDE) with Pre-Boot Authentication as the outer layer, paired with Software Full Drive Encryption (SWFDE) as the inner layer. This design provides the strongest balance of cryptographic independence, operational reliability, and resilience against physical capture or tampering while fully aligning with CSfC’s layered protection model.
Outer Layer Protection: Hardware Full Drive Encryption (HWFDE) with Pre-Boot Authentication (PBA)
The outer layer establishes the earliest and broadest encryption boundary, protecting the entire storage device before the operating system begins to load.
HWFDE Using NSA-Approved Cryptography
HWFDE employs AES-256 through a FIPS-validated cryptographic module built directly into the storage device. Because encryption occurs entirely in hardware, it covers all data on the device—including file contents, metadata, paging files, hibernation files, temporary artifacts, and remnants—without relying on the integrity of the operating system. The encryption keys are generated and managed within the drive’s secure boundary, minimizing exposure to host-level attacks or OS-based vulnerabilities.
Pre-Boot Authentication (PBA)
PBA provides a secure authentication process that occurs before the OS boot sequence. By requiring users to authenticate in a minimal, trusted environment, PBA prevents attackers from intercepting passwords or manipulating the boot chain to bypass the encryption boundary. This pre-OS enforcement is a critical advantage for devices that may be lost, confiscated, or subjected to forensic analysis
Why this outer layer is recommended:
- Establishes the encryption boundary as early as possible in the boot process.
- Protects all on-device data uniformly, regardless of file type or system state.
- Remains resilient even if the OS, bootloader, or application stack is compromised.
- Reduces reliance on software trust anchors that may be targeted by advanced adversaries.
Inner Layer Protection: Software Full Drive Encryption (SWFDE)
The inner layer introduces a second, independently implemented encryption boundary that is cryptographically and operationally distinct from the hardware-based outer layer.
SWFDE Using Independent Cryptography
SWFDE applies AES-256 encryption through a separate FIPS-validated software cryptographic module. It uses its own key hierarchy, its own enforcement mechanism, and a completely different implementation path from the hardware layer. By maintaining this independence, SWFDE ensures that weaknesses or exploitation in one layer do not compromise the other.
Multifactor Authentication
SWFDE can incorporate additional authentication mechanisms such as PINs, passwords, smart cards, or hardware security tokens. While multifactor authentication is not required for every deployment, it provides an additional security option for environments where policy, mission needs, or operational conditions support it. MFA enhances the separation between layers without defining the functionality of SWFDE itself.
Why this inner layer is recommended:
- Provides a cryptographically independent second barrier.
- Uses a different codebase, key material, and execution path than HWFDE.
- Helps ensure resilience even if the hardware encryption layer is bypassed or compromised.
- Aligns with CSfC’s requirement for independent, separately implemented protections.
Why This Two-Layer Architecture Is Preferred
Pairing HWFDE with PBA as the outer layer and SWFDE as the inner layer creates a highly robust and widely adopted CSfC-aligned DAR solution. The hardware layer provides early, uniform, and tamper-resistant encryption enforcement, while the software layer introduces a second, logically distinct encryption boundary that relies on entirely separate cryptography and key management. Together, they establish a strong defense-in-depth architecture capable of protecting classified information, up to the Top Secret level, when implemented according to NSA guidance.
This architecture is especially well-suited for devices used in field operations, tactical environments, mobile missions, and other scenarios where physical loss, capture, or interdiction are realistic threats.
CSfC for DAR Benefits
Benefits of Utilizing CSfC for DAR
CSfC Data-at-Rest (DAR) protections provide strong, layered security for classified information up to the Top Secret level when implemented in accordance with NSA guidance. The program enables organizations to leverage commercial innovation while ensuring compliance with national security standards.
Key benefits include:
- Effective Data Protection: CSfC solutions use a defense-in-depth model requiring two independently implemented encryption layers built on Commercial National Security Algorithm (CNSA) Suite–approved cryptography. These independently enforced protections safeguard data, up to the Top Secret level, while it is stored or unauthenticated, reducing risk from capture, loss, or tampering.
- Faster Deployment and Time-to-Market: CSfC enables U.S. government agencies to use pre-approved, commercial-off-the-shelf (COTS) products within a secure, layered architecture.
- Cost Efficiency: By utilizing widely available commercial technology, agencies can achieve substantial cost savings compared to developing custom government encryption solutions. It also minimizes the cost and complexity of operations and maintenance (O&M) by relying on commercial tools and simplified update paths.
- Access to Modern Technology: The program enables the U.S. government to keep pace with rapid technological advancements in the commercial sector. This ensures that the latest, often superior, security capabilities and innovations are employed in their systems.
- Flexibility and Scalability: Allows agencies to tailor solutions to specific mission needs and environments. These solutions are more flexible and can be quickly scaled to adapt to evolving operational requirements.
- Simplified Logistics and Interoperability: Using COTS products simplifies equipment handling and security procedures. It also enables easier communication and data sharing with U.S. and coalition partners, without requiring them to take possession of sensitive government-developed equipment.
- Streamlined Compliance and Auditing: The use of predefined architectures, pre-approved components (validated through NIAP/Common Criteria processes), and clear documentation in the CPs makes compliance, auditing, and certification less burdensome.
CSfC | FIPS 140-3 | Common Criteria
Difference Between CSfC, FIPS 140-3, and Common Criteria
FIPS 140-2 & 140-3
The Federal Information Processing Standard (FIPS) 140-2/140-3 is a NIST standard that validates the cryptographic modules used in hardware, software, or firmware. FIPS validation ensures that the underlying cryptography is implemented correctly, keys are handled securely, and the module performs the required self-tests. It does not evaluate the full security behavior of a product; it only evaluates the cryptographic module within it.
FIPS 140-3 is the successor to FIPS 140-2 and aligns U.S. cryptographic module validation with modern ISO standards. Because many existing products were validated under 140-2 and those certificates remain active, both versions still appear in current documentation and deployed systems. Agencies can continue using 140-2–validated modules for the duration of their certificate lifecycles.
Common Criteria / NIAP
Common Criteria (ISO 15408) is an international framework for evaluating the complete security functionality of IT products. In the United States, these evaluations are performed through the National Information Assurance Partnership (NIAP), which publishes Protection Profiles for specific product categories such as hardware full-drive encryption, software full-drive encryption, file encryption, mobile platforms, VPNs, and more. To pass NIAP evaluation, a product’s cryptographic module must already be FIPS-validated, and the product must demonstrate correct security behavior against the requirements of its applicable Protection Profile.
CSfC
The NSA’s Commercial Solutions for Classified (CSfC) program builds on top of both FIPS and Common Criteria. CSfC does not certify individual cryptographic modules or evaluate product behavior directly. Instead, it allows only components that have already passed NIAP evaluation (which requires FIPS-validated crypto) to be used in layered architectures defined in the CSfC Capability Packages. Once a product completes its NIAP/Common Criteria evaluation, it becomes eligible for review by the NSA. If accepted, the solution is placed on the CSfC Components List, meaning it may be used as part of a registered CSfC solution.
How the Standards Work Together
In practice, the path to CSfC eligibility flows in one direction: a product must first implement FIPS-validated cryptography, then successfully complete NIAP/Common Criteria evaluation against the appropriate Protection Profile. Only after meeting these requirements can the product be considered for placement on the CSfC Components List. From there, agencies can use these approved components within the architectures defined in the CSfC Capability Packages, such as the Data-at-Rest Capability Package, to build solutions authorized to protect classified information. This layered process ensures that CSfC solutions sit atop products that have already passed the government’s highest cryptographic and functional security evaluations.
Additional Approaches
Additional DAR Protection Approaches
There are other DAR encryption solutions that protect data-at-rest. One of the most widely used in the commercial market is Microsoft BitLocker. BitLocker provides full-drive encryption but does not meet NSA Capability Package Requirements. And while file-level encryption (FE) and platform encryption (PE) are recognized by the Commercial Solutions for Classified (CSfC) program as permissible layer types, the number of products listed on the official CSfC Components List is extremely limited, and those currently listed are constrained to specific mobile devices and operating system environments.
All three of these protection methodologies are more vulnerable to advanced attacks than the full drive hardware and software encryption previously reviewed. BitLocker, FE, and PE each have vulnerabilities that a sophisticated adversary can readily exploit, making them less reliable options for protecting classified data.
BitLocker
BitLocker is a full-drive encryption feature embedded within Microsoft Windows. While a popular commercial solution, BitLocker is not authorized by the NSA for protecting classified data.
BitLocker is effective against basic threats but has key weaknesses:
- As part of the OS, BitLocker is vulnerable to sophisticated hardware-based attacks, such as cold-boot attacks and Trusted Platform Module (TPM) sniffing.
- Closed-source code that is not available for independent audits by cybersecurity experts or government agencies increases the likelihood of undetected vulnerabilities.
- Designed and optimized for enterprise management, sometimes at the expense of ensuring security (i.e., default configurations that automatically back up recovery keys to Active Directory).
File Encryption
File encryption encrypts the data contained within individual files, making each protected file unreadable without the correct decryption key. Although File Encryption (FE) is recognized in the CSfC Data-at-Rest Capability Package as a permissible inner-layer technology, its real-world applicability is extremely limited. Only a small number of FE implementations have completed Common Criteria evaluation, and the solutions currently appearing on CSfC-related listings are restricted to specific mobile device platforms rather than general-purpose laptops, servers, or endpoint systems.
FE has several inherent weaknesses, including incomplete data coverage, reliance on application behaviors, and exposure of metadata. Because FE operates higher in the software stack than full-drive encryption, it leaves file names, directory structures, temporary files, paging data, and other artifacts unprotected. This makes FE significantly more vulnerable to offline forensic analysis and targeted attacks by sophisticated adversaries.
Additionally, because each file must be encrypted and decrypted independently, FE can introduce computational overhead, particularly when handling large numbers of files or operating on devices with limited processing resources.
Platform Encryption
Platform Encryption (PE) provides data protection at a higher level in the technology stack, such as at the operating system, file system, or application layer. PE is recognized in the CSfC DAR Capability Package as an allowable layer only when paired with File Encryption. However, the availability of CSfC-listed PE components is extremely limited, and those that do exist apply only to specific mobile device ecosystems, not to general-purpose computing platforms.
PE introduces two significant security limitations:
- Dependency on the software stack: Platform encryption relies on the integrity of the operating system, drivers, and other platform components. A vulnerability in any of these layers could allow an attacker to bypass the encryption boundary or extract sensitive key material.
- Limited scope of protection: Platform encryption typically secures only selected files, regions, or objects rather than the entire storage device. Metadata, system files, temporary files, crash dumps, and other unencrypted artifacts can inadvertently expose sensitive information outside the protected boundary.