For Authorizing Officials and program managers supporting Department of War initiatives, storage encryption can appear deceptively simple.
A product specification says “FIPS validated.” The device uses strong encryption. The manufacturer calls it a secure drive. It is easy to conclude that the system is therefore ready to store classified information. That conclusion can create serious risk. FIPS validation addresses the security of a cryptographic component. NSA’s Commercial Solutions for Classified Data-at-Rest program defines how approved commercial components must work together as a complete architecture for protecting classified information. One is a standard, the other a solution to protect classified data-at-rest.
Think of a secure storage system as a vault. FIPS validation evaluates the cryptographic lock. CSfC defines the vault: which locks can be used, why independent layers are required, how users authenticate, how the components must be configured, and how the complete solution is managed. A validated lock is important. It does not make the entire vault secure.
FIPS 140-2 and its successor, FIPS 140-3, establish federal security requirements for cryptographic components. Validation provides evidence that a specific hardware or software cryptographic module was independently tested against those requirements.
For a non-technical decision-maker, the important point is scope: FIPS validation applies to a defined cryptographic component, not automatically to the complete device, application, or mission system containing it. It does not determine whether the system is suitable for classified information, whether the storage unlocks securely, how users authenticate, what happens when the device is captured, or whether the overall configuration follows an NSA-approved architecture. Program managers should also distinguish between a product described as “FIPS compliant” and a module that has completed formal validation. NIST recommends requesting the validation certificate number and verifying that it covers the specific version and configuration being acquired.
FIPS 140-3 is the current standard. FIPS 140-2 validations are moving to historical status as part of the federal transition, so new acquisitions should prioritize active FIPS 140-3 validations while following agency-specific guidance for existing systems.
A FIPS validation does not answer the larger operational questions an AO must consider:
These are system-level questions. FIPS validation alone does not resolve them.
Commercial Solutions for Classified is an NSA program that allows government organizations to use properly configured commercial technologies to protect classified information.
NSA publishes Capability Packages that define architectures, security requirements, configuration rules, and approved component categories for specific use cases.
For stored information, the relevant guidance is the CSfC Data-at-Rest Capability Package. The current DAR Capability Package is Version 5.1.0, approved in 2026. It provides designs and implementation guidance for protecting classified information on end-user devices and other DAR-protected systems.
Rather than evaluating only one cryptographic component, CSfC addresses how multiple commercial technologies must be assembled into a complete protection solution.
The central principle of CSfC DAR is defense in depth. NSA’s DAR architecture uses two independent layers of encryption to protect stored information while the system is powered off or remains unauthenticated. The user or platform must authenticate through both layers before the classified data becomes available. The second layer is not required because modern encryption algorithms are considered weak. It is intended to reduce the risk that a single configuration error, operator mistake, product vulnerability, or compromised security component exposes classified information. Depending on the approved design, a CSfC solution may combine hardware full-drive encryption with software full-drive encryption or use two independent software-encryption layers. The important point for an AO is straightforward: The security comes from the complete layered architecture, not from any single encrypted drive or software product.
The choice is not FIPS or CSfC.
FIPS helps establish that the cryptographic components have been properly validated. CSfC determines how eligible commercial components must be selected, configured, authenticated, and operated together to protect classified data.
| FIPS validation | CSfC Data at Rest |
|---|---|
| Evaluates a cryptographic component | Defines a complete protection architecture |
| Focuses on the security of the cryptography | Focuses on how the overall solution protects classified data |
| Applies to a specific version and configuration | Applies to an integrated, properly configured system |
| Does not authorize a complete system for classified storage | Provides an NSA-approved commercial framework |
| May apply to one component | Normally requires two independent protection layers |
A FIPS-validated drive may be one component of a CSfC solution. It is not, by itself, a CSfC DAR solution.
CSfC compliance does not result simply from purchasing two encryption products. Products must be selected from the applicable NSA CSfC Components List and support the chosen architecture. The implementing organization must then configure, integrate, document, test, administer, and maintain those components according to the Capability Package. NSA also requires CSfC solutions protecting National Security Systems to be registered. Registration allows NSA to acknowledge that the solution conforms to the applicable Capability Package.
Buying approved components without following the required architecture and configuration does not create a compliant solution.
The AO’s responsibility extends beyond confirming that encryption is present. NSA places responsibility on the implementing organization and AO to define when a device is considered outside the positive control of authorized users. That determination must reflect the mission and threat environment. The answer may differ across platforms. A laptop inside a controlled facility presents one risk. A tactical server in a vehicle presents another. An unmanned aircraft, unattended sensor, deployable command system, or edge-computing platform operating in contested territory creates a very different loss or capture scenario.
The AO should ask:
A product label cannot answer these questions. The security architecture must.
Data-at-rest protection can affect storage selection, operating systems, boot behavior, authentication, key management, performance, administration, and system maintenance. Waiting until authorization testing to address CSfC can force expensive redesign.
Program managers should establish the protection approach before the platform architecture is fixed:
This work should occur during requirements development and system design, not immediately before the Authority to Operate decision.
FIPS validation provides evidence that a particular cryptographic component meets defined security requirements. It does not establish that the complete system is approved to retain classified data. Organization with programs including classified data on endpoints should follow NSA’s CSfC DAR architecture, use eligible components, implement the required independent layers, and satisfy authentication and configuration requirements. A FIPS-validated encryption component may be an ingredient. CSfC is the recipe for turning validated commercial components into a defensible classified-data protection solution. For AOs and program managers, the practical rule is straightforward: If a system will retain classified information, do not ask only whether its encryption is FIPS validated. Ask whether the complete data-at-rest architecture follows the applicable NSA requirements for protecting classified data.
Brett Hansen, Cigent CEO, has 30 years of IT experience. Prior to joining Cigent, he held leadership positions with companies providing SaaS data solutions. He was also an executive at Dell for over a decade overseeing Client Software organization including developing and leading Dell Data Security business that provided integrated hardware and software security solutions. Brett started his career with IBM holding leadership positions with various software organizations focusing on IT management, development, and security.
