The 2025 milestone dates in the CNSA 2.0 transition timeline are not future planning items. For any defence supplier with an active national security system programme contract, those dates are now in the past. Suppliers reading this in mid-2026 who have not yet started on their applicable product categories are behind the NSA's published schedule. This article works through the timeline category by category, identifies where the contractual obligations actually sit, and builds toward a practical readiness plan that a Programme Manager, CISO, or Contracts Director can use.

What CNSA 2.0 actually requires: the algorithm transition from version 1.0

CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) was published by the National Security Agency in September 2022, superseding CNSA 1.0. CNSA 1.0 relied on RSA-3072/4096, ECDH on P-384, and AES-256. CNSA 2.0 replaces those asymmetric primitives entirely and mandates NIST-standardised post-quantum algorithms at specific parameter sets for national security systems (NSS). The parameter set requirements are higher than the commercial defaults in the NIST FIPS standards, and that distinction matters operationally.

For key encapsulation, CNSA 2.0 mandates ML-KEM-1024, not ML-KEM-768. The difference is not marginal: ML-KEM-1024 has a public key of 1,568 bytes and a ciphertext of 1,568 bytes; ML-KEM-768 has a public key of 1,184 bytes and a ciphertext of 1,088 bytes. For digital signatures, CNSA 2.0 mandates ML-DSA-87, with a signature size of 4,627 bytes, compared to ML-DSA-65 at 3,309 bytes in commercial contexts. SLH-DSA-256 is the mandated alternative signature scheme. Symmetric requirements are AES-256 and SHA-384 or SHA-512. These specific parameter sets must be implemented in any product built for an NSS environment. A supplier who builds for the standard NIST commercial parameter sets and assumes they satisfy CNSA 2.0 has not read the advisory carefully enough.

FN-DSA (FIPS 206, Falcon) is not mandated by CNSA 2.0 for NSS. Falcon-1024 produces signatures of 897 bytes, considerably smaller than ML-DSA-87's 4,627 bytes, but introduces implementation complexity through Gaussian sampling that is harder to implement in constant time. NSA has taken ML-DSA-87 as the preferred NSS signature algorithm; FN-DSA is not prohibited but is not the primary recommendation. For a supplier choosing between ML-DSA-87 and FN-DSA for an NSS application, the safe default is ML-DSA-87.

For the comparative analysis of the algorithm transition from CNSA 1.0 to CNSA 2.0, see the companion article CNSA 2.0 vs CNSA 1.0: What Changes for Defence Suppliers.

The timeline: when each product category must transition

NSA's September 2022 advisory published a product-category-specific transition timeline. It is not a single deadline. The categories and dates are:

The 2025 begin-transition dates for software, firmware, IoT, OT, and network device categories are behind us. A supplier in those categories who has not yet initiated transition activity is not on schedule. The 2026 begin-transition dates for data-at-rest, PKI, and VPN categories are current obligations: products in those categories must be moving in 2026.

The 2030 complete-transition dates for software and network devices converge with NIST IR 8547 (November 2024), which specifies that RSA, ECDSA, ECDH, and DSA are deprecated for new use from 2030 and disallowed from 2035. A supplier whose product has a commercial market alongside its NSS market will face both the CNSA 2.0 programme deadline and the NIST IR 8547 commercial deprecation at the same point. Treating them as separate compliance tracks is inefficient. The migration architecture should satisfy both simultaneously.

The contractual layer: DFARS and CMMC

Understanding where CNSA 2.0 enters a contract is not straightforward, and assuming it does not apply because the standard DFARS clause text does not name it is a common error.

DFARS clause 252.204-7012 (Safeguarding Covered Defence Information and Cyber Incident Reporting) incorporates NIST SP 800-171 requirements by reference. As of knowledge cutoff August 2025, DFARS does not contain an explicit CNSA 2.0 mandate in its standard clause text. That absence does not mean exemption. CNSA 2.0 requirements enter defence contracts through Statement of Work language, Security Classification Guides, System Security Plans, and programme-specific Security Technical Implementation Guides (STIGs). A supplier whose DFARS clause review returns no explicit CNSA 2.0 reference must still review the programme-specific security documentation. The gap between standard clause text and programme-specific requirements is exactly where CNSA 2.0 obligations appear.

The CMMC 2.0 Final Rule (32 CFR Part 170, effective December 2024) requires defence contractors to demonstrate compliance with NIST SP 800-171 (CMMC Level 2) or NIST SP 800-172 (CMMC Level 3). CMMC Level 2 includes control 3.13.8 on cryptography, requiring FIPS-validated cryptographic modules. CMMC Level 3 adds enhanced APT defence controls. Neither level explicitly mandates CNSA 2.0 by name. However, NSS-category products require FIPS 140-3 validated modules implementing CNSA 2.0 algorithms, creating an intersection between the CMMC validation requirement and the CNSA 2.0 algorithm mandate that is not expressed explicitly in either document but follows from both together.

FIPS 140-3 validation is the practical hard constraint that determines which cryptographic libraries can be used in NSS production. As of mid-2025, a limited number of cryptographic modules incorporating ML-KEM and ML-DSA had achieved FIPS 140-3 validation. A supplier cannot use an unvalidated PQC library in NSS-category production, even if that library correctly implements the NIST FIPS algorithms. The NIST Cryptographic Module Validation Programme (CMVP) is processing PQC module submissions; historical FIPS 140-3 validation timescales run 12 to 24 months. [ASSUMED: verify current CMVP processing times before publication.] That lead time must be factored into programme planning.

Engineering implications: timelines, libraries, and platform constraints

The arithmetic for a supplier in the software or network device category is uncomfortable. The 2030 completion deadline leaves four years as of 2026. Remove 12 to 24 months for FIPS 140-3 validation of a PQC module, an updated System Security Plan requiring Government review and approval, Government acceptance testing, and independent verification and validation (IV&V). The effective engineering window is closer to 24 to 30 months. Suppliers who have not yet identified their cryptographic dependencies are not at the start of that 24 to 30 month window. They are behind it.

The prerequisite for migration is a cryptographic bill of materials (CBOM): a structured inventory of every cryptographic component in the programme, the algorithm and parameter set in use, the system or service it protects, the data classification and confidentiality lifetime of what it protects, and the migration complexity. NIST NCCoE SP 1800-38B provides the methodological framework for CBOM construction. For large defence programmes with multi-thousand component systems, this is a significant programme management task requiring dedicated resourcing. It is also the only way to produce a defensible migration schedule.

Products that do not currently use a FIPS 140-3 validated cryptographic module may need to switch to a different library to obtain a validated module within the required timeline. Switching cryptographic libraries mid-programme is a non-trivial engineering activity. It requires code changes, regression testing, and re-evaluation of the software security architecture. Suppliers should assess which validated or in-validation PQC library fits their existing stack and begin transition planning immediately. [ASSUMED: verify current CMVP submission and validation status for specific library candidates before publication.]

For the detailed technical implementation of CNSA 2.0 algorithms, parameter sets, and integration patterns, see CNSA 2.0 Suite: A Detailed Implementation Walkthrough.

Sub-tier flow-down: your suppliers are part of your readiness problem

Prime contractors are contractually responsible for flowing down applicable cybersecurity requirements to their sub-contractors. DFARS clause 252.204-7012(m) explicitly requires prime contractors to flow down the requirements of that clause to sub-contractors. For CNSA 2.0-specific requirements entering a contract through SOW language or STIGs, the same flow-down principle applies: the prime contractor must ensure sub-tier suppliers of components incorporating cryptographic functionality meet CNSA 2.0 requirements.

Sub-tier suppliers of embedded systems, hardware security modules, firmware, software libraries, and communications components should expect their CNSA 2.0 readiness to be audited by prime contractors as part of supply chain risk management. A sub-tier supplier who cannot demonstrate readiness within the prime contractor's required timeline is a programme risk item. The consequence can be replacement. Sub-tier suppliers should not wait for a questionnaire from a prime customer. They should engage proactively with their prime contractor customer base and provide a CNSA 2.0 roadmap. Being asked is already late.

International sub-tier suppliers, particularly those from UK, EU, Australia, and Canada, face a dual compliance challenge. National government customers may apply different standards: UK DEFSTAN 05-138 for Type 1 equivalent protections [INFERRED: UK DEFSTAN 05-138 covers Type 1 cryptographic equipment requirements; its specific PQC transition obligations and parameter set mandates should be confirmed against the current DEFSTAN issue and any MOD programme-specific security instructions before planning], NATO STANAG 4778 in development [INFERRED: STANAG 4778 is reported to be in development as a NATO quantum-safe cryptography standard; verify ratification status and applicability to specific programme categories before relying on it in supplier readiness plans], and EU standards emerging from ENISA guidance. Where those standards converge on the same NIST algorithms, the compliance overlap is manageable. Where parameter set requirements differ, suppliers may need to maintain separately validated product builds. Mapping CNSA 2.0 requirements to applicable national equivalent standards is a planning task that should be done early, before the product architecture is fixed.

The sub-tier management framework for prime contractors is covered in detail in CNSA 2.0 Sub-Tier Supplier Guide: Managing Supply Chain Compliance.

Hybrid transition and the NSA supplemental sheets

NSA has published individual cybersecurity information sheets providing implementation guidance for each CNSA 2.0 product category: software signing, firmware, TLS 1.3, and internet of things. Programme planners should identify the relevant supplemental sheets for each system element and incorporate them into the System Security Plan. The supplemental sheets are available through NSA's CNSA 2.0 resources.

The TLS 1.3 supplemental sheet specifies that hybrid key exchange combining a classical algorithm with a PQC algorithm is acceptable during the transition period. RFC 9496 (X-Wing, using X25519 and ML-KEM) is the commercially deployed hybrid construction. For NSS, the PQC component of the hybrid must be ML-KEM-1024, not ML-KEM-768. RFC 9496 X-Wing as typically deployed in commercial contexts uses ML-KEM-768. A supplier deploying hybrid TLS for NSS based on a commercial X-Wing configuration is using the wrong parameter set. The NSS-appropriate hybrid requires the ML-KEM-1024 variant. This is not a minor version difference; it is a distinct parameter set with different public key and ciphertext sizes that must be specified explicitly in the IKEv2 or TLS configuration.

The NSA advisory also distinguishes new products from legacy products. New products and new software versions must implement CNSA 2.0 algorithms from the 2025 start dates for their category. Legacy products not in active development may remain on CNSA 1.0 algorithms through the transition window but must complete migration by the relevant 2030 or 2033 category deadline. This distinction matters for resource planning: it is not a big-bang replacement of all products simultaneously. It is a planned retirement of CNSA 1.0 algorithms across the portfolio, with new development using CNSA 2.0 from now.

Building the supplier readiness plan: a six-item checklist

A CNSA 2.0 programme readiness plan for a defence supplier requires six specific outputs. Each item below names the artefact, not the activity:

1. Cryptographic inventory mapped to CNSA 2.0 categories. For each programme element, identify the current algorithm and parameter set, the applicable CNSA 2.0 category (software/firmware, IoT/OT, network devices, data-at-rest, PKI, VPN), and the category deadline. Use the CBOM methodology from NIST NCCoE SP 1800-38B. This artefact is the prerequisite for all subsequent items.
2. FIPS 140-3 validation strategy document. For each programme element, identify the current cryptographic library and its FIPS 140-3 status. Determine whether to use an existing validated module, initiate a new validation, or engage a cryptographic library vendor with an active CMVP submission. Document the decision and the expected validation date.
3. DFARS and SOW review across active contracts. Identify which contracts contain explicit CNSA 2.0 language through SOW, STIG, or SSP requirements. Identify reporting obligations and milestone-based deliverables. This review must cover programme-specific security documentation, not only standard DFARS clause text.
4. Sub-tier supplier CNSA 2.0 questionnaire and roadmap collection. Issue the questionnaire to all sub-tier suppliers providing cryptographic components. Collect written roadmaps with dated milestones. Identify suppliers with gaps and escalate those gaps to the programme risk register before they surface in a Government review.
5. Internal programme milestone schedule aligned to NSA category deadlines. Map each programme element to its applicable category deadline. Build in the FIPS 140-3 validation lead time, SSP update and Government approval cycle, and IV&V schedule. The schedule must show whether the programme is on track by category, not only overall.
6. NSA supplemental sheet review per product category. For each applicable category, obtain the relevant NSA cybersecurity information sheet and confirm the programme's technical approach matches the specified algorithm requirements, cipher suites, and hybrid construction. The TLS supplemental sheet requires particular attention for the ML-KEM-1024 versus ML-KEM-768 distinction in NSS hybrid deployments.

A programme that can produce all six artefacts is positioned to defend its CNSA 2.0 readiness under Government scrutiny. A programme that cannot produce them has programme risk that is not yet visible to the supplier's leadership.