CNSA 2.0 Compliance Guide

1. The 2027 Deadline Is Nine Months Away

Starting January 1, 2027, every new national security system acquisition has to support the NSA's Commercial National Security Algorithm Suite 2.0 – CNSA 2.0. That's the post-quantum mandate, and it's no longer a slide in a future roadmap. It's a procurement gate that vendors either clear or lose the business.

The ripple effect extends well past the Department of Defense. Every defense contractor, every sub-tier supplier, every commercial vendor selling anything into a classified or controlled environment is on the hook. And the downstream effect on commercial PKI is already showing up in procurement language – enterprise buyers referencing CNSA 2.0 algorithms as a forward-looking requirement, even for systems that will never touch a national security network.

This guide covers what CNSA 2.0 actually requires, who it affects, the full timeline through 2035, and the practical work to get there. The short version: the algorithms exist, the standards are finalised, and the remaining gap is almost entirely in the certificate infrastructure that issues, rotates, and manages those algorithms at scale.

2. What Is CNSA 2.0?

CNSA – the Commercial National Security Algorithm Suite – is the NSA's approved algorithm list for protecting National Security Systems (NSS). NSS is defined broadly: any federal system involved in intelligence activities, cryptologic activities, command and control of military forces, weapons systems, or the processing of classified information. If a system is in that scope, the algorithms it uses are constrained by whatever version of CNSA is current.

CNSA 1.0 – the suite that shipped in 2015 and that virtually every large enterprise PKI has been aligned with in some form – is an all-classical suite: RSA-3072 or ECDSA P-384 for signatures, ECDH P-384 for key exchange, AES-256 for symmetric encryption, SHA-384 for hashing. It's the "conservative but classical" baseline. A sufficiently capable quantum computer running Shor's algorithm breaks RSA and ECC; the symmetric and hash primitives remain intact but halved in effective strength.

CNSA 2.0 is the replacement, announced by the NSA in September 2022 and refined through a series of advisories since. The mandate swaps the quantum-vulnerable primitives (RSA, ECC) for lattice-based and hash-based post-quantum alternatives, and hardens the symmetric and hash primitives by specifying the highest-security parameters. The algorithms are the NIST PQC standards – FIPS 203 (ML-KEM, formerly CRYSTALS-Kyber), FIPS 204 (ML-DSA, formerly CRYSTALS-Dilithium) – plus established hash-based signatures for code and firmware.

The policy scaffolding runs through CNSSP-15 (the National Manager for NSS policy that formalises CNSA in acquisition requirements) and NSM-10 (the 2022 National Security Memorandum that sets the 2035 goal for NSS quantum resistance). Together they turn an algorithm list into a procurement and compliance regime.

3. The Required Algorithms

CNSA 2.0 specifies five primitives. Every NSS system has to use the version listed below for its function – no longer a range of "acceptable" parameters, but a specific pick per category.

AES-256 is the symmetric baseline. Grover's algorithm halves its effective security against a quantum adversary, which is why CNSA 2.0 mandates the 256-bit variant rather than the AES-128 common in commercial deployments – the post-quantum effective strength is 128 bits, enough to remain secure for the foreseeable future.

ML-KEM-1024 is the lattice-based key encapsulation mechanism. It replaces ECDH and RSA key exchange. The "1024" refers to the parameter set that delivers Category 5 security, the highest of three NIST levels. ML-KEM-1024 is what two endpoints use to agree on a symmetric session key without a quantum-vulnerable handshake.

ML-DSA-87 is the lattice-based digital signature algorithm. It replaces RSA and ECDSA signatures for general use – certificate signing, document signing, authentication tokens, and anything else that previously produced an RSA or ECDSA signature. "87" is again the Category 5 parameter set. Signatures are larger than ECDSA (roughly 4,627 bytes vs 64), which has real implications for protocols with small headroom.

LMS and XMSS are stateful hash-based signatures, reserved for the specific case of software and firmware signing. Hash-based signatures are quantum-safe on the strength of the underlying hash function alone, which is why they were available long before lattice schemes matured. The stateful variant is appropriate for signing because the number of signatures is known and bounded – you're not signing a billion things with the same key.

4. The Compliance Timeline

The dates in CNSA 2.0 aren't a single cliff – they're staggered by equipment category, reflecting realistic migration timelines for each. The universal deadline is 2035: every NSS must be fully CNSA 2.0 compliant by then, no exceptions. But the milestones before that dictate procurement and deployment choices now.

The 2027 acquisition gate is the one that reorders immediate planning. A system being procured now but delivered in 2027 has to ship CNSA 2.0 capable out of the box. That pushes the real readiness deadline backward into 2026 for vendor engineering, into 2025 for standards conformance testing, and essentially into today for architectural choices that will determine whether an existing product line can even be adapted.

5. Who Needs to Comply?

CNSA 2.0 directly binds three overlapping populations. The directness falls off as you move outward, but the practical pressure doesn't.

NSS operators. Federal agencies running systems designated as national security systems – the DoD, the intelligence community, the military services, and the civilian agencies with NSS-scoped environments. These are the primary bound parties and the subjects of CNSSP-15 and NSM-10.

Defense contractors and their suppliers. Anyone selling into the NSS procurement channel, including prime contractors and the entire sub-tier supplier base feeding them. The 2027 acquisition gate means primes will cascade the requirement down – a sub-sub-contractor providing a component that ends up in a classified system is in scope for the algorithms that component uses, because the prime has to demonstrate CNSA 2.0 compliance for the whole.

Commercial vendors with federal customers. Any product sold to the federal government for use in a controlled environment – FedRAMP High systems, CUI-handling infrastructure, Impact Level 4/5/6 cloud services – inherits CNSA 2.0 pressure even where the system isn't classified. Agencies will read the NSA guidance as a forward indicator and build it into procurement language ahead of the formal mandate.

The second-order population is commercial infrastructure vendors with no federal business at all. They don't have a CNSA 2.0 mandate, but their enterprise customers are increasingly asking for CNSA 2.0-aligned algorithms in RFPs as a proxy for "quantum-ready" – and it's harder to be wrong shipping Category 5 parameters than to argue for something weaker.

6. The Certificate Infrastructure Gap

An algorithm in a library isn't the same as an algorithm in production. The NIST standards are finalised, OpenSSL 3.5 exposes ML-KEM and ML-DSA through its EVP API, BoringSSL has landed experimental support, and the major cryptographic vendors have CNSA 2.0 roadmaps. So why isn't the migration already done?

Because the binding layer is certificates, and most enterprise PKI wasn't built to handle a simultaneous algorithm rollover at scale. Four specific gaps show up repeatedly:

Issuance pipelines only know classical algorithms. The internal CA, the ACME server, the SCEP responder, the MDM enrollment flow – each of these has to understand how to accept a CSR with an ML-DSA public key, validate it, sign a certificate with an ML-DSA issuer key, and return a chain. Most CA software built before 2024 either can't do this at all or can do it only in an experimental branch.

Key management doesn't support hybrid material. ML-DSA keys are big (the public key is ~2.6 KB for ML-DSA-87, the private key is larger). Hardware security modules that were sized for RSA-3072 and ECDSA P-384 may not have the object size or the PQC algorithm support to hold and operate on them. The enterprise key management plane has to be upgraded in lockstep with the CA.

Relying parties validate classical chains only. Every system that terminates TLS, validates a client certificate, or checks a code signature is a relying party, and each one has to learn to parse ML-DSA signatures. In an enterprise with thousands of relying party configurations – load balancers, ingress controllers, RADIUS servers, supplicants, MDM agents – the coordination problem is the dominant cost.

No visibility into current algorithm inventory. Teams don't generally know which certificates in their fleet use which algorithms. Without that baseline, you can't plan the migration, can't prioritise, and can't measure progress. [cyphrs] Scout surfaces algorithm distribution alongside the standard expiry and issuer fields, which is the starting point for any CNSA 2.0 readiness work.

The shared pattern across these gaps: CNSA 2.0 is a PKI problem, not a protocol problem. Getting ML-DSA into a TLS handshake is the easy part. Getting an enterprise CA to issue, rotate, and revoke ML-DSA certificates at scale, with the tooling and automation that makes that sustainable, is the hard part – and it's the part most readiness plans underestimate.

7. Hybrid Certificates as the Bridge

A hard cutover from classical to post-quantum certificates isn't practical for most enterprises. Relying-party support for ML-DSA is still rolling out, and many embedded devices, legacy appliances, and older operating systems will never get a firmware update that adds lattice verification. The bridge pattern is a hybrid certificate: one cert, two signatures, classical and post-quantum side by side.

Three concrete hybrid approaches are converging, all covered in the Gartner 2026 Buyers' Guide for PKI and Certificate Lifecycle Management:

Composite signatures encode the two signatures as a single X.509 signature field using a new algorithm OID. Simple on the surface, but changes the signature algorithm identifier – every relying party has to recognise the new OID or the certificate fails to parse.

Chameleon certificates use a delta-extraction mechanism to produce two valid "views" of the same certificate, one classical and one post-quantum. Elegant, but requires each relying party to implement the extraction step, which is non-trivial for embedded stacks.

Catalyst extensions carry a post-quantum alternate public key and signature as a non-critical X.509 extension. A classical relying party parses the cert as a normal ECDSA or RSA certificate and ignores the extension; a quantum-aware relying party additionally verifies the ML-DSA signature over the binding hash. No OID churn, no parser rewrites, graceful fallback. Catalyst is the pragmatic choice for enterprises mid-migration, and it's the approach [cyphrs] Trust CA issues today.

The value of hybrid is that it lets the readiness timeline decouple from the relying-party upgrade timeline. A hybrid certificate issued today passes validation on both current and future stacks. When enough of the relying-party population has caught up – and when CNSA 2.0 enforcement tightens toward 2030 – the issuance flips to ML-DSA-only without a second migration. The infrastructure that supports hybrid today is the infrastructure that supports pure PQC later. See Post-Quantum Cryptography Is Not a Future Problem for the four-phase bridge model in more depth.

8. The CNSA 2.0 Readiness Checklist

Eight concrete steps, ordered. The sequence matters: you can't plan a migration you haven't inventoried, and you can't test the end state without a target architecture.

The checklist above scales from a single product line to an agency-wide programme with the same ordering. What changes is the breadth of each step, not the sequence.

9. Beyond NSS – Why Commercial Orgs Should Care

Most organisations reading this aren't bound by CNSA 2.0 directly. The compliance regime still matters, for four practical reasons.

Supply chain pull-through. If any part of the business ships into federal channels, sub-sub-tier pull-through will catch up. Vendors learn the CNSA 2.0 requirement when a prime contractor flows it down, and at that point "our roadmap has PQC in 2028" stops being an acceptable answer.

Data longevity. The "harvest now, decrypt later" threat model assumes adversaries are already capturing ciphertext that a future quantum computer will break. For data with a 10-year confidentiality requirement – health records, legal archives, intellectual property, long-horizon M&A materials – the migration deadline is not 2035 but today, because anything encrypted under a classical key exchange from now onward is potentially compromised in retrospect.

Audit and insurance. Cyber insurance renewals and regulatory audits are starting to reference quantum readiness. Exact language varies, but CNSA 2.0 alignment has become a convenient proxy – an enterprise that can demonstrate an ML-DSA-87 issuance path, hybrid deployment, and an algorithm inventory is visibly ahead of an enterprise that can't.

Competitive positioning. When two vendors bid on an enterprise PKI engagement and only one ships hybrid certificates today, the conversation is short. CNSA 2.0 is giving enterprise buyers a vocabulary they didn't have before – "quantum-safe" is fuzzy, but "supports ML-DSA-87 issuance" is a checkable fact.

None of this changes whether CNSA 2.0 is legally binding on a commercial organisation. It changes how quickly the market will demand alignment anyway.

10. Frequently Asked Questions