Someone Is Already Collecting Your Encrypted Traffic. Post-Quantum Migration Is Not a Future Problem.
Your RSA-2048 keys are secure right now. Against a sufficiently powerful quantum computer running Shor's algorithm, they will not be. That transition is coming, the timeline is uncertain but sits comfortably within the next decade or two for most threat models, and the migration work takes years. If you are waiting for quantum computers to become an imminent threat before starting, you are already late.
There is also a problem that is not hypothetical at all: nation-state actors are collecting encrypted traffic today with the intention of decrypting it when they have the capability. If you operate in a high-value sector, your traffic is probably already in someone's storage infrastructure.
What Harvest Now, Decrypt Later Actually Means
The attack is straightforward. An adversary intercepts and stores encrypted network traffic now. Years later, when cryptographically relevant quantum computers exist, they decrypt it. The data's confidentiality requirement does not expire just because the collection happened in 2026.
This is not speculative. Intelligence agencies and nation-state actors have explicitly described this posture. The NSA issued guidance in 2022 stating that organizations should start migrating to post-quantum algorithms for sensitive data. CISA, NSA, and NIST published joint guidance to the same effect. The harvest-now threat is why the urgency is real today rather than in ten years.
For most enterprises, the data with the highest long-term confidentiality risk includes intellectual property, acquisition plans, litigation strategy, private key material that could be used to compromise future sessions, and anything with regulatory protection that persists for years. If that data transited RSA or ECC-protected channels in recent years, someone may already have copies of it waiting on a server somewhere.
What NIST Finalized and What It Means for You
In August 2024, NIST published three post-quantum cryptography standards. FIPS 203 standardizes ML-KEM (based on CRYSTALS-Kyber) for key encapsulation and key exchange. FIPS 204 standardizes ML-DSA (based on CRYSTALS-Dilithium) for digital signatures. FIPS 205 standardizes SLH-DSA, a hash-based signature scheme, as an alternative.
These are the algorithms you will be migrating to. They are mature, standardized, and implementations are arriving in TLS libraries, browsers, and operating systems now. The standardization question is settled. The operational question of how to get your enterprise from here to there is still entirely on you.
You Almost Certainly Do Not Know Where Your Cryptography Is
Before you can migrate, you need to find what you are migrating. This is harder than it sounds.
TLS certificates are the visible surface, and they are a fraction of it. SSH keys on servers, network devices, and automation accounts. Code signing certificates for software releases and firmware updates. Email signing and encryption certificates. Document signing infrastructure. VPN certificates and the PKI that issues them. JWT signing keys embedded in application code. Cryptographic dependencies inside applications that call library functions without the developers thinking about what algorithm family they are invoking. Hardware security modules and the key material they protect. Third-party products whose cryptographic choices are the vendor's to make and eventually to update.
The concept of a cryptographic bill of materials (CBOM) exists for exactly this problem. Borrowing from software supply chain work, a CBOM maps every cryptographic asset: what algorithm, what key size, what certificate, where it lives, and what depends on it. Generating one for a large enterprise is not quick work. It is the necessary starting point, because nothing else in the migration plan is buildable without it.
What to Prioritize Once You Know What You Have
Not everything migrates at the same time. Sequencing follows two factors: sensitivity of the data being protected and how long that data needs to remain confidential.
The first tier is infrastructure protecting long-lived secrets or high-sensitivity data with multi-year confidentiality requirements. Certificate authority infrastructure, key management systems, HSMs, and anything handling classified information or high-value intellectual property. These are also where the harvest-now threat has the highest leverage, because the keys and secrets stored there have the longest expected useful life.
TLS for external-facing applications comes next, partly because library support is arriving (X25519Kyber768 hybrid key exchange is live in current browser releases and major TLS library versions) and partly because the update path is more well-defined compared to embedded systems or OT environments.
The genuinely hard problems are the edge cases: IoT devices and operational technology with no firmware update path, legacy HSMs that do not support post-quantum algorithm families, applications with hardcoded cryptographic parameters, and environments where the operational risk of a failed update is not acceptable. These require long lead times and often hardware refresh cycles, which is another reason starting the inventory now matters.
Hybrid Mode Is a Migration Bridge, Not a Destination
Running post-quantum and classical algorithms together in hybrid mode is the practical transition approach. TLS 1.3 with hybrid key exchange (ML-KEM combined with X25519) means breaking the session requires breaking both algorithms. You get quantum resistance from ML-KEM while retaining classical protection against adversaries who lack quantum capability today.
Hybrid mode also surfaces operational problems in a controlled way. Post-quantum public keys are larger than classical keys. Certificate chains get longer. Some older TLS implementations handle the larger handshakes poorly. Running hybrid in production exposes those compatibility issues before a hard cutover forces them. Every incompatible system you find in hybrid testing is a system you are glad you did not discover during a full migration.
It is a bridge, not a final state. The goal is full PQC deployment, with hybrid as the path to get there.
The Case for Starting Now
The argument for waiting - that quantum computers do not currently threaten your encryption - is technically accurate and practically wrong. Migration timelines for enterprise cryptographic infrastructure are measured in years. Replacing certificates across an organization requires vendor support for new algorithms, updated library dependencies, testing, hardware lifecycle decisions, and often regulatory approval cycles. Organizations starting that process in 2026 are at a reasonable point in the timeline. Organizations waiting for cryptographically relevant quantum computers to be an imminent threat are planning to do in six months what realistically takes three to five years.
The harvest-now problem removes the luxury of waiting for the highest-sensitivity data entirely.
Begin with the inventory. It is not glamorous work, and the deliverable is a spreadsheet nobody will put on a slide in a board presentation. But it is the only place the migration actually starts.