Everyone wants to tell you the post-quantum story as one horse, one cart, one tidy road to 2030.
It isn’t.
Project management at it again.
There are three horses, they’re all pulling at once, they’re hitched to five different carts, and at least two of them are dragging the same cart in slightly different directions. That’s why Public Key Infrastructure (PKI), from management to planning for future efforts feels heavier now even though nothing in your environment technically broke.
The horses are our deadlines, and they don’t coordinate. One is certificate validity collapsing from 398 days toward 47. One is Post-Quantum Cryptography (PQC) mandates, every major regulator setting its own pace around the year 2030. One is the FIPS-140-2 sunset, quietly invalidating cryptographic modules you’re still running (I’m also going to lean in on this horse analogy way too much, you’re welcome).
Survivable, any one of them. But none of them checked the other two’s calendar.
Ballot: The 47-day Certificate Countdown
The first horse is named Ballot, and it’s the one already at a gallop. In April 2025 the CA/Browser Forum passed ballot SC-081v3, scheduling a reduction in maximum certificate lifetime from 398 days down to 47 by 2029 [1]. The schedule:
- 200 days as of March 15, 2026 (done)
- 100 days in 2027
- 47 days in 2029, with domain-validation reuse collapsing to 10 days
That last step is the one that bites: a certificate you touched once a year becomes one you touch roughly eight times a year, multiplied by every public or regulated certificate in an inventory you haven’t finished counting. Treat 2029 as the deadline and you’ve misread the schedule. The 2027 step to 100 days is where manual renewal breaks for most enterprises [2], and the market isn’t waiting for the mandate either: Let’s Encrypt has committed to a 45-day default by 2028, ahead of the industry timeline [3]. This is a now problem wearing a 2029 disguise.
Reckoning: The Global Post-Quantum Cryptographic Timeline
The second horse, called Reckoning, broke out running this year. US Executive Order 14412, signed June 22 2026, turned years of post-quantum draft guidance into enforceable federal deadlines [4]. High-value and high-impact systems must complete key-establishment migration to NIST-approved algorithms by the end of 2030, with digital-signature migration following by the end of 2031, and contractors are pulled to a 2030 line through the acquisition rules [4].
This isn’t an American story alone. Every major regulatory bloc is running its own version of the same clock, non-exhaustively:
- EU: national roadmaps due end of 2026, high-risk systems migrated by 2030, full transition by 2035 [5]
- Australia: classical asymmetric cryptography retired entirely by end of 2030 [6]
- Canada: CCCS is running its own migration guidance on a parallel track, distinct from the NIST/CNSA baseline
The mandates differ in mechanism and pace, but they converge on the same decade.
Sunset: FIPS 140-2’s Expiration Date
The third horse is the quietest, which is exactly why it catches people. On September 21 2026, NIST’s Cryptographic Module Validation Program (CMVP) moves FIPS 140-2 validations to its historical list, and a module on that list can no longer be procured to satisfy a federal cryptographic requirement [7]. Nothing about the module changes on that date. What changes is whether you are allowed to keep buying it.
If your compliance story rests on a 140-2 certificate, that validation expires before either of the other two horses finishes its run. The replacement path runs through 140-3, and through providers that haven’t finished validating their post-quantum primitives. We name this horse Sunset.
The Pale Horse: CRQC’s Unscheduled Arrival
There is a fourth horse, and it’s the reason the other three feel so urgent. Ballot’s window collapse has the CA/Browser Forum cracking the whip; the Reckoning has regulators on different continents setting the pace; Sunset has a time window stamped on it by the CMVP. Somebody scheduled all three. Nobody scheduled the fourth. It rides last, and you already know the verse.
And I looked, and behold a pale horse: and his name that sat on him was CRQC.
Note: I’m pretty sure that’s how the passage goes.
The cryptographic relevant quantum computer (CRQC), it’s the only thing on this page that never filed a transition timeline. You can’t plan against its arrival date because it does not have one, which is exactly why the move is to start now instead of when it becomes obvious: by the time it is obvious, the broken thing is the math underneath everything you already shipped.
Name the three and you have named the horses. The carts are the actual work efforts they tow behind them:
- Discovery: Finding the cryptography you can’t currently see
- Automation: Issuance because manual renewal will be a death sentence
- Multi-CA: Running more than one certificate authority (CA) whether you wanted to or not
- PQC Deployment (including Hybrid): Deploying new quantum-resistant algorithms defined by your federal mandates
- PQC Cost: Surviving what those algorithms do to revocation and certificate size
The trouble is that the horses don’t line up one per cart. Ballot drags both discovery and automation. Reckoning is hitched to our PQC algorithm choices and our CA strategy and your deployment sequencing all at once. Sunset pulls on the same algorithm cart from the other side, because the modules you’re forced onto are the ones still validating the new primitives. Pull hard on any one rein and you’ll tighten three other traces you weren’t watching.
Note: A harness trace is what connects the horse to the cart.
So this isn’t a roadmap in the do-these-seven-things-in-order sense, because the work does not queue that cleanly. It’s a map of which force is pulling which part of your estate, where they overlap, and what you can do about it, one dependency harness at a time. And every harness shares a single starting line. The horses do not agree on a deadline, and none of the work they demand is even possible until we know where our cryptography actually lives. Which is the part almost nobody has done.
That’s where this article series starts: not with algorithms or ballots, but with the unglamorous inventory every regulator quietly assumes you’ve already finished. From there we follow the path forward, one horse and one cart at a time.
Analogy over. But we’re just getting started with this article series.
References
[2] Understanding the Risk Scale: 6-month SSL/TLS Validity Starts March 15, 2026.
[3] Let’s Encrypt. Decreasing Certificate Lifetimes to 45 Days.