The Timeline Stayed the Same. The Threat Model Did Not.

There is a subtle but important problem emerging in post-quantum planning.

NIST finalized IR 8547 on October 27, establishing the official transition path away from quantum-vulnerable public-key cryptography. The roadmap reinforces the 2030 to 2035 migration window and explicitly supports accelerated deadlines for the most sensitive federal systems.

That gives organizations something they have wanted for years:  a clearer timetable.

But a timetable is only useful if the assumptions underneath it remain reasonably stable. They are not.

Quantum resource estimates continue to fall as researchers improve algorithms, arithmetic techniques, error correction, and hardware architectures. Craig Gidney’s 2025 work, for example, reduced his own prior RSA-2048 estimate from roughly 20 million noisy qubits to fewer than one million under the same broad hardware assumptions.

More recent estimates using very different architectures have pushed theoretical resource counts lower still.

That does not mean Q-Day is imminent. It means something more relevant to governance: the engineering assumptions can improve much faster than an enterprise migration program can move.

The first signal remains Starknet.

Its community voted with 93.52% of voting power to research a possible transition toward an independent post-quantum Layer 1. The vote does not approve the move. It authorizes research into the technical and economic trade-offs.

The reason matters.

Starknet is increasingly being discussed not simply because it uses hash-based STARK proofs, but because its account architecture allows cryptographic controls to evolve. That makes the conversation about adaptability, not simply whether one algorithm is resistant today.

The second signal comes from Stellar.

Protocol 30, known as Bell, adds support for ML-DSA post-quantum signature verification inside Stellar smart contracts. The testnet vote was scheduled for November 3, with a mainnet validator vote scheduled for November 23. 

Importantly, Stellar itself says this does not make the entire network post-quantum. Network transaction signatures remain Ed25519.

That distinction is exactly what mature quantum-readiness conversations need. A system can have a post-quantum capability without being post-quantum ready.

The third signal is NIST IR 8547 itself.

NIST now describes the transition as a high-level roadmap whose implementation will vary by use case. It explicitly recognizes that some migrations will take longer than others and that organizations need to understand products, services, infrastructure, and the broader cryptographic supply chain, and that is where the emerging mismatch becomes important.

NIST has created a timetable. But NIST does not control how quickly quantum attack costs decline. Nor does an enterprise.

The biggest mistake organizations could make now is to treat 2030 or 2035 as permission to wait. Those dates are transition markers. They are not predictions of Q-Day, and they certainly are not guarantees that the cost of attacking today's cryptography will remain where researchers estimated it when the roadmap was drafted.

This creates a very different governance problem. Imagine an organization builds its migration program around the assumption that it has nine years. Then resource estimates improve.

• A new hardware architecture changes the economics.
• A better error-correction method appears.
• An algorithmic improvement reduces circuit depth.

None of those developments instantly creates a cryptographically relevant quantum computer. But each can reduce the safety margin.

Meanwhile, the enterprise migration plan may still require:

• two years to discover cryptographic dependencies,
• another year to prioritize them,
• several years of vendor remediation,
• hardware replacement cycles,
• application modernization,
• certificate migration,
• testing,
• and operational rollout.

The organization's timetable does not automatically accelerate because quantum research does. That leads to a distinction boards should understand:  A regulatory deadline is not the same thing as a risk deadline.

NIST can tell you when algorithms should be deprecated. It cannot tell you when your particular exposure becomes unacceptable. That depends on your data lifetime.

Your vendor dependencies.

Your replacement cycles.

Your testing requirements.

Your migration speed.

And your ability to change course when the threat model changes.

This is why crypto-agility is becoming so important.

Starknet is exploring it architecturally. Stellar is introducing it selectively.

NIST is encouraging it explicitly. NIST published updated crypto-agility guidance in June 2026 alongside its broader PQC work. For enterprises, the lesson is straightforward. Do not build a migration plan that works only if today's assumptions remain true. Build one that can accelerate. That changes the boardroom question.

Instead of asking:  “Are we on track for 2035?”

ask:  “If the threat timeline moved forward by three years tomorrow, what would we have to accelerate, and could we?”

That is a much harder question. But it is also a much better measure of readiness. Because the most dangerous thing about the post-quantum transition may not be that the deadline moves.

It may be that the deadline stays exactly where it is while the margin beneath it quietly disappears.

Think Earlier. Trust Must Survive.