Your Kubernetes Cluster Already Negotiates Post-Quantum TLS. Your Edge Probably Doesn't

Here is a surprise most platform teams have not caught up with: if your clusters run Kubernetes v1.33 or newer, the API server, kubelets, and controllers are quite possibly already negotiating post-quantum-secure key exchange on every TLS connection between them — and nobody on your team configured it. It arrived silently, as a side effect of a Go standard-library upgrade.

That is the good news. The rest of the stack — the ingress that terminates your tenants' traffic, the certificate pipeline that mints their custom-domain certs, the secrets encryption you assume is future-proof — is a patchwork of "already fine," "needs a version bump," and "the ecosystem isn't there yet." This post is the layer-by-layer inventory: what your self-hosted PaaS inherits for free, what needs real work, and the dated compliance clock that turns "someday" into a plan.

The one-minute readiness check​

Run this first; everything below branches off the answer:

kubectl version --output json | python3 -c "import json,sys; print(json.load(sys.stdin)['serverVersion']['gitVersion'])"

If the server reports v1.33 or newer, your control-plane TLS already prefers the hybrid post-quantum key exchange X25519MLKEM768 whenever both ends support it. Here is the full picture in one table — each row gets its section below:

Two caveats before we go deeper. First, "post-quantum" here means one specific thing is deployed: hybrid key exchange combining classical X25519 with NIST's ML-KEM-768. Nobody is suggesting your RSA certificates are already broken — a cryptographically relevant quantum computer still does not exist. Second, urgency is not uniform: key exchange must migrate before such a machine exists (attackers can record traffic today and decrypt it later), while signatures only need to be trustworthy at the moment of verification. That asymmetry drives every priority call in this post.

Two migrations, not one​

People say "the PQC migration" as if it were a single project. It is two, with different standards, different timelines, and very different blast radiuses:

NIST finalized its first three PQC standards on August 13, 2024, after an eight-year competition, then selected HQC in March 2025 as a code-based backup KEM built on different mathematics than ML-KEM's lattices. The standards layer is settled for key exchange. The signature layer has standards but, as we will see, almost no deployable certificate infrastructure yet.

For a PaaS operator, the takeaway is simple: migrate key exchange now, plan signatures for later, and never let anyone sell you a migration plan that conflates the two.

What you inherit for free: control-plane TLS​

Kubernetes' PQC story was laid out in a Kubernetes contributor-blog deep dive by Fabian Kammel in July 2025, and its central finding still surprises people: Kubernetes components are written in Go, Go 1.24 enabled X25519MLKEM768 in crypto/tls by default (February 2025), and Kubernetes v1.33 (April 2025) builds on Go 1.24. So every TLS connection between API server, kubelets, controllers, and a current kubectl negotiates hybrid post-quantum key exchange with zero configuration — provided neither side overrides Config.CurvePreferences.

One commentator called v1.33 "arguably the first major platform to ship PQC KEMs by default." As long as you stay current, the hardest part of your infrastructure got its PQC migration as a compile flag.

But "by default" has two sharp edges worth knowing about, because both fail silently:

Version skew downgrades you to classical crypto. Go 1.23 — which is what Kubernetes v1.32 builds on — shipped a draft variant, X25519Kyber768Draft00, also enabled by default. Go 1.24 removed the draft and replaced it with the finalized X25519MLKEM768. A v1.33 kubectl talking to a v1.32 API server shares no common PQC algorithm, so the handshake quietly falls back to classical X25519. Nothing errors; you just lose the quantum protection you thought you had. During any upgrade window where clients and servers straddle the v1.32/v1.33 line, assume parts of your fleet are classical-only and close the window promptly.

Oversized handshakes break brittle middleboxes. An ML-KEM-768 public key is about 1.2 KB, which pushes the TLS ClientHello past the 1,500-byte Ethernet frame — it no longer fits in a single packet. Most modern stacks fragment and reassemble without complaint, but some older middleboxes, DPI appliances, and load balancers assume a one-packet ClientHello and drop or stall the handshake.

The failure catalog at tldr.fail documents real-world cases, including Kubernetes-adjacent components. If a segment of your fleet sits behind an aging appliance, test a PQC handshake through it before you declare victory; Go exposes the tlsmlkem setting to disable the new group as an escape hatch, which tells you the ecosystem takes this failure mode seriously.

Both gotchas share a moral: the control plane gives you PQC for free, but only if you keep versions aligned and verify the path your packets actually travel.

What still needs work: the edge​

Your tenants do not connect to the API server. They connect to your ingress — envoy, nginx, Traefik, a cloud load balancer in front of your machines — and that TLS stack decides whether their traffic gets harvest-now-decrypt-later protection. This is the layer most self-hosted platforms have not audited, and it is where your leverage is highest.

The good news is that the building blocks are all available. OpenSSL 3.5 and newer, BoringSSL, GnuTLS, and NSS all negotiate X25519MLKEM768. Each ingress just needs a new-enough build with hybrid groups enabled — check your envoy or ingress-nginx version against its TLS library, not against its marketing page.

If you terminate TLS at a CDN or edge provider in front of your own machines, you may already be done: Cloudflare reports the majority of human browser traffic arriving over hybrid PQ key exchange, and Google documents staged enablement across its load balancers heading toward always-on.

The subtler question is tenant certificates. A self-hosted PaaS mints a lot of them — per-tenant custom domains via cert-manager and Let's Encrypt, internal service identities, maybe mutual TLS between tenant workloads. Every one of those is still classically signed, and that is the correct posture for now.

There is no production PQ certificate path to migrate to: ML-DSA keys run roughly 30 times the size of an Ed25519 key, PQ certificates an order of magnitude larger than classical ones, mainstream CA software has no mature issuance flow, and Go's standard library does not yet ship ML-DSA support (the Go team has called it a high priority, with optimistic estimates pointing at Go 1.26 or later). Experiments exist — Cloudflare's CIRCL library plus its cfgo fork can mint Dilithium-signed certificates — but "requires a custom Go toolchain" is another way of saying "not for your tenant pipeline."

So the edge action list is short and concrete: upgrade the terminator so hybrid key exchange negotiates, leave certificate issuance classical, and put PQ-certificate tracking on the roadmap behind a trigger ("Go stdlib + a mainstream CA both support ML-DSA issuance") rather than a date. Anyone proposing PQ tenant certs today owes you an explanation of which client on the public internet could verify them.

What still needs work: secrets and signing​

Now the layer the title promised second billing: secrets at rest. Here the verdict is refreshingly boring — your secrets encryption almost certainly needs no change.

Kubernetes encrypts secrets in etcd with AES-CBC, AES-GCM, or a KMS envelope provider, and cloud KMSes wrap those data keys in AES-256. Symmetric cryptography degrades gracefully against quantum attacks: Grover's algorithm halves effective strength, turning AES-256 into a still-formidable 128-bit equivalent. There is no harvest-now-decrypt-later cliff for properly encrypted data at rest, no algorithm migration on the horizon, and no compliance regime asking you to replace AES. The same holds for the TLS record layer itself — once the handshake negotiates a symmetric session key via a quantum-safe KEM, the bulk encryption was never the weak link.

The one real to-do in this area is hygiene you should already have: confirm you are actually using envelope encryption with a KMS provider (not the static aescbc key file), confirm 256-bit keys throughout, and confirm your etcd backups inherit the same protection. Those are classical-security basics that happen to also be your quantum posture for data at rest.

Signing and attestation sit one rung further out. The supply-chain signatures your platform produces or verifies — container image signatures, SBOM attestations, admission-controller policy checks — rely on classical algorithms (Ed25519, ECDSA) that a future quantum computer could forge. But forgery only matters at verification time, so this migrates last, after the ecosystem converges.

The early pieces are landing: AWS KMS added ML-DSA signing keys in June 2025, and Google Cloud's KMS roadmap covers the full NIST suite in software and HSM. For a self-hosted fleet, the practical move today is crypto-agility, not migration: make sure your signing pipeline can add an algorithm without a rewrite (Sigstore-style tooling already thinks this way), inventory where signatures are verified, and wait for the standards to settle into the tooling you actually run.

The compliance clock​

"Before PQC becomes the default" is not vibes — it is a published timetable, and parts of it are already ticking. Two tracks matter:

NSA CNSA 2.0 (national-security systems, but the market follows it):

• Software and firmware signing: prefer PQC since 2025, exclusive by 2030
• Web servers and cloud services: prefer since 2025, exclusive by 2033
• Network equipment (VPNs, routers): prefer by 2026, exclusive by 2030
• Operating systems: prefer by 2027, exclusive by 2033

The sharpest tooth: from January 1, 2027, newly acquired national-security systems are expected to be CNSA 2.0-compliant at procurement — miss the algorithm support and you simply do not get bought.

NIST civilian guidance (NIST IR 8547 and the transition report): classical public-key crypto deprecated for new use starting 2030, disallowed after 2035. Commercial regulators in finance and healthcare are expected to publish their own PQC guidance between 2026 and 2028 with effective dates in the early 2030s.

Map those dates onto a PaaS: the 2026 networking-equipment milestone is the one that touches your TLS terminators first. The 2027 procurement gate matters the moment any government-adjacent customer asks for your PQC posture in an RFP. And the 2030 horizon is closer than infrastructure refresh cycles suggest — certificates and firmware you ship this year with ten-year lifetimes will still be in the field when classical crypto starts getting deprecated.

None of this demands panic. It demands a dated plan, which is exactly what the checklist below is.

The operator checklist​

In priority order, for a self-hosted Kubernetes PaaS:

1. Get the fleet to v1.33+ and keep clients aligned. This single upgrade buys hybrid PQC key exchange across all control-plane TLS. Track the v1.32/v1.33 skew window explicitly — mixed Go 1.23/1.24 peers silently downgrade to classical.
2. Audit every TLS terminator for hybrid KEM support. List each place TLS terminates (ingress controllers, edge proxies, any CDN in front), record its TLS library version, and confirm X25519MLKEM768 negotiates end to end. Test through middleboxes; oversized ClientHello failures are real.
3. Leave tenant certificates classical — deliberately. Document why: no production PQ issuance path, no verifying clients, signatures migrate last. Revisit when Go stdlib and a mainstream CA both support ML-DSA. A written "not yet, and here's the trigger" beats both premature migration and unexamined drift.
4. Verify secrets-at-rest is 256-bit envelope encryption. KMS provider, 256-bit keys, encrypted backups. No algorithm change needed — this row of the table is already green, so confirm it and move on.
5. Build crypto-agility into signing, then wait. Inventory image and attestation signing; prefer tooling that can add ML-DSA without a rewrite. When the ecosystem converges, you will slot the algorithm in instead of rebuilding the pipeline.

Do those five and you can answer the RFP question honestly: key exchange quantum-safe wherever it terminates, data at rest quantum-safe by construction, signatures on a tracked roadmap with a defined trigger.

The through line of this whole migration is that the boring infrastructure work — staying current, knowing your TLS terminators, writing down decisions — is the PQC strategy for most of the stack. The quantum computer gets the headlines, but the actual project is version hygiene plus one careful audit of where your handshakes terminate. Start that audit now, while the deadlines are still comfortably far away, and 2030 arrives as a non-event.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.