Post-Quantum Cryptography: Enterprise Migration Roadmap

Every large enterprise we work with has a post-quantum cryptography programme on paper. Most of them are also two to three years behind where they need to be, and the gap is quietly widening. The technology risk has moved from theoretical to schedulable, the regulatory pressure has become concrete, and yet the work being done in most organisations is a slide deck, a vendor scan, and an intention to start next quarter.

This is a practitioner's view of what enterprise PQC migration actually looks like in 2026 — what has become urgent, what has become tractable, and where the honest work has to happen before Q-Day stops being a hypothetical calendar entry.

Why the calendar is real now

Three things have changed since the last time most enterprises seriously reviewed their crypto migration plans.

• The standards are finished. NIST's core PQC standards — ML-KEM for key encapsulation, ML-DSA and SLH-DSA for digital signatures — have been ratified since 2024. Additional algorithms have followed. There is no longer an "we're waiting for the standards" position. Anyone still using that line has not looked recently.
• Regulatory deadlines have arrived. CNSA 2.0 requires classified US national security systems to be quantum-resistant by 2033 with hard interim milestones through 2027-2030. EU financial services regulators have published broadly similar timelines. If you sell into either market you already have a compliance clock running whether you have noticed or not.
• "Harvest now, decrypt later" is not hypothetical. State-level actors have been recording encrypted traffic in bulk for years on the working assumption that they will decrypt it retrospectively. Anything encrypted today with classical algorithms and long-lived value — customer PII, intellectual property, source code, financial records, medical data — should be considered future-decryptable. The clock on that data started years ago.

None of this requires cryptographically relevant quantum computers to actually exist yet. The migration timeline is already binding.

What we find when we walk in

The engagements follow a depressingly consistent pattern.

• No usable crypto inventory. The organisation cannot answer "where do we use RSA, ECC, and DH, and with what key sizes, and who owns those systems." Not "roughly", not "in the main systems" — the actual answer. Without this, no migration plan is real.
• Crypto embedded in code, not abstracted. Applications call cryptographic primitives directly. Algorithm choices are hardcoded. Rotating algorithms requires touching hundreds of code paths. Crypto-agility, in the sense that the industry has been talking about since 2015, is largely absent.
• Certificate authorities and PKI on schedules built for a decade of stability. Rotation, revocation, and re-issuance processes designed for occasional key changes, not systemic algorithm migration. The operational muscle for large-scale re-issuance does not exist.
• Vendor and supplier chains uncharted. Payment processors, identity providers, HSMs, network equipment vendors, IoT device fleets — the enterprise's PQC posture is bounded by the weakest link in a chain nobody has enumerated.
• Firmware and long-lived embedded systems that will outlive the migration window. Devices in the field for ten to twenty years, unable to receive PQC updates, running classical algorithms that will not survive the transition period.

What actually needs to happen in 2026

The list is shorter than most vendors will tell you. The discipline required is more sustained than most CISOs will initially budget for.

1. Build a real cryptographic inventory

Not a survey. An automated, continuously-maintained inventory of every use of asymmetric cryptography across the estate — TLS terminations, certificate authorities, code-signing infrastructure, application-level crypto, database TDE, backup encryption, VPNs, IoT, third-party integrations. Tools for this exist and are maturing quickly. The output is the ground truth every subsequent decision depends on.

2. Prioritise by data lifetime and exposure

Not everything is equally urgent. The highest priorities are systems that (a) encrypt data with long-lived value and (b) transmit or store that data in ways potentially observable to a persistent adversary. Payment credentials, health records, source code, government correspondence, intellectual property with a ten-year horizon. Session tokens that expire in an hour matter less. Rank ruthlessly.

3. Achieve crypto-agility before you achieve PQC

The single most valuable engineering investment in 2026 is not switching algorithms — it is putting the architectural pieces in place that make switching algorithms tractable. Central crypto libraries, algorithm negotiation at every boundary, key material stored with algorithm metadata, deployment pipelines that can roll algorithms independently of application code. Do this first. Every subsequent migration is materially cheaper if you do.

4. Deploy hybrid schemes where they are ready

Hybrid TLS (classical plus PQC key exchange) is production-ready with major libraries and is being deployed at meaningful scale. It provides forward secrecy against a future quantum adversary without giving up compatibility with classical clients. This is a genuinely available 2026 action for enterprise TLS terminations and internal service meshes.

5. Get PQC into your PKI roadmap

Certificate authorities need to issue PQC and hybrid certificates. Root and intermediate CAs need new key material. This is a multi-year programme and it needs to be started, not scoped. If your PKI team does not have concrete PQC milestones in the next 18 months, that is where to start the conversation.

6. Contract for it

New vendor contracts should specify PQC roadmaps as a procurement requirement. Existing critical vendors should be asked, in writing, for their PQC transition plan. This is not a technical activity; it is a supply-chain risk activity, and CISOs who let procurement handle it in isolation are consistently surprised.

The organisational failures we see

The technical work is tractable. The organisational failures are what actually kill these programmes.

• Owned by "security architecture" with no engineering authority. A team that can produce standards but cannot land changes. Migration requires engineering ownership backed by executive air cover.
• Framed as a compliance project. The regulatory clock is real but compliance framing produces the minimum viable checkbox, not the actual security outcome. Frame it as a technical resilience programme with a compliance byproduct.
• Budgeted as a one-year initiative. This is a five-to-seven-year programme. Budget accordingly. Programmes budgeted for a year run out of runway at the moment the hard integration work begins.
• No named owner accountable end-to-end. Split responsibilities across security, infrastructure, application teams, and procurement without a single person accountable for the whole. Predictable stalemate.

What good looks like in 2026

The organisations we see doing this well share a small number of traits.

• A named PQC programme lead, senior enough to make architectural calls across the enterprise. Not a working group. A person.
• A public, versioned crypto inventory that engineering teams contribute to. Treated as production infrastructure, not a spreadsheet.
• Crypto-agility as an engineering goal, measured and reported. Percentage of asymmetric crypto going through central libraries. Percentage of systems capable of algorithm rotation without code change.
• PQC roadmap milestones on the same governance track as SLO and security KPI reporting. Visible to executive leadership every quarter.
• Procurement engaged and empowered. Vendor PQC posture is a first-class evaluation criterion.

The organisations that will handle the PQC transition well are the ones treating 2026 as the year to build crypto-agility, not the year to switch algorithms. The switch is the easy part once the infrastructure supports it. The infrastructure work is what is running late in most enterprises we see, and it is the work that determines whether the eventual switch is a nine-month programme or a five-year firefight.

If your organisation cannot produce a current cryptographic inventory this quarter, that is the first deliverable. Everything else depends on it, and no PQC migration plan built on estimates rather than measurements will survive contact with the real estate. The clock is not waiting for the plan to be more comfortable.