NIST IR 8547: RSA and ECC deprecation in 2030 and 2035

NIST IR 8547 is the National Institute of Standards and Technology’s proposed schedule for retiring quantum-vulnerable public-key cryptography. RSA, finite-field Diffie-Hellman and elliptic curve algorithms (ECDH, ECDSA, EdDSA) become “deprecated” after 2030 at the 112-bit security level and “disallowed” after 2035 at every security level. Post-quantum standards such as ML-KEM replace them.

For organizations that run operational technology (OT) and critical infrastructure, these dates matter more than the headline suggests. The VPN tunnels, site-to-site links, cloud connections and remote access sessions installed today will often still be running in 2035. This article explains what the draft says, what the terms mean, and how it applies to long-lived industrial systems.

What does NIST IR 8547 say about deprecating RSA and elliptic curve cryptography?

NIST IR 8547 lists RSA, Diffie-Hellman, MQV, ECDSA and EdDSA as quantum-vulnerable and proposes two cut-off points: 2030 for algorithms at 112-bit strength and 2035 for all of them. NIST released the document in November 2024 as an initial public draft.

According to NIST’s own summary of the draft, the quantum-vulnerable set is RSA, (EC) Diffie-Hellman, MQV, ECDSA, EdDSA, and the replacements are ML-KEM, ML-DSA, SLH-DSA, LMS, XMSS. The draft covers key establishment in NIST SP 800-56A (Key establishment based on Diffie-Hellman and MQV over finite field and elliptic curves) and SP 800-56B (RSA). It also covers the signature algorithms in FIPS 186-5, which specifies RSA, ECDSA and EdDSA signatures.

NIST ties the schedule to policy: NIST IR 8547 timeline supports NSM-10 goal of transitioning USG systems to PQC by 2035. National Security Memorandum 10, issued by the White House on May 4, 2022, states the target as “with the goal of mitigating as much of the quantum risk as is feasible by 2035”.

The proposed timeline at a glance

The underlying rules are short. Algorithms at 112-bit security strength - deprecated after 2030, disallowed after 2035, and those at 128-bit and higher security strength - disallowed after 2035. The security-strength values for each key size come from NIST SP 800-57 Part 1. Symmetric cryptography is not part of the change: NIST does not expect to need to transition away from these standards as part of the PQC migration.

The draft also brings forward a change that was already planned. For years, the plan has been to transition from the 112-bit security strength to a 128-bit security strength on January 1, 2031. NIST SP 800-131A Rev. 3 (draft, October 2024) replaces that two-step path and discusses the transition from a security strength of 112 bits to a 128-bit security strength and to quantum-resistant algorithms for digital signatures and key establishment.

What is the difference between deprecated and disallowed in NIST guidance?

Deprecated means you may still use an algorithm, but the data owner accepts a documented risk. Disallowed means the algorithm may no longer be used to apply new cryptographic protection.

NIST IR 8547 takes these terms from SP 800-131A. There, Deprecated means that the algorithm and key length/strength may be used, but there is some security risk. The draft adds that the data owner must examine this risk potential and decide whether to continue to use a deprecated algorithm or key length. Disallowed means the algorithm, key length, parameter set or scheme is no longer allowed for the stated purpose. A third status, “legacy use”, covers processing data that was protected earlier, such as verifying old signatures.

Earlier versions of SP 800-131A put the risk logic plainly: if a user determines that the risk is unacceptable, then the algorithm or key length is considered disallowed, from the perspective of that user. It is the responsibility of the user or the user’s organization to determine the level of risk that can be tolerated. In practice, an operator can treat the 2031 to 2035 window as a period that needs a documented risk decision for each system, not as a safe grace period.

Will ECDH and RSA key exchange in VPNs be disallowed after 2035?

Yes, under the draft. Classical ECDH, finite-field Diffie-Hellman and RSA key exchange in IPsec, TLS-based VPNs and similar tunnels would all be disallowed for federal use after 2035. RSA-2048 and DH-2048 also become deprecated after 2030.

Most VPN key exchanges today use ECDH on NIST curves (128 bits or more) or 2048-bit Diffie-Hellman groups (112 bits). The first group skips the deprecated phase and moves straight to disallowed after 2035. The second group gets an extra five years of formal risk acceptance. The tunnel’s bulk encryption, typically AES or another approved symmetric cipher, is not affected. The handshake that produces its keys is the part that must change.

Timing is why many operators start with key exchange rather than signatures. The NSM-10 briefing material NIST presented points out that the threat to information protected by asymmetric cryptography exists now because an adversary can collect currently encrypted data and break it when sufficient quantum computation becomes available. Experts disagree on when that capability will arrive. CISA notes that estimates range from 2026 to 2041, with 2030 to 2035 being estimated as an inflection point.

Is hybrid ECDH plus ML-KEM still allowed after 2035 under NIST IR 8547?

The draft does not settle this. It treats hybrid key establishment as a transition tool, and NIST is revising SP 800-56C to formalize hybrid shared secrets. Whether ECDH remains acceptable as one component after 2035 is still an open question.

The draft states that the migration to post-quantum cryptography may initially include hybrid solutions that incorporate the use of quantum-resistant and quantum-vulnerable algorithms when establishing cryptographic keys or generating digital signatures. These hybrid solutions are typically designed to remain secure if at least one of the component algorithms is secure. It refers to the composite technique in SP 800-56C, where a classical shared secret and a second secret are concatenated and passed through an approved key derivation function.

Public commenters spotted the gap. One noted that the section proposing deprecation dates gives no guidance about hybrid schemes. NIST later listed “allowed combinations before and after PQC transition” among the main comment themes. In January 2026, NIST said it would revise SP 800-56C to allow the shared secret Z to incorporate a shared secret obtained from an approved key-encapsulation mechanism (KEM).

The practical approach is to design hybrid links so that the ML-KEM component carries the security on its own and the classical part can be removed without redesigning the system. That is cryptographic agility in a concrete form: changing the algorithm should be a configuration or software update, not a hardware replacement at every site.

How does NIST IR 8547 affect long-lived SCADA and ICS devices deployed today?

A controller, RTU or HMI commissioned in 2026 will usually still be in service after 2035. Any public-key cryptography built into its firmware will then be disallowed under NIST’s schedule, even though the device itself keeps working.

CISA has stressed this mismatch for years, describing the long replacement life cycle of ICS hardware and wide geographic distribution of equipment as a concentrated vulnerability. It also identified potential quantum risks to each of the 55 NCFs (National Critical Functions). In its 2024 OT guidance, CISA anticipates that implementing post-quantum cryptography for OT systems will be a significant and enduring challenge for owners and operators.

CISA recommends strong OT network segmentation, using quantum-resistant algorithms where appropriate, ensuring crypto-agility in applications and protocols, and applying quantum mitigation considerations to platform update schedules and upgrade lifecycles. In practice, this leads OT operators to three decisions:

• Procurement: add PQC roadmap and firmware-update questions to tenders for equipment expected to run beyond 2030. Ask specifically about ML-KEM support and whether algorithms can be swapped in the field.
• Prioritization: CISA, NSA and NIST jointly advise that prioritization should be given to high impact systems, industrial control systems (ICSs), and systems with long-term confidentiality/secrecy needs.
• Separating the transport layer: where field devices cannot be upgraded, protect the links between them at the network layer instead of waiting for firmware.

The third option is where a gateway approach fits. Quantum Network’s QPN, for example, places a gateway at each end of a site-to-site, edge-to-cloud or remote access connection. It encrypts at Layer 3 using a hybrid key agreement that combines a classical part with ML-KEM (FIPS 203), and nothing has to be installed on the PLCs or servers behind it. This protects data in transit without changing the cryptography inside the devices, and the devices themselves still need their own security measures.

Does NIST IR 8547 apply to private critical infrastructure operators or only federal agencies?

Formally, NIST transition guidance binds U.S. federal agencies. In practice, it reaches private operators through federal contracts, FIPS-validated products and sector expectations, and CISA explicitly asks private critical infrastructure to prepare now.

SP 800-131A Rev. 3 states that it is intended to provide details about the transitions associated with the use of cryptography by federal agencies to protect sensitive but unclassified information. Industry commenters on NIST IR 8547 pointed out the knock-on effect: the timelines will also impact government contractors that provide services or capabilities that must adhere to NIST or FIPS requirements. Equipment vendors that sell into federal markets also align their product roadmaps with NIST dates, so private buyers end up on the same timetable.

CISA’s position covers both sectors: government and critical infrastructure entities-including both public and private sector entities-must act now to prepare for future quantum cryptographic threats. Operators outside the United States are not bound by NIST, but many national cybersecurity agencies point to the same NIST algorithms. That makes the 2030 and 2035 dates a common planning reference for multinational OT estates.