The 2030 clock: every post-quantum deadline that matters

The first post-quantum deadline on your calendar is not in 2030. It is January 1, 2027, when new national security system acquisitions are expected to be CNSA 2.0-compliant by default. The second is roughly March 2027, when CISA and NIST owe the market guidance on the minimum elements of a cryptographic bill of materials. Neither date asks you to deploy a new algorithm. Both ask you to prove something about the estate you already run.

That mismatch explains why so many migration plans are sequenced backwards. A team reads “2030” and “2031,” treats those as the start of the work, and spends the intervening years waiting for a vendor release. The calendar does not work that way. The dates that arrive first are evidence dates, and producing evidence takes longer than swapping a library.

The dates, in the order they arrive

Date	What is due	Authority
September 21, 2026	FIPS 140-2 certificates move to the CMVP historical list	NIST CMVP
January 1, 2027	New national security system acquisitions compliant with CNSA 2.0 by default	CNSA 2.0 v2.1
~March 2027	Minimum CBOM elements published, 270 days from the order	EO 14412
December 31, 2027	NIST post-quantum migration pilot complete	EO 14412
December 31, 2030	PQC key establishment on high-value assets; FAR contractor compliance; non-CNSA equipment phased out	EO 14412, CNSA 2.0
December 31, 2031	PQC digital signatures on high-value assets; CNSA 2.0 algorithms mandated	EO 14412, CNSA 2.0
After 2030, then after 2035	Proposed deprecation, then disallowance, of classical public-key algorithms	NIST IR 8547 (draft)

2026 moved the validation floor, not the algorithm

FIPS 140-2 certificates moved to the CMVP historical list on September 21, 2026. If your procurement language still says “FIPS 140-2 validated,” it now points at a list that receives no new entries. That matters for PQC because the module you intend to use for ML-KEM or ML-DSA has to be validated before you can field it in a regulated environment.

The FIPS 140-3 queue has averaged roughly 18 months, and 18 to 30 months is the realistic planning range. Work backwards from the 2030 key establishment date and the module selection decision lands in 2027 or 2028, not 2029. Validation timing is a post-quantum dependency, not an unrelated compliance chore.

2027 is the year of evidence

Three things land in 2027, and none of them is a production cutover.

The acquisition default on January 1 means a vendor selling into a national security system has to demonstrate CNSA 2.0 support, and you as the buyer have to state which algorithm protects which interface. The CBOM guidance, due within 270 days of Executive Order 14412, turns the inventory question into a format question. The NIST pilot, due December 31, 2027, is explicitly a pilot.

Read together, the message is that 2027 is when you must be able to describe your cryptography, not when you must have replaced it. An organization that arrives at 2027 with a spreadsheet of certificate expiry dates will not be able to answer the first vendor questionnaire it receives.

2030 is key establishment plus an equipment cliff

Under Executive Order 14412, agencies must transition high-value assets and high-impact systems to PQC for key establishment by December 31, 2030. A concurrent FAR rule requires covered contractors to comply with FIPS that incorporate PQC algorithms by the same date. CNSA 2.0 adds a third obligation on that date: equipment that cannot support the suite must be phased out of national security systems.

Key establishment is the more tractable half of the problem. TLS termination, VPN concentrators, SSH, and bulk encryption are session-scoped. A failure is visible in seconds, and a retry costs nothing. That is why 2030 is achievable for organizations that began inventory work in 2026, and why it is not achievable for organizations that begin in 2029 with a dependency scan.

2031 is where the long tail lives

Digital signatures are due December 31, 2031, and CNSA 2.0 algorithms are mandated across national security systems on the same date. Signatures are harder than key exchange for reasons that have nothing to do with mathematics.

A signature is embedded in an artifact. It sits in a firmware image on a device in a warehouse, in a code signing chain that gates your build, in a document archive with a retention obligation, and in a certificate hierarchy with a twenty-year root. You cannot renegotiate it on the next connection. You have to re-issue it, and often re-qualify the thing it protects.

CNSA 2.0 also narrows your options in a way that surprises teams who read only FIPS 205. It requires LMS or XMSS, per NIST SP 800-208, for software and firmware signing, and it does not approve SLH-DSA for national security systems. SLH-DSA remains a valid NIST standard for other contexts. It is not a fallback you can assume everywhere.

2035 is a draft, and it still belongs in the budget

NIST IR 8547 is an initial public draft. It proposes deprecating RSA, ECDSA, EdDSA, and finite-field and elliptic-curve Diffie-Hellman after 2030, and disallowing them after 2035. Label it a draft every time you cite it, and do not treat those dates as settled regulation.

Then use it as a design constraint anyway. Anything you build in 2027 with a ten-year depreciation schedule has to be gone before the schedule ends. The draft tells you the destination is an estate with no classical public-key algorithms in it. A system that cannot get there without replacement was the wrong system to buy.

The work order is inventory, prioritization, migration, operations

Each date maps to an artifact, and the artifacts have a dependency order.

Inventory produces the CBOM: what algorithms, where, in which library, under whose ownership. Prioritization turns the CBOM into a sequence using data lifespan and reachability rather than algorithm age. Migration changes the cryptography, beginning with hybrid where interoperability demands it. Operations keeps the inventory true after the project ends, because certificates expire, libraries get upgraded, and new services ship without asking.

Reverse that order and you get the common failure. A team starts at migration with a TLS pilot, which is genuinely useful work, and then discovers it cannot answer the audit question about firmware signing keys, code signing certificates, or the cryptography inherited from a vendor appliance. The pilot was not wrong. It was just not first.

The reverse order also fails in a subtler way. Migration work is visible and fundable; inventory work is neither. A program built around a headline cutover date will spend its budget on the cutover and discover in year three that it has no way to prove what remains.

What the next two quarters should produce

Concretely: a CBOM in CycloneDX 1.6 for one business unit, not the whole estate. A list of every signing key and what it signs, with expiry dates. Data-lifespan labels on the twenty systems that matter most. A named owner for each date in the table above. A documented decision on whether external TLS goes hybrid first.

None of that requires a quantum computer, a vendor contract, or a re-architecture. It requires someone to open the inventory and start, and a date on the calendar that is earlier than the one everyone is watching.