What the 2030 NIST PQC Deadline Actually Means for Your TLS Stack

In November 2024 NIST published IR 8547, a quiet draft document titled Transition to Post-Quantum Cryptography Standards. The draft proposed concrete deadlines for the federal government’s migration off classical public-key cryptography. The numbers in it are the reason your TLS roadmap for the next five years just got rewritten.

These are NOT a marketing reading of an aspirational guidance document. They are NIST’s own proposed timeline for the cryptographic algorithms that protect ~every TLS handshake on the internet today. The draft entered public review on 2024-11-12, closed comment on 2025-01-13, and is on track to become final NIST guidance during 2026. CNSA 2.0, the parallel National Security Systems mandate from NSA, points the same direction with even tighter ratchets for classified-adjacent systems (see the CNSA 2.0 Cybersecurity Information Sheet). NIST IR 8547 is the civilian-sector echo of CNSA 2.0.

If your stack is going to be alive in 2030, and almost every TLS-terminating service we look at today was designed to be, you have five years to make every key exchange in it post-quantum. Federal contractors have it written into the procurement contract; everyone else will have it written into the SOC 2 report by 2028 because that’s how SOC 2 evolves. Pick your timeline.

This post is the operational answer to “what does that actually require?” It is the second in our PQC series; the first covered the implementation side. This one is for the CISO or security architect who has been told “we need to be PQC-ready” and is staring at a TLS termination layer that has no idea what ML-KEM means.

1. What's actually getting deprecated

The cleanest summary of NIST IR 8547’s algorithm table is this: every public-key primitive your TLS stack uses today appears on it.

2. Where every gateway fails the 2030 test today

Pull up a packet capture of one TLS 1.3 handshake from any gateway you operate. The ClientHello carries a supported_groups extension that enumerates the key-share groups the client is willing to use. Look at what is there. For >99% of HTTPS deployments in production today, you will see only classical groups, every one on the deprecation list:

supported_groups:
  - x25519                   # NIST IR 8547: deprecated 2030
  - secp256r1 (P-256)        # NIST IR 8547: deprecated 2030
  - secp384r1 (P-384)        # NIST IR 8547: deprecated 2030

The server picks one, the handshake completes, the session key is derived from a primitive on the deprecation list. Every byte of that TLS session is on a 2030 clock. The ones you don’t see, and which need to be there by 2030, are the hybrid PQ groups Chrome 131+ already negotiates by default:

  - X25519MLKEM768           # hybrid, IETF codepoint 0x11EC
  - MLKEM768                 # pure PQ, post-2030 default

If your gateway can’t speak hybrid post-quantum today, meaning Chrome 131+ clients silently downgrade to X25519 when they connect, you don’t have a PQC migration plan. You have a 2030 problem.

3. The three costs of waiting

A 5-year deadline feels like a lot. Three forces compress that into ~24 months of actual runway.

4. What a real PQC migration touches

“Just enable hybrid PQ” sounds like a config-flag flip. The actual migration touches five layers of your stack, and each has independent risks.

5. Where Scrutari fits

Our gateway is a multi-tenant Rust-based TLS terminator that ships with hybrid X25519MLKEM768 enabled by default. Every TLS handshake completes with the same hybrid key exchange Chrome 131 already negotiates, no opt-in, no flag, no separate “PQ mode.” The implementation details (rustls 0.23 + aws-lc-rs + quinn) are in our companion post on building the gateway; the operational point for this post is that we removed the “should we enable PQ?” decision from your migration plan entirely.

The reason this matters operationally is that our gateway sits before your existing TLS terminator. You point a CNAME at our edge, hand us your domain, and we terminate hybrid PQ on the public side while forwarding plain-TLS (or even plain HTTP, if your backend lives on a trusted network) to your existing infrastructure. Your application doesn’t change; your existing nginx / Envoy / ALB doesn’t change; your customers’ browsers start negotiating hybrid PQ on the next visit. The migration window for the key-exchange layer collapses from “rewrite your TLS termination” to “update your DNS.”

The cert-chain migration (§4.2) is separately on our roadmap and will follow public-CA PQ signature support as it ships. Our AI Insights daily briefing surfaces the per-tenant ratio of hybrid-PQ vs classical handshakes in a daily report, so you can watch the migration happen across your client fleet without spinning up your own observability stack.