What Is Post-Quantum Cryptography? PQC Standards Explained

Post-quantum cryptography (PQC) is a new generation of encryption and digital-signature algorithms designed to resist attacks from future quantum computers. The reason it matters right now, years before such a computer exists, is a threat security researchers call "harvest now, decrypt later": adversaries can capture encrypted traffic or stolen data today and simply store it, waiting for a sufficiently powerful quantum computer to break the encryption later. In August 2024, the U.S. National Institute of Standards and Technology (NIST) finalized the first three PQC standards, and major platforms — Chrome, Cloudflare, Signal and Apple — have already started rolling quantum-resistant algorithms into the tools billions of people use every day.

What is post-quantum cryptography, and why now?

Post-quantum cryptography refers to cryptographic algorithms — mainly for key exchange and digital signatures — that are believed to remain secure even against an adversary with a large-scale, fault-tolerant quantum computer. It's distinct from "quantum cryptography" (which uses quantum physics itself, such as quantum key distribution); PQC algorithms run on ordinary classical computers, but their underlying math problems are chosen specifically because quantum algorithms like Shor's algorithm don't appear to offer a shortcut to break them, unlike the math behind RSA and elliptic-curve cryptography (ECC) in use almost everywhere today.

No cryptographically relevant quantum computer exists yet. The urgency comes from the harvest now, decrypt later (also written "store now, decrypt later") threat model: an attacker — a nation-state intelligence agency, for instance — can record encrypted internet traffic, VPN sessions, or stolen database exports today, store them indefinitely, and decrypt them once a capable quantum computer arrives. For data that needs to stay confidential for a long time — medical records, trade secrets, government communications, long-term financial data — "later" can still mean "too late," even if "later" is a decade away. That's why NIST, Google's Chrome team, Cloudflare and Signal all cite harvest-now-decrypt-later as their primary reason for moving on key exchange now, well before quantum computers are a practical reality.

NIST's finalized PQC standards: FIPS 203, 204 and 205

NIST ran a multi-year public competition to select quantum-resistant algorithms, starting with a call for submissions in 2016 and announcing its first selected algorithms in 2022. On August 13, 2024, NIST finalized the first three PQC standards as Federal Information Processing Standards (FIPS). NIST says these three "can and should be put into use now" and should form the foundation of most PQC deployments.

A fourth algorithm, FN-DSA (based on FALCON, formerly planned as FIPS 206), was still in draft as a second, more compact signature option. NIST also selected the HQC algorithm as a backup key-encapsulation mechanism in case a weakness is later found in the lattice-based math underlying ML-KEM. Per NIST's PQC project page, the agency's internal report NIST IR 8547 lays out a transition plan under which quantum-vulnerable algorithms like RSA and ECC are expected to be deprecated and ultimately removed from NIST's own standards by 2035, with NIST explicitly urging organizations to begin migration planning well before that date, and sooner for the highest-risk systems. For background on how cryptographic weaknesses get tracked and disclosed once they're found, see our explainer on how CVE vulnerability IDs and CVSS scores work.

ML-KEM / CRYSTALS-Kyber: the key-exchange standard everyone is rolling out first

Of the three finalized standards, ML-KEM (FIPS 203) is the one being deployed fastest, because key exchange is where the harvest-now-decrypt-later threat bites hardest — an intercepted key exchange from today can be broken retroactively. ML-KEM comes in three parameter sets — ML-KEM-512, -768 and -1024 — offering increasing security strength at the cost of larger keys and more computation. Most production rollouts so far use ML-KEM-768.

Crucially, essentially every real-world deployment uses ML-KEM in a hybrid construction, pairing it with a classical algorithm like X25519 rather than replacing classical crypto outright. The logic, as both Google's Chrome team and Cloudflare have explained in their own posts, is that an attacker would need to break both the classical and the post-quantum component to recover the key — hedging against the (currently unlikely, but not zero) possibility that a flaw is later found in the newer post-quantum math.

ML-DSA and SLH-DSA: why signatures are the harder migration

Digital signatures authenticate who sent a message or issued a certificate — they're what let your browser trust that a website's TLS certificate really belongs to that website. Unlike key exchange, a signature can't be broken "after the fact" to retroactively decrypt old traffic, so the harvest-now-decrypt-later urgency is lower here. But migrating signatures is technically harder: Google's Chrome security team has noted that ML-DSA keys and signatures run roughly 40 times larger than the ECDSA signatures used today, and a naive swap could add well over 10 KB to a single TLS handshake. That's why Cloudflare, Google and others are moving on key exchange first and treating certificate and signature migration — including the public Web PKI used for HTTPS certificates — as a longer, multi-year project still in progress.

Who's already rolling out post-quantum cryptography

PQC isn't just a NIST paper exercise — it's already shipping in production software several billion people use.

• Google Chrome: Chrome enabled a hybrid post-quantum key exchange (initially the pre-standard Kyber, paired with X25519) by default for TLS 1.3 and QUIC on desktop starting with Chrome 124, as described on Google's Chromium blog. Google has said it plans to move from the draft Kyber implementation to the finalized ML-KEM once server-side support catches up, citing harvest-now-decrypt-later ("store-now-decrypt-later," in Google's phrasing) as the motivation for prioritizing key exchange first.
• Cloudflare: Cloudflare has supported post-quantum key agreement on connections to its network since 2023 and to customer origin servers as well, and its own security blog tracks adoption of PQ key agreement across the TLS 1.3 connections it handles, calling out Chrome as the dominant source of that traffic. See Cloudflare's post-quantum cryptography blog for its technical detail on hybrid key exchange and the harder problem of post-quantum certificates.
• Signal: Signal added a post-quantum upgrade to its key-establishment protocol, called PQXDH, combining the classical X25519 exchange with CRYSTALS-Kyber. Per Signal's own announcement, PQXDH is already used for new conversations between up-to-date Signal clients, explicitly framed as a defense against harvest-now-decrypt-later.
• Apple iMessage (PQ3): Apple's own security blog post on PQ3 describes a protocol that combines Kyber (standardized by NIST as ML-KEM) with classical elliptic-curve cryptography, applying post-quantum protection not just at initial key setup but repeatedly, through an ongoing "quantum-secure" rekeying ratchet. Apple shipped PQ3 starting in iOS 17.4, iPadOS 17.4, macOS 14.4 and watchOS 10.4, and said it planned for PQ3 to fully replace the prior protocol in supported conversations during 2024.

Worth noting: these companies' own posts distinguish between protecting the key exchange (the urgent part, already largely deployed) and protecting signatures and certificates (the slower-moving part, still being worked out across the industry, including at NIST and the CA/Browser Forum that governs public HTTPS certificates).

What CISA says businesses should do

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has published its own PQC migration guidance, built around a few concrete steps rather than a hard deadline for private industry. Per CISA's guidance on post-quantum cryptography, organizations should: inventory where cryptography is actually used across their systems (CISA points to the joint CISA/NIST/NSA roadmap built around inventory, planning and risk-based migration); prioritize systems that protect the most sensitive or longest-lived data first; check whether vendors' products already support the finalized NIST algorithms; and coordinate with cloud providers and critical-infrastructure partners on timing. CISA is explicit that functioning cryptographically relevant quantum computers don't exist yet, but says organizations "must begin preparing now" given how long full migrations of this kind historically take.

What you should actually do: now versus later

For almost everyone reading this, the honest answer is that there's very little to actively do today — the migration is mostly happening underneath you, inside the software you already use. The table below breaks down what's realistic now versus what will matter more in a few years.

If your organization manages passwords, secrets or encrypted communications for a team, this is also a reasonable moment to double-check the basics are solid before layering on anything post-quantum-specific — see our comparisons of 1Password versus Bitwarden on price, passkeys and security and Proton Mail versus Tuta for encrypted email, both of which touch on how these providers are approaching long-term data protection.

Common misconceptions about PQC

A few points worth clearing up. First, "post-quantum" doesn't mean the algorithms run on quantum computers — they run on the same classical hardware as everything else; "post-quantum" describes the threat they're designed to resist, not the hardware they use. Second, PQC being finalized doesn't mean RSA and ECC are suddenly broken or unsafe to use today — NIST's own 2035 deprecation timeline reflects a long, deliberate transition, not an emergency recall. Third, adopting PQC isn't a single switch; as the rollouts above show, key exchange and digital signatures are being migrated on different timelines because they carry different levels of urgency under the harvest-now-decrypt-later threat model.

What's next for post-quantum cryptography

Expect the next phase of PQC adoption to center on the harder problems that key-exchange migration has mostly sidestepped: post-quantum digital signatures and certificates. NIST has continued work on backup algorithms (including FN-DSA, based on FALCON, and HQC as a backup key-encapsulation method), and bodies like the CA/Browser Forum still have to work out how public HTTPS certificates will eventually carry post-quantum signatures without bloating every TLS handshake. Browser vendors, cloud providers and standards bodies have described multi-year timelines for that work — treat any specific date mentioned for "when the public web fully moves to PQC certificates" as a vendor estimate, not a settled fact, since none of the primary sources checked for this piece commit to one. For now, the practical reality is that the key-exchange side of PQC — the part that defends against harvest-now-decrypt-later today — is already live in the browser, messaging app or operating system you're using, usually without you noticing.

Frequently asked questions

What does PQC stand for? PQC stands for post-quantum cryptography — cryptographic algorithms designed to remain secure against attacks from quantum computers.

Is post-quantum cryptography the same as quantum cryptography? No. Post-quantum cryptography runs on ordinary classical computers and uses math believed to resist quantum attacks. Quantum cryptography (such as quantum key distribution) is a different approach that uses quantum physics itself to secure communication.

Do I need to do anything personally to be protected? For most people, no — keeping your browser, phone OS and messaging apps updated is enough, since companies like Google, Apple and Signal are rolling PQC into their products through normal software updates.

What is "harvest now, decrypt later"? It's the practice of an attacker capturing and storing encrypted data today with the intent to decrypt it once a powerful enough quantum computer exists, which is why organizations are told to migrate before such a computer is actually built.

When will quantum computers be able to break current encryption? No organization cited in NIST's, CISA's or industry vendors' own publications gives a confirmed date — NIST's planning documents describe a deprecation timeline running through 2035 for quantum-vulnerable algorithms, which is a planning horizon, not a prediction of when a quantum computer capable of breaking encryption will exist.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage