Commercial Solutions for Classified (CSfC) is an NSA program that enables U.S. government organizations to protect classified information using approved combinations of commercial security technologies as an alternative to relying exclusively on government-developed Type 1 cryptographic equipment. It provides a path for a defense program to field a laptop, a server, or an unmanned platform carrying classified data, provided the architecture follows the program’s requirements and receives the necessary approvals. CSfC addresses the need to protect classified information across increasingly diverse systems and mission environments, using layered commercial security technologies that meet NSA requirements. For data at rest, this includes protecting information when equipment is lost, seized, or captured.
Understanding CSfC requires distinguishing between its core requirements, including component listing, solution registration, Capability Packages, and Protection Profiles. Each serves a specific purpose in determining how commercial security products can be used to protect classified information. Misinterpreting these requirements can lead to architectural gaps, compliance challenges, and security risks, particularly in environments where equipment may be lost or captured.
This guide explains the fundamentals of NSA’s CSfC program, including its purpose, component eligibility, Capability Package requirements, and the two-layer approach to protecting classified data at rest. It provides security architects, program engineers, ISSMs, and systems integrators with a clearer understanding of the requirements for designing and implementing CSfC solutions.
Commercial Solutions for Classified (CSfC) is an NSA program that allows properly configured, layered combinations of commercial off-the-shelf products to protect classified National Security Systems data. Instead of relying exclusively on government-developed Type 1 cryptographic devices, a program can implement two independent commercial encryption layers that meet NSA’s published security requirements.
The program rests on a straightforward piece of risk logic. No single commercial encryption implementation should be the sole protection for classified information within a CSfC layered solution. Two independent layers, configured according to NSA requirements, reduce the risk that a vulnerability or compromise affecting one layer will expose the protected data. Independence is intended to limit shared failure modes, although layered encryption does not eliminate every potential security vulnerability.
CSfC matters because it provides an alternative to relying exclusively on specialized government-developed cryptographic equipment. Commercial hardware can offer greater product choice, procurement flexibility, and shorter technology refresh cycles, although actual costs and deployment timelines depend on integration, evaluation, registration, and authorization requirements. For data at rest specifically, CSfC provides a framework for protecting classified information on laptops, deployable servers, and other mission systems, including equipment operating outside controlled facilities.
The direct answer: government-developed cryptographic equipment was not always the most practical way to meet the expanding demand for classified computing capabilities. Type 1 devices remain important for missions requiring their particular security properties, but they are purpose-built, controlled items with specialized acquisition and integration requirements. Commercial technologies provide additional options for protecting classified information across laptops, vehicles, unmanned platforms, and other systems used by the modern force.
Meanwhile, the commercial security market matured. Hardware encryption became a standard drive feature, software encryption capabilities expanded, and the Common Criteria evaluation system gave NSA a structured way to assess commercial products against defined security requirements. CSfC is the mechanism that allows government programs to incorporate qualifying commercial technologies into architectures designed to protect classified information.
The trade is explicit, programs gain access to a broader selection of commercial technologies and potentially greater deployment flexibility. NSA establishes requirements through the Components List, Capability Packages, and solution registration process, while government Authorizing Officials remain responsible for accepting operational risk and authorizing systems. Understanding CSfC means understanding how these responsibilities work together.
Here is the distinction that separates teams who know the program from teams who do not: CSfC does not issue a separate certification for products or complete solutions. Components are listed on the NSA CSfC Components List. Assembled solutions are registered with NSA. A vendor claiming to be “CSfC certified” is using terminology the program does not formally issue, and procurement reviewers should recognize the distinction.
Specific Cigent products appear on the NSA CSfC Components List in defined categories, including Cigent PBA Software v2.0 for Authorization Acquisition (AA), Cigent PBA Software with M.2 2230 SSD for AA and Encryption Engine (EE), and listed configurations of Cigent M.2 2280, U.2, and E3.S Secure SSDs for EE. Program teams should verify the exact product version, category, configuration, and current status on NSA’s Components List. An EE-only listing does not by itself satisfy every requirement of a complete encryption layer.
The Components List is NSA’s public register of commercial products eligible for use in CSfC solutions, organized by component category. A product gets there through defined evaluation and program requirements, and stays there only through continued compliance with applicable obligations.
Gate one is NIAP evaluation. The National Information Assurance Partnership (NIAP) oversees Common Criteria evaluation in the United States. Products are evaluated by accredited laboratories against applicable Protection Profiles, standardized requirement sets for their product classes. Depending on the product, these requirements address security functionality such as encryption, authentication, key management, and other relevant controls. NIAP validation is an important prerequisite for applicable CSfC components, but it does not independently establish that a complete solution meets CSfC requirements.
Gate two is the agreement with NSA. The vendor must satisfy the CSfC program’s additional obligations, including the applicable Memorandum of Agreement. These obligations support the continued eligibility and maintenance of components used in CSfC architectures. Products that satisfy the applicable requirements may appear on the Components List in their designated categories.
Then the listing has to be kept. Product versions, evaluation status, vendor obligations, and other program requirements can affect continued eligibility. That is why a program team verifies a component’s current status on NSA’s published list at design time rather than relying on a datasheet from two years ago.
For data at rest, relevant component categories include Encryption Engines (EE) and Authorization Acquisition (AA). The specific components and functions required depend on the selected DAR solution design and the configuration requirements established by the Capability Package.
A Capability Package (CP) is NSA’s published architecture specification for one class of CSfC solution. It defines which component categories are required, how protection layers must be composed and configured, and what independence between them means. The published solution areas include:
The Data at Rest Capability Package, currently v5.1.0, establishes requirements for protecting classified information stored on computing and storage devices. Unlike Capability Packages primarily focused on protecting data in transit, the DAR Capability Package addresses stored information, including threats associated with loss, theft, removal, or physical compromise of equipment. Its requirements are intended to protect the confidentiality of stored data when the device is powered off or in an unauthenticated state.
The DAR Capability Package does not eliminate every risk associated with physical compromise. In particular, protection of stored data confidentiality should not be confused with guaranteeing the integrity of a device after it has been outside authorized control. Programs must consider those distinctions when determining how equipment can be returned to trusted operation.
Version 5.1.0 also addresses additional implementation options, including software/software full drive encryption, guidance for virtualization, expanded location-based security considerations, and additional multifactor authentication use cases.
A CP is not a suggestion or a starting point for negotiation. Solutions are registered against applicable Capability Package requirements, including approved deviations where permitted. The published requirements, available through NSA’s Capability Packages page, establish the security controls, configuration conditions, and architectural expectations against which solutions are evaluated.
The DAR Capability Package v5.1.0 requires two independent encryption layers and specifies permitted solution designs, component requirements, and configuration conditions. One architecture Cigent supports pairs hardware full drive encryption and Pre-Boot Authentication with independent software full drive encryption. The package also addresses a software/software full drive encryption design.
The outer layer is hardware full drive encryption combined with Pre-Boot Authentication. In Cigent’s hardware/software architecture, a secure self-encrypting drive uses hardware-based AES-256 encryption to protect stored information. Pre-Boot Authentication requires successful authentication before access to encrypted storage is authorized. Depending on the implementation, authentication may authorize use of a cryptographic key or unlock an encryption engine rather than cause the drive to release a key. A useful analogy: the drive is the safe, and Pre-Boot Authentication is the lock. Both must be configured correctly to provide the intended protection.
The inner layer is independent software full drive encryption. Cigent Software Full Drive Encryption provides a separate encryption layer with its own cryptographic implementation and key management. Within a properly configured hardware/software DAR architecture, it protects data independently of the hardware encryption layer and implements the authentication controls required for the selected solution design. The precise authentication sequence and configuration must be validated against the applicable Capability Package requirements.
The drive and its PBA are one layer, not two. Pre-Boot Authentication provides access control for the hardware encryption layer. It does not independently constitute a second encryption layer. An architecture that counts an encrypted drive plus PBA as its two encryption layers is missing the additional independent protection required by the hardware/software solution design.
Independence is the point of the second layer. Independent encryption layers are designed to reduce the risk that a vulnerability or compromise affecting one layer will expose classified data. The DAR Capability Package establishes specific independence requirements intended to limit shared failure modes between the layers. Appropriate separation of cryptographic implementations, key management, authentication, and other dependencies is essential to meeting those requirements. Independence reduces risk but does not guarantee protection against every possible vulnerability or operational compromise.
Hardware/software encryption is not the only design addressed by DAR CP v5.1.0. The Capability Package also includes a software/software full drive encryption solution design. Organizations must evaluate their selected configuration against the applicable requirements rather than assuming every CSfC DAR solution must use the same hardware and software combination.
The full Cigent architecture, including how it can be applied across laptops, servers, and embedded platforms, is described on the data at rest protection solution page.
The division of responsibility is straightforward; vendors qualify components for listing, implementing organizations design and document solutions, NSA reviews solution registrations, and the government Authorizing Official accepts operational risk and authorizes the resulting system. These responsibilities overlap during the registration process, and compliance depends on the complete implementation rather than the product list alone.
One practical consequence for program teams is that buying listed components is only the beginning. The questions that affect the timeline are architectural, including which Capability Package version applies, how the layers are composed, how authentication and key management are implemented, and how the system will be maintained throughout its lifecycle.
Programs must also address applicable media sanitization and end-of-life data handling requirements. NIST SP 800-88 Revision 2 provides guidance for media sanitization, but the specific controls, verification procedures, and documentation required depend on the applicable security policies, system requirements, and authorization decisions. These considerations should be addressed during solution planning rather than left until the system is ready for review.
FIPS 140-2 and 140-3 validation is necessary context and a persistent source of false confidence, so it deserves precise placement. FIPS validation, conducted through NIST’s Cryptographic Module Validation Program, evaluates cryptographic modules against defined security requirements, including relevant implementation, operational, authentication, and key management controls. It does not independently validate an entire data-at-rest architecture.
The assumption that trips up programs goes like this: the drive is FIPS validated, therefore the data on it is adequately protected. But a FIPS-validated self-encrypting drive does not automatically establish that access is appropriately controlled. Some drives support authentication-based locking, while others may be deployed without sufficient access restrictions. Effective protection depends on authentication, key management, configuration, and the broader security architecture, as well as the validated cryptographic module.
That is why CSfC treats cryptographic validation as an ingredient rather than a complete solution. The DAR Capability Package establishes requirements for approved cryptography, authentication, key management, configuration, and independent encryption layers. FIPS validation evaluates a cryptographic module within its defined boundary, while CSfC establishes requirements for the complete solution architecture.
NSPM-12, signed June 12, 2026, addressed governance and cybersecurity responsibilities for National Security Systems, including the roles of the Committee on National Security Systems and NSA. It reinforces the importance of defined cybersecurity responsibilities and accountable security decisions. It does not, by itself, establish a universal CSfC Data at Rest deployment deadline or require every National Security System to implement CSfC.
For programs evaluating classified data-at-rest protection, CSfC provides an established framework with published requirements in the DAR Capability Package, a public component register through the Components List, and eligible commercial products. Whether a particular system must implement CSfC depends on the mission, applicable policies, system architecture, and government authorization decisions.
That framework can help organizations evaluate security options without developing every element of an architecture from the ground up. However, CSfC implementation still requires engineering, component selection, configuration, testing, registration, and authorization. The strongest reason to evaluate appropriate protection remains operational: equipment can be lost or captured, and the classified information stored on it must remain protected against unauthorized access.
Cigent and Curtiss-Wright PacStar collaborated on data-at-rest protection capabilities for tactical edge systems, deployable platforms that may operate disconnected or in contested environments, where loss or capture of hardware is a planning consideration.
The combined approach brings secure storage and Pre-Boot Authentication to rugged PacStar systems and can support an independent software full drive encryption layer. A CSfC-aligned design does not by itself establish that a specific configuration has been registered with NSA or authorized for classified operation. The collaboration is described in the Protecting Classified Data at the Tactical Edge case study.
The approach illustrates how eligible commercial security components and published Capability Package requirements can inform the design of rugged mission systems. Each classified deployment must still satisfy the applicable configuration, registration, and authorization requirements. The availability of a supported architecture should not be confused with confirmation that every implementation has completed those processes.
CSfC is the NSA’s answer to a question every classified program eventually faces, how do you protect classified information on commercial hardware without relying on a single commercial encryption implementation? The answer is layered independence, supported by a Components List that identifies eligible products, Capability Packages that define approved solution architectures, and a registration process that works alongside government authorization.
Components are listed, solutions are registered, and authorization belongs to the AO. CSfC does not issue a separate certification for complete solutions. For data at rest, one supported design pairs a secure encrypted drive gated by Pre-Boot Authentication with independent software encryption. The drive plus PBA count as one encryption layer, and the complete configuration must meet the applicable DAR Capability Package requirements. Other supported designs, including software/software encryption, must satisfy their own applicable requirements.
If you are evaluating your platform against these requirements, the CSfC DAR Assessment provides a starting point for identifying gaps in your current data-at-rest protection architecture and determining where additional controls may be needed.
CSfC stands for Commercial Solutions for Classified, an NSA program that allows layered combinations of commercial products to protect classified National Security Systems data. It defines which products qualify through the Components List and how they must be assembled through published Capability Packages, providing an alternative to relying exclusively on government-developed Type 1 equipment.
No. CSfC does not issue a separate certification for products or complete solutions. Components are listed on the NSA CSfC Components List after satisfying applicable evaluation and program requirements, and assembled solutions are registered with NSA. Government authorization to operate is a separate responsibility of the appropriate Authorizing Official.
It is NSA’s public register of commercial products eligible for use in CSfC solutions, organized by component category. Applicable products must satisfy NIAP Common Criteria evaluation and NSA program requirements, including the relevant vendor agreement. Listings apply to specific versions and configurations and must be maintained.
A Capability Package is NSA’s published architecture specification for one class of CSfC solution. It defines applicable component categories, layer composition, configuration, and independence requirements. Published solution areas include Mobile Access, Campus WLAN, Multi-Site Connectivity, Data at Rest, and Tactical, with solutions registered against the relevant requirements and approved deviations where applicable.
The Data at Rest Capability Package v5.1.0 requires two independent encryption layers. One supported design combines hardware full drive encryption gated by Pre-Boot Authentication with independent software full drive encryption. The drive and PBA together form one layer, not two. The package also addresses software/software full drive encryption, with each design subject to its applicable requirements.
No. FIPS validation evaluates a cryptographic module against defined security requirements; it does not establish that the complete architecture meets CSfC requirements. Self-encrypting drives may support authentication-based locking, but effective protection depends on configuration, authentication, key management, and the broader system design. CSfC DAR solutions must satisfy the applicable independent encryption and security control requirements established by the Capability Package.
The government Authorizing Official is responsible for accepting operational risk and authorizing the system. The AO also participates in the CSfC registration process, including review and signature of required documentation. NSA’s CSfC Program Management Office separately reviews submitted solution registration materials and provides registration acknowledgement following the applicable process. Registration does not independently constitute authorization to operate.
A Trusted Integrator is an organization recognized by NSA to support the design, implementation, testing, and documentation of CSfC solutions. Using one is encouraged but not mandatory. Organizations with sufficient internal expertise may self-integrate, provided the solution satisfies the applicable Capability Package, registration, and authorization requirements.
Yes. CSfC Data at Rest architectures can be used to protect classified information stored on eligible unmanned systems, rugged computers, tactical servers, and other mission platforms. The DAR Capability Package addresses protection of stored information, including when devices are powered off or unauthenticated. Each deployment must satisfy the applicable architectural and authorization requirements. NSA also publishes a Tactical Capability Package addressing specified tactical communications use cases.
Start by identifying the classified information requiring protection, the systems storing it, and the encryption and authentication capabilities already in place. Evaluate the applicable DAR Capability Package designs, identify eligible components, and determine which additional controls or architectural changes are necessary. The CSfC DAR Assessment can help initiate that review and frame a more detailed discussion with your Authorizing Official and systems integrator.
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.
