Post-quantum cryptography: the migration mid-market IT teams should start in 2026, not 2030

Most IT leaders file post-quantum cryptography under "problem for the next decade". That was a defensible position in 2023. It is not one now - not because a cryptographically relevant quantum computer exists, but because the migration itself takes years, and the data you send today can be stored today and read later.

The standards settled. Mainstream browsers and major cloud load balancers now negotiate hybrid post-quantum key exchange by default, which means a meaningful share of your public web traffic is already protected whether or not anyone on your team decided so. Meanwhile procurement questionnaires from banks, insurers and public-sector buyers have started asking for a PQC transition plan by name.

The uncomfortable maths: if your migration takes four years and your sensitive data must stay confidential for ten, then any data you transmit today under classical-only encryption needs to survive a threat that arrives well inside that window.

A well-resourced adversary captures encrypted traffic or exfiltrates encrypted archives today, stores them cheaply, and decrypts them once the capability exists. Nothing about that requires a breakthrough to happen first; the capture is happening with today's technology. It only matters for data with a long shelf life - and every organisation has more of that than it expects.

Symmetric encryption (AES) is comparatively fine with larger key sizes. The exposure sits in key exchange and digital signatures - exactly the parts buried inside TLS, VPNs, code signing, document signing and hardware roots of trust.

Same principle as any security programme: you cannot migrate what you cannot see. We inventory, per system: the algorithm and key length, where the key material lives, who owns rotation, whether the algorithm is configurable or hard-coded, and the expected lifetime of the data it protects.

• Public edge: TLS on websites, APIs, CDNs and load balancers. Usually the easiest wins.
• Private tunnels: site-to-site and client VPNs, service mesh mTLS, database connections.
• Signatures: code signing, firmware, document signing, SSO assertions, JWT issuance.
• Data at rest: backups, archives, and anything encrypted once and kept for a decade.
• Embedded and OT: devices with hard-coded crypto and ten-year field lives. The genuinely hard category.

Rank each system by how long its data must stay secret, then by how hard it is to change. Ten-year confidentiality on an easily reconfigured load balancer is the first thing you fix. Two-year confidentiality on firmware you cannot update without a truck roll goes into a longer programme with compensating controls. Ignore the temptation to start with whatever is technically most interesting.

1. 01
   Phase 1 - Discover (1-2 months)

   Cryptographic inventory across edge, internal, signing and at-rest. Output is a ranked register with owners and data shelf lives.
2. 02
   Phase 2 - Crypto agility (3-6 months)

   Remove hard-coded algorithms, centralise certificate and key management, shorten certificate lifetimes, and make algorithm choice a configuration value. This phase pays for itself even if quantum never arrives.
3. 03
   Phase 3 - Hybrid deployment (6-18 months)

   Enable hybrid post-quantum key exchange at the public edge first, then VPNs and internal mTLS. Hybrid keeps a classical algorithm alongside the new one, so a flaw in either does not break you.
4. 04
   Phase 4 - Signatures and retirement (18-36 months)

   Move code and document signing to post-quantum schemes as tooling matures, then retire classical-only paths and re-encrypt long-lived archives.

Phase 2 is the one clients try to skip and the one that decides the outcome. Crypto agility is what lets you change algorithms in a sprint instead of a programme - and you will change them again. Most of this work rides on the same platform our cloud practice and managed IT team already operate.

Four questions, in writing, to every material supplier - SaaS, payments, identity, hardware:

• Which post-quantum algorithms do you support today, and on which endpoints?
• What is your dated roadmap for hybrid key exchange and post-quantum signatures?
• Can we configure the algorithm, or is it fixed in your product?
• How long do you retain our encrypted data, and how would it be re-encrypted?

The answers sort your suppliers into three groups quickly: ready, credible, and a renewal decision.

Treating it as a certificate refresh. It is an architecture programme with a certificate component, not the other way round.

Skipping the inventory because "it's all TLS". It never is. Signing keys and long-lived archives are where the real exposure hides.

Going pure post-quantum too early. Hybrid exists precisely because new algorithms are young. Run both.

No owner. A programme spanning three years and every system needs a named accountable individual, or it becomes a slide that gets re-presented annually.

We run PQC readiness as a scoped engagement for mid-market and enterprise clients across the US, UK, EU and APAC: a six-week discovery producing a ranked cryptographic register and a costed roadmap, then optional delivery of the agility and hybrid phases with your team. It sits alongside our cybersecurity services and existing VAPT and SOC work, so the evidence feeds straight into your audits.

If AI risk is on the same board agenda, read our companion piece on the AI control stack we install before an audit. First call is free and goes to a senior consultant - email info@ranwebs.com or use the contact page.