up:: The Mandates MOC
CNSA 2.0 vs the NIST Civilian Track
What is the difference between CNSA 2.0 and the NIST civilian track?
They are two separate US federal regimes covering two separate populations, and they do not overlap. CNSA 2.0 governs national security systems. The NIST civilian track, carried by OMB M-26-15 and NIST IR 8547, governs federal civilian executive branch agencies and says plainly that it does not apply to national security systems.
Which one applies is not a judgment call. It is decided by whether the system meets the statutory definition of a national security system.
The short version:
- CNSA 2.0 mandates specific parameter sets at Level V. ML-KEM-1024, ML-DSA-87, AES-256, SHA-384 or SHA-512.
- The civilian track points at the standards and lets NIST’s guidance name the default, which is ML-KEM-768 at category 3.
- ⭐ They name different hash-based signature schemes. CNSA 2.0 requires the stateful LMS and XMSS for firmware and software signing. The civilian standard is the stateless SLH-DSA.
- The bar differs. NSS are judged on being NSA-approved, a stricter standard than FIPS-validated.
- An organization that touches both runs both, on different clocks, with different parameter sets.
What is CNSA 2.0?
The National Security Agency’s advisory naming the post-quantum algorithms US national security systems must use and the years by which they must use them, issued September 2022 as “Announcing the Commercial National Security Algorithm Suite 2.0.”
It is a mandate rather than a recommendation. It lists required algorithms and dated deadlines, and NSS are judged on being NSA-approved.
Its deadlines reach past government. They land on vendors through procurement, so a company selling into national-security buyers inherits them whether or not it operates an NSS itself.
What is the NIST civilian track?
The federal civilian regime: the FIPS standards (203, 204, 205), the transition schedule in NIST IR 8547, and the migration directive in OMB M-26-15.
M-26-15 is addressed to the heads of executive departments and agencies and carries exactly one explicit exclusion, stated verbatim: “This memorandum does not apply to national security systems.”
CNSA 2.0 vs the civilian track at a glance
| Dimension | CNSA 2.0 | NIST civilian track |
|---|---|---|
| Who it binds | National security systems, their owners, operators and vendors | Federal civilian executive branch agencies |
| Instrument type | NSA advisory operating as a mandate | FIPS standards plus an OMB migration directive and a NIST transition schedule |
| Key establishment | ML-KEM-1024, Level V, required | ML-KEM. NIST recommends ML-KEM-768 as the general-purpose default |
| Signatures | ML-DSA-87, Level V, required | ML-DSA and SLH-DSA, across their parameter sets |
| Hash-based signing | LMS and XMSS, which are stateful, for firmware and software signing | SLH-DSA, which is stateless |
| Symmetric and hashing | AES-256, and SHA-384 or SHA-512 | The FIPS-approved range |
| Validation bar | NSA-approved, stricter than FIPS-validated. Cryptographic service providers also need NIAP or NSA validation under CNSSP 11 | FIPS-validated |
| Hybrid | Permitted, and standalone post-quantum is favored | Hybrid is the overwhelmingly deployed construction |
| Key dates | Software and firmware signing and traditional networking exclusive by 2030; web, cloud and operating systems by 2033; complete by 2035 | 112-bit strengths deprecated after 2030; all classical public key disallowed after 2035 |
Sources: NSA CNSA 2.0 and OMB M-26-15 in this Guide, each citing its primary document; NIST IR 8547 for the civilian transition schedule.
How do they actually differ?
⭐ The stateful-versus-stateless split is the difference practitioners most often miss, and it is an operational one rather than a preference.
CNSA 2.0 requires LMS and XMSS for firmware and software signing. Both are stateful hash-based schemes, meaning the signer has to track which one-time keys have been used, and reusing state catastrophically breaks the signature. That is a real engineering burden involving durable state, backup discipline and careful failover.
The civilian standard is SLH-DSA, which is stateless by design and carries none of that burden, at the cost of much larger signatures.
So an organization signing firmware for both populations is running two different hash-based signature systems, with different failure modes, not two configurations of one.
The parameter-level difference is the second surprise. CNSA 2.0 requires Level V throughout, while NIST recommends category 3 as the general-purpose civilian default. An engineer who standardizes on ML-KEM-768 because NIST recommends it has not met CNSA 2.0, and one who standardizes on ML-KEM-1024 everywhere is carrying larger artifacts than the civilian side requires.
And the dates are structured differently rather than merely being different. CNSA 2.0 sets exclusive-use dates by system type, with software and firmware signing and traditional networking equipment first at 2030. The civilian track sets a deprecation-then-disallowance schedule by security strength. One asks “what kind of system is this,” the other asks “how strong is this key.”
Where do they agree?
Both point at the same NIST algorithms. CNSA 2.0 names them by their competition names, CRYSTALS-Kyber and CRYSTALS-Dilithium, because it shipped in 2022 before NIST finalized the standards. Those are now ML-KEM and ML-DSA.
Both set 2035 as the outer horizon, in line with the National Security Memorandum on quantum.
Both reach vendors through procurement rather than only binding the government directly.
And both treat the migration as mandatory rather than advisory for the populations they cover.
When does CNSA 2.0 apply?
Where a system meets the statutory definition of a national security system, and to the owners, operators and vendors of those systems. It also reaches the Department of Defense and the Defense Industrial Base through the NSA’s cybersecurity mission authorities.
When does the civilian track apply?
To federal civilian executive branch agencies and the systems they own or operate, and to vendors through the procurement and FedRAMP channels the directive names.
It also functions as the de facto template well outside government, because sector regulators, insurers and procurement offices tend to model on NIST even where nothing binds them to it.
Why do people confuse them?
Because both are US federal, both are post-quantum, and both quote 2035.
The confusion has a specific cost: an organization reads whichever document it found first and assumes it has the requirement. A defense contractor working from FIPS 203 alone will build to category 3 and miss CNSA 2.0’s Level V requirement. A civilian agency working from CNSA 2.0 will over-build and may adopt stateful signatures it never needed.
The question that resolves it is not “are we government” but “is this system an NSS.” An agency can operate both kinds, on both regimes, simultaneously.
Is one replacing the other?
No. They are parallel regimes for populations that do not overlap, and both are expected to run to 2035.
Common misconceptions
“CNSA 2.0 is guidance.” It operates as a mandate for national security systems, with dated deadlines and an NSA-approved validation bar.
“FIPS-validated is enough for NSS.” NSA-approved is the stricter bar, and cryptographic service providers face NIAP or NSA validation under CNSSP 11 as well.
“ML-KEM is ML-KEM.” CNSA 2.0 requires Level V specifically. Meeting the standard is not the same as meeting the parameter requirement.
“SLH-DSA satisfies CNSA 2.0’s hash-based requirement.” CNSA 2.0 names the stateful LMS and XMSS. SLH-DSA is stateless and is a different scheme.
“CNSA 2.0 requires hybrid.” It permits hybrids and favors standalone post-quantum for national security systems.
“M-26-15 covers everything federal.” It states plainly that it does not apply to national security systems.
Questions people ask
Which applies to us? It turns on whether the system is a national security system under the statutory definition. Organizations frequently operate both kinds and answer to both regimes.
We sell to the government. Which do we build to? Whichever your buyer’s systems are, and vendors selling into national-security buyers inherit CNSA 2.0 through procurement regardless of what they operate themselves.
Can we just build to CNSA 2.0 everywhere and be safe? It satisfies the stricter parameter requirement and carries larger artifacts, and its stateful signing requirement brings an operational burden the civilian side does not impose.
Why does CNSA 2.0 use old algorithm names? It shipped in September 2022, before NIST finalized the standards, so it names CRYSTALS-Kyber and CRYSTALS-Dilithium.
Are the deadlines the same? No. CNSA 2.0 sets exclusive-use dates by system type starting at 2030. The civilian track deprecates 112-bit strengths after 2030 and disallows all classical public key after 2035.
Is 2035 a hard cutoff? The civilian framing is a qualified policy goal rather than an absolute switch. See The Mandates MOC.
What if we are not federal at all? Neither regime binds you directly, and both function as templates that regulators, insurers and customers increasingly reference.
Last verified 2026-08-10 · Maintained by Addie LaMarr, LaMarr Labs. Work with Addie at lamarrlabs.com.