What CNSA 2.0 doesn't approve — and why it matters

Somewhere in a platform team’s architecture decision record there is a line that reads: signing uses ML-DSA-87, with SLH-DSA as the fallback if the HSM firmware lags. It was approved in review, because the three post-quantum standards came out of NIST on the same day and all three are FIPS publications. The line is reasonable. It is also wrong if the system in question is a national security system.

This is the most common misreading of the NSA’s Commercial National Security Algorithm Suite 2.0, and it is a scoping error rather than a cryptographic one. The suite is a list of what an agency will accept as evidence. Your fallback chain is only as good as the shortest list item on it.

What the suite approves

CNSA 2.0 version 2.1, published in December 2024, is narrower than the set of NIST standards it draws from. It approves ML-KEM and ML-DSA at the CNSA 2.0 level, which means ML-KEM-1024 for key establishment and ML-DSA-87 for signatures. For software and firmware signing it requires LMS or XMSS, as specified in NIST SP 800-208. Symmetric requirements carry over from the earlier suite: AES-256 and SHA-384 remain the baseline.

That leaves a shape worth internalizing. Key establishment has one approved family, signatures have two approved routes that are not interchangeable, and the choice between them is determined by the artifact rather than by preference or by which library you already have.

What it does not approve, and what that does not mean

SLH-DSA, FIPS 205, is not approved for national security systems. It is a NIST standard, it is final, and it is not approved here.

The gap between those clauses is where most of the confusion lives. Excluding SLH-DSA is not a statement that the algorithm is weak. It is one of the most conservative designs in the set: security resting only on hash function properties, with small public keys and a straightforward security argument. Those properties are why it appears in commercial products and in long-lived archive designs where the verifier is a constrained device.

It is also slow to sign and produces large signatures, and the NSA’s suite is built around a narrower deployable set. So the exclusion is a scoping decision about what an agency will accept and validate, not a judgment about whether the mathematics holds. If you are outside national security systems, SLH-DSA remains a legitimate option, and for some verifier constraints it is a good one.

Inside national security systems, your evidence has to name ML-DSA-87, or LMS, or XMSS. A FIPS number in a design document is not the same thing as an approved algorithm in a profile.

Three ways teams get this wrong

Treating FIPS 205 as a universal fallback. The reasoning runs: all three standards were published on August 13, 2024, all three are final, therefore any of them satisfies any requirement. That reasoning survives right up to the first questionnaire that asks for the algorithm identifier and the approved-suite mapping. If your HSM plan is “ML-DSA if available, SLH-DSA otherwise,” you have a plan with an unapproved branch that will be discovered at the worst possible moment — during a deployment freeze, not during design.

The fix is structural. When the HSM cannot do ML-DSA, the fallback is not a different signature family. It is a different module, a different artifact class, or a schedule change.

Assuming larger classical keys satisfy the requirement. RSA-4096 and P-384 are not on the list at any size. A larger key raises the cost of a classical attack; it does nothing to a quantum attack against the underlying problem, and it does nothing to a compliance mapping that names ML-DSA-87. This mistake is common in firmware estates because the bootloader already verifies RSA, and the shortest path in a roadmap slide is “increase the key size and revisit in 2032.” That path ends at the 2030 phase-out with a device generation that cannot be updated.

Assuming hybrid is automatically acceptable. Hybrid key exchange is the right default for external TLS, and it is defensible engineering. But the suite is a list of approved algorithms, not a list of approved constructions, and a hybrid handshake carries a classical component that the suite does not name. For a national security system, treat hybrid as a compatibility measure with a documented end date, and keep a pure ML-KEM path available for the interfaces your evidence actually covers. Do not let a hybrid default quietly become the answer to “which approved algorithm protects this link.”

State is the operational consequence

LMS and XMSS are stateful. Each one-time key is consumed in sequence, and the signer must never reuse an index. Two signatures under the same index are enough to forge, so the requirement is not “keep the counter reasonably current” but “never, under any failure mode, sign twice with the same index.”

That single property propagates into everything around the signer: a single-writer HSM or transactional ledger, no restoring the signing host from a snapshot, no failover to a replica holding stale state, reserved index ranges for multi-region operation, and audit logs that record the index consumed for every signature. It also introduces a finite capacity that has to be planned years ahead, because running out of indices is a migration event with a lead time, not an outage you can patch.

ML-DSA has none of these problems, which is why teams reach for it. The suite’s answer is that firmware and software signing call for LMS or XMSS, and ML-DSA-87 covers the general signature case. Choose by artifact class, then accept the operational contract that comes with the choice.

The validation queue picks the module for you

FIPS 140-2 certificates moved to the CMVP historical list on September 21, 2026. FIPS 140-3 validation has averaged roughly 18 months, with 18 to 30 months a realistic planning range.

Two consequences follow. First, a vendor claiming LMS or ML-DSA-87 support without a certificate number covering a specific firmware version is offering a roadmap item, not a deployable capability. Second, the module decision for a 2030 or 2031 obligation lands in 2027 or 2028 at the latest. If your HSM refresh is scheduled for 2029, the validation queue — not the algorithm — sets your date, and the sensible move is to start the refresh earlier rather than to plan a waiver.

Artifact class to signing option

Artifact class	Approved option	Operational catch
Firmware image (NSS)	LMS or XMSS, SP 800-208	State custody, and a verifier in ROM that must already support it
Software release (NSS)	LMS or XMSS, SP 800-208	Build pipeline must not clone or snapshot the signer
Bootloader verifier	LMS or XMSS verification	Verification code is silicon-level; plan a hardware generation
Document, API, or general signature	ML-DSA-87	Stateless and simpler, but needs a validated module and larger signatures
Long-lived trust anchor (NSS PKI)	ML-DSA-87 where the profile permits	Chain validation across verifiers you do not control
Commercial signing outside NSS	ML-DSA, SLH-DSA, LMS, or XMSS	Decide on verifier constraints and validation availability, then document it

The last row is the one people forget to write down. If a system is out of scope, say so in the record, with the reasoning, so that a later reviewer does not apply the NSS profile to it by default and force an unnecessary migration.

The dates, and the ones that are not on the CNSA list

New national security system acquisitions are expected to be CNSA 2.0-compliant by default from January 1, 2027. Equipment that cannot support the suite must be phased out by December 31, 2030. CNSA 2.0 algorithms are mandated by December 31, 2031.

Executive Order 14412, signed June 22, 2026, adds a parallel obligation for high-value assets and high-impact systems: post-quantum key establishment by December 31, 2030, and post-quantum signatures by December 31, 2031. The two regimes converge on the same signature date, which is convenient for planning and unhelpful for scheduling, because every signature migration in the estate now has the same deadline.

NIST IR 8547, still an initial public draft, proposes deprecating RSA, ECDSA, EdDSA, and finite-field and elliptic-curve Diffie-Hellman after 2030, and disallowing them after 2035. It is a draft. It is also the direction of travel, and it is the reason a larger classical key is a delay rather than a strategy.

What to do this quarter

Three actions, none of which needs a procurement.

Inventory every signing key. Key identifier, algorithm, what it signs, where the private key lives, who can invoke it, when it expires, and which verifiers trust it. Signing keys hide in build systems, in appliance management interfaces, and in certificate hierarchies nobody has opened since the last acquisition.

Draw the national security system boundary. Not every system your organization runs is in scope, and the ones that are carry obligations the rest do not. Write the boundary down with the reasoning, then check which signing pipelines fall inside it.

Confirm module validation status. For each algorithm you intend to use, ask for the FIPS 140-3 certificate number and the exact firmware version it covers. Sort the answers into deployable, in process, and aspirational. The aspirational column is your risk register, and its size tells you whether 2031 is a plan or a hope.