What CNSA 2.0 actually is
CNSA 2.0 is the NSA's Commercial National Security Algorithm Suite, version 2.0 — the set of cryptographic algorithms the agency requires for protecting US national security systems (NSS) in a world where a cryptographically relevant quantum computer is a planning assumption rather than a hypothetical. It is the successor to CNSA 1.0, which was built around RSA, ECDH, and ECDSA — exactly the public-key algorithms that Shor's algorithm breaks.
The important framing for a buyer or compliance lead: CNSA 2.0 is not a law and not a NIST standard. It is a requirements suite issued by the NSA. It points at NIST's finalized post-quantum standards for the algorithms themselves, then layers on the federal expectation of when and where they must be used. That distinction matters because the algorithms are governed by NIST (FIPS 203/204/205), while the migration mandate and timeline are governed by NSA and the broader National Security Memorandum framework (NSM-8 and NSM-10).
Why a new suite at all: the quantum threat, stated precisely
The quantum threat is narrower and sharper than most marketing implies, and CNSA 2.0's algorithm choices reflect that precision. Shor's algorithm efficiently breaks the asymmetric, public-key primitives — RSA, finite-field and elliptic-curve Diffie-Hellman, and ECDSA. Those underpin key establishment and digital signatures across essentially all modern protocols.
Symmetric cryptography and hashing are affected only by Grover's algorithm, which provides at most a quadratic speedup. That halves the effective security level rather than collapsing it: AES-256 drops to roughly 128 bits of post-quantum security (safe), AES-128 to roughly 64 bits (marginal), and SHA-384/512 remain comfortable. This is precisely why CNSA 2.0 replaces the asymmetric layer with lattice schemes while keeping symmetric and hash primitives classical — it raises them to AES-256 and SHA-384 rather than inventing new ones.
The algorithms CNSA 2.0 mandates
CNSA 2.0 deliberately selects the algorithms NIST finalized in August 2024, not draft candidates. That conservatism is the point — national security systems should not standardize on a moving target.
- Key establishment: ML-KEM (Module-Lattice Key Encapsulation Mechanism), standardized as FIPS 203. CNSA 2.0 specifies the highest parameter set, ML-KEM-1024.
- Digital signatures (general purpose): ML-DSA (Module-Lattice Digital Signature Algorithm), standardized as FIPS 204.
- Digital signatures (software/firmware): stateful hash-based signatures LMS and XMSS are specified for firmware and software signing, where their one-time-use constraints are manageable; SLH-DSA (FIPS 205) is the stateless hash-based option.
- Symmetric encryption: AES-256.
- Hashing: SHA-384 (and SHA-512 where appropriate).
- FIPS 206 (FN-DSA / Falcon) is still a DRAFT standard and is therefore not part of the finalized federal requirement; HQC was selected by NIST in March 2025 as a backup KEM but is not yet a finalized FIPS standard either.
The timeline is staged, not a single date
This is the single most misunderstood part of CNSA 2.0. There is no one switch flipped on one day. The NSA published a staged transition where different product categories adopt and then exclusively use CNSA 2.0 algorithms on different schedules, with the overall window running through roughly 2030 to 2033.
The general shape: software and firmware signing is expected to support and prefer CNSA 2.0 algorithms earliest — those are long-lived trust anchors that are painful to change after deployment. Web browsers, web servers, and traditional networking and cloud equipment follow. The exclusive-use end states — the dates after which non-CNSA-2.0 algorithms are no longer acceptable for that category — land across the early 2030s, category by category. Custom or niche equipment is generally given the longest runway, into 2033.
Who CNSA 2.0 actually binds
CNSA 2.0 directly governs national security systems — the classified and sensitive systems operated by US defense, intelligence, and certain federal agencies. But its practical reach is far wider, and this is what surprises commercial vendors.
Because NSS are built from commercial products, CNSA 2.0 flows down the supply chain. Vendors and contractors who want their products used in NSS environments must support the suite on the relevant category timeline, or be designed out of procurement. That makes CNSA 2.0 a de facto buying requirement for any company selling cryptographic products, networking gear, signing infrastructure, key management, or cloud services into the federal and defense markets — even if those companies are nowhere near a classified facility themselves.
It also acts as a directional signal for the broader regulated economy. Finance, healthcare, and critical-infrastructure buyers increasingly use CNSA 2.0's algorithm choices as the reference definition of 'quantum-safe,' because it is the most concrete, finalized-standard-based articulation a procurement team can cite.
Inventory first: why CBOM is the opening move
Federal guidance under NSM-10 and the accompanying OMB direction made one thing the first deliverable of any quantum migration: a cryptographic inventory. The logic is unavoidable — you cannot migrate algorithms you cannot see, and most large estates do not actually know where RSA and ECDSA are embedded across firmware, TLS endpoints, signing keys, libraries, and third-party components.
The modern form of that inventory is a Cryptographic Bill of Materials (CBOM). Like an SBOM for software components, a CBOM enumerates cryptographic assets — algorithms, key sizes, certificates, protocols, and where they live — in a machine-readable format. The CycloneDX 1.5 specification added a cryptographic-properties extension precisely for this. A credible CNSA 2.0 program produces and continuously updates a CBOM rather than treating inventory as a one-time spreadsheet exercise.
Policy: allowing only finalized algorithms
The second operational requirement is a crypto policy that enforces the suite rather than merely documenting it. For a CNSA-2.0-aligned posture that means: permit only FIPS-finalized post-quantum algorithms (no draft schemes such as Falcon/FN-DSA quietly slipping in), enforce AES-256 as the symmetric minimum, require HSM protection for root keys, and rotate keys on a tight cadence.
Enforcement has to be technical, not aspirational. A policy that lives in a PDF but is not checked at the point a key is generated or a signature is produced is not a control — it is a hope. The control must reject a non-compliant algorithm at runtime.
Evidence: making the claim verifiable
The third requirement is the one auditors actually care about: proof. A migration plan and a policy are necessary, but a regulated buyer will ask you to demonstrate that what you shipped is what runs, and that your implementation behaves correctly against the standardized test vectors.
NIST's Automated Cryptographic Validation Protocol (ACVP) defines public test vectors for ML-KEM and the other PQC algorithms. Running your implementation against those vectors and publishing the results — ideally bound to a tamper-evident digest so the evidence cannot be silently edited — turns 'we support ML-KEM' into 'here is the reproducible test run.' This is the difference between a marketing claim and an audit artifact.
How QNSP maps to CNSA 2.0
QNSP — the flagship PQC platform from CUI Labs — was built so that the three CNSA 2.0 obligations (inventory, policy, evidence) are features rather than projects. It is a full managed platform of 18 backend services covering PQC key management, encrypted vault and storage, audit, and crypto-policy enforcement, supporting approximately 90 PQC algorithms across 14 families with dual-provider cross-verification.
On algorithms, QNSP's government crypto-policy tier is deliberately conservative: it permits only FIPS-finalized post-quantum algorithms — ML-KEM-1024 for key establishment (FIPS 203), ML-DSA-87 for signatures (FIPS 204), and SLH-DSA-256f variants (FIPS 205) — and explicitly excludes draft standards such as FN-DSA/Falcon. It enforces a 256-bit symmetric minimum (AES-256), requires HSM-protected root keys, and mandates weekly key rotation. This mirrors the CNSA 2.0 asymmetric-plus-AES-256/SHA-384 shape rather than approximating it.
- Inventory: the crypto-inventory service emits a CycloneDX 1.5 CBOM with the cryptographic-properties extension, so the migration starts from a real, machine-readable picture of cryptographic assets.
- Policy: the government tier allows only FIPS-finalized algorithms (ML-KEM-1024, ML-DSA-87, SLH-DSA-256f), enforces AES-256, requires HSM root keys, and runs mandatory dual-provider cross-verification (liboqs primary + @noble/post-quantum secondary) across all operations.
- Evidence: public ACVP conformance at /verify/conformance, bound to a SHA-3-256 tamper digest regenerated each release, plus a tamper-evident audit trail (signatures default to ML-DSA-65) for operational provenance.
- Production signing already runs on the finalized lattice schemes: JWTs default to ML-DSA-44, audit signing to ML-DSA-65, and CBOM crypto-attestation uses ML-DSA-44 verified against a pinned public key.
The honest line on certification
A precise platform deserves a precise claim, so here is the boundary stated plainly. Being able to MAP to CNSA 2.0 — selecting only the mandated finalized algorithms, enforcing them in policy, and producing verifiable conformance evidence — is not the same as being NSA-certified or holding a NIST CAVP/CMVP validation. Those are formal programs with their own processes.
QNSP's implementation is independently auditable: the source code, ACVP test vectors, and conformance evidence are publicly available. The value to a buyer or auditor is transparent, reproducible verification against published standards — not an endorsement, certification, or validation badge from any government agency. Any vendor that blurs 'we map to CNSA 2.0 and can prove our algorithm conformance' into 'we are NSA-approved' is doing exactly the kind of overclaiming a federal buyer will catch. The defensible value is the evidence you can hand an auditor, not a badge.
What to do before the 2030–2033 window closes
The deadlines are when the migration must be COMPLETE for a given category, not when it should begin — and the harvest-now-decrypt-later threat means long-lived secrets are already at risk today. A pragmatic CNSA 2.0 program runs in this order.
- Build the inventory (CBOM). Find every place RSA, ECDH, and ECDSA live across firmware, TLS, signing, and dependencies.
- Identify your product categories and their CNSA 2.0 exclusive-use dates — signing infrastructure first, then servers/browsers/networking, then niche equipment.
- Prioritize long-lived secrets and trust anchors (signing keys, root certificates, archived confidential data) — these have the worst harvest-now-decrypt-later exposure.
- Enforce a policy that permits only FIPS-finalized algorithms at the point of key generation and signing, with AES-256 and HSM-protected roots.
- Generate reproducible conformance and audit evidence so the migration is provable, not just planned.