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.

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: 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.

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.