Post‑quantum cryptography has an image problem. It sounds like science fiction right up until it becomes an architecture constraint, a vendor question, and a programme of work you can’t avoid.

NIST finalised its first post‑quantum standards in August 2024—FIPS 203 (ML‑KEM), FIPS 204 (ML‑DSA), and FIPS 205 (SLH‑DSA). The algorithms are no longer theoretical. The migration work, however, has barely started for most organisations.

The risk isn’t a sudden quantum apocalypse. The risk is more mundane: cryptography is embedded everywhere, and changing it takes years.

Most organisations don’t have “an encryption system”. They have encryption inside protocols, libraries, PKI, device identities, VPNs, signing pipelines, document workflows, embedded hardware, and third‑party integrations. Some of those components have lifecycles measured in years. Some can’t be upgraded without vendor support. Some are invisible until they fail.

That’s why waiting is such a trap. Crypto migrations are slow because they aren’t just algorithm swaps. They’re operational migrations: certificate lifecycles, key management, trust chains, interoperability testing, performance impacts, and legacy systems that refuse to die.

There’s also a strategic threat model that’s easy to ignore because it’s boring: harvest now, decrypt later (sometimes called “capture now, decrypt later”). If data has a long shelf life—intellectual property, sensitive personal data, strategic plans—then today’s encrypted traffic can still be tomorrow’s breach if the protection expires faster than the data’s value.

The architectural starting point is not picking a favourite post‑quantum algorithm. It’s discovery and agility. Where do RSA and ECC exist in your environment? Which systems rely on them? Which data needs long‑term confidentiality or long‑term signature validity? Can you swap cryptographic primitives without rewriting entire applications?

That last question is the quiet killer. Crypto agility is what turns “an emergency migration” into “a managed capability”. It’s also what protects you from the next change after post‑quantum, because cryptography never stops evolving—it just changes under pressure.

In the near term, hybrid deployments—running classical and post‑quantum algorithms in parallel—are the most practical first step. They preserve backward compatibility while adding quantum‑resistant protection, and they buy time for the longer tail of legacy system migration.

The organisations that handle this well won’t be the ones who predict timelines perfectly. They’ll be the ones who treat cryptography as an engineering dependency that must be inventoried, owned, and designed for change—before change becomes mandatory.