What is Post-Quantum Cryptography (PQC)? Explained

What Post-Quantum Cryptography is

Post-Quantum Cryptography (PQC) — sometimes called quantum-safe or quantum-resistant cryptography — is the term for public-key algorithms whose security does not depend on problems a large-scale quantum computer could solve efficiently. It is not quantum cryptography (which uses quantum physics itself for security, e.g. QKD). PQC runs on ordinary classical computers using ordinary silicon — it just uses different underlying math from RSA and elliptic-curve cryptography.

NIST kicked off a global standardisation competition in 2016 and, after multiple rounds, published the first PQC standards in August 2024:

Standard	Algorithm	Use
FIPS 203	ML-KEM (formerly Kyber)	Key encapsulation — replaces RSA-OAEP and ECDH for key exchange
FIPS 204	ML-DSA (formerly Dilithium)	Digital signatures — replaces RSA and ECDSA for general signing
FIPS 205	SLH-DSA (formerly SPHINCS+)	Hash-based signatures — conservative alternative to ML-DSA
FIPS 206	FN-DSA (formerly Falcon)	Compact lattice-based signatures — draft published 2025

Additional algorithms — HQC (code-based KEM as a Kyber backup) and any second-round signature winners — are working through NIST at different paces.

Why it matters

RSA and elliptic-curve cryptography are secure because factoring large integers and computing discrete logarithms are computationally hard on classical computers. In 1994 Peter Shor showed that a sufficiently large quantum computer could solve both problems in polynomial time. A "cryptographically relevant quantum computer" (CRQC) — one large and stable enough to run Shor's algorithm on real key sizes — does not exist yet. Public estimates for when one might exist range from "roughly 2035" (US NSA CNSA 2.0 planning horizon) to "later, if ever" (skeptics).

The problem is that many of today's encrypted communications will still be sensitive when a CRQC arrives. Attackers with the means to store bulk encrypted traffic today can decrypt it later once a quantum computer becomes available. This is called Harvest Now, Decrypt Later (HNDL), and it is why the migration timeline is measured from today, not from the CRQC arrival date.

The most urgent categories:

Long-lived confidentiality (state secrets, medical records, IP).
Root-of-trust certificates and code-signing keys whose validity windows extend past the CRQC horizon.
IoT devices with 10-20 year field lifetimes that will still be deployed when quantum arrives.
Financial and payments infrastructure with regulatory expectations of long-term forward secrecy.

The migration mandate

Regulators have started to specify timelines:

US CNSA 2.0 (NSA, 2022) — federal systems must be using PQC for long-lived data by 2030 and exclusively PQC by 2033 for national security systems. New systems should be PQC-native from 2025.
CNSA 2.0 hash requirement — SHA-384 is mandated as the minimum hash for national-security PQC deployments, driving multi-bank TPM support for SHA-256 + SHA-384 concurrent quotes.
UK NCSC — published a PQC migration roadmap in 2024 targeting 2035 for full migration.
EU Cybersecurity Act / CRA — expected to reference PQC as part of "state of the art" cryptography for critical infrastructure by 2027.
BSI Germany — has published a formal PQC migration guidance document (TR-02102-1).

Regulatory intent aside, the operational reality is that migrating a large PKI takes years. Discovering every cert, replacing every dependency, updating every client library, and negotiating cross-vendor compatibility does not happen quickly.

What migration actually involves

A realistic PQC migration is a multi-year programme with these phases:

Inventory. Discover every algorithm in use — every cert, every JWT signing key, every TLS termination, every code-signing key, every HSM slot. Categorise by criticality and remaining validity horizon.
Crypto agility. Refactor code and infrastructure so that swapping an algorithm is a configuration change, not a rewrite. Most legacy code hard-codes RSA or ECDSA in ways that make PQC insertion painful.
Hybrid deployment. Deploy PQC alongside classical algorithms (hybrid X.509 certs, hybrid TLS 1.3 key exchange). This preserves classical security guarantees during the transition while proving PQC works in production.
PQC-only for new systems. Once tooling is mature, new certificates and keys default to PQC.
Classical retirement. Old classical-only systems are decommissioned or migrated. This is the longest phase.

Different systems will move at different speeds. Symmetric cryptography (AES-256, SHA-384) is already considered quantum-resistant enough with sufficient key sizes and does not require replacement. Public-key cryptography is where the work is.

Common misconceptions

"Quantum computers do not exist, so PQC does not matter yet." Encrypted data harvested today will be decryptable later. The migration deadline is when a CRQC exists; the start deadline was several years ago.

"PQC replaces AES." No. Symmetric encryption (AES) and hash functions (SHA) are affected by Grover's algorithm, which offers only a square-root speedup — doubling key sizes (AES-256 instead of AES-128, SHA-512 instead of SHA-256) is enough. Shor's algorithm is what breaks RSA and ECC; PQC replaces those.

"ML-KEM is a signature algorithm." ML-KEM is a Key Encapsulation Mechanism — it produces a shared secret two parties can use for symmetric encryption. ML-DSA and SLH-DSA are the signature algorithms.

"Bigger keys are all we need." RSA-16384 does not save you — Shor's algorithm scales gracefully. Only algorithms based on genuinely different hard problems (lattices, hashes, codes, isogenies, multivariate) provide quantum resistance.

"Post-quantum means quantum-key-distribution." QKD is a separate technology using quantum physics for key exchange. It requires special hardware and dedicated fibre. PQC is what runs on your existing servers. NIST, NSA, and NCSC all recommend PQC over QKD for general use.

"We can wait until the standards are final." The main FIPS standards are final. Vendors have started shipping. Waiting further is a policy choice, not a technical constraint.

Signature and key sizes to plan for

PQC objects are noticeably larger than their classical counterparts. Plan for this in bandwidth-constrained environments (IoT, embedded, low-power radio):

Algorithm	Public key	Signature or ciphertext
RSA-2048	256 B	256 B signature
ECDSA P-256	64 B	64 B signature
ML-DSA-65	~1,952 B	~3,309 B signature
SLH-DSA-128s	~32 B	~7,856 B signature
ML-KEM-768	~1,184 B	~1,088 B ciphertext

For TLS handshakes over LTE-M, LoRaWAN, or NB-IoT the size increase can materially affect protocol design. Hybrid designs may need multi-fragment handshakes; some use cases will prefer SLH-DSA (smaller public key, larger signature) or ML-DSA (larger public key, smaller signature) depending on which side has bandwidth budget.

How TigerTrust approaches PQC

TigerTrust treats PQC as a lifecycle problem: you cannot migrate what you cannot see. The platform's discovery layer inventories algorithms across cert fleets so operators know exactly which systems are still on RSA and ECDSA, and where the CNSA 2.0 SHA-384 hash requirement is not yet met. Issuance supports the NIST-standardised algorithms and hybrid certificate profiles as they mature in upstream libraries and browsers. For TPM-attested deployments, TigerTrust supports concurrent SHA-256 and SHA-384 PCR quotes so operators can start meeting CNSA 2.0's minimum-hash requirement without waiting for a full fleet firmware refresh. Full detail on TigerTrust's PQC readiness at PQC and CNSA 2.0.

Post-Quantum Cryptography (PQC)