NIST's 2035 Post-Quantum Deadline

In August 2024, NIST finalized the first three post-quantum cryptographic standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). The standards are published. The algorithms are specified. The timeline is set. And it is more aggressive than most organizations realize.

What CNSA 2.0 Actually Says

The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) defines specific milestones for National Security Systems:

By 2025: Begin transition planning. Organizations should have a migration strategy.
By 2030: All key establishment must use ML-KEM. All firmware and software signing must use ML-DSA or SLH-DSA. RSA, ECDH, and ECDSA are disallowed for these purposes.
By 2033: All NSS software and firmware must exclusively use CNSA 2.0 algorithms.
By 2035: Classical asymmetric cryptography is fully deprecated. Every RSA key, every ECDH exchange, every ECDSA signature must be replaced.

Why 2035 Is Closer Than It Sounds

Cryptographic migrations don't happen in months. They happen in years. Consider what a typical migration involves: inventorying every cryptographic component across every system, assessing quantum vulnerability for each, planning replacements in dependency order, testing hybrid configurations, updating certificates and key management infrastructure, redeploying across production environments, and verifying that nothing breaks.

The Y2K comparison is apt — not because post-quantum migration is a simple date change, but because the scale is similar and the deadline is firm. Organizations that started Y2K remediation in 1999 suffered. Organizations that started in 1996 succeeded.

The Scale of the Problem

Every RSA key in your infrastructure is quantum-vulnerable. Every ECDH key exchange. Every ECDSA signature. Every DH parameter negotiation. This includes TLS certificates, SSH host keys, VPN configurations, code signing certificates, JWT signing keys, API authentication tokens, S/MIME email signing, DNSSEC, and more.

A typical enterprise might have hundreds or thousands of individual cryptographic component instances. Each one needs to be identified, assessed, and either replaced or confirmed as quantum-safe.

Step 1: Know What You Have

You cannot migrate what you cannot enumerate. The first step is generating a complete Cryptographic Bill of Materials (CBOM) — a machine-readable inventory of every cryptographic component deployed across your infrastructure. This means scanning source code, parsing configuration files, inventorying certificates, querying cloud KMS services, and documenting hardware crypto modules.

Step 2: Assess Quantum Vulnerability

Not every cryptographic component is quantum-vulnerable. AES-256, SHA-256, and other symmetric/hash algorithms remain secure against quantum attacks (with Grover's algorithm halving effective security, but 128-bit post-Grover security for AES-256 is sufficient). The urgent targets are asymmetric algorithms: RSA, ECDH, ECDSA, EdDSA, DH, DSA.

Step 3: Plan Migration in Dependency Order

You can't replace a cipher suite until the replacement certificate is deployed. You can't deploy a new certificate until the CA infrastructure supports ML-DSA. You can't update the CA until your HSMs support post-quantum algorithms. Dependencies dictate migration sequence.

What Organizations Should Do This Year

Generate a CBOM. Use automated scanning to inventory all cryptographic components. The CBOM specification provides the format.
Identify quantum-vulnerable components. Filter your CBOM for asymmetric algorithms.
Assess crypto agility. Determine which components can be updated via configuration vs. which require code changes.
Start hybrid deployments. Begin testing ML-KEM + X25519 hybrid key exchange on non-critical systems.
Engage vendors. Ask your HSM, cloud, and security vendors about their PQC roadmaps.

The specification is available at cbom.io/spec. Start with visibility. Start now.