Recent updates to Addendum 2 of NIAP Policy Letter 5 and Commercial National Security Algorithm (CNSA) policy are set to significantly impact Common Criteria (CC) evaluations, particularly under the Common Criteria 2022 (CC:2022) framework. While elements of these changes have already been communicated, this article consolidates the key points and clarifies their practical implications for our vendors.
The CAVP mapping table has recently been updated to reflect two primary goals:
- Alignment with Modern Cryptographic Standards
The previous version of Addendum 2, dating back to around 2018, no longer reflects current cryptographic practices. In particular, it does not account for the substantial evolution of the Automated Cryptographic Validation Protocol (ACVP), which is used to obtain CAVP certificates, over recent years. The update ensures alignment with modern validation processes and contemporary cryptographic standards. - Enforcement of CNSA Compliance
The revised mapping table enforces the use of the CNSA Suite. As a result, most non-CNSA algorithms have been removed, with only a limited number of narrowly defined exceptions remaining.
The updated mapping table will be mandatory for all CC:2022 evaluations, and there are no transition periods or exceptions; as a consequence, CNSA 1.0 will also be mandatory for all CC:2022 evaluations. Additionally, while not strictly required, the new mapping table is strongly recommended for all CC v3.1 evaluations, both ongoing and upcoming.
Mapping Table Overrides Other Requirements
The updated Addendum 2 also clarifies that CAVP mapping table takes precedence over all NIAP-approved Protection Profiles (PPs), collaborative Protection Profiles (cPPs), PP-Modules, and Functional Packages. This means that even if a PP or cPP permits a specific algorithm (e.g., AES-128), it cannot be selected in a CC:2022 evaluation under NIAP unless it is also allowed in the mapping table. Thus, the mapping table should always be the first reference when defining cryptographic selections in a Security Target.
Foreign Evaluations and the CNSA-Only Mode Requirement
Evaluations performed under a non-NIAP scheme (“foreign evaluations”) are not limited to algorithms from the CAVP mapping table. Non-CNSA algorithms may still be selected in the Security Target (if allowed by the PP or cPP).
However, to list the product on the NIAP Product Compliant List (PCL), the product must include a “CNSA-only” mode.This mode must restrict the product to use CNSA algorithms only (i.e., following the CAVP mapping table), and explicit instructions to enable this mode must be clearly documented in the administrative guidance, and this will be verified during the PCL posting process.
The exact requirements are specified in the endorsement Technical Decisions, such as TD0972. The intent is clear, however: even if a product supports non-CNSA cryptography, U.S. federal users must be able to operate it in a strictly CNSA-compliant configuration.
Looking Ahead: CNSA 2.0
atsec previously published a blog article about CNSA 2.0, which provides details on the allowed algorithms, the proposed timeline, and NIAP’s goal for the transition.
While CNSA 2.0 is not yet mandatory, NIAP will likely require support to be present in validated products much sooner than many vendors anticipate. The exact timeline is still unclear and not completely under the control of NIAP. Vendors are however strongly encouraged to begin implementing CNSA 2.0 now, and not wait for 2030, as proposed by the CNSA 2.0 transition timeline.
Early adoption will help avoid future rework and ensure smoother transitions.
Key Takeaways
- The updated CAVP mapping table is central to all CC:2022 evaluations
- CNSA 1.0 compliance is now non-negotiable for NIAP evaluations
- The mapping table overrides all other cryptographic guidance
- Foreign evaluations must support a CNSA-only mode for NIAP recognition
- CNSA 2.0 adoption should begin now
If you have questions or want to discuss how these updates affect your current or upcoming evaluations, reach out to info@atsec.com.
