What Is NIST's Timeline for Deprecating RSA and ECC, and What Should Enterprises Do Before 2030?
.png)
Under NIST IR 8547, RSA, ECDSA, EdDSA, and Diffie-Hellman key exchange are deprecated after 2030 and disallowed after 2035. Executive Order 14412, signed on June 22, 2026, sets earlier federal dates: December 31, 2030 for key exchange and December 31, 2031 for signatures. Federal agencies must meet these dates ahead of NIST’s 2035 cutoff, and the order directs the FAR Council to propose a rule requiring covered federal contractors to comply with NIST’s post-quantum standards by December 31, 2030. Companies that sell to the government should expect these requirements to flow to them. For most companies, the real deadline comes well before 2035.
What NIST IR 8547 Deprecates and Disallows
NIST IR 8547 is the transition plan that accompanies the post-quantum standards NIST published in 2024. Deprecated means an algorithm is still allowed but carries accepted risk, and disallowed means it can no longer be used to protect data. The report names RSA, ECDSA, EdDSA, and Diffie-Hellman because each depends on integer factoring or discrete logarithms, which Shor's algorithm solves on a sufficiently large quantum computer. AES-256, which encrypts the bulk of network traffic, is not the target of this timeline. The exposure sits in the key exchange and signatures around it.
For key establishment, the report points to ML-KEM, the lattice-based key encapsulation mechanism in FIPS 203, with ML-KEM-768 as the default parameter set. Hybrid modes, which pair a classical exchange with ML-KEM, are described as a temporary measure. Federal agencies also face a January 2, 2030 deadline to support TLS 1.3, the version for which the hybrid ML-KEM groups are defined. Enterprises that run older TLS versions on internal services need to account for that dependency.
How the Final Report Differs From the 2024 Draft
The 2024 draft deprecated algorithms at 112-bit security strength after 2030 and disallowed all quantum-vulnerable algorithms after 2035. The final report extends the 2030 deprecation to every approved strength, which includes RSA-3072 and the P-256 curve that many enterprises treat as strong. An organization that planned to keep 128-bit-strength RSA and ECC in service until 2035 now sees a deprecated status five years sooner than the draft implied. NIST withdrew the draft when it published the final report.
How Executive Order 14412 Shortens the Federal Timeline
The order sets post-quantum key establishment by December 31, 2030 and signatures by December 31, 2031 for federal high-value assets and high-impact systems. FAR contractor compliance also targets December 31, 2030, and national security systems are excluded. NSM-10 had already pointed to 2035 as the federal migration horizon, so the NIST disallowance date works as the backstop behind these earlier deadlines. Enterprises that sell to agencies or handle federal data should treat December 31, 2030 as the working deadline.
What Enterprises Should Do Before 2030
Start by making a list of everything in your company that uses RSA, ECDSA, EdDSA, or Diffie-Hellman. These are the older encryption algorithms that NIST is phasing out. Check your apps, websites, VPNs, digital certificates, and outside vendors. Then rank the list by how long each type of data needs to stay private. Data that must stay private for many years, such as health records and proprietary IP, goes first. It is the most at risk if powerful quantum computers arrive before your upgrade is finished.
Fix how your data is protected in transit before you fix the digital signatures. Attackers can record encrypted traffic now and unlock it later, so ensure harvest-proof protection before you start any migration strategy. Update your websites and VPNs to TLS 1.3 with a quantum-safe option where your vendors support it. Plan changes to certificates and code signing around the 2031 federal date. Ask each vendor for a written quantum-safe plan with dates. When you buy new products, require that security methods can be swapped through settings instead of a full rebuild.
What the Migration Window Leaves Exposed
Even a company that finishes its upgrade on December 31, 2030 will have sent more than four years of traffic using an encryption algorithm that NIST has already marked for retirement. To protect data traversing cables between links that have not yet been updated, we built Carmel to close this gap. Carmel uses Photonic Layer Security (PLS) to protect the light signal that travels through a fiber cable. If someone taps the cable, they capture only noise instead of data they can store and unlock later.
What Carmel Does Not Cover
Carmel covers WAN fiber links only. It does not secure LAN traffic, endpoints, data at rest, or cloud workloads, and it does not replace the algorithm migration described above. Signatures, certificates, and key management still need the NIST changes, and ML-KEM remains the standard answer for key establishment. PLS ensures ongoing harvest proof protection while post-quantum cryptography updates are underway, because when there is nothing to decrypt there is nothing to harvest, not now, not ever.
Our article on how long post-quantum cryptography migration takes and what protects data in transit while it is underway covers the planning side in more detail.
FAQs
Q: When does NIST deprecate RSA and ECC?
A: NIST IR 8547 deprecates RSA, ECDSA, EdDSA, and finite-field and elliptic-curve key establishment after 2030. It disallows them after 2035. The final report, published on October 27, 2026, applies the 2030 deprecation to all approved security strengths.
Q: What is the difference between deprecated and disallowed in NIST IR 8547?
A: Deprecated means the algorithm is still allowed but carries accepted risk, and new systems should avoid it. Disallowed means it can no longer be used to protect data. The report places deprecation after 2030 and disallowance after 2035.
Q: Does the NIST timeline apply to private companies?
A: NIST standards bind federal agencies directly, and private companies are not required to follow them. Yet, Executive Order 14412 directs the FAR Council to propose a rule requiring covered contractors to comply with NIST FIPS, including post-quantum algorithms, by December 31, 2030, so that date is expected to reach private companies that sell to the government
Q: What replaces RSA and ECC for key exchange?
A: ML-KEM, defined in FIPS 203, replaces them for key establishment, with ML-KEM-768 as the default parameter set. Hybrid modes that pair a classical exchange with ML-KEM are a temporary option during the transition. Signatures move to the post-quantum signature standards NIST published alongside ML-KEM.
Q: Is AES-256 affected by the NIST deprecation timeline?
A: No. The timeline targets public-key algorithms used for key exchange and signatures. AES-256 remains an approved cipher for encrypting traffic.
Q: Is post-quantum encryption enough to protect data in transit?
A: Post-quantum encryption is necessary, and organizations should complete the migration. It takes years to deploy, and traffic recorded under the old key exchanges during that time stays recorded. Photonic Layer Security addresses that window by protecting the optical signal on the fiber, and it complements the migration.
Q: What is a cryptographic inventory?
A: A cryptographic inventory is a list of every place an organization uses cryptography, including algorithms, key sizes, certificates, protocols, and the systems and vendors involved. It shows which uses depend on RSA, ECC, or Diffie-Hellman. Teams use it to rank migration work by how long each data set must stay confidential.
Q: What is CyberRidge?
A: CyberRidge is a Photonic Layer Security company. We build Carmel, a platform that protects data traveling over fiber links between sites. Our approach is designed to stop attackers from recording that traffic in a form they can unlock later.
Q: What is Carmel?
A: Carmel is our optical security platform for WAN fiber links. It applies Photonic Layer Security (PLS) to the light signal on the fiber. A tap on the fiber captures only noise instead of traffic that can be stored and decrypted later.
Q: What is Photonic Layer Security, and how is it different from optical encryption?
A: Photonic Layer Security protects the light signal itself, so a tap on the fiber cannot capture a usable recording. Optical encryption adds another layer of encryption to the data being sent. PLS stops the recording from being usable in the first place. Where optical encryption is already in use, PLS can be added alongside it.
Q: Does Carmel replace post-quantum cryptography?
A: No. Carmel works alongside post-quantum cryptography. Signatures, certificates, and key management still need the NIST changes, and ML-KEM remains the standard answer for key exchange. Carmel protects fiber traffic while that work is underway.
Q: What does Carmel not protect?
A: Carmel covers WAN fiber links only. It does not secure LAN traffic, endpoints, data at rest, or cloud workloads. It also cannot protect traffic that was recorded before Carmel was installed.
Q: How is Carmel installed, and what speed and distance does it support?
A: Carmel installs as an overlay, using a matched pair of units, with no changes to existing DWDM equipment. Deployment takes weeks. Carmel runs at 100–400 Gb/s uplink and reaches up to 100 km unamplified, and it works with EDFA and Raman amplification.