Post-Quantum TLS Migration Checklist: The 2026 Work That Can't Wait for 2030

Most post-quantum TLS migration checklist articles are written about 2030 and about quantum computers that do not exist yet. That framing is why so many platform teams have done nothing. The work that bites you in 2026 has nothing to do with cryptanalysis. Your FIPS 140-2 module validations expire this month, your cloud load balancer already offers post-quantum key agreement that your Terraform is quietly refusing, and the first team in your company to turn on hybrid handshakes will file a ticket about mysterious connection timeouts. We have walked clients through this. The cryptography is the easy part.

The deadline that lands this month has nothing to do with quantum computers

On September 21, 2026, NIST moves every FIPS 140-2 validation certificate to the Historical list. Modules on that list can keep running in existing systems. They are not valid for new ones. If you sell into federal, healthcare, or finance, the question on next quarter's security questionnaire is whether your crypto modules are FIPS 140-3 validated, and a Historical certificate is not an answer.

Separately, Executive Order 14412, signed June 22, 2026, sets dates that reach past federal agencies. High value assets and high impact systems move to post-quantum encryption by December 31, 2030, and to post-quantum signatures by December 31, 2031. Federal contractors have to comply with post-quantum FIPS standards by December 31, 2030. Contractor obligations flow downhill into subcontractor and vendor requirements, which is how a 2030 date becomes a 2027 procurement conversation.

| Date | What changes | Who it binds | |---|---|---| | Sep 21, 2026 | FIPS 140-2 certificates move to the Historical list | Anyone claiming FIPS-validated crypto in new systems | | Dec 31, 2030 | Post-quantum encryption required for high value and high impact systems | Federal agencies and their contractors | | Dec 31, 2031 | Post-quantum digital signatures required for the same systems | Federal agencies and their contractors | | After 2035 | Quantum-vulnerable public-key algorithms disallowed | Direction set by NIST IR 8547, still an initial public draft |

The standards themselves have been settled for two years. FIPS 203, the Module-Lattice-Based Key-Encapsulation Mechanism Standard, was published August 13, 2024 and defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024. ML-DSA and SLH-DSA followed as FIPS 204 and 205. There is nothing left to wait for on the algorithm side.

Inventory every place you terminate TLS, before you touch a cipher list

The single most common failure we see is a team that enables hybrid key agreement on the public CDN, declares the migration done, and never discovers the seventeen other places their traffic gets decrypted and re-encrypted. Do not start with configuration. Start with a list.

Walk the path of a request and write down every hop that holds a private key: the CDN, the external load balancer, the ingress controller, the service mesh sidecars, the internal load balancers, the database proxy, the message broker, the outbound forward proxy, and every vendor appliance doing TLS inspection. Then add the things that are not request paths at all, because those are the ones that get missed: VPN concentrators, mTLS between microservices, S3 and object storage endpoints, code signing keys, SSH host and user keys, and any long-lived certificate authority you run yourself.

Rank the list by how long the data stays sensitive. Traffic crossing the public internet carrying data that matters in ten years goes first, because that is what an adversary can record today and decrypt later. Internal east-west traffic on a private network is a lower priority than most vendors will tell you it is. A session token that expires in an hour is not worth a migration sprint.

| Hop | Typical PQ readiness in 2026 | Priority | |---|---|---| | CDN and public edge | Supported, often on by default | Do first | | Cloud L7 load balancer | Supported via an opt-in security policy | Do first | | Ingress controller / NGINX | Supported with OpenSSL 3.5 | Do second | | Service mesh mTLS | Depends on the proxy build | Do second | | TLS-inspecting appliances | Frequently the blocker | Test early, budget for replacement | | Code signing and internal CA | Signature algorithms not ready | Plan, do not migrate yet |

Turn on hybrid key agreement at the edge first

Hybrid key agreement derives the session secret from both a classical algorithm and ML-KEM, so the connection holds unless both are broken. The group everyone has standardized on is X25519MLKEM768. Apart from the middlebox problem covered two sections down, there is no downside to enabling it on public endpoints, and it is the only part of this migration that protects traffic recorded today from being decrypted later.

Adoption is already well past the early stage. Cloudflare reports that over two-thirds of browser traffic to its network is protected with post-quantum encryption. Your browser is almost certainly negotiating it right now.

For NGINX, this is one directive, and you need OpenSSL 3.5 or newer for native support:

server {
  listen 443 ssl;
  ssl_protocols TLSv1.3;
  ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;
}

Keep the classical groups in the list. Clients that do not support the hybrid group fall back rather than fail. Verify what was negotiated instead of trusting the config:

# Requires an OpenSSL 3.5+ client. Look for the negotiated group in the output.
openssl s_client -connect example.internal:443 -groups X25519MLKEM768 </dev/null 2>&1 \
  | grep -i 'Negotiated TLS1.3 group'

If that line comes back as X25519 instead of X25519MLKEM768, something between you and the server stripped or rejected it, and that something is worth finding.

Your Terraform-provisioned load balancers are not getting the post-quantum default

AWS added post-quantum key exchange to Application and Network Load Balancers on November 21, 2025, in all commercial regions, GovCloud, and China, at no additional cost. Thirteen security policies now carry a PQ marker, including FIPS variants. They support X25519MLKEM768 and SecP256r1MLKEM768.

Here is the trap. The AWS documentation on load balancer security policies states that the default policy depends on how the listener was created. Create it in the console and you get ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09. Create it with the CLI, CloudFormation, or the CDK and you get ELBSecurityPolicy-2016-08.

Every load balancer your platform team provisions as code is defaulting to a ten-year-old policy with no post-quantum support. Meanwhile the one an engineer clicked together in the console last week is quantum-safe. Teams audit the console, see the PQ policy, and conclude they are covered.

Set it explicitly and stop relying on defaults:

resource "aws_lb_listener" "https" {
  load_balancer_arn = aws_lb.public.arn
  port              = 443
  protocol          = "HTTPS"
  certificate_arn   = aws_acm_certificate.public.arn

  # Without this line the provider default is ELBSecurityPolicy-2016-08.
  ssl_policy = "ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.app.arn
  }
}

Then write a policy check that fails the build when ssl_policy is absent or does not contain -PQ-. This is the same class of silent default we wrote about in Terraform security best practices for AWS, and it is worth a Conftest or Checkov rule rather than a wiki page nobody reads.

To see what your account actually offers:

aws elbv2 describe-ssl-policies \
  --query 'SslPolicies[?contains(Name, `-PQ-`)].Name' \
  --output text

What breaks is the ClientHello that no longer fits in one packet

This is the section that gets skipped, and it is the reason post-quantum rollouts get reverted.

ML-KEM keys are large. Adding them to the TLS handshake pushes the ClientHello past the size a lot of network software silently assumed it would be. The Go project hit this squarely: when Go 1.27 began advertising ML-KEM and ML-DSA by default, the ClientHello grew to roughly 1,467 bytes and started stalling through middleboxes, producing net/http: TLS handshake timeout against gateways that had worked for years.

The mechanism is ordinary and boring. Plenty of load balancers, firewalls, and TLS-inspecting appliances were written expecting the entire ClientHello in the first packet. Once it spans two, they look for the end of a message that has not arrived, and they either hang or drop the connection. Nothing logs an error about post-quantum anything. You get timeouts.

Plan for it the way you would plan any change that can take down ingress:

1. Enable hybrid groups on one low-traffic public endpoint and leave it for a week.
2. Watch handshake failure rate and p99 handshake latency. Error rate alone will not show you this, because a retry storm hides inside a healthy-looking 200 rate.
3. Test explicitly through every corporate VPN, inspection proxy, and partner network your traffic crosses. These are where the old appliances live.
4. Keep the rollback to a single config value and know who can apply it at 2am.

For Go services that need to call an endpoint behind a broken middlebox while you fix it, the escape hatch is setting CurvePreferences explicitly rather than turning off TLS 1.3. Treat that as a temporary exception with a ticket attached, not a standard.

Signatures are the part that is not ready, and you should not force it

Key agreement protects against recorded traffic being decrypted later. Signatures protect against forged identity, and a quantum computer that can forge a certificate has to exist before that matters. The threat models are different, and so is the tooling maturity.

Do not migrate your certificate authority, your code signing, or your SSH host keys to post-quantum signatures this year. Public CAs are not issuing ML-DSA certificates for general use, the chain sizes are awkward, and you would be building a bespoke trust path you then have to operate. We would not recommend it to a client.

What we would do now is inventory and shorten. Find every long-lived key: root CAs with a fifteen-year validity, code signing certificates, firmware signing keys, anything embedded in a device you cannot easily update. Those are the migrations that take years, and they are the ones EO 14412's December 2031 signature date is really about. Shortening certificate lifetimes and proving you can rotate a root on demand is worth more than any algorithm change you could make today, and it pays off whether or not the quantum timeline holds.

The 90-day sequence we would run

| Phase | Weeks | What you do | Done looks like | |---|---|---|---| | Inventory | 1 to 3 | Enumerate every TLS termination point and every long-lived key, with an owner per row | A list your CISO can read, ranked by data sensitivity lifetime | | Edge enablement | 4 to 6 | Hybrid groups on CDN and public load balancers, one endpoint at a time | openssl s_client confirms X25519MLKEM768 on every public hostname | | Codify | 7 to 9 | Explicit ssl_policy in every IaC module, plus a policy check in CI | A pull request that omits a PQ policy fails the build | | Interior and appliances | 10 to 12 | Ingress controllers and mesh proxies rebuilt on OpenSSL 3.5, appliance vendors given a written deadline | A named replacement plan for anything that cannot do hybrid |

Three things deliberately sit outside the ninety days: signature migration, internal CA replacement, and anything embedded. Those belong in a roadmap with budget, not a quarter.

If FIPS validation is the driver rather than the quantum timeline, the sequencing changes. You go looking for FIPS 140-3 validated modules and the FIPS-PQ policy variants first, and the edge work follows. That is a compliance project with a cryptography component, closer in shape to the EU Cyber Resilience Act work than to a platform upgrade. The identity and segmentation groundwork in our zero trust implementation guide covers the key inventory this depends on.

When to Get Help

Enabling a hybrid group on a CDN takes an afternoon. Knowing which of your forty TLS termination points can take it, which appliance vendor is going to stall, and which long-lived keys will still be in production in 2031 takes an inventory nobody has time to build. The teams that get burned are the ones that changed a cipher list before they had that list, and spent a night chasing handshake timeouts that no dashboard explained.

We help platform teams run this as a sequenced project: inventory first, edge enablement with a real rollback, IaC defaults fixed so the next load balancer is correct by construction, and an honest roadmap for the signature work that cannot happen yet. If you are staring at a security questionnaire asking about post-quantum readiness and do not know what to write, talk to us.