Post-Quantum Cryptography: NIST Standards and Transition Planning

Post-quantum cryptography (PQC) encompasses the cryptographic algorithms and transition frameworks designed to remain secure against adversaries equipped with large-scale quantum computers. The National Institute of Standards and Technology (NIST) completed its first standardization round in 2024, publishing three initial post-quantum standards and initiating a migration timeline that affects federal agencies, critical infrastructure operators, and private-sector organizations handling long-lived encrypted data. This page covers the algorithm families NIST selected, the mechanics underlying their quantum resistance, the regulatory and compliance landscape governing migration, and the classification boundaries that distinguish PQC from related fields such as quantum key distribution.


Definition and scope

Post-quantum cryptography refers to classical (non-quantum) cryptographic algorithms whose underlying mathematical problems are believed to resist attacks from both conventional and quantum computers. The scope is distinct from quantum cryptography, which exploits quantum mechanical properties directly. PQC algorithms run on standard silicon hardware and require no quantum communication channel.

The threat driving PQC adoption is Shor's algorithm, published by mathematician Peter Shor in 1994, which demonstrates that a sufficiently powerful quantum computer can factor large integers and compute discrete logarithms in polynomial time. This breaks the two dominant public-key families in use: RSA and elliptic curve cryptography. Grover's algorithm provides a quadratic speedup against symmetric ciphers, effectively halving their bit-security — meaning AES-128 would operate at 64-bit effective security against a quantum adversary, while AES-256 retains approximately 128-bit quantum security.

NIST's post-quantum standardization project, initiated formally in December 2016, evaluated 69 candidate algorithms across two categories: key encapsulation mechanisms (KEMs) and digital signature schemes. The scope of affected systems includes public key infrastructure, TLS/SSL protocols, digital signatures, and any protocol relying on Diffie-Hellman or RSA key exchange.


Core mechanics or structure

The four algorithm families NIST advanced to standardization or finalist status differ in their mathematical hardness assumptions:

Lattice-based cryptography underpins the largest share of NIST-selected algorithms. Security rests on the hardness of problems such as Learning With Errors (LWE), Module-LWE, and the Shortest Vector Problem (SVP) in high-dimensional lattices. NIST finalized two lattice-based standards in August 2024: ML-KEM (FIPS 203), derived from the CRYSTALS-Kyber submission, and ML-DSA (FIPS 204), derived from CRYSTALS-Dilithium.

Hash-based signatures rely solely on the security of cryptographic hash functions. SLH-DSA (FIPS 205), derived from SPHINCS+, uses a stateless hash-based construction. Its security assumption is among the most conservative available — no algebraic structure is exploited. The tradeoff is signature sizes that range from approximately 8 KB to 50 KB depending on parameter selection.

Code-based cryptography grounds security in the hardness of decoding random linear codes (the McEliece problem, dating to 1978). Classic McEliece was a NIST alternate candidate; its key sizes (public keys exceeding 250 KB in standard parameters) have limited deployment feasibility.

Multivariate polynomial cryptography bases security on solving systems of multivariate quadratic equations over finite fields (the MQ problem). NIST's FALCON algorithm (now FN-DSA under FIPS 206) is technically lattice-based via NTRU lattices, not multivariate, but produces compact signatures (approximately 666 bytes for the 512-bit variant).

Each FIPS document specifies permitted parameter sets, test vectors, and implementation requirements. FIPS 203, 204, and 205 are available at the NIST Computer Security Resource Center.


Causal relationships or drivers

The urgency of PQC migration is shaped by the "harvest now, decrypt later" threat model: adversaries can intercept and store encrypted traffic today, then decrypt it once a cryptographically relevant quantum computer (CRQC) becomes operational. Classified and long-lived data — government records, health data, financial contracts — face retrospective exposure even if a CRQC does not exist at the time of encryption.

National Security Memorandum 10 (NSM-10), signed in May 2022, directed federal agencies to migrate to post-quantum cryptography on a defined timeline, with the Cybersecurity and Infrastructure Security Agency (CISA) and NIST jointly responsible for migration guidance. The Office of Management and Budget (OMB) subsequently issued Memorandum M-23-02, requiring agencies to inventory cryptographic systems and prioritize migration of high-value assets.

NIST's Cybersecurity Practice Guide SP 1800-38 (under development via the National Cybersecurity Center of Excellence) addresses crypto-agility — the architectural property of being able to swap algorithms without redesigning entire systems. Crypto-agility is treated as a prerequisite for managed migration rather than a one-time cutover.

The quantum threats to encryption landscape is further complicated by the absence of a confirmed timeline for a CRQC. Estimates from sources including the IBM Quantum roadmap and academic projections range from 10 to 20 years for fault-tolerant quantum systems capable of running Shor's algorithm at cryptographically relevant scale, but this uncertainty does not reduce migration urgency given the harvest-now threat vector.


Classification boundaries

PQC occupies a specific position within the broader cryptographic taxonomy:

PQC vs. quantum key distribution (QKD): QKD (e.g., BB84 protocol) uses quantum mechanical properties to distribute keys over optical fiber or free-space links. QKD is a hardware-dependent physical-layer solution with range and infrastructure constraints. PQC is software-implementable on classical hardware. NIST's position (NIST IR 8413) explicitly does not endorse QKD as a replacement for PQC in federal systems.

PQC vs. symmetric encryption: Symmetric algorithms like AES-256 are not broken by Shor's algorithm. Grover's algorithm reduces security by a square-root factor, meaning AES-256 retains approximately 128 bits of quantum security. PQC migration is primarily directed at asymmetric and key exchange components, not bulk encryption. Encryption key management frameworks must account for which layers require algorithm substitution.

PQC vs. hybrid schemes: Hybrid cryptography combines a classical algorithm (e.g., ECDH) with a PQC KEM in parallel, using both shared secrets to derive a session key. Hybrid schemes are transitional: they preserve security if either algorithm remains unbroken, which is relevant during the period when PQC algorithm confidence is still maturing.

Signature vs. KEM applications: ML-KEM addresses confidentiality and key exchange. ML-DSA and SLH-DSA address authentication and integrity. These are not interchangeable functions. Digital certificate ecosystems require PQC signature adoption independently of PQC key exchange.


Tradeoffs and tensions

Performance overhead: Lattice-based KEMs introduce larger key and ciphertext sizes relative to ECDH. ML-KEM-768 produces a 1,184-byte public key and 1,088-byte ciphertext, compared to 32 bytes for X25519. This increases handshake overhead in TLS and similar protocols. For constrained IoT environments (see IoT device encryption), these sizes can saturate memory budgets.

Algorithm confidence and standardization timeline pressure: CRYSTALS-Kyber, Dilithium, and FALCON have undergone approximately 6 years of public cryptanalysis since submission in 2017. By contrast, RSA has been analyzed for over 45 years. The shorter cryptanalytic track record is a genuine concern — not a reason to delay migration, but a reason to prefer hybrid deployments in the near term.

Stateless vs. stateful signatures: Hash-based signatures such as XMSS and LMS (standardized in NIST SP 800-208) are stateful, meaning the signer must track state across signature operations to avoid key reuse. SLH-DSA avoids this but at the cost of larger signature sizes. Stateful schemes carry operational risk if state management fails.

Crypto-agility debt: Systems hardcoded to specific algorithm identifiers (e.g., TLS cipher suites not negotiating algorithm type dynamically) cannot swap algorithms without significant re-engineering. Legacy protocol stacks in financial infrastructure and industrial control systems represent the highest friction migration targets.


Common misconceptions

Misconception: quantum computers already break current encryption.
No publicly documented cryptographically relevant quantum computer exists as of the NIST finalization of FIPS 203-205 in 2024. Current quantum systems (including IBM's 1,000+ qubit processors) lack the error correction required to execute Shor's algorithm at cryptographic scale. The threat is prospective, not present — but data encrypted today remains at risk.

Misconception: upgrading to AES-256 is sufficient for PQC compliance.
AES-256 addresses symmetric bulk encryption. It does not address the key exchange and authentication layers, which rely on RSA or ECDH/ECDSA. A system using AES-256 with an RSA-2048 key exchange is quantum-vulnerable at the key exchange layer. Complete PQC migration requires replacing asymmetric components regardless of symmetric key length.

Misconception: FIPS 203-205 are optional guidance documents.
For federal agencies subject to FISMA, NIST FIPS publications carry mandatory status once OMB and agency policy adopt them. NSM-10 and M-23-02 have set binding migration deadlines for federal systems. Non-federal entities subject to sector-specific regulations (HIPAA, PCI-DSS) face indirect obligations as those frameworks reference NIST standards. See FIPS 140 encryption standards for the broader mandatory FIPS framework.

Misconception: QKD solves the post-quantum problem.
QKD addresses only key distribution over direct optical links. It does not provide authentication independently and cannot be deployed in software across arbitrary internet paths. NIST's NISTIR 8413 explicitly categorizes QKD as outside the scope of the PQC standardization project for federal use.


Checklist or steps (non-advisory)

The following phases represent the migration framework structure described in NIST SP 1800-38 and OMB M-23-02. These are process phases, not prescriptive professional advice.

  1. Cryptographic inventory — Identify all systems, protocols, and data stores using asymmetric cryptography. Catalog algorithm types, key lengths, certificate authorities, and protocol versions. Prioritize by data sensitivity and lifespan.

  2. Risk prioritization — Classify assets by exposure to harvest-now threats. Long-lived sensitive data (classified records, health data, financial contracts exceeding 10-year retention) represent highest priority. Short-lived transactional data represents lower near-term risk.

  3. Crypto-agility assessment — Evaluate whether protocol stacks and libraries support algorithm negotiation. Identify hardcoded algorithm dependencies in custom applications, embedded firmware, and hardware security modules (see hardware security modules).

  4. Algorithm selection — Map use case to NIST-selected algorithm. KEMs: ML-KEM (FIPS 203). General-purpose signatures: ML-DSA (FIPS 204). Constrained or stateless hash-based signatures: SLH-DSA (FIPS 205). Hash-based stateful alternatives: XMSS/LMS (SP 800-208).

  5. Hybrid deployment — For high-value systems, deploy hybrid classical/PQC schemes during the transition window. Standardize on a defined sunset date for purely classical key exchange.

  6. Library and dependency updates — Update cryptographic libraries to versions with FIPS 203-205 support (e.g., OpenSSL 3.x branches with OQS integration, BoringSSL with hybrid KEM support, or FIPS-validated modules as listed in the CMVP).

  7. Certificate infrastructure migration — Coordinate PQC certificate issuance with certificate authorities. Monitor CA/Browser Forum guidance on PQC certificate profiles as they develop.

  8. Testing and validation — Run interoperability tests against NIST test vectors (available in FIPS 203-205 appendices) and cross-vendor test environments maintained by the Open Quantum Safe (OQS) project.

  9. Documentation and audit trail — Record algorithm transitions, deprecation timelines, and exception approvals. Federal systems document this under FISMA authorization-to-operate (ATO) processes.

  10. Ongoing monitoring — Track NIST post-quantum standardization rounds (a 4th round for additional signature algorithms is active) and adjust algorithm selections as new standards finalize.


Reference table or matrix

Algorithm FIPS Designation Type Hardness Assumption Public Key Size Signature/Ciphertext Size Primary Use
ML-KEM-512 FIPS 203 KEM Module-LWE 800 bytes 768 bytes Key encapsulation (lower security)
ML-KEM-768 FIPS 203 KEM Module-LWE 1,184 bytes 1,088 bytes Key encapsulation (NIST recommended)
ML-KEM-1024 FIPS 203 KEM Module-LWE 1,568 bytes 1,568 bytes Key encapsulation (higher security)
ML-DSA-44 FIPS 204 Signature Module-LWE/SIS 1,312 bytes 2,420 bytes Digital signatures (Category 2)
ML-DSA-65 FIPS 204 Signature Module-LWE/SIS 1,952 bytes 3,293 bytes Digital signatures (Category 3)
SLH-DSA-128s FIPS 205 Signature Hash function security 32 bytes 7,856 bytes Stateless hash-based signatures
SLH-DSA-256f FIPS 205 Signature Hash function security 64 bytes 49,856 bytes Stateless hash-based, fast verify
FN-DSA-512 FIPS 206 Signature NTRU lattice 897 bytes ~666 bytes Compact signatures
XMSS SP 800-208 Signature Hash function security Variable Variable Stateful hash-based (limited operations)
Classic McEliece NIST Round 4 alt KEM Code decoding (Goppa) >250 KB ~128 bytes High-assurance KEM, large key contexts

Sizes are approximate and parameter-set dependent. Refer to FIPS 203-206 specifications for normative values.


References

Explore This Site