← All articles

NIST's 2030 Post-Quantum Deadline: What Your Team Needs to Do Now

In November 2024, NIST published Internal Report 8547, "Transition to Post-Quantum Cryptography Standards." It is the first formal NIST document to set hard deprecation deadlines for the asymmetric algorithms that protect virtually every internet transaction today: RSA, ECDSA, ECDH, and DH. The headline dates: 2030 (deprecated for new uses) and 2035 (disallowed entirely). For federal systems and any vendor in the federal supply chain, those dates are now binding.

If you operate any system that touches U.S. federal data, processes payments, handles regulated healthcare or financial information, or sells into the European market under NIS2 or DORA, the 2030 deadline is closer than it looks. It's not 4 years to a goal — it's 4 years to complete migration, which means about 18-24 months to plan, design, and start, plus 24-30 months to roll out and validate.

This article walks through what NIST IR 8547 actually requires, how it intersects with CNSA 2.0 and other regulatory frameworks, and what your team should be doing this quarter, this year, and through 2030.

What NIST IR 8547 actually says

NIST IR 8547 establishes a transition timeline for cryptographic algorithms that will be broken by sufficiently large quantum computers. The specific dates depend on the algorithm and use case:

Algorithm	Use case	Deprecated	Disallowed
RSA (≥ 2048-bit)	Digital signatures	After 2030	After 2035
RSA (≥ 2048-bit)	Key establishment	After 2030	After 2035
ECDSA	Digital signatures	After 2030	After 2035
ECDH	Key establishment	After 2030	After 2035
EdDSA	Digital signatures	After 2030	After 2035
DH (finite-field)	Key establishment	After 2030	After 2035

"Deprecated" in NIST language means: still allowed to use, but discouraged, and any new system MUST be designed for migration. "Disallowed" means: cannot be used for any security purpose in federal systems or systems sold to federal customers.

The replacements are the three NIST PQC standards finalized in August 2024:

• FIPS 203 — ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism, derived from CRYSTALS-Kyber). Replaces RSA, ECDH, and DH for key establishment.
• FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm, derived from CRYSTALS-Dilithium). Replaces RSA, ECDSA, and EdDSA for digital signatures.
• FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, derived from SPHINCS+). Conservative alternative to ML-DSA when you want signature security based purely on hash function strength.

How NIST IR 8547 interacts with CNSA 2.0

NIST IR 8547 isn't the only post-quantum mandate. The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) is the binding standard for U.S. national security systems and the contractors that supply them. CNSA 2.0 is more aggressive than IR 8547:

Year	CNSA 2.0 milestone
2025	New equipment must support PQC algorithms (ML-KEM-1024, ML-DSA-87, SLH-DSA, SHA-384/512, AES-256)
2027	Software/firmware in use must support PQC; new procurements must use it as default
2030	All RSA, ECC, and Diffie-Hellman use must end in NSS environments

If your organization sells into the U.S. defense, intelligence, or national security supply chain — directly or as a subcontractor — CNSA 2.0 is binding through your contracts. Even if you don't, expect CNSA 2.0 timelines to flow downstream into FedRAMP, StateRAMP, and DoD CMMC requirements over the next 24 months.

Other regulatory frameworks pulling in the same direction

NIST and NSA aren't operating in a vacuum. The same migration is required (with slightly different framing) by other major regulators:

• PCI DSS 4.0 (March 2025 in force) requires payment processors to maintain a cryptographic inventory and assess quantum-vulnerable algorithms. By 2027, formal quantum risk assessments are expected as part of regular PCI audits.
• EU NIS2 Directive (transposed into national law in 2024-25) requires "essential and important entities" to implement appropriate cryptographic measures; ENISA guidance explicitly references PQC migration as part of this.
• EU DORA (Digital Operational Resilience Act, in force January 2025) requires financial entities to manage cryptographic key lifecycles and respond to evolving threats — quantum being the named example in implementing technical standards.
• HIPAA Security Rule update (proposed 2024) explicitly references the need for cryptographic agility and PQC migration for protected health information.
• UK GDPR enforcement guidance notes that "appropriate technical measures" for personal data must account for foreseeable threats including quantum capabilities.

The pattern: every major data-protection regulator is now either explicitly requiring PQC migration or interpreting existing rules to require it. The 2030 deadline isn't just NIST's deadline. It's a global regulatory convergence.

What your team needs to do now (the quarter-by-quarter plan)

Migration is a multi-year program. Here's a realistic phased plan starting from Q2 2026:

Q2-Q3 2026: Discovery and inventory

Goal: produce a Cryptographic Bill of Materials (CBOM) for your entire stack.

• List every TLS endpoint (external and internal mTLS).
• List every X.509 certificate, including key type, signature algorithm, expiry, and issuer.
• List every cryptographic library version in use (OpenSSL, BoringSSL, libsodium, language stdlib crypto).
• List every signing operation (code signing, document signing, JWT signing, webhook signing).
• List every key encapsulation use (TLS, IPsec, SSH, message-level encryption like JWE/JWS).
• Use the CycloneDX 1.6 CBOM format for the deliverable — this becomes a feedable artifact for compliance and downstream tools.

Tools that help: SBOM scanners (Syft, CycloneDX CLI), TLS scanners (QVS, SSL Labs, testssl.sh), package auditors. For internal services, a static-analysis pass over code looking for crypto-library imports gives you the rest.

Q4 2026: Triage and prioritization

Goal: rank every finding by risk and migration effort.

Risk is a function of:

• Data confidentiality lifetime. Anything that needs to remain confidential beyond 2030 is at risk from harvest-now-decrypt-later attacks today.
• Compliance exposure. Federal contracts, payment systems, and regulated industries have the hardest deadlines.
• Blast radius. Forging a code-signing certificate compromises every user; forging a single API token compromises one customer.

Migration effort is a function of:

• Library support. Hybrid TLS in OpenSSL 3.5+ is 2-4 hours of config. Replacing custom RSA-based protocols can be months.
• Certificate authority readiness. Public CAs won't issue ML-DSA certificates broadly until 2027-2028. Internal CAs you control can do it today.
• Backward compatibility constraints. Hybrid mode handles this well; full migration to ML-DSA-only signatures cannot happen until your client population is ready.

Q1-Q2 2027: Hybrid TLS rollout

Goal: every external and internal TLS endpoint negotiates hybrid post-quantum key exchange.

• Upgrade to OpenSSL 3.5+ or BoringSSL with PQC support across all servers.
• Enable X25519MLKEM768 as the preferred key exchange group.
• Keep RSA/ECDSA certificates for now — only the key exchange changes in this phase.
• Re-scan all endpoints quarterly and track the percentage of connections negotiating hybrid PQC.

Q3 2027 - Q4 2028: Signature migration begins

Goal: pilot ML-DSA in production for internal signing operations.

• Code signing — start issuing ML-DSA signatures alongside existing RSA/ECDSA (dual signing).
• Internal mTLS — issue ML-DSA certificates from your internal CA.
• JWT/JWS — many libraries now support ML-DSA via the EdDSA-style API; pilot it for service-to-service auth.
• Webhook signing (Stripe, GitHub, custom) — coordinate with vendors on PQC signature support.

2029: Full external migration

Goal: be ready to switch from RSA/ECDSA certificates to ML-DSA when public CAs make them broadly available.

• Test certificate automation pipelines (cert-manager, Let's Encrypt clients) with ML-DSA.
• Audit and update key management systems (HSMs, KMS) for PQC support.
• Run dual-signature pilots with public-facing systems.

2030: NIST IR 8547 deadline

Goal: no new RSA/ECDSA/ECDH/DH for signing or key exchange in any system you control.

By this point, hybrid PQC should be the default everywhere, ML-DSA signatures should be in production for high-value signing, and you should have a documented exception process for any remaining classical-only system with a closure plan.

What happens if you miss the deadline

For federal systems and CNSA 2.0-bound contractors: failed audits, contract loss, and remediation orders. For PCI DSS 4.0: failed assessments and the fines that come with non-compliance. For EU NIS2 / DORA: regulatory penalties up to a percentage of annual revenue.

For everyone else: the more dangerous failure mode is silent. Quantum computers don't announce their arrival with a press release. The first sign that RSA-2048 is broken in practice will likely be the disclosure of a successful attack on real-world infrastructure — and at that point, the migration window is no longer 4 years, it's 4 weeks. Anyone not already in late-stage migration will be in panic mode.

The bottom line

NIST IR 8547 made the post-quantum migration timeline official. CNSA 2.0 made it binding for federal systems. PCI DSS 4.0, NIS2, and DORA are pulling the same direction in the financial and infrastructure sectors. The 2030 deprecation deadline is real, the 2035 disallowance deadline is enforceable, and most organizations are dramatically behind the planning curve.

The good news: the technical path is clear, the standards are finalized, the libraries are ready, and the operators who have already started (Cloudflare, Apple, Google, Signal, OpenSSH, AWS) have proven the migration is feasible. The work in front of you is operational, not research.

Start with discovery. Get a CBOM. Get a baseline. Build the plan. Four years sounds like a long time. It isn't.

Related reading: Why Your TLS Will Break by 2030 · Is Your Website Quantum Safe? · When Will Quantum Computers Break RSA?