NIAP’s Accelerated PQC Transition (Policy Letter 33)

NIAP has published Policy Letter #33, setting certification deadlines for the transition to post-quantum cryptography (PQC). The policy affects products entering NIAP evaluation, products seeking placement on the Product Compliant List (PCL), and products already certified by NIAP or a CCRA partner.

For vendors, the practical effect is clear: PQC adoption is now on the critical path, and timelines are tightening. NIAP is introducing certification and market-access gates ahead of some of NSA’s broader operational transition dates. These gates apply not only to products entering NIAP evaluation, but also to internationally certified CCRA products seeking placement on the NIAP PCL. Existing listings are also affected. NIAP intends to archive noncompliant products on a date yet to be determined, regardless of how much time remains on their certifications. At the same time, Protection Profiles and supporting requirements still need to be updated to provide a viable path to demonstrating CNSA 2.0 compliance through NIAP evaluation.

The rest of this post looks at what Policy Letter 33 changes, how its deadlines compare with NSA’s broader CNSA 2.0 transition schedule, and the implementation gaps vendors still need to navigate.

What Policy Letter 33 changes

NIAP will prioritize validation resources based on CNSA 2.0 compliance. Products that fully comply will receive priority over partially compliant products, and partially compliant products will receive priority over products that do not comply.

The policy also establishes the following deadlines:

• January 1, 2027: Products that do not meet CNSA 1.0 minimum requirements for every cryptographic function will no longer be accepted into NIAP evaluation. These products also lose access to Assurance Maintenance extensions and cannot receive a certificate longer than two years.
• July 1, 2027: Products that do not meet CNSA 1.0 minimum requirements for every cryptographic function will no longer be posted to the PCL.
• January 1, 2028: Products that do not meet CNSA 2.0 requirements for every cryptographic function will no longer be accepted into NIAP evaluation.
• January 1, 2029: Products that do not meet CNSA 2.0 requirements for every cryptographic function will no longer be posted to the PCL.

NIAP will also archive non-compliant products from the PCL on a date still to be determined, regardless of the time remaining on their certificates. AES-128 for Bluetooth is the one temporary exception identified in the policy.

Does this accelerate the CNSA 2.0 transition?

Policy Letter #33 does not replace NSA’s technology-specific operational transition dates. NSA has previously identified later exclusive-use dates for several product categories, generally 2030 or 2033.

However, the policy does accelerate the transition for vendors seeking NIAP PLC access. From 2028, a product cannot enter NIAP evaluation unless every cryptographic function meets CNSA 2.0 requirements. From 2029, a non-compliant product cannot be newly posted to the PCL.

This distinction is important. Policy Letter #33 does not say that every deployed National Security System must exclusively use CNSA 2.0 in 2028. It creates earlier NIAP evaluation and PCL eligibility gates. For vendors selling into the NSS market, those gates may drive product changes several years before NSA’s final operational deadlines.

Protection Profiles still need to catch up

A complicating factor is that current NIAP Protection Profiles and their supporting requirements do not yet consistently support the CNSA 2.0 algorithms needed to meet the new policy across every cryptographic function. In some cases protocol (TLS, IPsec etc.) related RFCs that the Protection Profiles make use of may require update / publication to fully support CNSA 2.0 algorithms.

In its announcement for Policy Letter #33, NIAP stated that it will issue new Technical Decisions, or update existing Technical Decisions, for applicable Protection Profiles. These updates will temporarily allow selected algorithms that are not CNSA 1.0 compliant for functions such as secure boot and trusted update. NIAP also strongly recommends that vendors adopt CNSA 2.0-compliant algorithms as soon as possible.

This means the implementation path is still developing. Vendors need to follow both the Policy Letter #33 deadlines and the Technical Decisions that define which algorithm selections can be claimed under the applicable Protection Profile. The policy sets the destination and dates, while the Protection Profiles and Technical Decisions must provide a workable evaluation path.

CAVP support is mostly available

CAVP testing is available for the principal CNSA 2.0 algorithms, including AES-256, SHA-384 and SHA-512, ML-KEM-1024, ML-DSA-87, and LMS. However, CAVP does not currently support XMSS or XMSS^MT, which NSA permits as alternatives to LMS for firmware and software signing. NIST has not published a timeline for adding XMSS support. Vendors therefore have a viable CAVP-supported path using LMS, but not every CNSA 2.0 algorithm option is currently supported.

What vendors should do now

• Review every cryptographic function in the product, including trusted channels, key establishment, signatures, secure boot, and software or firmware update.
• Identify current CNSA 1.0 gaps that could affect evaluation intake, certificate duration, Assurance Maintenance, or PCL eligibility in 2027.
• Build a CNSA 2.0 roadmap for products expected to enter NIAP evaluation in 2028 or remain relevant to the NSS market after 2029.
• Track updates to the applicable Protection Profiles, RFCs and NIAP Technical Decisions so the product design and Security Target use supported algorithm selections.
• Confirm that the selected CNSA 2.0 algorithms, parameter sets, and operational environments can obtain the required CAVP evidence. Products using XMSS should account for the absence of CAVP support and a published support timeline.
• Review existing PCL listings and do not assume that the original certificate expiry date will protect a non-compliant product from archival.

Lightship Security can help vendors assess their current cryptographic implementation, identify CNSA and Protection Profile gaps, and align product and evaluation plans with the Policy Letter #33 deadlines.

Bottom line

Policy Letter #33 does not formally move NSA’s final CNSA 2.0 operational deadlines. It does introduce earlier NIAP certification gates that will accelerate the transition for commercial products seeking NSS market access. The immediate challenge is planning for those dates while NIAP updates its Protection Profiles and Technical Decisions and the remaining gaps in algorithm validation support are addressed.

Contact Lightship Security to discuss how Policy Letter #33 affects your current certifications and future projects.