The common problem in defence contractor CNSA 2.0 planning is not a lack of awareness that the requirement exists. It is the gap between knowing it exists and knowing which specific programmes it applies to, which milestones are immediately operative, and how CNSA 2.0 interacts with CMMC certification. Those three questions have specific, concrete answers that change what a compliance officer or programme security officer needs to do in 2026.

This article addresses the scope question first, because getting it wrong in either direction creates problems, and then works through the 2026 milestone, the CMMC interaction, and the structure of a compliance programme. For broader CNSA 2.0 supplier obligations, see the CNSA 2.0 vs 1.0 supplier comparison. For the full compliance programme framework, see the defence contractor compliance guide. For the key management layer of this migration, see the quantum key management comparison.

Which Defence Programmes Are in Scope for CNSA 2.0

CNSA 2.0 was published by NSA in September 2022. Its scope is National Security Systems (NSS), defined at 44 USC § 3552(b)(6) as telecommunications or information systems used or operated by the government, or by a contractor on its behalf, that process classified information or perform functions critical to a military or intelligence mission [VERIFIED: 44 USC § 3552(b)(6); NSA CNSA 2.0 Advisory, media.defense.gov]. The key question for any programme is whether the contractor's deliverable is or contains an NSS component.

CNSA 2.0 obligations are not universal across all defence contracts. A contractor building physical hardware with no cryptographic processing role may have no CNSA 2.0 obligation on that specific contract. The trigger is the system function: classification processing, or a critical military or intelligence function. The absence of explicit CNSA 2.0 language in the Statement of Work does not suspend the requirement if the system meets the NSS statutory definition. Silence in contract text is not a compliance exemption [VERIFIED: NISPOM, 32 CFR Part 117, §§ 117.18-117.22; INFERRED, NSS statutory definition as the trigger independent of contract specificity].

Sub-contractors receive CNSA 2.0 obligations via flow-down from prime contractors. DFARS clause 252.204-7012 (Safeguarding Covered Defense Information and Cyber Incident Reporting) establishes the general flow-down mechanism for cybersecurity requirements on defence contracts [VERIFIED: DFARS 252.204-7012]. A sub-contractor delivering a cryptographic subsystem to a prime for integration into an NSS-bound programme carries the CNSA 2.0 obligation for that subsystem. The prime cannot certify compliance of a sub-contractor-supplied component that does not meet the CNSA 2.0 algorithm requirements.

On cloud environments: DFARS 252.204-7012 requires contractors using cloud services for Covered Defense Information to use FedRAMP Moderate or equivalent. For NSS workloads, the applicable standard is higher. NSS-classified and CUI/NSS workloads require DISA Impact Level 5 (IL5) or IL6. The cryptographic requirements at those impact levels include CNSA 2.0 algorithm support for key establishment and authentication [VERIFIED: DoD Cloud Computing Security Requirements Guide; DFARS 252.204-7012].

CMMC and CNSA 2.0: Two Compliance Regimes on Different Clocks

The CMMC and CNSA 2.0 interaction is under-addressed in compliance planning and is the source of a specific, named gap that technically literate programme security officers need to understand.

CMMC (32 CFR Part 170, effective December 2024) establishes three certification levels for contractors handling Federal Contract Information and Controlled Unclassified Information [VERIFIED: 32 CFR Part 170, CMMC final rule, December 2024]. CMMC Level 2 maps to the 110 controls of NIST SP 800-171 Rev. 2 (note: NIST SP 800-171 Rev. 3 has been published but is not yet the CMMC assessment baseline). CMMC Level 3 adds 24 controls from NIST SP 800-172. Neither CMMC Level 2 nor Level 3 explicitly mandates CNSA 2.0 algorithm migration: NIST SP 800-171 predates the publication of FIPS 203, 204, and 205.

The relevant CMMC control is 3.13.10: "Employ FIPS-validated cryptography when used to protect the confidentiality of CUI." With FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) now published (August 2024), that control will eventually require PQC implementations [VERIFIED: NIST SP 800-171 Rev. 2, control 3.13.10; NIST FIPS 203/204/205, August 2024]. However, CMMC assessment guides have not yet been updated to reference FIPS 203/204/205 as the required implementations [ASSUMED: verify whether CMMC assessment guides have been updated as of June 2026 before publication]. Until they are, contractors may satisfy 3.13.10 with FIPS-validated legacy algorithms including AES-256 and RSA-3072.

The compliance risk is this: a CMMC-certified environment relying on RSA for key establishment satisfies current assessment criteria but does not meet CNSA 2.0 algorithm requirements if that environment also handles NSS workloads. The two frameworks are on different update cycles. Tracking only CMMC status while also carrying NSS programme obligations creates a false confidence problem. Both must be tracked and managed independently.

The 2026 Deadline: What It Actually Requires

NSA's CNSA 2.0 roadmap specifies four milestone years [VERIFIED: NSA CNSA 2.0 Advisory, Timeline Table; NSA CNSA 2.0 FAQ, Q7-Q10]:

  • End of 2025: All new software and firmware delivered on NSS programmes must be signed with CNSA 2.0 algorithms, ML-DSA-87, or stateful hash-based alternatives (XMSS per NIST SP 800-208, LMS per RFC 8554).
  • End of 2026: All new systems implementing PKI and key management must natively support CNSA 2.0 algorithms.
  • End of 2030: Deprecation of RSA and ECC for new key generation across all NSS.
  • End of 2033: Full retirement of RSA and ECC from all NSS.

The 2026 milestone is the most immediately operative for contractors with active programme deliveries. "Natively support" has a specific interpretation: the product as delivered must implement ML-KEM-1024 and ML-DSA-87 as standard, built-in capability, not as a planned future update or an optional extension pending future firmware [INFERRED: "natively support" as distinguishing built-in capability from planned patching, consistent with NSA's historical use of "support" in algorithm transition milestones]. A new command and control system delivered in Q3 2026 whose PKI and KMS components implement only X25519 and ECDH P-384 for key establishment does not meet the 2026 milestone.

The 2025 firmware signing milestone is worth addressing explicitly for contractors with Q1-Q2 2026 deliveries. That milestone required ML-DSA-87 signatures on new NSS firmware delivered after end of 2025. Contractors that updated firmware in Q1 2026 using RSA-PSS or ECDSA code signing are delivering firmware signatures that do not meet the 2025 milestone. Embedded system suppliers with long validation cycles, where a firmware update cycle can run 12-18 months, are the most exposed to this timing gap [VERIFIED: NSA CNSA 2.0 Advisory, software/firmware signing milestone; NIST SP 800-208, XMSS; IETF RFC 8554, LMS].

The 2030 and 2033 milestones apply to existing systems in service, not new deliveries. The 2026 milestone applies to new systems. Organisations conflating these timelines, treating the 2030 deprecation date as the relevant deadline for 2026 deliveries, are misreading the roadmap.

Building a CNSA 2.0 Compliance Programme: The Five Components

A structured CNSA 2.0 compliance programme for a defence contractor has five components [INFERRED: synthesis of CNSA 2.0 Advisory requirements, NISPOM SSP obligations, and standard programme security practice]:

Cryptographic inventory. Enumerate all cryptographic algorithms, key lengths, and protocols in scope for each NSS-bearing programme. Every RSA and ECC instance requiring migration must be identified before it can be prioritised. The NIST NCCoE SP 1800-38 series provides a practical reference methodology: SP 1800-38B (2024) covers key management migration including HSM firmware, PKCS#11 v3.1 integration, and KMIP 2.2 [VERIFIED: NIST NCCoE SP 1800-38B]. Start the inventory at programme level, not at the enterprise level: a system on an NSS-designated contract is in scope; a system on a CDI-only contract operating no NSS function may not be.

Programme-level scope classification. For each contract, apply the NSS test: does the deliverable contain or constitute an NSS component under 44 USC § 3552(b)(6)? This cannot be done at the enterprise level. The answer varies by programme, and the contracting officer technical representative and programme security officer need to make this determination together, documented in the programme SSP. Use the cryptographic inventory tool at QSECDEF Cryptographic Inventory to structure this exercise.

Vendor dependency assessment. Identify third-party components, HSMs, TLS libraries, VPN gateways, PKI systems, and their ML-KEM/ML-DSA support roadmaps. FIPS 140-3 validation timelines are the rate-limiting dependency: a library that implements ML-KEM-1024 but lacks FIPS 140-3 validation for that implementation is not compliant for NSS use. Plan for the validation timeline, not the implementation completion date. SP 1800-38C (TLS migration) provides reference architecture for the TLS layer [VERIFIED: NIST NCCoE SP 1800-38C].

Migration sequencing. Prioritise by programme delivery date and risk. Systems with deliveries in 2025-2026 are on the critical path for the PKI and KMS milestone. Systems already in service have until 2030 for RSA/ECC deprecation and 2033 for retirement, they are not on the critical path for 2026, unless contract modifications trigger new CNSA 2.0 obligations.

SSP update cycle. System Security Plans for classified NSS under NISPOM (32 CFR Part 117, §§ 117.18-117.22) must document cryptographic mechanisms used for all protective functions [VERIFIED: NISPOM, 32 CFR Part 117]. An SSP that still documents RSA or ECC as the primary key establishment mechanism is technically deficient once the CNSA 2.0 2026 milestone arrives for a new system. Plan SSP revisions to document ML-KEM-1024 and ML-DSA-87 implementations before DCSA oversight assessments. DCSA has published guidance encouraging contractors to begin cryptographic inventories and migration planning [ASSUMED: verify whether DCSA has issued specific assessment criteria for PQC migration as a named review item as of June 2026].

Hybrid Mode for NSS: Construction and Parameter Set Rules

NSA permits hybrid key establishment during the transition period, combining a classical algorithm with ML-KEM to protect against both classical and quantum adversaries while ecosystem migration proceeds [VERIFIED: NSA CNSA 2.0 FAQ, hybrid operation]. For NSS programmes, the hybrid construction is ECDH P-384 + ML-KEM-1024. This is a specific and non-negotiable parameter set requirement: ML-KEM-768 + X25519 is the commercial X-Wing construction (RFC 9496) and is not the approved NSS hybrid configuration [VERIFIED: IETF RFC 9496, X-Wing uses ML-KEM-768 + X25519; NSA CNSA 2.0 Advisory, NSS parameter requirements].

Programme managers and ISSOs specifying TLS configuration for NSS systems must verify that vendor documentation references ML-KEM-1024 and ECDH P-384 as the hybrid configuration. A vendor whose TLS implementation defaults to X-Wing (ML-KEM-768 + X25519) is not providing an NSS-compliant configuration without explicit reconfiguration to ML-KEM-1024 + P-384.

For digital signatures in hybrid mode: NSA's guidance permits pairing ML-DSA-87 with ECDSA P-384 during the transition for backward compatibility with verification infrastructure that cannot yet process ML-DSA signatures. NSA's stated preference is to move to pure ML-DSA-87 for new systems. Hybrid signatures add implementation complexity and performance overhead compared to hybrid KEMs; the practical case for hybrid signatures is specifically interoperability with existing verifiers [VERIFIED: NSA CNSA 2.0 FAQ, signature hybrid discussion; NIST FIPS 204].

Key Sizes and What They Mean for Programme Planning

Two parameter sets require specific attention in programme planning:

ML-KEM-1024 (FIPS 203, security Level 5, the CNSA 2.0 mandated variant): public key 1,568 bytes; ciphertext 1,568 bytes; shared secret 32 bytes [VERIFIED: NIST FIPS 203, Tables 2-3]. Compare ML-KEM-768 (Level 3): public key 1,184 bytes. The difference is relevant in high-volume PKI environments: 384 bytes per key exchange. On a system processing thousands of TLS sessions per second, that is a meaningful bandwidth planning consideration, but not a reason to substitute a lower security level.

ML-DSA-87 (FIPS 204, security Level 5, the CNSA 2.0 mandated variant): public key 2,592 bytes; private key 4,896 bytes; signature 4,627 bytes [VERIFIED: NIST FIPS 204, parameter tables]. Compare ECDSA P-384: public key 96 bytes; signature 96 bytes. The factor-of-48 increase in signature size for code signing operations, certificate issuance, and PKI hierarchy operations is a storage and bandwidth planning input. A contractor PKI hierarchy with a large code-signing certificate volume will see measurable HSM storage and network bandwidth changes. Plan for this at the capacity level, not as a compliance concern.

ML-DSA-65 (Level 3) is not the CNSA 2.0-compliant choice for NSS even though it is smaller than ML-DSA-87. The CNSA 2.0 mandate is Level 5. Selecting ML-DSA-65 to reduce bandwidth and storage overhead is a compliance defect, not an optimisation.

See the full defence contractor compliance guide for programme management timelines and SSP documentation templates. For detailed parameter set implications, see ML-KEM key sizes for enterprise architects.