Post-Quantum Migration with Azure Key Vault
A practitioner guide to post-quantum cryptography on Azure — ML-KEM, Azure Key Vault and Managed HSM PQC, crypto-agility, and a realistic migration plan.
The cryptography protecting your enterprise today has an expiry date, and you do not control when it arrives. A cryptographically relevant quantum computer would break the RSA and elliptic-curve algorithms that underpin almost every TLS session, signed artifact and encrypted database in your estate. The machine does not exist yet. The threat does — because adversaries can harvest now and decrypt later. This article sets out how we approach post-quantum migration on Azure, with Azure Key Vault and Azure Managed HSM at the centre of the plan, drawing on how we sequence this work for clients who have to make it defensible rather than merely aspirational.
TL;DR / Key takeaways
- The clock is data-driven, not hardware-driven. Under harvest now, decrypt later, any data whose confidentiality must outlive the next decade is already at risk — migration timing follows data lifetime, not quantum availability.
- NIST finalized the standards in August 2024: FIPS 203 (ML-KEM, key encapsulation), FIPS 204 (ML-DSA, signatures) and FIPS 205 (SLH-DSA, hash-based signatures). These are what you migrate to.
- Azure is mid-rollout. Microsoft's SymCrypt gained ML-KEM and ML-DSA in late 2024; Azure Key Vault PQC and Managed HSM PQC support is tracking through 2026. Plan now, pilot as features land.
- Discovery dominates the timeline. Cryptographic inventory alone takes 12-24 months for large organisations; full migration realistically runs 5-15 years.
- Crypto-agility is the actual goal. PQC is not a one-time swap; build the ability to change algorithms in weeks, not years.
Why this is a now problem, not a 2035 problem
The instinct of most boards is to file post-quantum cryptography under "future risk" and revisit it when quantum hardware looks imminent. That instinct is wrong, and the reason is the harvest now, decrypt later threat model. An adversary does not need a working quantum computer today. They need only to capture ciphertext today and store it. When a sufficiently capable machine arrives — whether in 2032 or 2038 — they decrypt everything they retained.
This reframes the deadline entirely. The question is not "when will quantum computers break RSA?" It is "how long must my data stay confidential?" If you hold health records, financial archives, long-lived intellectual property, state-adjacent data or anything with a multi-decade confidentiality requirement, the exposure window has already opened. Data leaving your network in 2026 protected only by classical key exchange is, for these purposes, data you should assume an adversary may eventually read.
The standards bodies have moved accordingly. NSA's CNSA 2.0 requires quantum-safe algorithms for new national-security systems by January 2027, with full migration across 2030-2035. The hyperscalers are ahead of their own customers: Google, Cloudflare, AWS and Microsoft are deploying hybrid post-quantum key exchange now and target roughly 2029 for broad internal coverage. If the platform providers treat this as a present-tense engineering programme, enterprises building on those platforms cannot treat it as a 2035 concern.
What you are migrating to
In August 2024 NIST finalized the first post-quantum standards, and these are the algorithms that matter for enterprise planning.
| Standard | Algorithm | Type | Primary use |
|---|---|---|---|
| FIPS 203 | ML-KEM | Lattice-based key encapsulation | Establishing shared keys (replaces RSA/ECDH key exchange) |
| FIPS 204 | ML-DSA | Lattice-based digital signature | General-purpose signing (replaces RSA/ECDSA signatures) |
| FIPS 205 | SLH-DSA | Hash-based digital signature | Conservative high-assurance signing backup |
For most Azure estates, ML-KEM and ML-DSA are the workhorses — they cover the key-exchange and signing operations that dominate real systems. SLH-DSA matters where you deliberately want a different mathematical foundation (hash-based rather than lattice-based) for the highest-assurance signing, such as firmware or root-of-trust scenarios, accepting larger signatures in exchange for conservative security. A deeper treatment of the trade-offs sits in our note on ML-KEM and ML-DSA for architects.
Hybrid first, pure post-quantum later
A pragmatic point that often gets lost: you do not jump straight to pure post-quantum. Most mature migrations begin with hybrid schemes, where a hybrid key exchange combines a classical algorithm (such as ECDH) with a post-quantum KEM (such as ML-KEM). The session is secure as long as either component holds. This is deliberately conservative — the post-quantum algorithms are young, and a hybrid construction protects you against an undiscovered flaw in the new lattice mathematics while still delivering quantum resistance today. This is exactly the pattern the hyperscalers chose, and it is the right default for enterprises too.
Where Azure Key Vault and Managed HSM fit
Post-quantum migration is, in large part, a key-management problem. Every algorithm you replace touches keys, and the place those keys live determines how painful the swap is. This is why Azure Key Vault and Azure Managed HSM sit at the centre of a sound Azure PQC plan.
Microsoft's progress is concrete but in-flight. The underlying SymCrypt cryptographic library added ML-KEM and ML-DSA in late 2024, which is the foundation everything else builds on. Azure Key Vault PQC and Managed HSM PQC support is tracking through 2026. The honest assessment for early 2026: the primitives are arriving, but a uniformly available, turnkey production PQC key type you simply select from a dropdown is not yet here across all regions and tiers. The correct posture is to plan and architect now, and pilot as features land — not to wait for a finished feature before starting the hard work, which is discovery and agility, not the key type itself.
The strategic value of routing key operations through Key Vault and Managed HSM is crypto-agility. If your applications never see raw keys and never hardcode algorithm choices — if they call a centralised key service that abstracts the algorithm — then adopting ML-KEM, and the algorithm after it, becomes a configuration and policy change rather than a code rewrite across hundreds of services. Managed HSM additionally gives you FIPS-validated, single-tenant key protection where regulatory or sovereignty requirements demand it, which European regulated entities frequently do.
| Capability | Azure Key Vault (Premium) | Azure Managed HSM |
|---|---|---|
| Tenancy | Multi-tenant service | Single-tenant, dedicated HSM pool |
| Isolation level | High | Highest (dedicated hardware boundary) |
| Typical fit | Most application keys and secrets | High-assurance, sovereignty, regulated workloads |
| PQC trajectory | Tracking through 2026 | Tracking through 2026 |
A realistic migration sequence
We have run cryptographic-discovery and roadmap work for Azure-centric estates, and the consistent lesson is that the algorithm swap is the easy part. The programme lives or dies on inventory and agility. Here is the sequence we use.
- Inventory your cryptography. You cannot migrate what you cannot see. Discover every place keys, certificates and algorithms are used — Key Vault objects, Managed HSM keys, TLS endpoints, code-signing pipelines, data-at-rest encryption, VPNs, and embedded or hardcoded secrets. Record algorithm, key length, owner and data lifetime. Expect this to take 12-24 months at enterprise scale; it is the single largest line item. Our cryptographic discovery and inventory guide goes deep on method here.
- Prioritise by data lifetime and exposure. Rank systems by how long their data must remain confidential and by their exposure to harvest-now-decrypt-later interception. Long-lived, high-confidentiality data migrates first — irrespective of how old or modern the system is.
- Engineer crypto-agility. Centralise key operations behind Key Vault and Managed HSM, abstract algorithm selection out of application code, and eliminate hardcoded algorithm assumptions. This is the investment that makes every future migration cheap.
- Pilot hybrid algorithms. As Azure PQC features land, adopt hybrid key exchange on a contained, high-value workload. Validate performance, the larger payload and key sizes that lattice schemes bring, and interoperability with partners and clients.
- Roll out in waves. Migrate prioritised systems in waves, updating key types and signature schemes, watching for regressions, and keeping classical algorithms as a fallback during transition.
- Govern and re-test. Stand up ongoing cryptographic governance — periodic re-inventory, algorithm-policy review, and rehearsed key rotation — so the estate stays agile as the standards continue to move.
The full strategic framing, including how this maps onto regulatory drivers and board reporting, sits in our crypto-agility roadmap for the enterprise. Post-quantum migration is also, properly understood, a Zero Trust concern: it hardens the cryptographic assumptions that identity, segmentation and data-protection controls all rest on.
What to do in 2026
If you take one action this year, make it discovery. Begin the cryptographic inventory now, because it gates everything else and it is the part that cannot be accelerated by waiting for better tooling. In parallel, route new key operations through Azure Key Vault and Managed HSM with algorithm abstraction, so that agility is built in by default rather than retrofitted under deadline pressure. Treat pure-PQC adoption as a destination and hybrid as the on-ramp. The organisations that will migrate calmly in 2029 are the ones that started inventorying in 2026.
A note on getting help
CC Conceptualise plans and delivers post-quantum and crypto-agility programmes for European enterprises on Azure, grounded in real key-management and Zero Trust delivery rather than slideware. If you want a defensible roadmap that survives both an auditor and a CISO, our Zero Trust and cybersecurity practice is where this work lives.
FAQ
Is Azure Key Vault post-quantum ready today? Partly. Microsoft added the ML-KEM and ML-DSA algorithms to its underlying SymCrypt library in late 2024, and post-quantum support for Azure Key Vault and Azure Managed HSM is tracking through 2026. The honest position for early 2026 is that the platform primitives are arriving, but a turnkey production PQC key type you can simply select is not yet uniformly available. Plan now, pilot as features land.
What is harvest now, decrypt later and why does it matter before quantum computers exist? It is the threat model where an adversary captures encrypted traffic or stored ciphertext today and retains it until a cryptographically relevant quantum computer can break it. The decryption happens in the future, but the data theft happens now. Any data whose confidentiality must outlive the next decade — health records, state secrets, long-lived IP, financial archives — is already exposed, which is why migration timing is driven by data lifetime, not by quantum readiness.
What are FIPS 203, 204 and 205? They are the post-quantum standards NIST finalized in August 2024. FIPS 203 is ML-KEM, a lattice-based key-encapsulation mechanism used to establish shared keys. FIPS 204 is ML-DSA, a lattice-based digital signature scheme. FIPS 205 is SLH-DSA, a hash-based signature scheme used as a conservative backup. ML-KEM and ML-DSA are the workhorses for most enterprise migrations; SLH-DSA matters where you want a different mathematical foundation for high-assurance signing.
How long does a realistic enterprise PQC migration take? For a large organisation, plan for five to fifteen years end to end. Cryptographic discovery — simply building an accurate inventory of where and how cryptography is used — typically takes twelve to twenty-four months on its own. The migration is not a single cutover but a multi-year programme of inventory, prioritisation, crypto-agility engineering, and phased algorithm replacement. The deadlines that bind you are NSA CNSA 2.0 (quantum-safe for new national-security systems by 2027, full migration 2030-2035) and your own data-retention requirements.
Do we migrate to pure post-quantum or to hybrid algorithms first? Most enterprises should start hybrid. A hybrid key exchange combines a classical algorithm such as ECDH with a post-quantum KEM such as ML-KEM, so the session stays secure as long as either one holds. This hedges against early implementation flaws in the new algorithms while delivering quantum resistance immediately. Hyperscalers including Google, Cloudflare, AWS and Microsoft are deploying hybrid key exchange first and targeting roughly 2029 for broad internal coverage.
What is crypto-agility and why is it the real goal? Crypto-agility is the ability to change cryptographic algorithms, parameters and key types across your estate quickly, safely and without re-architecting applications. It matters because PQC is not a one-time swap: standards will evolve, some algorithms may be weakened, and you will need to rotate again. An organisation that centralises key operations behind Azure Key Vault and abstracts algorithm choice from application code can adopt the next algorithm in weeks rather than years.
Topics