Crypto-Agility Roadmap for the Post-Quantum Era
A practitioner roadmap for crypto agility and PQC migration — discovery, ML-KEM/ML-DSA adoption, Azure timelines, and a defensible plan for CTOs and CISOs.
The hard part of the post-quantum transition is not the mathematics — NIST settled that in 2024. The hard part is that most enterprises cannot answer a deceptively simple question: where, exactly, is cryptography used across our estate, and how would we change it? That question is what crypto-agility answers, and it is the difference between a migration that takes a controlled few years and one that becomes an open-ended emergency. This article sets out the post-quantum roadmap we use with clients who need a plan that survives an audit and a board review, not just a slide.
TL;DR / Key takeaways
- Crypto-agility is the real objective, not PQC adoption itself. The goal is an estate where changing an algorithm is a configuration change, because you will have to do it again after the first migration.
- The clock is set by data lifetime, not by quantum hardware. Under the harvest-now, decrypt-later model, any secret that must outlast ~2030 is already exposed. NSA CNSA 2.0 anchors 2027–2035; major clouds target ~2029.
- Discovery is the long pole. A trustworthy cryptographic inventory takes 12–24 months for a large org; full migration realistically takes 5–15 years. Start discovery now.
- The standards are stable. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. Platform support — including Azure — is arriving through 2026.
- Prioritise ruthlessly. Sequence by confidentiality lifetime and exposure, not by what is easiest to change.
Why crypto-agility, not just "switch to PQC"
It is tempting to frame the post-quantum era as a one-time replacement: swap RSA and elliptic-curve cryptography for the new lattice-based schemes and move on. That framing is wrong, and acting on it produces brittle systems. The new standards are excellent, but they are not the end of cryptographic history — parameters will be tuned, schemes will be deprecated, and hybrids will give way to pure post-quantum modes. An organisation that hardcodes ML-KEM the way it once hardcoded RSA simply schedules the same pain for the next decade.
Cryptographic agility reframes the objective. Instead of asking "which algorithm do we install," you ask "how do we make algorithm choice a property we can change safely and quickly across the whole estate." That means cryptography lives behind interfaces, certificates and keys are managed centrally, algorithm identifiers are negotiated rather than assumed, and no business logic embeds a specific primitive. Get this right and the post-quantum migration is the first beneficiary; every migration after it is cheaper.
This is also where most estates are weakest. Decades of pragmatic engineering have scattered cryptography everywhere — TLS configurations, signing pipelines, embedded device firmware, database-level encryption, application libraries, and vendor products you cannot inspect. You cannot make agile what you cannot see, which is why the roadmap starts with discovery.
The timeline that actually constrains you
There is no single legal deadline forcing a quantum-safe enterprise by a fixed date, and waiting for one is a mistake. The binding constraint is the confidentiality lifetime of your data combined with the harvest-now, decrypt-later threat. An adversary does not need a quantum computer today to harm you — they need only to capture encrypted data today and decrypt it once the hardware exists. For data that must remain secret into the 2030s and beyond, the exposure is already real.
The external anchors help calibrate urgency:
| Signal | What it commits to | Practical reading |
|---|---|---|
| NIST FIPS 203/204/205 | PQC standards finalized Aug 2024 | The algorithms are stable; no reason to wait for standards |
| NSA CNSA 2.0 | Quantum-safe for new national-security systems by 2027; migration 2030–2035 | Government supply chains will demand PQC well before 2030 |
| Hyperscalers (Google, Cloudflare, AWS, Microsoft) | Internal quantum-safe targets ~2029 | Platform-level protections arrive this decade; application-level is yours |
| Microsoft SymCrypt / Azure Key Vault & Managed HSM | ML-KEM/ML-DSA in SymCrypt since late 2024; KV/HSM PQC tracking through 2026 | The platform is no longer the blocker for most workloads |
The honest conclusion: even the most aggressive realistic migration takes five to fifteen years end to end for a large enterprise, and the discovery phase alone consumes twelve to twenty-four months. If your data has a long secrecy horizon, the arithmetic says the programme should already be funded.
Step 1 — Cryptographic discovery (the long pole)
Everything downstream depends on a trustworthy cryptographic bill of materials: a living inventory of every algorithm, key length, certificate, protocol version, and library across applications, infrastructure, identity systems, data stores, network appliances, and third-party products. In our delivery work the single most common surprise is not the volume of cryptography — it is the proportion that is embedded: baked into firmware, pinned in legacy clients, or buried inside vendor binaries where you have no configuration switch at all. Those items dictate the critical path, so finding them early is the entire point.
Discovery combines several techniques: static and binary scanning, TLS and certificate inventory, network observation of negotiated suites, configuration management data, and structured supplier questionnaires for the opaque parts of the estate. The output is not a spreadsheet you file away — it is a maintained capability. We go deeper on method and tooling in our guide to cryptographic discovery and inventory. Budget realistically: for a complex estate this is a year-plus of effort, and rushing it produces an inventory you cannot trust, which is worse than none.
Step 2 — Prioritise by data lifetime and exposure
You cannot migrate everything at once, and you should not try. Prioritisation is the discipline that turns a sprawling inventory into a sequenced plan. Rank systems along two axes: how long the data must stay confidential and how exposed the cryptography is to harvest-now collection or to external trust dependencies.
- Long-lived secrets over public or untrusted networks — first. Health, legal, financial, IP, and state data with multi-decade confidentiality, especially where key exchange happens across the internet.
- Externally reachable key exchange and authentication — high. TLS termination, VPN, mutual-auth APIs, and federation endpoints adversaries can record today.
- Long-lived signatures and roots of trust — high but distinct. Code-signing, firmware-signing, and certificate-authority roots that must remain valid for years; these favour ML-DSA or, where conservatism is paramount, SLH-DSA.
- Short-lived, internal, low-sensitivity cryptography — last. Genuinely ephemeral secrets carry the least harvest-now risk.
This sequencing is what makes a five-to-fifteen-year programme defensible: you are demonstrably protecting the data that matters most, first.
Step 3 — Engineer agility, then adopt the algorithms
Only now does algorithm adoption become sensible, because you have somewhere to put it. The engineering work is to abstract cryptography behind stable interfaces and centralised services — a crypto provider layer, centralised key and certificate management, and protocol stacks that negotiate rather than hardcode. With that in place, adopting ML-KEM for key establishment and ML-DSA for signatures becomes a contained change rather than a sprawl of code edits.
The prudent first move is hybrid key exchange: combining a classical algorithm with ML-KEM so a flaw in either leaves you protected, which is also how the major TLS deployments are proceeding. Centralise key operations in a managed key store and HSM so algorithm transitions happen in one controlled place — relevant given that Azure Key Vault's post-quantum migration capability is arriving through 2026. For architects who need to reason about parameter sets, performance, and where each scheme fits, we cover the primitives in ML-KEM and ML-DSA for architects. The non-negotiable principle: no application should know which algorithm it is using.
Step 4 — Migrate in waves, verify, and keep it live
Roll out in waves that follow your prioritisation, and treat verification as a first-class activity. Post-quantum algorithms change key and signature sizes and have different performance characteristics, so interoperability and latency testing are not optional — handshake sizes and certificate chains in particular can break assumptions baked into older clients and middleboxes. Each wave should leave behind updated runbooks, monitoring for deprecated algorithms still in use, and a refreshed inventory.
The governance wrapper matters as much as the engineering. Update procurement and vendor requirements so new systems arrive crypto-agile and PQC-ready by contract, not by remediation. Because this work sits squarely inside a Zero Trust posture — where you assume the network is hostile and verify cryptographically at every boundary — it belongs in the same strategic conversation; see our Zero Trust services. The migration ends not when the last algorithm is swapped, but when crypto-agility is a permanent, owned capability.
A defensible roadmap on one page
The phases run roughly in sequence, but discovery and prioritisation overlap, and the inventory never stops — each migration wave feeds it new state, which keeps the whole programme honest.
| Phase | Horizon | Primary outcome |
|---|---|---|
| Govern | Now | Accountable owner, board sponsorship, funded multi-year programme |
| Discover | 12–24 months | Trustworthy cryptographic bill of materials, maintained, not one-off |
| Prioritise | Overlaps discovery | Systems sequenced by data lifetime and exposure |
| Engineer agility | Ongoing | Cryptography behind interfaces; centralised keys and certificates |
| Migrate & maintain | 5–15 years | Hybrid then PQC rollout in waves; agility as a permanent capability |
The organisations that will struggle are not the ones who started a year late — they are the ones who treated this as a procurement exercise rather than an architectural one. Crypto-agility is the asset that outlasts any single algorithm, and it is built deliberately, beginning with knowing what you have.
Working with us
We help European enterprises turn the post-quantum question from anxiety into a sequenced, evidence-backed plan — discovery, prioritisation, and the crypto-agility engineering underneath it. If you are scoping a PQC migration plan or want a second opinion on one already in motion, our Zero Trust and security advisory is a good place to start the conversation. No pressure, no body-shop pitch — just architects who have done the work.
FAQ
What is crypto-agility and why does it matter for post-quantum migration?
Crypto-agility is the ability to change cryptographic algorithms, key sizes, and protocols across your estate quickly and with low risk, ideally without re-architecting applications. It matters because the post-quantum transition is not a one-time swap — algorithms will keep evolving, and you will need to replace them again. Building agility now means the next migration is a configuration change, not a multi-year programme.
When do we actually need to be quantum-safe?
There is no single deadline, but credible anchors exist. NSA's CNSA 2.0 requires quantum-safe algorithms for new US national-security systems by 2027, with broader migration through 2030 to 2035, and major cloud providers target roughly 2029 internally. The harder constraint is data with a long confidentiality lifetime: anything that must stay secret beyond about 2030 is already exposed to harvest-now-decrypt-later collection and should be protected sooner rather than later.
What are FIPS 203, 204, and 205?
They are the post-quantum cryptography standards NIST finalized in August 2024. FIPS 203 is ML-KEM, a key-encapsulation mechanism for establishing shared secrets. FIPS 204 is ML-DSA, a lattice-based digital signature scheme. FIPS 205 is SLH-DSA, a hash-based signature scheme used where a conservative, well-understood security basis is preferred. ML-KEM and ML-DSA are the two most organisations will adopt first.
How long does an enterprise PQC migration realistically take?
For a large organisation, realistic end-to-end migration runs five to fifteen years, and cryptographic discovery alone — building a trustworthy inventory of where and how cryptography is used — typically takes twelve to twenty-four months. The wide range reflects estate complexity, the prevalence of hardcoded and embedded cryptography, and dependency on vendors and hardware you do not control.
What is 'harvest now, decrypt later' and does it affect us today?
It is the threat model where an adversary captures encrypted traffic or exfiltrates encrypted data today and stores it until a cryptographically relevant quantum computer can decrypt it. It affects you today if you hold data whose confidentiality must outlast the arrival of such machines — health records, state secrets, intellectual property, long-lived financial data. For that data, the migration clock has already started even though quantum computers cannot yet break the keys.
Does Azure support post-quantum cryptography yet?
Support is arriving in stages. Microsoft's SymCrypt library added ML-KEM and ML-DSA in late 2024, and post-quantum capability in Azure Key Vault and Managed HSM is tracking through 2026. The practical implication is that platform support is no longer the blocker for most workloads — the work shifts to discovery, prioritisation, and engineering crypto-agility into your own applications and protocols.
Topics