CNSA 2.0 Compliance: The Post-Quantum Deadline Explained

CNSA 2.0 is the NSA's Commercial National Security Algorithm Suite 2.0 — a mandate that national security systems migrate to quantum-resistant cryptography. It requires post-quantum algorithms such as ML-KEM-1024 and ML-DSA, with a phased transition timeline that begins with software and firmware signing and runs through roughly 2030 to 2035 for full adoption. If your company sells into the defense or federal supply chain, CNSA 2.0 affects you long before those final dates arrive.

What CNSA 2.0 Is and Who Issued It

The Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) was published by the National Security Agency (NSA). It is the successor to the original CNSA suite and exists to protect National Security Systems (NSS) — the classified and high-value systems used across the U.S. defense and intelligence community — against the threat of a future cryptographically relevant quantum computer.

The core concern is straightforward. Today's public-key cryptography (RSA, elliptic-curve Diffie-Hellman, ECDSA) is secure against classical computers but breakable by a sufficiently powerful quantum computer running Shor's algorithm. Adversaries are already engaged in "harvest now, decrypt later" collection: capturing encrypted traffic today to decrypt once quantum capability exists. For long-lived secrets — weapons designs, intelligence sources, infrastructure controls — that future risk is a present-day problem. CNSA 2.0 is the NSA's answer.

Unlike a voluntary guideline, CNSA 2.0 is a directive for systems that handle national security information. For the commercial vendors who build those systems, it functions as a hard procurement requirement.

The Algorithm Requirements

CNSA 2.0 standardizes on a small set of quantum-resistant and quantum-safe algorithms. The headline additions are the post-quantum primitives that replace today's vulnerable public-key cryptography.

A few points worth emphasizing for compliance planning:

• Only the top parameter sets qualify. CNSA 2.0 specifies ML-KEM-1024 and the Level 5 ML-DSA variant. Lower-security parameter sets that NIST also standardized are not sufficient for NSS use.
• AES-256, not AES-128. Symmetric keys must be 256 bits. Grover's algorithm halves effective symmetric key strength, so 256-bit keys are the floor.
• Stateful hash-based signatures (LMS/XMSS) are called out specifically for firmware and software signing because they are well-understood, conservative, and resistant to quantum attack. They carry state-management responsibilities (you must never reuse a one-time key), which is an implementation detail your engineering team needs to plan for.

The Phased Timeline

The NSA has described CNSA 2.0 as a phased transition rather than a single cutover date. Treat the following as approximate, directional ranges — the NSA has signaled adjustments before, and exact mandatory dates should be confirmed against current NSA guidance rather than assumed:

• Earliest phase (~2025–2027): software and firmware signing. Because signing protects the integrity of code that may run for years, it is the first area where CNSA 2.0 algorithms are expected — using LMS/XMSS for firmware and software signing.
• Middle phase (~2027–2030): networking, browsers, and traditional IT. Web servers, VPNs, TLS endpoints, and general-purpose software are expected to support and prefer CNSA 2.0 algorithms.
• Full adoption (~2030–2035): exclusive use. The end state is that national security systems use CNSA 2.0 algorithms exclusively, with legacy public-key cryptography phased out.

The practical takeaway: the deadline is not one date in the 2030s. It is a staged ramp that has effectively already begun, and the earliest obligations land on the parts of a product that are hardest to retrofit — boot chains, firmware, and code-signing infrastructure.

Who CNSA 2.0 Affects

This is the part most commercial companies underestimate. CNSA 2.0 does not stop at government agencies.

• National Security Systems and the agencies that operate them are the direct subjects of the mandate.
• Federal agencies procuring or operating systems that touch national security data inherit the requirements.
• Contractors and the defense supply chain are where the obligation flows downhill. If you build a component, library, appliance, firmware image, or SaaS product that ends up inside an NSS, your customer will require CNSA 2.0 conformance — and they will increasingly write it into contracts and procurement language.

That last group is broad. A chip vendor, an industrial-controls manufacturer, a managed service provider, a medical-device maker selling to military hospitals, an IoT firmware shop — any of them can sit in the supply chain. You may be several tiers removed from the agency and still be told "your product must support CNSA 2.0 algorithms" as a condition of the sale. See our defense and government contractor guide for how this lands in practice.

How a Private Company Should Prepare

If you are a commercial business in the defense or federal supply chain, here is a pragmatic sequence:

1. Inventory your cryptography. You cannot migrate what you cannot see. Build a cryptographic bill of materials: every place you use RSA, ECDH, ECDSA, AES, and hashing — in TLS, code signing, firmware, stored data, and third-party libraries.
2. Find your harvest-now-decrypt-later exposure. Identify long-lived secrets and any data with a confidentiality lifetime extending into the 2030s. Those are your highest-priority migration targets.
3. Prioritize signing and firmware first. Because these are the earliest CNSA 2.0 phase and the hardest to update in the field, start your roadmap there with LMS/XMSS.
4. Plan for crypto-agility. Design so algorithms can be swapped without re-architecting. Hybrid key establishment (classical + ML-KEM) is a common transitional pattern.
5. Verify your dependencies. Confirm that the libraries, HSMs, and platforms you rely on have a credible ML-KEM-1024 and ML-DSA roadmap. Vendor readiness is often the bottleneck.
6. Document everything. Compliance is partly a paperwork exercise. Keep records of your inventory, risk assessment, and migration plan so you can answer customer and auditor questions.

Secuur exists to help supply-chain companies do exactly this. Our free A–F Readiness Scan gives you a graded snapshot of where your public-facing cryptography stands today and what to fix first. Start with a free quantum-risk scan, then build out using our post-quantum migration roadmap.

How CNSA 2.0 Relates to NIST Standards

CNSA 2.0 and the NIST post-quantum standards are complementary, not competing.

NIST ran the multi-year competition that produced the standardized algorithms — FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), and SP 800-208 (LMS/XMSS). NIST defines what the algorithms are and provides the broad guidance that applies to all U.S. federal systems and the private sector.

CNSA 2.0 is the NSA's narrower, stricter profile of those standards specifically for national security systems. It selects particular algorithms and parameter sets (ML-KEM-1024, Level 5 ML-DSA, AES-256) and attaches the phased timeline.

In short: NIST builds the toolbox; CNSA 2.0 tells national security systems which tools to use and when. A company that aligns to CNSA 2.0 is, by construction, also aligned to the underlying NIST post-quantum standards — making CNSA 2.0 conformance the more demanding bar to clear. Our overview of the NIST post-quantum standards covers the full algorithm set in detail.

Frequently Asked Questions

What is CNSA 2.0?

CNSA 2.0 is the Commercial National Security Algorithm Suite 2.0, published by the NSA. It mandates that national security systems adopt quantum-resistant cryptography — primarily ML-KEM-1024 for key establishment and ML-DSA for digital signatures, alongside AES-256, SHA-384/512, and LMS/XMSS for firmware and software signing.

What is the CNSA 2.0 deadline?

There is no single deadline. CNSA 2.0 uses a phased timeline running approximately from 2025 through 2035. Software and firmware signing come earliest (around 2025–2027), and full, exclusive adoption is targeted in the 2030–2035 range. Because these are directional ranges that the NSA can adjust, confirm specific dates against current NSA guidance for your system category.

Does CNSA 2.0 apply to my company?

If you sell products, components, firmware, or services into the defense or federal supply chain, then almost certainly yes — indirectly. The mandate binds national security systems and federal agencies, but the requirement flows down to contractors and suppliers through procurement contracts. Even companies several tiers from the end customer are being asked to support CNSA 2.0 algorithms as a condition of doing business.

What algorithms does CNSA 2.0 require?

The core set is ML-KEM-1024 (key establishment), ML-DSA at Level 5 (signatures), LMS/XMSS (firmware and software signing), AES-256 (symmetric encryption), and SHA-384/SHA-512 (hashing). Notably, only the highest parameter sets — ML-KEM-1024 and AES-256 — are acceptable for national security use.

How is CNSA 2.0 different from NIST's standards?

NIST standardized the post-quantum algorithms themselves (FIPS 203, 204, 205, and SP 800-208) for use across all U.S. federal systems and industry. CNSA 2.0 is the NSA's stricter profile of those standards specifically for national security systems, selecting particular algorithms, parameter sets, and a transition timeline. Meeting CNSA 2.0 inherently means meeting the underlying NIST standards.

Secuur helps supply-chain companies get post-quantum ready. Run a free quantum-risk scan for an A–F readiness grade. Secuur is a product of Triple Seven Solutions LLC.