CNSA 2.0 and the PQC Migration Reality Check for 2026

NSA’s CNSA 2.0 timeline stopped being a planning artifact sometime in 2025. Software and firmware signing was supposed to prefer LMS or XMSS by 2025 and require it by 2030. Web browsers, network gear, and operating systems are supposed to prefer ML-KEM and ML-DSA by 2025 and require them by 2030. Niche and legacy categories get until 2033. The 2035 “all NSS quantum-resistant” line is the one most program managers point at, but it is not the binding constraint — the binding constraint is the in-between work, and most systems I have assessed in 2026 are not on track.

FIPS 203, 204, and 205 have been final since August 2024. FIPS 206 (FN-DSA / Falcon) is in draft as of this writing. The standards exist. The HSM firmware exists. The TLS 1.3 hybrid groups (X25519MLKEM768 and friends) are in Chrome, Edge, Firefox, OpenSSL 3.5, and BoringSSL. The ecosystem is no longer the problem. The problem is that nobody has an honest crypto inventory, and the SR, SC, and CM controls that should have surfaced this gap years ago were satisfied with paperwork.

The crypto inventory most programs do not actually have

A real cryptographic bill of materials (CBOM) tells you, per system and per data flow, which algorithms are in use, where the keys live, what their lifetimes are, and which protocol versions negotiate them. CycloneDX 1.6 added the cryptography schema specifically for this, and the CISA/NSA/NIST joint guidance from 2024 leaned hard on it. What I see in 2026 ATO packages is still, overwhelmingly, a spreadsheet that says “TLS 1.2/1.3, AES-256, RSA-2048, SHA-256” and calls it done.

That spreadsheet is wrong on its face. It does not capture:

• KEX algorithms negotiated at runtime versus those configured
• Code-signing chains, including intermediate CAs you do not control
• Long-lived signed artifacts (firmware, container images, Authenticode binaries) whose signatures must remain verifiable past 2035
• Embedded or vendor-supplied crypto inside appliances, HSMs, and FIPS modules whose certificates predate ML-KEM
• Data-at-rest encryption where the KEK is RSA-wrapped on a smartcard issued in 2019

AU-2, CM-8, and SA-4(10) all already required this level of fidelity. The PQC transition is what makes the absence of it expensive.

Hybrid is not a hedge, it is the deployment model

The production answer for transport security in 2026 is hybrid key establishment: a classical curve concatenated with ML-KEM-768, with the shared secret derived from both. This is not a compromise position. NIST SP 800-227 (final in 2025) specifies the construction; CNSA 2.0 explicitly permits hybrid through the transition window; and every serious TLS stack ships it.

The operational issues are mundane and unsexy:

• MTU and fragmentation. ML-KEM-768 ciphertexts are 1088 bytes. ClientHello messages now routinely exceed a single TCP segment, and middleboxes that assumed otherwise drop them. If your WAF, load balancer, or DPI appliance was last tuned in 2022, expect connection failures that look like classical bugs.
• QUIC initial packet sizing. Hybrid ClientHellos break the 1200-byte initial packet assumption in older QUIC implementations.
• Session resumption and 0-RTT. PQ-hybrid resumption tickets are larger; some stacks silently fall back to full handshake under memory pressure.
• HSM throughput. ML-DSA signing is dramatically slower per-op than ECDSA P-256 on most current HSMs. Code-signing pipelines that batch thousands of signatures need to be re-benchmarked, not assumed.

None of this is theoretical in 2026. It is what shows up in SI-4 telemetry as “intermittent TLS errors” two weeks after a stack upgrade.

The signature problem is worse than the KEM problem

KEMs protect confidentiality forward. Signatures protect authenticity, and the failure mode is different: a signature scheme broken in 2032 retroactively invalidates trust in everything signed under it that is still in service. Firmware images, secure boot chains, signed driver packages, and long-lived JWTs are the obvious cases. Less obvious: signed log archives kept for AU-11 retention, and signed artifacts in your SBOM attestation chain (SR-4, SR-11).

LMS and XMSS are stateful hash-based signatures. They are mature, NIST-approved (SP 800-208), and the right answer for firmware and bootloader signing because the signer side can be operated as a controlled, audited process. They are the wrong answer anywhere statefulness cannot be guaranteed — and “we will just be careful with the state” is not a control.

ML-DSA is the general-purpose replacement for ECDSA and RSA signatures. SLH-DSA (the stateless hash-based option) is the conservative fallback if a lattice break ever materializes. A defensible signing strategy in 2026 picks one primary and one contingency, and the PKI is designed so the contingency can be activated without re-issuing every leaf.

Mapping to controls assessors will actually cite

The SR family is where most programs will get hurt. You cannot ship PQC if your appliance vendors cannot, and “vendor commitment” in a glossy slide is not a contract clause.

What a credible 2026 posture looks like

If an ISSO asked me what minimum evidence I would accept this year for a system claiming PQC readiness, it would be: a generated CBOM updated per build; hybrid key establishment enabled in production for all externally-facing TLS endpoints with telemetry showing actual negotiation rates; a signed migration plan with named owners for each long-lived signature use case; HSM and PKI vendor commitments with dates; and a tested rollback path. Anything less is a paper exercise that will not survive contact with 2030.

The quantum computer that breaks RSA-2048 may or may not exist on schedule. The deadlines do.