CNSA 2.0 Compliance Guide: What US Defence Contractors Must Do

It is 2026. The NSA's preferred schedule for CNSA 2.0 migration had 2025 as the target year for software and firmware signing and for cloud services handling classified information. Both dates have passed. The preference dates for network equipment, operating systems, traditional networking, and applications are the current year. Contractors who have not begun CNSA 2.0 migration are not ahead of schedule. They are behind the NSA's stated preferred timeline on the categories that matter most.

The September 2022 advisory that published CNSA 2.0 specified algorithms, parameter sets, and transition dates. This article works through each as a compliance guide: what the mandate actually requires, where contractors stand in 2026, and how to sequence the work from cryptographic inventory through to RMF documentation.

What CNSA 2.0 Mandates and What It Replaces

CNSA 1.0 (NSA's Suite B) was published in 2006 and updated in 2012. The cryptographic foundation: ECDH P-384 for key agreement, ECDSA P-384 for digital signatures, SHA-384 for hashing, AES-256 for symmetric encryption. NSA signalled intent to deprecate it in 2015 and published replacement guidance in 2016, with quantum computing cited as a reason for the change in direction.

CNSA 2.0, published September 2022, replaces the public-key component of that suite entirely. ECDH P-384 and ECDSA P-384 are out. The mandatory algorithms for National Security Systems are:

The parameter set requirement is not a detail. CNSA 2.0 mandates ML-KEM-1024 (NIST security category 5, equivalent to 256-bit classical security). NIST's general-purpose recommendation for most enterprise applications is ML-KEM-768. Contractors who have begun PQC migration using ML-KEM-768 for general purposes must ensure their NSS workloads use ML-KEM-1024. The distinction is not interchangeable in procurement documentation, STIG compliance, or RMF security assessment.

ML-KEM-1024 technical parameters from FIPS 203: public key 1,568 bytes, private key 3,168 bytes, ciphertext 1,568 bytes. ML-DSA-87 from FIPS 204: public key 2,592 bytes, private key 4,896 bytes, signature 4,627 bytes. These are the values that STIGs, security assessment reports, and procurement specifications should reference.

On FN-DSA (FIPS 206): FIPS 206 was published in August 2024, after the September 2022 CNSA 2.0 advisory. The 2022 advisory did not include FN-DSA (then designated FALCON). [ASSUMED, no FN-DSA update to CNSA 2.0 as of article authoring; verify whether NSA has issued any updated CNSA 2.0 guidance post-September 2022 that incorporates FN-DSA, and whether any NSA advisory or FAQ specifically addresses FIPS 206 status for NSS use, before the June 2026 publication date.]

For a detailed comparison of CNSA 2.0 against CNSA 1.0 at the implementation level, see CNSA 2.0 versus CNSA 1.0 for defence suppliers.

The Timeline: Where Contractors Stand in 2026

NSA specified transition timelines by NSS application category in the September 2022 advisory and the October 2022 FAQs. The "preference" dates represent NSA's expected substantial progress milestone. The "required" dates are the compliance deadlines.

Software and firmware signing carries the 2025 preference date because code signing creates long-lived trust chains. Firmware signed today with ECDSA P-384 for a DoD weapons system will need to be re-signed when ECDSA is retired. Every signed update distributed before that migration point accumulates a re-signing debt. Starting ML-DSA-87 code signing now prevents that debt from growing. Contractors who have not yet migrated their code signing pipelines are already behind the NSA's stated timeline on the category NSA prioritised first.

Network equipment is the current-year preference target. VPN appliances, firewalls, and routers running IKEv2/IPsec or TLS on NSS-connected infrastructure should be migrating to CNSA 2.0 key exchange. The appropriate hybrid for TLS in classified environments is ECDH P-384 + ML-KEM-1024, not X25519+ML-KEM-768, which is the general internet recommendation but does not use the CNSA 1.0 classical component. X25519 is not in CNSA 1.0; P-384 is. The hybrid must use the CNSA 1.0 approved classical algorithm.

For cloud services, the 2025 preference date has passed. Cloud service providers handling classified information should be assessed for their CNSA 2.0 migration roadmaps now. Migration of cloud encryption infrastructure requires co-ordination with the CSP and cannot be completed unilaterally by the contractor. Obtaining vendor roadmap letters confirming ML-KEM-1024 and ML-DSA-87 support timelines is an immediate step.

The Compliance Pathway: Eight Steps

The compliance pathway follows from the regulatory structure and the technical dependencies. It cannot be compressed arbitrarily, because each step's output is the input to the next.

Step 1: Cryptographic Inventory (CBOM)

Identify every system that processes, stores, or transmits NSS data or data subject to CNSA 2.0 requirements. For each system, map the algorithms in use (including algorithms embedded in third-party software, commercial off-the-shelf components, firmware, and cryptographic libraries), the function each algorithm serves, and the CNSA 2.0 compliance gap. NIST SP 1800-38 (NCCoE PQC Migration Project, 2024) provides the Discover phase methodology. A Cryptographic Bill of Materials (a structured machine-readable inventory of cryptographic dependencies) is the output.

The CBOM work consistently takes longer than anticipated for defence system integrators. Embedded cryptographic dependencies in COTS hardware and commercial software are not always visible to the organisation's own security architects. Tools for automated cryptographic discovery and SBOM-to-CBOM conversion are becoming available from vendors including IBM, Veracode, and others, but manual audit of custom firmware and embedded controllers remains necessary. Build this schedule into the programme plan.

Step 2: Prioritisation by Timeline and HNDL Risk

Map the CBOM inventory against the CNSA 2.0 timeline table. Systems in categories with 2025 or 2026 preference dates are first priority. Within those categories, prioritise by HNDL risk: systems handling data with long classification retention periods or high sensitivity are the first migration targets because adversary collection of encrypted traffic carrying classified content is present-tense. The NSA's CNSA 2.0 timeline reflects NSA's own judgment about which categories of NSS are at highest exposure: software and firmware signing first, network equipment next.

Step 3: Hybrid Migration for Key Establishment

Deploy hybrid key exchange (ECDH P-384 + ML-KEM-1024) for TLS and IKEv2/IPsec on NSS-connected systems. This provides quantum protection for new sessions while maintaining classical interoperability during the transition. OpenSSL 3.x with the Open Quantum Safe liboqs integration supports ML-KEM; FIPS 140-3 validation of specific ML-KEM-1024 implementations is the constraint that determines which library versions can be deployed in federally accredited systems. Track the CMVP modules-in-process list for validated ML-KEM-1024 module availability. [INFERRED, CMVP validation of ML-KEM-1024 implementations is in progress as of mid-2026; verify current status before publication.]

Step 4: PKI and Certificate Infrastructure Migration

Transitioning to ML-DSA-87 for certificate signing requires replacing the full PKI hierarchy, not just leaf certificates but intermediate and root CAs. An intermediate CA signed with ECDSA P-384 cannot issue a CNSA 2.0-compliant trust chain. For DoD PKI, the DoD Public Key Infrastructure Programme manages the issuing CA infrastructure; migration of that CA hierarchy is a programme-level decision that contractors must co-ordinate with DISA and the authorised programme authority. Plan for this coordination lead time; it is not a unilateral technical change.

Step 5: Software and Firmware Signing Migration

Migrate code signing pipelines to ML-DSA-87, or to hybrid ML-DSA-87 + ECDSA P-384 during the transition. Update firmware signing keys for all DoD-delivered firmware. This is the category with the 2025 preference date. Contractors who deliver firmware updates to DoD weapons systems, aircraft, or communications infrastructure and have not yet begun this migration should treat it as the most overdue item on their CNSA 2.0 programme.

SLH-DSA (FIPS 205) is also appropriate for software and firmware signing where stateless operation is operationally required. SLH-DSA's security rests entirely on hash function properties, providing algorithm diversity from the lattice-based ML-DSA. For long-lived firmware signing chains where the cryptographic diversity argument is material, SLH-DSA is a defensible choice.

Step 6: CMVP Validation Verification

US federal and NSS systems require FIPS 140-3 validated cryptographic modules. For each ML-KEM-1024 and ML-DSA-87 implementation deployed in an NSS, verify that the implementing module has FIPS 140-3 validation. Not all ML-KEM and ML-DSA library implementations are yet validated; the validation queue typically runs 12 to 24 months. Deploying an unvalidated ML-KEM-1024 implementation in a system seeking an Authority to Operate may block accreditation. Track the NIST CMVP approved algorithms list and modules-in-process list for the specific hardware and software versions in use.

Step 7: Supply Chain Requirements

Prime contractors are responsible for the cryptographic posture of the systems they deliver to DoD. If a sub-tier software component uses ML-KEM-768 where ML-KEM-1024 is required, or ECDSA P-384 where ML-DSA-87 is required, the prime contractor's system does not meet CNSA 2.0. CNSA 2.0 obligations must flow to sub-tier suppliers through contract language and verification.

Practically this means three things: issue vendor questionnaires to sub-tier suppliers covering cryptographic algorithm usage; require written CNSA 2.0 migration roadmaps with target dates; and update procurement specifications for new components to include explicit ML-KEM-1024 and ML-DSA-87 requirements. Sub-tier suppliers without a documented CNSA 2.0 programme are a supply chain liability for the prime contractor who must deliver an accredited system. For the sub-tier supplier compliance perspective, see the CNSA 2.0 guide for sub-tier suppliers.

Step 8: RMF Documentation

Systems on DoD classified networks must be accredited under the DoD Risk Management Framework per DODI 8510.01. CNSA 2.0 requirements enter the RMF process at the security control selection step, through NIST SP 800-53 controls SC-12 (Cryptographic Key Establishment and Management) and related controls, and through DISA STIGs for specific technologies. Update System Security Plans to include CNSA 2.0 compliance status and migration milestones. Include CNSA 2.0 migration as a tracked item in Plans of Action and Milestones (POA&Ms) for systems with outstanding algorithm gaps. DISA is updating its STIGs to reflect CNSA 2.0 requirements; track DISA STIG releases for TLS, VPN, PKI, and code signing configurations.

The Compliance Hierarchy: Why "It Doesn't Apply to Us" Fails

CNSA 2.0 applies to all National Security Systems, defined in 44 U.S.C. § 3552(b)(6) as information systems operated by the US government or by contractors on its behalf that involve intelligence activities, cryptologic activities, command and control of military forces, equipment integral to weapons systems, or systems critical to direct fulfilment of military or intelligence missions. The statutory definition is broader than "classified systems at NSA."

DFARS clause 252.239-7001 (Information Assurance) provides the contractual flow-down mechanism for DoD cybersecurity requirements including cryptographic standards. [ASSUMED, 252.239-7001 is the relevant DFARS clause for CNSA 2.0 cryptographic flow-down; verify this clause number and its current text against the DFARS Part 239 before publication, as DFARS is subject to interim and final rules that may have introduced a more specific CNSA 2.0 clause.] A defence contractor delivering a system that meets the NSS definition, or delivering software or hardware components that are integrated into such a system by a prime contractor, is in scope. DFARS 252.204-7012 (Safeguarding Covered Defense Information) creates parallel obligations for systems handling Covered Defense Information. [ASSUMED, no formal dedicated DFARS clause explicitly mandating CNSA 2.0 compliance across all relevant contracts as of article authoring; verify whether such a clause has been published before the June 2026 publication date.]

CMMC v2.02 applies to contractors handling CUI or FCI and maps to NIST SP 800-171 Rev 3 for CMMC Level 2. [ASSUMED, CMMC v2.02 is the current version at article authoring; verify whether a newer CMMC version has been finalised before the June 2026 publication date, as the DoD has been iterating on CMMC rulemaking.] CMMC compliance does not substitute for CNSA 2.0 compliance. They address different requirements through different mechanisms. CMMC v2.02 does not yet explicitly mandate PQC deployment; CNSA 2.0 obligations flow through NSS designation, DFARS clauses, DISA STIGs, and RMF accreditation requirements. A contractor can be CMMC Level 2 certified and still have CNSA 2.0 compliance gaps.

National Security Memorandum 10 (NSM-10, January 2022) directed federal agencies to prioritise migration of NSS to quantum-resistant cryptography and established the policy framework CNSA 2.0 operationalises. The Q-Day context that motivated the timeline: the academic consensus (Webber et al., AVS Quantum Science, 2022) places the earliest plausible date for a CRQC capable of breaking RSA-2048 at 2033. NSA's required dates of 2030 to 2033 are designed to complete migration before that window opens.

Three Misconceptions Contractors Hold

"ML-KEM-768 is enough for DoD contracts." For NSS workloads, it is not. CNSA 2.0 mandates ML-KEM-1024 at NIST security category 5. ML-KEM-768 is the general recommendation for non-NSS applications. The parameter set is specified in procurement requirements, STIGs, and RMF documentation. Using the wrong parameter set is a compliance gap that will surface at accreditation.

"We can wait for the 2033 required date." The NSA's stated intent was for migration to be substantially advanced by the preference dates, several of which have already passed. A contractor starting from zero in 2026 has the required date window but must demonstrate progress in their RMF documentation and contractual reporting. FIPS 140-3 validation lead times of 12 to 24 months mean that development not started until 2026 or 2027 will constrain 2028 or 2029 deployment capability.

"Sub-tier suppliers are their own problem." Prime contractors must deliver CNSA 2.0-compliant systems. If a sub-tier component fails to meet the parameter requirements, the prime's system does not comply. Supply chain requirements must flow contractually; verification of sub-tier supplier CNSA 2.0 status is the prime's responsibility under the DoD's systems integration model. The CNSA 2.0 compliance audit framework and checklist provides a structured approach to verifying compliance at each tier.

What to Do Now

The compliance pathway is defined: CBOM, prioritisation, hybrid deployment, PKI migration, code signing migration, CMVP validation, supply chain requirements, RMF documentation. For large system integrators with extensive COTS dependencies and multi-tier supply chains, the execution is complex. The sequencing is not optional: each step depends on the previous one's output.

The most immediate action for any contractor who has not yet started: confirm the current IBM Quantum and NIST CMVP status of ML-KEM-1024 implementations for the specific HSM and cryptographic library platforms in use. FIPS 140-3 validation availability is the practical gating factor for production deployment in accredited systems, and the validation queue does not shorten by waiting.

QSECDEF's certificated training programme covers CNSA 2.0 algorithm selection, cryptographic inventory methodology, hybrid deployment for NSS contexts, and RMF security assessment documentation for PQC compliance. Details at QSECDEF certificated training programme. QSECDEF professional membership provides access to the practitioner methodology library and the community of security architects working through the same compliance programme.