Two years ago, post-quantum cryptography was a research conversation. In 2026 it is a procurement line item, a compliance deadline, and in some sectors a contractual requirement. The standards are finished, the deadlines are published, and the threat model is no longer hypothetical. What has not changed is the hard part: most enterprises still do not know where their cryptography lives, which means they cannot migrate it on a schedule someone else sets.
This is a status report, not a sales pitch for panic. The honest summary is that the easy decisions are done and the hard work has barely started.
The standards are settled — that part is over
NIST finalized its first three post-quantum standards on August 13, 2024, ending an eight-year selection process. If you are still seeing the old algorithm names in vendor decks, that is a red flag about the vendor, not the standards. The names to know:
- FIPS 203, ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), formerly CRYSTALS-Kyber. This is the key exchange workhorse — the thing protecting your TLS handshakes and VPN tunnels.
- FIPS 204, ML-DSA (Module-Lattice-Based Digital Signature Algorithm), formerly CRYSTALS-Dilithium. The default replacement for RSA and ECDSA signatures.
- FIPS 205, SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), formerly SPHINCS+. A more conservative, hash-based signature scheme with no lattice assumptions — slower and larger, but a useful hedge if a structural weakness is ever found in the lattice family.
The practical takeaway is that the algorithm debate is effectively closed for general enterprise use. If a project is choosing between candidates in 2026, it is relitigating a decision that was already made. The interesting questions now are operational, not cryptographic.
The deadlines are real, and they are closer than the calendar suggests
NIST IR 8547 lays out a two-stage sunset for the algorithms most enterprises run today. Quantum-vulnerable algorithms such as RSA-2048 and ECC P-256 are slated for deprecation around 2030, and quantum-vulnerable algorithms are to be disallowed in NIST-aligned systems by 2035. For anyone touching federal work, the NSA's CNSA 2.0 framework is more aggressive still: it expects quantum-safe algorithms in new national security systems beginning in 2027.
Gartner has put dates on the threat itself rather than the compliance timeline. Its framing distinguishes "unsafe" from "broken" — broadly, that asymmetric cryptography becomes untrustworthy for long-lived confidentiality toward the end of the decade, with a fully practical break expected several years after that. The exact years move depending on which Gartner note you read, and that uncertainty is the point: nobody can promise you a precise Q-Day, which is exactly why you cannot plan around one.
Here is the trap in those dates. A 2030 deprecation deadline reads like four years of runway. But credible estimates put a serious enterprise migration at two to five years of real work, and that work cannot begin until you finish an inventory most organizations have not started. Run the subtraction honestly and the comfortable margin disappears.
Harvest-now-decrypt-later means some of your data is already exposed
The most misunderstood part of the quantum threat is the timeline. People hear "quantum computers cannot break RSA yet" and conclude there is nothing to do. That reasoning fails for any data that must stay confidential for years.
Harvest-now-decrypt-later is exactly what it sounds like. An adversary captures encrypted traffic today and stores it, betting on a future decryption capability. They do not need a quantum computer now; they need patience and storage, both of which are cheap. Anything with a long confidentiality lifetime is a target the moment it crosses a wire: health records, source code and IP, government and defense communications, M&A material, and long-dated financial instruments.
The uncomfortable implication is that for a subset of your data, the migration deadline was already in the past. You cannot un-harvest what has already been collected. What you can do is stop adding to the pile, and that argues for prioritizing PQC on your longest-lived secrets first rather than treating the whole estate as one undifferentiated project.
The real work is inventory and crypto-agility, not algorithm selection
Migration fails or succeeds on a deeply unglamorous question: do you know where all your cryptography is? In most enterprises the honest answer is no. Cryptography is embedded in TLS termination, code signing, mutual auth between services, hardware security modules, firmware, document signing, database encryption, and — critically — in third-party products and libraries you do not control. There is no single switch to flip.
This is why crypto-agility has become the actual goal, not PQC per se. NIST has gone as far as publishing a dedicated white paper on the subject (CSWP 39, "Considerations for Achieving Cryptographic Agility"), which introduces a maturity model ranging from unstructured, ad hoc practices to adaptive programs fully integrated into enterprise risk management. The principle is straightforward: design systems so the algorithm is a swappable parameter rather than a load-bearing assumption baked into a hundred call sites. An organization that is crypto-agile can adopt ML-KEM this year and pivot again if a weakness emerges, without a multi-year fire drill each time. An organization that is not agile will repeat this entire migration the next time the ground shifts.
There is encouraging movement at the protocol layer. Cloudflare reported that by late 2025 more than half of human-initiated web traffic across its network was protected by hybrid post-quantum key exchange (X25519MLKEM768), and Google and Apple have shipped hybrid PQC to large user bases. That is genuine progress — but notice what it covers. Browser-to-edge TLS is the part with a clear owner and a clean upgrade path. The long tail of internal services, embedded devices, signing infrastructure, and vendor software is where the multi-year timelines actually live.
The third-party problem nobody owns
The hardest segment is the cryptography you did not write. Your dependency tree, your SaaS vendors, your firmware, and your hardware all make their own cryptographic choices, and most of them have not published a PQC roadmap. You can be diligent about your own code and still ship quantum-vulnerable cryptography because a transitive dependency or an upstream appliance never moved.
This reframes PQC migration as a software-supply-chain and third-party-risk problem as much as a cryptography problem. The questions that matter are: which components in your software bill of materials still rely on RSA or ECC, which vendors have a credible migration plan, and how do you keep that picture current as dependencies change weekly. Treating quantum readiness as a vendor-risk discipline — with evidence, not promises — is what separates a real program from a slide that says "we're on it."
A practical sequencing falls out of all this. Start with an inventory you can keep current, because everything downstream depends on knowing what you have. Rank by confidentiality lifetime so your harvest-now-decrypt-later exposure gets attention before low-stakes ephemeral traffic. Adopt hybrid key exchange where a clean upgrade path already exists, since that buys protection without waiting on a big-bang cutover. And push your vendors for dated commitments rather than reassurances, because their timelines become your timelines whether you track them or not. None of these steps require a quantum computer to exist. They require organizational discipline, which is the genuinely scarce resource here.
How Safeguard Helps
Safeguard treats post-quantum readiness as a supply-chain visibility problem first. We surface cryptographic dependencies across your SBOM and AIBOM, flag components still leaning on quantum-vulnerable algorithms, and track which third parties have a credible migration plan through our vendor scorecard and TPRM workflows — so quantum readiness becomes evidence you can audit instead of a vendor's verbal assurance. Our Multi-Agent TAOR Deep Think AI Engine adds verification above any single model, which keeps the inventory accurate and cuts the false positives that make crypto inventories untrustworthy. If you want a clear picture of where your cryptography actually lives before the 2030 deadlines arrive, reach out.