# NIST Post-Quantum Standards
The 2024 publication of FIPS 203, FIPS 204, and FIPS 205 marks the first time the United States federal government has standardized cryptographic algorithms specifically designed to resist attacks from quantum computers. These standards exist because the public-key algorithms underpinning virtually all encrypted communications today, including RSA, ECDH, and ECDSA, are mathematically vulnerable to Shor's algorithm running on a sufficiently powerful quantum computer. The standards replace those algorithms across key establishment and digital signature functions, giving agencies, contractors, and commercial operators a concrete, federally validated migration target. The problem they solve is not hypothetical: adversaries are already collecting encrypted traffic today with the intent to decrypt it once quantum capability matures, a strategy known as harvest-now-decrypt-later.
---
NIST Post-Quantum Standards are the cryptographic algorithm specifications published by the National Institute of Standards and Technology following a multi-round public evaluation process that began in 2016. The three initial Federal Information Processing Standards are FIPS 203, which specifies ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism); FIPS 204, which specifies ML-DSA (Module-Lattice-Based Digital Signature Algorithm); and FIPS 205, which specifies SLH-DSA (Stateless Hash-Based Digital Signature Algorithm). A fourth standard based on FALCON, designated FN-DSA, was in final draft stages as of 2024.
These standards are distinct from post-quantum cryptography research generally. PQC research encompasses dozens of candidate families, including code-based, multivariate, isogeny-based, and lattice-based schemes. The NIST standards are the subset that passed years of public cryptanalysis and were formally standardized for federal use. They are not quantum key distribution (QKD), which is a hardware-based key exchange approach using photon transmission. QKD is a separate technology category with different deployment constraints and no current federal mandate.
The standards also do not address symmetric encryption. AES-256 and SHA-384 or higher are considered quantum-resistant under current analysis because Grover's algorithm, the relevant quantum threat to symmetric schemes, only halves effective key length, meaning AES-256 retains approximately 128-bit security against quantum adversaries. The NIST PQC standards specifically target asymmetric operations: key exchange, key encapsulation, and digital signatures. Hybrid deployment, where a classical algorithm and a PQC algorithm run in parallel, is explicitly supported and encouraged during the transition period to guard against both classical and quantum attacks simultaneously.
---
Each of the three standards addresses a different cryptographic function, and each uses a distinct mathematical foundation with specific operational characteristics.
FIPS 203: ML-KEM (Key Encapsulation)
ML-KEM is used to establish shared secrets between two parties. It is based on the hardness of the Module Learning With Errors (MLWE) problem, a variant of the lattice problem that has resisted both classical and quantum attacks in public analysis. The mechanism works as follows: the recipient generates a public-private key pair. The sender uses the recipient's public key to encapsulate a randomly generated shared secret, producing a ciphertext. The recipient decapsulates that ciphertext using the private key to recover the same shared secret. Neither party transmits the shared secret directly. The output is a symmetric key that can then drive AES or another symmetric cipher for bulk data encryption.
ML-KEM specifies three parameter sets. ML-KEM-512 targets security roughly equivalent to AES-128. ML-KEM-768 targets AES-192 equivalent security. ML-KEM-1024 targets AES-256 equivalent security. Key sizes are notably larger than elliptic curve equivalents. An ML-KEM-768 public key is 1,184 bytes, compared to 32 bytes for Curve25519. This has practical implications for TLS handshakes, certificate sizes, and constrained environments such as IoT devices or smart cards.
A concrete deployment scenario: a federal agency running a TLS 1.3-based VPN gateway begins a hybrid key exchange where the client and server each run both X25519 and ML-KEM-768. The shared secrets from both are combined using a key derivation function. The session key is resistant to both a classical adversary breaking elliptic curve discrete log and a quantum adversary running Shor's algorithm. This hybrid approach is supported in IETF drafts and is the recommended migration path for TLS deployments while the ecosystem matures.
FIPS 204: ML-DSA (Digital Signatures)
ML-DSA replaces RSA and ECDSA for general-purpose digital signatures. It is also lattice-based, using the Module Learning With Errors and Short Integer Solution problems. The signing process generates a signature by computing a response to a challenge derived from the message hash and a random nonce, using the signer's private key and a masking polynomial to prevent key leakage. Verification checks the response against the public key and the challenge.
ML-DSA-44, ML-DSA-65, and ML-DSA-87 correspond to the three security levels. Signature sizes range from 2,420 bytes for ML-DSA-44 to 4,627 bytes for ML-DSA-87. For comparison, a P-256 ECDSA signature is 64 bytes. This size increase affects any system that stores, transmits, or processes large numbers of signatures: code signing pipelines, certificate chains, firmware update servers, and timestamping services all require capacity planning adjustments. The standard specifies both a randomized and a deterministic signing mode; the deterministic mode requires careful implementation to avoid fault attacks.
A practical example: a defense contractor signs firmware images for embedded systems deployed in field hardware. Migrating from RSA-2048 to ML-DSA-65 means firmware signing scripts, verification libraries, and storage allocations all change. The contractor must test that existing bootloaders can handle the larger signature payloads and that verification latency remains acceptable on the target hardware.
FIPS 205: SLH-DSA (Hash-Based Signatures)
SLH-DSA is the standards' diversity option. Unlike ML-DSA, its security does not rest on lattice hardness assumptions. Instead, it relies solely on the collision resistance and preimage resistance of cryptographic hash functions, which are among the oldest and most thoroughly analyzed assumptions in cryptography. This makes SLH-DSA a conservative fallback if a future breakthrough weakens lattice-based schemes.
SLH-DSA generates signatures using a hypertree of few-time signature schemes (FORS) combined with Winternitz one-time signatures (WOTS+). The stateless construction means signers do not need to track which keys have been used, solving a critical operational problem present in earlier stateful hash-based signature schemes like XMSS. The tradeoff is large signature sizes: SLH-DSA-128s produces signatures of approximately 7,856 bytes in the small-signature configuration, while the fast configuration produces larger signatures to reduce computation time.
Implementation guidance in FIPS 205 addresses randomized versus deterministic signing and specifies the exact domain separation needed to prevent cross-protocol signature forgery.
---
The operational consequence of not migrating is straightforward: encrypted data and authenticated communications protected by RSA or ECDSA become retroactively readable and forgeable once a cryptographically relevant quantum computer (CRQC) exists. Government and intelligence community estimates place the timeline for a CRQC at anywhere from eight to fifteen years, though uncertainty is high. The harvest-now-decrypt-later threat compresses that timeline from a planning perspective because the exposure window for sensitive data often extends decades. A classified document encrypted today with RSA-2048 and collected by an adversary today will be decryptable whenever the adversary's quantum capability matures, regardless of when that is.
The real-world consequence of delayed migration is already visible in the policy pressure building around legacy systems. In 2022, the White House issued NSM-10, directing agencies to inventory cryptographic systems and begin migration planning. In 2023, OMB Memorandum M-23-02 established timelines for agencies to report and prioritize systems using quantum-vulnerable cryptography. Federal agencies that have not begun cryptographic inventory have no baseline from which to plan migration, meaning they are already behind the policy curve before the technical migration work begins.
A common misconception is that post-quantum migration is purely a future problem that can be deferred until quantum computers are closer to operational. This is wrong for two reasons. First, cryptographic infrastructure has long replacement cycles. Replacing PKI root certificates, updating embedded firmware, renegotiating supplier contracts for compliant HSMs, and retraining development teams each take years. Second, data with long-term sensitivity is already at risk today due to harvest-now-decrypt-later collection. Deferring migration is not a neutral choice; it is an acceptance of that risk.
Another misconception is that adopting PQC algorithms requires replacing all cryptography at once. The hybrid deployment model explicitly endorsed in NIST guidance and IETF standards allows incremental rollout, maintaining compatibility with classical endpoints while protecting sessions with quantum-resistant keys.
---
CDA addresses NIST Post-Quantum Standards through the Regulatory and Governance Assurance (RGA) domain of the Planetary Defense Model, with execution supported by the Data Protection and Sovereignty (DPS) domain where key management and data classification intersect. The governing methodology is Perpetual Compliance Assurance (PCA), which treats compliance as a continuous operational state rather than a point-in-time audit result.
In practice, PCA applied to post-quantum migration means CDA does not wait for a federal deadline to trigger action. The cryptographic inventory is a living artifact maintained in the client's governance environment, updated whenever new systems are deployed, new vendors are onboarded, or certificate renewals occur. Every system that uses asymmetric cryptography is tagged with its algorithm, key size, certificate expiration, and a migration priority score based on data sensitivity and exposure duration.
CDA's approach is operationally specific in several ways that distinguish it from generic compliance consulting. First, CDA maps cryptographic dependencies to data flows, not just to system inventories. A system that encrypts data at rest with AES-256 but exchanges keys over RSA-2048 is flagged as quantum-vulnerable even though its bulk encryption is quantum-resistant. Second, CDA tracks HSM vendor roadmaps alongside FIPS algorithm publication, because algorithm compliance without hardware support is not deployable compliance. Third, CDA integrates migration milestones into existing change management workflows rather than treating PQC migration as a separate program, reducing the organizational friction that causes migration projects to stall.
For clients subject to CMMC Level 2 or Level 3, CDA maps PQC requirements to the existing control framework, identifying where cryptographic controls in NIST SP 800-171 will require algorithm-specific updates as CMMC guidance evolves to incorporate post-quantum expectations. The goal is not to run parallel compliance programs but to extend existing assurance structures to absorb the new requirements without duplication.
---
---
---