The CSfC Components List is the NSA’s public register of commercial products eligible for use in Commercial Solutions for Classified (CSfC) architectures. For programs building classified data protection solutions, the list provides a starting point for identifying products that have met applicable evaluation and program requirements. However, appearing on the list does not mean a product can be deployed in any configuration or that an assembled system automatically satisfies CSfC requirements.
That distinction matters during classified procurement and system design. Program teams may treat a listing as a general seal of approval, while vendors sometimes describe their products using terminology that does not reflect the NSA’s process. Listings also change over time, making it important to verify current eligibility rather than relying on older datasheets or procurement documents.
This article explains what a CSfC Components List entry establishes, how products qualify for listing, how component categories relate to data-at-rest architectures, and how defense organizations can verify vendor claims before selecting products for classified deployments.
The CSfC Components List is maintained by the National Security Agency (NSA) as part of its Commercial Solutions for Classified program. It identifies commercial products eligible to serve as components in architectures designed to protect classified information. The list is publicly available on the NSA Components List page, allowing government organizations, integrators, and procurement teams to verify vendor claims directly.
Each listing identifies a product and its vendor within a designated component category. These categories correspond to security functions that may be required by different CSfC Capability Packages, including encryption, authentication, and network protection. A product’s eligibility is therefore tied to its evaluated functionality and intended role within a solution.
The distinction between components and complete solutions is essential. A listed self-encrypting drive, software encryption product, or network security component represents one potential building block of a larger architecture. The complete solution must separately satisfy the applicable Capability Package requirements, follow NSA registration procedures, and undergo the responsible organization’s authorization process.
Consequently, a vendor’s statement that its product appears on the Components List is meaningful and independently verifiable. It does not establish that every system incorporating the product meets CSfC requirements or that the product can be used outside its evaluated configuration.
A CSfC Components List entry establishes that a product has satisfied the applicable requirements for inclusion in the program. This includes NIAP Common Criteria evaluation against the relevant NSA-approved Protection Profile requirements, additional CSfC-specific considerations where applicable, and NSA review. The vendor must also enter into a Memorandum of Agreement with NSA establishing responsibilities associated with participation in the program.
These requirements provide a basis for evaluating commercial security technologies intended for classified environments. However, NIAP validation and CSfC listing address defined security functionality and evaluated configurations rather than every possible implementation. A product’s presence on the list does not guarantee that it has been configured correctly or that its deployment satisfies the requirements of a complete CSfC architecture.
For example, a listed hardware encryption component does not independently establish that a data-at-rest solution meets the applicable two-layer encryption requirements. The complete architecture must incorporate the necessary independent protection mechanisms, authentication controls, and configuration requirements defined by the Data at Rest Capability Package.
This distinction also explains why the terminology used in procurement matters. CSfC does not issue a standalone certification establishing that an entire product or system is CSfC compliant. Individual products may receive NIAP Common Criteria validation and appear on the NSA CSfC Components List, while complete solutions follow a separate registration process and remain subject to authorization by the responsible Authorizing Official (AO).
For additional context, see FIPS Is Not CSfC and CSfC Certification.
Cigent has products listed on the NSA CSfC Components List for data-at-rest protection, including secure storage and Pre-Boot Authentication components. These listings apply to specific products and evaluated configurations, not automatically to every product within Cigent’s portfolio.
Qualifying for the CSfC Components List involves technical evaluation, NSA review, vendor commitments, and ongoing responsibilities. Although the process begins with product security evaluation, NIAP validation alone does not establish eligibility for every CSfC application.
The National Information Assurance Partnership (NIAP) oversees Common Criteria evaluation and validation in the United States. Products undergo evaluation by an accredited laboratory against applicable Protection Profiles, which establish standardized security requirements for defined technology categories.
Depending on the product class, evaluation may address encryption functionality, authentication mechanisms, key management, security administration, and other relevant security functions. Successful evaluation results in NIAP validation for the product and its evaluated configuration. This establishes an important technical foundation for CSfC consideration, but it does not independently guarantee placement on the Components List.
Following the applicable evaluation process, a product must satisfy NSA’s requirements for inclusion in the CSfC program. NSA may consider additional factors, including supply chain considerations, vendor vulnerability response practices, and the product’s intended use within CSfC architectures.
Vendors must provide required program information, including the applicable CSfC questionnaire, and enter into a Memorandum of Agreement with NSA. This agreement establishes responsibilities associated with maintaining the product’s security posture and addressing relevant program obligations. Products that complete NIAP validation do not automatically appear on the Components List without satisfying these additional requirements.
CSfC listing requires ongoing attention because evaluated products, software versions, firmware, security requirements, and vendor obligations can change. Vendors must address applicable maintenance requirements, including security updates and vulnerability remediation responsibilities. NSA may update a product’s listing status as evaluations expire, products evolve, or program requirements change.
Products may also move from the active list into archived status. Archived components are generally not eligible for new CSfC solution registrations, while existing deployments must follow applicable NSA transition and maintenance requirements. Program teams should therefore verify current listing status during system design and again before registration or major architectural changes.
The Components List organizes products by security function, and these categories help determine where a product may be used within a CSfC architecture. A product listed in one category does not automatically satisfy requirements associated with another. This distinction is particularly important for data-at-rest protection, where multiple independent security mechanisms must work together.
The NSA Data at Rest Capability Package defines requirements for protecting classified information stored on devices and systems. Depending on the selected architecture, different encryption technologies and supporting security components may be used to satisfy these requirements. One approach combines Hardware Full Drive Encryption as the outer layer with independent Software Full Drive Encryption as the inner layer.
Hardware Full Drive Encryption (HW FDE) uses a self-encrypting drive to protect stored information through encryption implemented in the storage device. In architectures using this approach, hardware encryption can serve as the outer protection layer. The drive must operate within the applicable evaluated configuration and meet the requirements assigned to that layer by the DAR Capability Package.
Pre-Boot Authentication (PBA) provides an additional access control mechanism before the operating system loads. Depending on the evaluated implementation, authentication functionality may be integrated into the drive or provided through a separate listed component. The precise relationship between authentication, key protection, and storage access depends on the product’s security architecture and evaluated configuration.
PBA should not be treated as an additional independent encryption layer simply because it is a separate security function. Instead, authentication and encryption mechanisms must be considered together when determining whether the complete architecture satisfies the applicable DAR requirements.
Software Full Drive Encryption (SW FDE) protects stored data through software-based cryptographic functionality. When used as the inner layer of a layered DAR architecture, it must provide protection independent of the outer encryption layer and satisfy the applicable requirements for cryptographic separation, key management, and authentication.
Combining hardware and software encryption can provide defense in depth by requiring multiple independent security mechanisms to be overcome before protected information can be accessed. However, the presence of two encryption products alone does not establish compliance. The architecture must satisfy the relevant Capability Package requirements, including independence between layers and the required configuration and authentication controls.
A vendor may have a product listed for Hardware Full Drive Encryption without having a corresponding Software Full Drive Encryption product listed. Similarly, an authentication component’s listing does not automatically establish that an entire encryption architecture is eligible for registration.
When evaluating a vendor, program teams should identify the exact product, component category, evaluated version, and intended role within the proposed solution. These details help determine whether the product is an appropriate candidate for the architecture being designed.
Verifying a CSfC listing should be a standard part of procurement and architecture reviews. The initial check can be completed relatively quickly using NSA’s published Components List, although validating the complete evaluated configuration may require additional documentation and technical review.
Search the NSA Components List for the specific product identified in the vendor’s proposal. Do not assume that a company name or product family establishes eligibility for every product offered by that vendor. Marketing names may differ from evaluated product names, so the official listing should be used as the reference.
Identify the category under which the product appears and compare it with the security function the product is intended to provide. A Hardware Full Drive Encryption listing does not establish eligibility for a Software Full Drive Encryption role. The listed category must align with the proposed architecture and applicable Capability Package requirements.
Confirm that the product remains eligible for its intended use. Components may move into archived status as evaluations expire, products change, or program requirements evolve. The implications of a status change may differ between new registrations and existing deployments, so teams should review NSA’s current guidance rather than assuming that historical listing establishes continued eligibility.
Compare the proposed product’s hardware, firmware, and software versions with those covered by the listing and associated evaluation documentation. A newer version or modified configuration should not automatically be assumed to fall within the original evaluation scope. Differences should be raised with the vendor and reviewed against the applicable documentation.
A product name and active listing are only the beginning of a complete technical review. Program teams should examine the applicable NIAP Security Target, evaluated configuration guidance, and any CSfC-specific selections or restrictions. These documents help establish whether the proposed hardware, firmware, software, and configuration are consistent with the evaluated product and the intended Capability Package architecture.
This verification process should be performed during initial design and repeated before solution registration or significant system changes. It reduces the risk of selecting products that appear suitable in vendor materials but do not meet the specific requirements of the intended classified deployment.
The Components List is one part of a broader process for developing and deploying CSfC solutions. Understanding the relationship between component eligibility, architecture requirements, registration, and authorization helps prevent confusion during procurement and security reviews.
The Components List identifies commercial products eligible for use in applicable CSfC architectures. The relevant Capability Package defines how those components must be assembled, configured, and operated to protect classified information. For data at rest, the DAR Capability Package establishes requirements for layered encryption, authentication, and other security controls appropriate to the selected architecture.
Solution registration with NSA is a separate process that documents the implementation of a CSfC architecture. Registration does not replace the responsible organization’s security authorization process or eliminate the need to assess operational risk. The Authorizing Official evaluates the system within the applicable risk management and authorization framework and determines whether the associated risks are acceptable.
These processes answer different questions. The Components List identifies which products may be considered, the Capability Package establishes how those products must be implemented, and registration and authorization address the proposed solution and its use within a specific environment.
For organizations evaluating classified data protection requirements, Cigent’s CSfC DAR Readiness Assessment provides an initial way to examine whether their systems may require a CSfC-aligned data-at-rest architecture. The assessment is a preliminary planning resource and does not replace a formal architecture review or authorization process.
The importance of component eligibility becomes clear when classified systems are deployed outside traditional data centers and controlled facilities. Tactical computing systems, mobile command environments, and other field-deployed platforms may store mission information while operating in locations where physical access cannot always be guaranteed. Protecting that information requires security architectures designed to address both technical requirements and operational exposure.
Cigent and Curtiss-Wright have collaborated to strengthen data-at-rest protection for rugged tactical edge systems. Their approach combines layered security, Pre-Boot Authentication, and centralized management to help protect classified mission data in physically exposed environments. The collaboration illustrates how CSfC-aligned architectures can address the security and operational requirements of defense systems.
The Protecting Classified Data at the Tactical Edge case study provides additional information about this approach.
For program teams, the larger lesson is that component selection and architecture design must be evaluated together. Listed products provide an important foundation, but successful deployment also depends on configuration, integration, authentication, lifecycle management, and adherence to the applicable security requirements.
The CSfC Components List provides a publicly accessible way to establish whether specific commercial security products are eligible for consideration within NSA-defined classified protection architectures. Its value comes from the ability to verify product eligibility against an authoritative source rather than relying exclusively on vendor descriptions.
However, listing status should never be interpreted as approval of a complete system. A listed product must still be deployed in an appropriate evaluated configuration, integrated according to the applicable Capability Package, and considered within the organization’s registration and authorization processes.
For defense organizations, verification should be a recurring design and procurement activity. Confirm the exact product, component category, current status, evaluated version, and supported configuration, then assess how the component fits within the complete architecture. This approach helps reduce avoidable procurement and integration risks while supporting more defensible security decisions.
Organizations evaluating layered data-at-rest protection can begin with Cigent’s CSfC DAR Readiness Assessment to identify potential architectural requirements. To learn more about Cigent’s approach to secure storage, Pre-Boot Authentication, and layered encryption, explore its data-at-rest protection solutions.
The CSfC Components List is the NSA’s public register of commercial products eligible for use in applicable Commercial Solutions for Classified architectures. Products must meet relevant evaluation and program requirements before being included. A listing establishes eligibility for a defined component role, not approval of every possible configuration or complete system.
No. CSfC does not issue a standalone certification establishing that an entire product or system is CSfC compliant. Products may receive NIAP Common Criteria validation and appear on the NSA CSfC Components List, while complete solutions follow a separate registration process and remain subject to authorization by the responsible Authorizing Official.
A product must complete applicable NIAP Common Criteria evaluation and satisfy NSA’s additional CSfC program requirements. These may include review of supply chain considerations, vulnerability response practices, and intended product use. The vendor must also provide required program information and enter into a Memorandum of Agreement with NSA.
Yes. Product listings may change as evaluations expire, products evolve, or program requirements are updated. Archived components are generally not eligible for new CSfC solution registrations, while existing deployments must follow applicable NSA transition requirements. Program teams should consult the current list and relevant NSA guidance when evaluating product eligibility.
The Data at Rest Capability Package supports architectures that use applicable encryption technologies and supporting security components. One approach combines Hardware Full Drive Encryption as an outer layer with independent Software Full Drive Encryption as an inner layer. The selected components must meet the requirements associated with their listed categories and the complete DAR architecture.
No. Listed components are an important foundation, but their presence does not establish that an assembled system meets CSfC requirements. The complete architecture must satisfy the applicable Capability Package, use components in supported configurations, and follow the relevant registration and authorization processes. Component eligibility and solution approval are separate considerations.
Begin by checking the NSA’s current Components List for the exact product and component category. Confirm the listing status and evaluated version, then review the applicable NIAP Security Target, configuration guidance, and CSfC-specific requirements. The proposed deployment should be evaluated against those documents and the relevant Capability Package.
Yes. Cigent has products listed on the NSA CSfC Components List for data-at-rest protection, including secure storage and Pre-Boot Authentication components. Eligibility applies to specific products and evaluated configurations rather than the company’s entire portfolio. Organizations should verify the exact product and current listing status on NSA’s published list.
The Components List identifies commercial products eligible to perform defined security functions within CSfC architectures. A Capability Package establishes the requirements for combining and configuring those components to protect classified information. Both are important, but neither independently replaces solution registration or the responsible organization’s authorization process.
The National Security Agency maintains and publishes the CSfC Components List as part of the Commercial Solutions for Classified program. Vendors are responsible for meeting applicable program obligations, including maintaining relevant security and evaluation requirements. NSA updates listing information as product status and program conditions change, making the current published list the authoritative reference.
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.
