CNSA 2.0 Compliance: Which Timeline Applies to You, and What It Points At

Two transition tracks, two different dates

Most post-quantum migration writing addresses the civilian federal track. If you supply U.S. national security systems, that is not your timeline, and reading the wrong one will put your schedule years off.

The two tracks, as published:

• CNSA 2.0 — the NSA's Commercial National Security Algorithm Suite — sets a 2027 timeline for U.S. national security systems.
• Civilian federal guidance is staged and later: high-priority, harvest-exposed systems by the end of 2031, and all remaining systems by the end of 2035.
• Running alongside both, NIST IR 8547 deprecates RSA-2048 and ECC P-256 in 2030 and disallows them after 2035.

The first question to answer is therefore not technical but a matter of scoping: which of your systems are national security systems, and which fall under the civilian track. Organizations that do both carry both schedules at once, and the earlier one sets the pace for the systems it covers.

What this page does not do is tell you what any specific contract obliges you to do. Per-contract and per-system obligations come from the suite itself and from your contracting authority. What follows is the shape of the transition and how to sequence work against a dated deadline.

What CNSA 2.0 points at

The algorithm side of the transition is settled and public. NIST has standardized the primitives:

• ML-KEM — key establishment — standardized as FIPS 203, published by NIST in August 2024.
• ML-DSA — digital signatures — standardized as FIPS 204.
• SLH-DSA — digital signatures — standardized as FIPS 205.

For key establishment, the parameter set that usually comes up is ML-KEM-768, which sits at NIST security category 3 and is built on the module-learning-with-errors problem with fully public parameters. Public parameters matter here: the security argument rests on a stated hard problem that anyone can inspect, not on any undisclosed construction.

Note also that validation infrastructure is moving on its own schedule — FIPS 140-2 validation sunsets in September 2026 — so a component's validation status can change independently of the algorithm work.

Why an earlier deadline changes the plan, not just the date

A 2027 timeline is not simply the 2031 plan with less slack. Compressing the schedule changes what you can do in what order.

Under a longer runway, an organization can discover cryptography opportunistically — as systems come up for refresh, as teams touch them anyway. On a compressed schedule that does not converge in time. Discovery has to be deliberate and front-loaded, because every week spent finding cryptography is a week not spent replacing it, and the systems you find late are the ones with no room left to move.

Prioritization becomes load-bearing for the same reason. With a long window, a flat work queue eventually drains. With a short one, ordering decides which systems make the date, so the ranking has to reflect actual exposure rather than the order things were found in.

The three steps, sequenced against your date

The preparatory work is the same regardless of which track governs you; only the deadline it is sequenced against changes.

Inventory first. A cryptographic inventory locates where and how cryptography is used across your systems — algorithms in use, whether classical or already post-quantum, key sizes, the protocols carrying them, certificate lifetimes, and the systems and data that depend on each. You cannot schedule a migration for cryptography you have not located, and unknown cryptography does not become known because a deadline approaches.

Rank second. A raw inventory is flat, and not every finding carries the same risk. Q-Shield scores quantum risk on five axes (a five-axis QRS) so the highest-risk, longest-lived secrets surface first. Secret lifetime carries particular weight because of the threat model below.

Sequence third. A NIST-aligned migration roadmap turns the ranked findings into an ordered plan toward ML-KEM, including a hybrid ECDH + ML-KEM key exchange where that fits — adding post-quantum protection without discarding the classical algorithm's established assurance mid-transition. The roadmap is anchored to whichever dated deadline applies to each system.

Harvest now, decrypt later: exposure that ignores the deadline

Deadlines govern paperwork; the threat model does not wait for them. Under harvest now, decrypt later, an adversary can capture encrypted traffic today and decrypt it once a quantum capability exists. Data whose confidentiality must outlive the migration window is therefore exposed now, not on the compliance date.

For long-lived national security data this is the sharper of the two pressures. A dataset that must stay confidential for decades gains nothing from the fact that its migration deadline is still years out — the traffic protecting it can be collected today.

Keeping Q-Day where it belongs — open

One thing on this page is genuinely not scheduled. The arrival of a cryptographically relevant quantum computer able to run Shor's algorithm is uncertain and debated among researchers. No authoritative date exists, and it should be treated as an open question rather than a countdown.

The planning case does not depend on resolving it. The deadlines above are already published and dated, and harvest-now exposure is already true of long-lived data. Both are enough to sequence work against without anyone predicting when a quantum capability arrives.

What a tool can and cannot do here

Worth stating plainly: Q-Shield does not certify, attest to, or validate CNSA 2.0 or FIPS compliance. Those determinations belong to your assessors and contracting authorities, and any tool claiming to issue them is overreaching.

What Q-Shield produces is the input that work depends on — an inventory of what you actually run, a five-axis quantum risk score that orders it by exposure and secret lifetime, and a NIST-aligned roadmap toward ML-KEM sequenced against the deadline that governs each system. On a 2027 timeline, having that ordered picture early is most of the schedule.