CNSA 2.0 for the Defense Industrial Base

Introduction

If you build, sell, or support anything that touches a U.S. National Security System, CNSA 2.0 is your problem. Not in the sense that it would be nice to prepare for. In the sense that your products will fail a procurement gate on January 1, 2027, if they cannot demonstrate support for ML-KEM-1024 and ML-DSA-87. No phase-in, no conditional certification, no workaround through a different acquisition pathway.

And CNSA 2.0 is not arriving alone. Defense contractors are simultaneously absorbing CMMC 2.0 Phase 2 enforcement (mandatory third-party assessments starting November 2026), the FIPS 140-2 sunset (all certificates moving to Historical status on September 21, 2026), and the ongoing FIPS 140-3 validation backlog that currently averages over 500 days from submission to active certificate. Each of these requirements interacts with the others, and each assumes the previous has been addressed.

For an industry that already spends significant resources on compliance, the compound burden is substantial. But the consequences of non-compliance are binary: products that cannot demonstrate CNSA 2.0 support will not be procured for NSS. Contractors that cannot demonstrate CMMC Level 2 compliance will not be awarded new contracts involving CUI. The defense supply chain is being filtered on cryptographic capability in a way it has never been before.

Who Is Actually Affected

CNSA 2.0 formally applies to National Security Systems. That sounds narrow until you trace the supply chain.

NSS includes systems handling classified information and systems supporting military, defense, or intelligence functions. The primes that build these systems (Lockheed Martin, Boeing, Northrop Grumman, RTX, General Dynamics, L3Harris) are directly in scope. But the requirements do not stop at the prime. Every component that performs a cryptographic operation within an NSS must use CNSA 2.0 algorithms. The operating system, the VPN concentrator, the HSM, the TLS library, the firmware signing mechanism, the certificate infrastructure. If any one of these components uses only classical algorithms after the gate closes, the system is non-compliant.

This cascade reaches deep into the supply chain. A small manufacturer providing an embedded controller with encrypted communications for a weapons system is in scope if that controller handles cryptographic operations. A cloud provider whose platform hosts a classified workload is in scope. A software vendor whose code-signing infrastructure validates firmware destined for an NSS deployment is in scope. The question is not “does CNSA 2.0 apply to me?” but rather “do any of my products, systems, or services end up inside or adjacent to a National Security System?”

For the commercial technology companies that serve the defense market without thinking of themselves as defense contractors, this is the wake-up call. If your HSM, your TLS stack, your PKI platform, or your operating system is deployed in an NSS context, your product must support ML-KEM-1024, ML-DSA-87, and the validation requirements that accompany them.

The Compound Compliance Challenge

The timing of concurrent compliance requirements creates a compounding effect that is worse than any individual mandate would be on its own. As I detail in the 2027 procurement gate analysis, three deadlines arrive within a five-month window, and each depends on the one before it.

September 21, 2026 brings the FIPS 140-2 sunset. Cryptographic modules validated under the old standard move to Historical status, meaning they cannot be specified for new federal procurement. For defense contractors, this is directly relevant to CMMC compliance: Control 3.13.11 of NIST SP 800-171 requires “FIPS-validated cryptography when used to protect the confidentiality of CUI.” After September 21, a Historical FIPS 140-2 certificate may not satisfy this requirement during a C3PAO assessment.

November 10, 2026 begins CMMC 2.0 Phase 2, when mandatory third-party C3PAO assessments start for most Level 2 contracts. Over 220,000 contractors and subcontractors are affected. Only about 1% of the defense supply chain is estimated to be fully prepared for Phase 2 assessments. The C3PAO assessment is evidence-driven: running your system in “FIPS mode” without holding an active CMVP certificate does not satisfy the control. A C3PAO assessor will look for a certificate number in the NIST database tied to a specific module version.

January 1, 2027 activates the CNSA 2.0 acquisition gate. All new NSS acquisitions must support CNSA 2.0 algorithms. For contractors delivering systems into NSS environments, this means NIAP validation against updated Protection Profiles that incorporate CNSA 2.0 algorithms. FIPS validation alone is insufficient; the NSA-approved designation requires NIAP validation plus correct configuration per CNSSP 15.

The dependency chain is clear. Without an active FIPS 140-3 certificate (September gate), your CMMC assessment is at risk (November gate). Without FIPS 140-3 and NIAP validation with CNSA 2.0 algorithms, your products fail the NSS procurement gate (January gate). Missing the first deadline cascades through the second and third with no recovery path that fits within the remaining timeline.

What Primes Are Already Doing

The major defense primes are not waiting for the deadlines. They are restructuring their supply chains now.

Lockheed Martin, Boeing, Northrop Grumman, RTX, and General Dynamics have issued supplier directives requiring compliance documentation from their sub-tier vendors. Some FY2026 contracts already include C3PAO certification requirements, even before Phase 2 formally begins. The Consolidated Cybersecurity Risk Assessment (CCRA), a standardized questionnaire developed by the Defense Industrial Base Sector Coordinating Council and delivered through Exostar, is being used by multiple primes to evaluate suppliers on a reciprocal basis. The CCRA contains up to 60 questions drawn from NIST SP 800-171, and primes can see the results directly.

Under DFARS 252.204-7021, primes are legally responsible for ensuring their subcontractors comply with CMMC requirements. A prime that knowingly awards work to a non-compliant subcontractor and misrepresents supply chain compliance faces liability under the False Claims Act. This liability structure means primes have a financial incentive to exclude subcontractors that cannot demonstrate compliance, and they are acting on it.

The practical effect: subcontractors that cannot demonstrate CMMC readiness and, increasingly, CNSA 2.0 awareness are being excluded from bid teams before formal assessments even begin. For small and mid-size defense contractors, which make up over 70% of the DIB, this filtering is already reducing contract opportunities.

CNSA 2.0 awareness at the prime level is currently less mature than CMMC compliance. Most prime contractor supplier questionnaires focus on CMMC and NIST SP 800-171 controls. But as the January 2027 gate approaches, primes building systems for NSS delivery will need to verify that their supply chain components support CNSA 2.0 algorithms. The logical next step is that CNSA 2.0 capability questions will appear in supplier qualification processes, likely through additions to existing CCRA-type instruments or through program-specific requirements in solicitations.

CMMC 2.0 and CNSA 2.0: Related but Different

A common point of confusion in the DIB is the relationship between CMMC 2.0 and CNSA 2.0. They are related but address different things, apply to different system boundaries, and use different enforcement mechanisms.

CMMC 2.0 governs how contractors protect CUI and FCI in their own environments. It requires implementing the 110 security controls of NIST SP 800-171, validated through self-assessment or third-party C3PAO assessment. Its focus is the contractor’s enterprise IT and the systems that handle controlled information. CMMC does not specify which cryptographic algorithms to use; it requires that the algorithms be FIPS-validated.

CNSA 2.0 governs which cryptographic algorithms are approved for National Security Systems. Its focus is the products and systems that operate within or interface with NSS. It specifies exact algorithms (ML-KEM-1024, ML-DSA-87) at exact parameter levels, and requires NIAP validation against Protection Profiles that incorporate these algorithms.

A defense contractor can be fully CMMC Level 2 compliant (all 110 controls implemented, SSP documented, C3PAO certified) and still fail the CNSA 2.0 procurement gate if the products it sells into NSS do not support the required algorithms. Conversely, a product can support every CNSA 2.0 algorithm perfectly but its manufacturer could fail a CMMC assessment due to inadequate access controls or incident response procedures in the corporate environment.

Both are necessary. Neither is sufficient alone. The contractor’s enterprise must pass CMMC. The contractor’s products must pass CNSA 2.0. The timelines for both converge in the same five-month window.

The FIPS 140-3 Bottleneck

The CMVP validation queue is the constraint that binds every other timeline in the DIB’s compliance roadmap. FIPS 140-3 validations currently average over 500 days from submission to active certificate. For post-quantum algorithms specifically, the testing infrastructure is newer and less proven, adding uncertainty to an already long process.

An organization that submitted a PQC-capable cryptographic module to the CMVP in late 2024 or early 2025 is likely to have an active certificate by mid-2026 or early 2027. An organization that enters the queue in mid-2026 is looking at early 2028 at best. For the January 2027 gate, the math is unforgiving.

There is a practical distinction in the CNSA 2.0 guidance that eases the near-term burden for some contractors. Products that only verify signatures (rather than generate them) can satisfy the CNSA 2.0 requirement through CAVP (algorithm-level) testing rather than full CMVP (module-level) validation. Most end-user devices in NSS environments verify firmware signatures; they do not generate them. For these products, CAVP certificates for LMS, XMSS, ML-KEM, and ML-DSA verification are achievable on a much shorter timeline than full module validation.

But for any product that performs key generation, key establishment, or signature generation (HSMs, certificate authorities, VPN gateways, signing infrastructure), full CMVP validation is required with no exception. These are the products where the 500-day queue creates the hardest bottleneck, and they are the products most critical to the CNSA 2.0 transition.

For the broader US PQC regulatory framework, the FIPS 140-3 bottleneck is the single most common reason organizations cite for delayed PQC readiness. The queue is a fixed resource. Organizations that entered it early have a structural advantage that no amount of late-stage urgency can replicate.

The Waiver Trap

CNSA 2.0 allows waivers for systems that cannot meet the algorithm requirements by the relevant deadline. Some defense contractors are treating waivers as an implicit extension, planning to deploy classical-only products and apply for an exception after the fact.

This is a losing strategy for several reasons.

Waivers are specific to the algorithm, implementation, and use case. Each one must be individually justified and approved. A blanket waiver that covers an entire product line or program does not exist in the CNSA 2.0 framework. Every waiver requires documentation of why CNSA 2.0 compliance cannot be achieved, a remediation plan with a timeline for achieving compliance, and approval through the appropriate NSS governance channel.

Every active waiver creates audit exposure. During RMF assessments, Approving Officials must verify compliance with CNSA 2.0 as part of Security Control SC-12. A system operating under waiver is a documented deviation that must be tracked, reported, and justified at each assessment cycle. The administrative burden accumulates.

Primes building NSS are incentivized to avoid sub-components that require waivers. A system integrator assembling a solution for an NSS program will prefer vendors whose products are CNSA 2.0 compliant out of the box over vendors whose products require exceptions. The waiver creates compliance overhead for the sub-tier supplier, the prime, and the program office simultaneously. Given a choice between a compliant component and one that requires a waiver, the compliant component wins.

The competitive dynamic is the strongest argument against the waiver strategy. As CNSA 2.0 compliant products become available from competing vendors, the justification for a waiver weakens. If ML-KEM-1024 support is available from three VPN vendors and your product does not support it, the program office has no reason to grant a waiver; they will simply select a compliant vendor. The waiver is a tool for genuinely unavoidable gaps (legacy hardware that cannot be upgraded, constrained devices where PQC implementation is not yet technically feasible), not a substitute for engineering investment.

The Small Contractor Problem

The compound compliance burden falls disproportionately on small and mid-size defense contractors. A 50-person machine shop that handles CUI for a weapons program faces the same CMMC Level 2 requirements as a 50,000-person prime. The fixed costs of compliance (C3PAO assessments, SSP development, FIPS-validated cryptographic modules, ongoing monitoring) are the same regardless of company size.

Adding CNSA 2.0 requirements to this picture compounds the pressure. A small contractor whose products include embedded systems with cryptographic functions must now evaluate whether those systems support ML-KEM-1024 and ML-DSA-87, determine whether their cryptographic libraries have FIPS 140-3 validation in the pipeline, and potentially redesign components that cannot accommodate the larger key and signature sizes that post-quantum algorithms produce.

Industry analysts project that CMMC alone could drive a 15-20% contraction in the Defense Industrial Base as smaller contractors exit the market or are acquired. Adding CNSA 2.0 requirements to the equation accelerates this consolidation. The contractors that survive will be those that treated compliance as a strategic investment rather than a cost to be minimized.

For small contractors that lack in-house cryptographic expertise, the starting point is clear: determine whether your products perform any cryptographic operations that could end up in an NSS context. If the answer is yes, you need to understand which algorithms your cryptographic libraries support, whether those libraries are on a FIPS 140-3 validation track that includes PQC algorithms, and whether your hardware can support the computational and bandwidth overhead of ML-KEM-1024 and ML-DSA-87.

The PQC Migration Framework provides a structured methodology for this assessment that scales to organizations of any size. The framework’s cryptographic inventory phase is the essential first step, and it does not require specialized quantum computing knowledge — it requires systematic identification of where cryptography exists in your products and infrastructure.

What “Ready” Looks Like for the DIB

Organizations positioned to clear the converging deadlines share recognizable characteristics.

They have completed a cryptographic inventory across every product line that touches or could touch NSS. They understand the distinction between their enterprise IT environment (CMMC scope) and their product cryptographic capabilities (CNSA 2.0 scope), and they have compliance programs addressing both.

They have FIPS 140-3 module submissions in the CMVP pipeline, with PQC algorithm support included. They are not waiting for their upstream library vendor to achieve validation; they have verified the validation timeline and have contingency plans if it slips.

They have begun firmware signing pilots with LMS or XMSS for products that deploy into NSS, because firmware roots of trust are the hardest component to retrofit and the one CNSA 2.0 prioritizes most urgently.

They are tracking NIAP Protection Profile updates and engaging with the CSfC program to understand how CNSA 2.0 algorithm requirements will appear in product evaluations.

They have communicated their CNSA 2.0 readiness posture to their prime contractor customers proactively, not waiting to be asked. In a market where primes are actively culling non-compliant suppliers, demonstrating CNSA 2.0 awareness before it appears in a formal supplier questionnaire is a competitive advantage.

And they are designing for crypto-agility, because CNSA 2.0 is a snapshot of NSA’s current assessment, not a permanent endpoint. A product that can support ML-KEM-1024 today and swap to a different algorithm tomorrow, whether because lattice assumptions weaken or because a new standard emerges, has a longer competitive life than one that hard-codes a single algorithm.

The Timeline Is Not the Problem

I hear frequently from defense contractors that the CNSA 2.0 timeline is “aggressive” or “unrealistic.” There is some truth to this: the FIPS 140-3 validation queue alone makes certain deadlines structurally difficult to meet. But the timeline is also not going to change. NSA’s Dr. Morgan Stern confirmed at RSA Conference 2026 that CNSSP-15 was updated in 2025 to deprecate CNSA 1.0, Protection Profiles began releasing in 2026, and the transition is underway.

As I have argued throughout PostQuantum.com, the relevant question is no longer when a cryptanalytically relevant quantum computer will arrive. The relevant question is whether your organization can clear the compliance gates that are already set. For defense contractors, those gates are closer and more consequential than for any other sector.

The organizations that frame CNSA 2.0 as a 2030 or 2035 problem are the ones most likely to discover that they missed the 2027 gate. The organizations that frame it as an engineering and procurement problem to be solved starting now are the ones that will still be selling into the defense market on January 2, 2027.

For the broader organizational readiness question — building the business case, briefing leadership, and structuring a multi-year compliance program that addresses both CMMC and CNSA 2.0, Quantum Ready covers the strategic dimension. And for a detailed walkthrough of PQC migration mechanics, see my Practical Steps to Quantum Readiness guide.