The NIST Post-Quantum Standards Era: What Security Leaders Need to Know

In August 2024 NIST published the first three finalized post-quantum cryptography (PQC) standards. For security leaders this changed the conversation from "if" to "when and in what order." This article summarizes what was standardized, what the proposed deadlines say, and how to turn that into a plan with owners and budget.

What NIST standardized

NIST has also been working on additional standards: a draft for FN-DSA (based on Falcon) for compact signatures, and in 2025 it selected HQC as a backup key-encapsulation algorithm based on different mathematics than ML-KEM. Check NIST's project page for current status, because drafts and final dates move.

The proposed timeline

NIST's draft report IR 8547, published in November 2024 as an initial public draft, proposes that quantum-vulnerable public-key algorithms (RSA, ECDSA, EdDSA, ECDH and finite-field Diffie-Hellman) at the 112-bit security level be deprecated after 2030, and that all such algorithms be disallowed after 2035. Because it is a draft, wording and dates can change, and it formally governs US federal systems. But it is already the reference point many vendors, auditors and procurement teams use. Separately, the NSA's CNSA 2.0 sets earlier dates for national security systems, depending on system category.

For a private-sector organization the dates matter in two ways: they predict when vendors will drop classical-only options, and they bound how long you have to finish a migration that, in large environments, takes years.

Why act before a quantum computer exists

The main driver is not a specific machine but data lifetime. If information must remain confidential for 10 to 25 years (health records, source code, trade secrets, government data), then anything captured in transit today and stored by an adversary is exposed once a capable quantum computer appears. That risk is explained in Harvest Now, Decrypt Later. Digital signatures are a separate and later concern: a forged signature can only be used when it is created, so signatures matter most for long-lived roots of trust such as firmware keys and certificate authorities.

A leadership checklist

1. Appoint an owner. PQC migration cuts across networking, application teams, PKI, procurement and compliance. Without one accountable owner it stalls.

2. Fund discovery first. You cannot plan what you cannot see. A cryptographic inventory (CBOM) is the first deliverable; the method is in Building a Cryptographic Inventory.

3. Classify by data lifetime and exposure. Rank systems by how long their data must stay secret and how exposed their traffic is. Internet-facing TLS carrying long-lived sensitive data comes first.

4. Put it in vendor contracts. Ask SaaS, HSM, VPN and CDN vendors for their PQC roadmap and support dates. Make it a renewal criterion.

5. Require crypto-agility in new builds. Systems built now should treat algorithms as configuration, not constants (crypto-agility patterns).

6. Plan for hybrid. Hybrid key exchange pairs a classical and a post-quantum algorithm, which is the low-risk path while the new algorithms accumulate real-world scrutiny. See Hybrid TLS.

Common mistakes

• Waiting for final dates. Inventory and agility work is useful regardless of how deadlines shift.
• Treating it as a TLS-only problem. Signing keys, VPNs, SSH, S/MIME, code signing, database encryption keys and HSM firmware all use public-key cryptography.
• Ignoring third parties. Your exposure includes every provider that terminates or stores your encrypted data.
• Assuming symmetric crypto needs replacement. AES-256 and SHA-384 remain fine; focus the budget on public-key algorithms.

What to report to the board

A short status with four numbers is usually enough: percentage of systems inventoried, number of systems using quantum-vulnerable key exchange, number of vendors with a published PQC roadmap, and the target date for enabling hybrid key exchange on external endpoints. The goal is steady, measurable progress rather than a single deadline.