For most of the last three decades, the cryptography protecting web traffic, VPNs, code signatures and stored secrets has quietly done its job while everyone thought about other things. That is exactly how good cryptography should feel. It is also why the arrival of standardised post-quantum cryptography deserves attention now rather than panic later: the algorithms we have relied on are not broken today, but the ground beneath a specific subset of them has shifted, and the migration will take years to do properly. This is a planning problem, not an emergency.

In August 2024, NIST published the first finalised post-quantum standards: FIPS 203 (ML-KEM, the key-encapsulation mechanism derived from CRYSTALS-Kyber), FIPS 204 (ML-DSA, the signature scheme from CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, the stateless hash-based signature scheme from SPHINCS+). A fourth selection based on FALCON has been slated to follow as a separate standard. These are the concrete, named building blocks that your libraries, browsers and vendors will implement over the coming years.

What a quantum computer actually threatens

The concern is narrow and worth stating precisely. A sufficiently large, fault-tolerant quantum computer running Shor's algorithm would break the public-key cryptography that underpins today's key exchange and digital signatures: RSA and the elliptic-curve schemes (ECDH, ECDSA). That is the asymmetric layer — how two parties agree on keys and prove identity.

Symmetric cryptography is in far better shape. The best known quantum attack on symmetric ciphers, Grover's algorithm, only weakens them modestly, and the standard mitigation is to use larger keys — AES-256 rather than AES-128, for example. So the picture is not "all cryptography collapses". It is "the asymmetric algorithms that negotiate and authenticate need replacing; the symmetric ones you use to bulk-encrypt data mostly need to be sized up". No machine capable of this exists today, and credible estimates for when one might put it somewhere in the next decade or two — with genuine uncertainty in both directions.

Harvest now, decrypt later

Here is why "no such machine exists yet" is not a reason to wait. An adversary can capture and store encrypted traffic or exfiltrated ciphertext today, sit on it, and decrypt it once a capable quantum computer arrives. This is the harvest now, decrypt later threat, sometimes called store-now-decrypt-later.

The exposure is a simple function you can reason about: does the confidentiality of this data still matter years from now, and could an adversary plausibly have recorded it in transit or captured it at rest? For a one-time session token that expires in an hour, the answer is no — by the time decryption is feasible, the secret is worthless. For medical records, legal case files, source code, state or trade secrets, long-lived credentials, or anything with a regulatory retention obligation measured in years or decades, the answer is uncomfortably yes. If your data has a long confidentiality lifetime, the clock for it is already running. This is the single most important reason to start now, and it applies unevenly — which is why an inventory matters more than a blanket rush.

What changes for TLS and stored secrets

In transit, the first meaningful change is in TLS key exchange. This is where harvest-now-decrypt-later bites, because it protects the confidentiality of the session. The industry direction is hybrid key exchange: run a classical algorithm (typically X25519) and a post-quantum KEM (ML-KEM) together, and combine both shared secrets so the connection is safe if either holds. Major browsers and servers have already been rolling out hybrid ML-KEM key exchange, so a lot of modern web traffic is quietly gaining this protection without anyone reconfiguring anything.

Signatures are a different, less urgent story. Authentication — TLS certificates, code signing, document signing — has to be valid at the moment of use, not for decades afterward. A signature verified today cannot be forged retroactively by a future quantum computer, so there is no harvest-now pressure on signatures. They still need to migrate eventually, but the timeline is calmer, and post-quantum signatures bring their own engineering friction: ML-DSA and especially SLH-DSA produce substantially larger keys and signatures than ECDSA, which stresses protocols, certificate chains and constrained devices in ways worth testing before committing.

For stored secrets, the reassuring part is that data encrypted at rest with a strong symmetric cipher is largely fine — provided you move toward 256-bit keys. The genuine risk in storage is the asymmetric wrapping around it: key-encryption keys, envelope encryption in cloud KMS, backups sealed with an RSA or EC public key, PKI hierarchies. Those wrappers are where post-quantum KEMs need to reach, and where long-retained backups make the harvest-now problem concrete.

Crypto-agility: the real deliverable

If there is one architectural lesson from this transition, it is crypto-agility: the ability to change algorithms without re-architecting the system around them. Many systems fail this test today. Algorithms are hard-coded, key sizes are baked into database columns and message formats, certificate handling assumes a fixed signature size, and swapping a primitive means a painful, risky rewrite.

The goal is not to guess the final answer now. It is to reach a state where the next change — and there will be a next one, because standards evolve and implementations get revised — is a configuration or dependency update rather than a project. Negotiated algorithms, versioned message and token formats, generous field sizing, and a clean boundary between "the system" and "the crypto it happens to use" are what agility looks like in practice. If you invest in one thing from this whole topic, invest here; it pays off regardless of quantum timelines.

A calm, staged migration plan

Panic and paralysis are both wrong responses. A measured plan looks roughly like this:

  • Inventory first. You cannot migrate what you cannot see. Build a cryptographic inventory: where cryptography is used, which algorithms and key sizes, which libraries and versions, which certificates and PKI, and — crucially — the confidentiality lifetime of the data each one protects. This is unglamorous and it is the single highest-value step. A CBOM (cryptography bill of materials), in the spirit of the SBOMs the EU's Cyber Resilience Act is pushing toward, is a natural home for it.
  • Triage by data lifetime. Rank systems by how long their data must stay confidential and how exposed it is to capture. Long-lived, high-value, in-transit-or-backed-up data goes to the front of the queue. Short-lived secrets can wait.
  • Prioritise key exchange, deploy hybrids. Enable hybrid classical-plus-ML-KEM key exchange where your stack supports it — modern TLS libraries, VPNs and messaging protocols increasingly do. Hybrids keep the classical guarantee intact while adding post-quantum protection, which is the responsible default while implementations mature.
  • Lean on vendors and standards; test signatures deliberately. Much of this arrives through updates — browsers, TLS libraries, cloud KMS, HSMs. Track your vendors' post-quantum roadmaps. Treat signature and certificate migration as a separate, later track, and pilot it against the larger key and signature sizes before rolling out.
  • Build agility as you go. Every touch is a chance to remove a hard-coded algorithm assumption, so the transition after this one is routine.

What this means for you

Post-quantum cryptography has crossed from research into finalised, named standards, and the sky is not falling. The honest summary is that there is no need to panic and no excuse to ignore it. If your organisation holds data that must stay confidential for years — and in regulated EU sectors under obligations like NIS2 and sector retention rules, much of it does — the work worth starting this year is not ripping and replacing algorithms. It is knowing exactly what cryptography you run, understanding how long your data needs to stay secret, and turning on hybrid key exchange where it is already available. Everything else follows from that inventory, calmly and in order. Producing that inventory, and quietly building the crypto-agility that makes future changes boring, is precisely the kind of unglamorous, high-leverage work I take on.