In August 2024, the National Institute of Standards and Technology finalized the first three post-quantum cryptographic standards: ML-KEM for key establishment, ML-DSA for digital signatures, and SLH-DSA as a hash-based signature alternative. Eighteen months later, most enterprise cryptographic inventories still look exactly as they did before the announcement. RSA-2048 and ECDSA remain the workhorses of TLS termination, code signing, VPN tunnels, database encryption, and every internal service that speaks TLS to every other internal service.
This is not a crisis today. It is a problem with a long fuse, a hard deadline, and a class of attackers who are already preparing for the transition by doing something that sounds theoretical and is not: they are collecting encrypted traffic now, storing it, and planning to decrypt it later, once a sufficiently capable quantum computer exists. The cryptography community calls this harvest now, decrypt later. For any data that still needs to be secret in 2035, the attack is happening in 2026 whether we have noticed it or not.
This post is a practical guide to where post-quantum cryptography migration sits for enterprises today, what the realistic timeline looks like, and what your organization should be doing in the next twelve months to avoid being caught unprepared.
Why now, when the threat is not now
Two dates matter. The first is the date a cryptographically relevant quantum computer exists — a machine capable of running Shor’s algorithm on keys of the size currently in production. No one knows this date. Credible estimates from cryptography researchers cluster in a window from the early 2030s to the late 2030s, with meaningful probability mass on either side.
The second date is the one that matters more: the date by which any given piece of data must already be protected by post-quantum cryptography. That date is not the date the quantum machine arrives. It is the date the data first leaves your control, minus the length of time the data must remain confidential.
A medical record with a thirty-year confidentiality requirement, transmitted in 2026 over conventional TLS, has to be considered compromised if a quantum computer exists in 2035. The encrypted packets were captured in 2026. The decryption just happens nine years later. The same logic applies to government communications, financial records subject to long retention, intellectual property, and any data governed by long-horizon compliance obligations.
This is why NIST, ENISA, and major regulators are pushing for migration to begin now rather than in the late 2020s. The deadline is not the arrival of the threat. The deadline is several years before the arrival of the threat.
What changed in the standards
The 2024 NIST standards replaced the entire asymmetric cryptography stack, not a layer of it. Three algorithms are now designated for production use:
ML-KEM (formerly Kyber) replaces RSA and elliptic-curve Diffie-Hellman for key establishment. This is the algorithm TLS 1.3 clients and servers will use to negotiate a shared session key.
ML-DSA (formerly Dilithium) replaces RSA and ECDSA for digital signatures. This is what certificates, code signing, and firmware signing will use.
SLH-DSA (formerly SPHINCS+) is a hash-based signature alternative, with different performance and size characteristics, suitable for long-lived signatures and applications where the mathematical assumptions underpinning ML-DSA are considered insufficient.
The practical consequence for enterprise systems is that every place RSA or ECDSA currently appears in production will, eventually, need a replacement or a hybrid construction. Certificate chains, TLS configurations, signed binaries, signed firmware, JWT signing keys, SSH host keys, VPN pre-shared keys and ephemeral exchanges — all of them.
Hybrid constructions — where a classical algorithm and a post-quantum algorithm are used in parallel, so a session is secure if either holds — are the expected transition mechanism. The major TLS libraries and cloud providers are rolling out hybrid modes through 2026 and 2027. This matters because it means migration does not have to be a flag day. It can be a gradual, measured shift.
What enterprises should do in the next twelve months
The first step is not deploying new algorithms. The first step is knowing where the old ones are. Most enterprises drastically underestimate the number of places in their infrastructure where asymmetric cryptography is in use, because most of those places are buried inside operating systems, libraries, appliances, and vendor products that were configured once and forgotten.
1. Build a cryptographic inventory
Identify every system that uses asymmetric cryptography. TLS-terminating load balancers, internal service meshes, certificate authorities, code-signing pipelines, firmware update channels, VPN gateways, database client authentication, SSH access, signed webhooks, JWT-based authentication between services. For each, record the algorithm, the key sizes, the expiry, and the owner.
This inventory is the single most valuable artifact of the migration. Everything else depends on it. Organizations that have done this exercise consistently find two or three times more cryptographic dependencies than they expected, most of them inside vendor products the security team did not know used public-key cryptography at all.
2. Classify data by confidentiality lifetime
Not all data needs to be migrated on the same schedule. Data with a short confidentiality lifetime — operational telemetry, transient session tokens, short-lived audit logs — is not meaningfully at risk from harvest-now-decrypt-later, because by the time a quantum computer exists, the data no longer matters.
Data with a long confidentiality lifetime — customer financial records, healthcare data, intellectual property, government communications, legally privileged material — must be prioritized. This is the data for which the transition window is already closing.
3. Audit your vendor dependency tree
Ask every critical vendor for their post-quantum cryptography roadmap in writing. Cloud providers, TLS CA vendors, identity providers, HSM and key-management vendors, VPN vendors, code-signing infrastructure. Expect a mix of confident answers, vague answers, and silence. The pattern of responses tells you which vendors will migrate on time and which will become a constraint on your own migration.
A vendor that cannot articulate a credible roadmap in 2026 will be a blocker in 2028.
4. Pilot hybrid TLS in a non-critical path
Most major TLS libraries and several cloud load balancers now support hybrid key exchange combining a classical algorithm with ML-KEM. Stand up a non-critical internal service using hybrid TLS. Measure the latency impact, the certificate handling, the compatibility with your observability tooling, the behavior of older clients that do not understand the new ciphersuites.
This is cheap learning. The point is not to protect anything. The point is to identify the operational problems — the unexpected log format changes, the tooling that does not parse the new algorithm names, the legacy systems that negotiate down — before you need to run hybrid on the paths that matter.
5. Build cryptographic agility into new systems
Every new system your organization builds in 2026 should treat the choice of cryptographic algorithm as a configuration, not a baked-in assumption. This is good architecture regardless of the post-quantum transition. With the transition on the horizon, it becomes essential. A system that hard-codes RSA key sizes into its data model will be migrated by rewriting. A system that reads its algorithm choices from configuration will be migrated by restart.
What to watch over the next two years
Three signals will shape how fast the rest of the industry moves.
Browser and operating system defaults. Chrome, Firefox, and Edge have all begun enabling hybrid key exchange by default for TLS. The schedule on which those defaults become mandatory, rather than opt-in, is a strong leading indicator of when the broader web will have migrated.
Public certificate authorities. The CA/Browser Forum is working on the rules under which public CAs will issue certificates using post-quantum algorithms. When those rules stabilize and the first public CAs begin issuing ML-DSA certificates, the migration of public-facing TLS will accelerate quickly.
Regulator guidance. NSA Suite CNSA 2.0 already mandates post-quantum cryptography for US national security systems by 2035, with internal milestones before then. EU, UK, and Japanese regulators are on similar trajectories. For regulated industries, the regulatory deadline will arrive before the technical deadline, and the migration will need to be complete earlier than the threat model alone would require.
The executive view
Post-quantum migration is not a security team project. It is an infrastructure program that touches networking, identity, application architecture, vendor management, and regulatory reporting. Budgeting for it, planning it, and staffing it is a 2026 decision, even though the execution will run for several years.
The organizations that start this year will migrate calmly. The ones that wait will migrate in a hurry, under regulatory pressure, with vendors who are themselves scrambling, and with a cryptographic inventory they built in panic rather than in deliberation. The cost difference between those two migrations is not small.
If post-quantum cryptography is not yet on your engineering or compliance roadmap for 2026, it is time to put it there.
Top comments (0)