When do RSA and ECDSA stop being allowed?

Under NIST's proposed transition (NIST IR 8547, initial public draft, November 2024), quantum-vulnerable public-key algorithms — RSA, ECDSA, ECDH and finite-field Diffie-Hellman — become deprecated after 2030 and disallowed after 2035 for systems that follow NIST rules. Deprecated means still allowed with restrictions; disallowed means no longer approved. Hybrid modes that pair a classical algorithm with ML-KEM or ML-DSA are not caught by the 2035 disallowance, which is what makes a gradual migration possible.

What is Korea's post-quantum timeline?

According to the National Intelligence Service plan as reported in 2025–2026, post-quantum readiness enters the public-sector cybersecurity assessment from 2027. For key encapsulation, verification targets are selected in January 2027, verified in January 2028, and installation becomes mandatory in January 2029. For digital signatures, targets are selected in January 2028 and installation becomes mandatory two years later. The national target for completing the transition is 2035. The mandatory steps apply to validated cryptographic modules, so a public website's TLS is an indicator of progress rather than the regulated item itself.

If 2035 is the deadline, why act now?

Because the risk for key exchange starts before the deadline. Anything encrypted today can be recorded and stored, then decrypted once a capable quantum computer exists. Data that must stay confidential for ten years is already exposed if it travels over classical key exchange today. That's why browsers and CDNs switched key exchange to hybrid ML-KEM years ahead of any rule, while certificates can wait.

Post-Quantum Migration Timeline: 2027

Problem

You keep seeing dates — 2027, 2029, 2030, 2035 — attached to “post-quantum,” and they don’t obviously refer to the same thing. Some are national rules, some are standards, some are what browsers already do. For a team that runs public websites and APIs, the question is simpler: which of these dates actually changes what we need to do, and in what order?

The dates, side by side

When	What	Who it binds
Aug 2024	NIST publishes FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)	The algorithms everyone else references
Nov 2024	Chrome 131 offers X25519MLKEM768 by default	Every site visited by Chrome users
Nov 2024	NIST IR 8547 draft: quantum-vulnerable algorithms deprecated after 2030, disallowed after 2035 (hybrid exempt)	Systems following NIST rules
Aug 2026	RFC 10024 standardizes hybrid ML-KEM key agreement for TLS 1.3, with X25519MLKEM768 as the recommended group	TLS implementations
2027	Korea: post-quantum readiness enters the public-sector cybersecurity assessment; KEM verification targets selected (Jan)	Korean public institutions
Jan 2028	Korea: KEM verification; signature verification targets selected	Validated cryptographic modules
Jan 2029	Korea: KEM installation mandatory	Validated cryptographic modules
Jan 2030	Korea: signature installation mandatory (two years after target selection)	Validated cryptographic modules
2030 / 2035	NIST deprecates / disallows classical-only public-key algorithms	Systems following NIST rules
2035	Korea: national transition target	Public-sector cryptography

The Korean milestones follow the NIS plan as reported in ZDNet Korea and Dataeconomy; NIST’s dates are from the IR 8547 draft.

What’s already true on the web

The rules lag the traffic. Cloudflare reported in September 2026 that about 70% of browser traffic reaching its network already used hybrid ML-KEM — but only about 15% of origin servers did on the connection from Cloudflare back to them. In other words: the visitor side of the internet has largely switched, and the server side mostly hasn’t. If your site sits behind a CDN, your visitors are probably protected to the edge while the hop to your own server is not.

What a public website should switch first

Key exchange, now. It protects recorded traffic, the browsers already ask for it, and turning it on is a configuration change on a current TLS stack (OpenSSL 3.5+, Go 1.24+). This is the item every date above points toward, and the only one with a “harvest now, decrypt later” cost for waiting.
TLS 1.3 everywhere. Hybrid groups don’t exist in TLS 1.2. Any endpoint still capped at 1.2 has to move first.
An inventory of where your crypto lives. Public TLS is the part you can see from outside. VPNs, databases, service-to-service links, code signing and firmware are where the long work is — and where the Korean module mandates actually land.
Certificates, later. No public CA issues post-quantum certificates yet. Track your chain’s signature algorithms so you know what to replace when they arrive, but don’t block on it.

Diagnose with DechoNet

Post-Quantum TLS check shows where a public endpoint stands today: hybrid key exchange yes/no, whether your server or a CDN edge provides it, TLS version and the chain’s signature algorithms. Watch the domain from the result to keep a dated record of when support was switched on — useful evidence when someone asks for your migration progress.
SSL Check covers the classical basics of the same endpoint — certificate validity, chain and protocol versions — which need to be clean before any of the above matters.

Resolution Checklist

List your public endpoints (web, API, mail submission) and test each for hybrid key exchange.
Separate CDN edge results from origin results; the origin leg is the usual gap.
Move every endpoint to TLS 1.3 and a stack that supports ML-KEM (OpenSSL 3.5+ / Go 1.24+).
Start a crypto inventory for what external checks can’t see: VPN, DB, internal TLS, signing.
Record the signature algorithms in your chains so certificate replacement is a lookup, not a hunt.
Re-check on a schedule and keep the dates — regulators ask for progress over time, not a single snapshot.

When to Escalate

If you’re a Korean public institution preparing for the 2027 assessment, the external TLS result is supporting evidence, not the assessment itself; the module-level requirements go through your cryptographic module vendor and the published NIS guidance.
If a vendor product in your chain (load balancer, WAF, hosting panel) can’t negotiate ML-KEM, get its roadmap in writing — that’s the dependency most likely to set your real timeline.
For the step-by-step check and the configuration lines for nginx, Apache and Go, see Post-Quantum TLS Check.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.