DEV Community: Paulo Victor Leite Lima Gomes

A vulnerability report is not a bug ticket

Paulo Victor Leite Lima Gomes — Wed, 16 Sep 2026 14:00:20 +0000

It is 16:47 on a Friday.

The report does not arrive in the security inbox. It arrives in a public GitHub issue, or worse, in the community Slack, or a DM to whoever was last active on the repo. It is written by someone who clearly knows what they are doing. There is a payload. There is a reproduction. There is a version number, and it is the version you shipped to production last week.

And it is public.

By 17:05 you have three problems, not one. There is a vulnerability. There is a disclosure control failure. And there is a small group of people trying to decide, in real time, who is allowed to read the thread, who owns the fix, and whether the person who found it is going to publish on Monday regardless of what you say.

That last part is not a security problem. It is an operations problem.

SECURITY.md is the front door, not the process

Most projects that "have disclosure" have a SECURITY.md with an email address and a sentence about responsible disclosure. Maybe a PGP key. Maybe a 90-day quote lifted from a blog post.

That is a front door. A door is not a building.

CNCF published a handling vulnerability reports recipe card in September 2026 aimed exactly at small and medium projects without a security team. It is good guidance, and it is honest about scope: it covers the policy artifacts. The hard part is not the policy text. The hard part is that a policy document does not decide who gets woken up, who has write access to the private fix branch, or who signs off on the advisory wording.

GitHub gives you private vulnerability reporting and repository security advisories with private forks, private discussion, CVE requests, and coordinated publication. OpenSSF's vulnerability disclosures working group publishes templates and runbooks. CISA has a disclosure policy template. FIRST has an entire PSIRT services framework.

The tooling exists. The templates exist. And teams still improvise the moment a real report lands, because none of that tells you who owns triage at 16:47 on a Friday.

My take:

a vulnerability report is not a bug ticket. It is an operational event with a clock attached.

The clock is the entire point. A bug can sit in a backlog for a quarter. A vulnerability report starts an embargo, and an embargo is a countdown that a stranger is holding.

the first 24 hours decide everything

The first 24 hours determine whether this becomes engineering work or organizational panic. Panic looks like: a dozen people pulled into a call, three half-fixes started in parallel, a draft advisory circulating in a doc that is not access-controlled, and public speculation while nobody has confirmed impact.

The output of the first 24 hours should be small and boring:

Acknowledged. The reporter knows a human received it, and knows approximately when they will hear more.
Contained. The report is in a private channel, not a public issue, and comments are frozen in the public place if it leaked there.
Owned. One named person owns the report until it closes. Not a team. A person.
Classified. Initial severity, affected versions, and exploitability — provisional is fine, unstated is not.
Scheduled. A tentative disclosure date, communicated to the reporter.

If you cannot produce those five things within a day, your SECURITY.md is marketing.

the intake contract

Intake is where most processes quietly fail, because the reporting path is whatever channel the reporter happens to find. You cannot fix that by asking nicely. You fix it by making the intended path obviously the best one.

One canonical intake. Private vulnerability reporting enabled on the repo, plus a monitored security address for people who do not want to use GitHub. Both routed to the same place.
Say what happens next on the page. "We acknowledge within 3 business days, we triage within 5, we will tell you our severity assessment and target disclosure window." A reporter who knows the timeline argues less about the timeline.
Require evidence, not drama. Affected version or commit, component, reproduction steps or PoC, observed impact, and whether the reporter has shared it anywhere else. That last question matters more than people expect.
Restrict the audience from the start. A security alias that forwards to a 40-person engineering mailing list is not a private channel. It is a leak with extra steps.
Assume reports will land in public anyway. Someone will file the issue publicly. Have a canned response that moves the conversation without confirming exploitability, and a moderator who can lock the thread fast.

The intake contract is not about gatekeeping researchers. It is about making sure the first person who reads the report is the right person.

the triage contract

Triage is where "vulnerability" and "bug" get separated, and it is the step AI is currently making harder.

A working triage decision answers five questions:

Is this a vulnerability or a robustness bug? A crash on malformed input is not automatically a security issue. An auth bypass is, even if the user must already be authenticated.
What is the impact if exploited? Confidentiality, integrity, availability, or privilege boundary crossed. Be specific about which boundary.
How exploitable is it really? Does it require a local attacker, an authenticated tenant, a non-default configuration, or a specific race window? Severity without exploitability context is a number nobody can act on.
Which versions are affected, and which are supported? Fixing an unsupported version is a gift, not an obligation. Say so early.
What does the reporter hear, and when? A triaged report always gets a reply with the assessment, even when the assessment is "not a vulnerability, here is why."

That last point is the one teams skip, and it is the cause of most hostile disclosures. Researchers escalate when they are ignored, not when they are told no.

the embargo contract

An embargo is not secrecy. It is a coordinated agreement with a deadline, and it should have the smallest useful group of people inside it.

Smallest useful group. Everyone who must act, nobody who is merely curious. Product managers who are not shipping a mitigation do not need the PoC.
Write the timeline down. Report date, triage date, fix target, disclosure date. Everyone in the thread can see the same clock.
Know what confidentiality means in practice. Private advisory or private fork instead of a public PR. No screenshots of the exploit in a shared doc. No vague "we have an issue" in the incident channel that turns into a game of twenty questions.
Decide the default window before you are under pressure. 90 days is a convention, not a rule. Some projects use 7 days for actively exploited issues and 30 for everything else. What matters is that the number is written down and defensible.
Handle disagreement explicitly. If the reporter wants to publish early, or you need an extension, that is a negotiation with a stated reason — not silence and not a legal threat.

The embargo ends when the fix is available, or when the deadline arrives and it is not. Both are allowed. Pretending the deadline does not exist is how you end up reading about your own bug on a security news site with no patch ready.

the fix and release contract

This is where disclosure becomes ordinary engineering, with two differences: the branch is private, and the communication is public.

Private fix path. Private fork or advisory branch, minimal diff, and reviewers who were explicitly added. No drive-by refactors while the clock runs.
Focused review. Security fixes get a second pair of eyes from someone who can evaluate the boundary being crossed, not just the code style. Reviewers outside the embargo circle do not get the context, and that is fine.
Test evidence. A regression test that fails before the fix and passes after. If you cannot write it, say why in the advisory.
Fixed version plus mitigation. Not every team can upgrade immediately. Backports, config workarounds, feature flags, and WAF rules are all legitimate. An advisory that says "upgrade" and nothing else gets ignored by everyone who cannot.
Advisory, CVE, and user notification. GHSA draft, CVE requested when the ecosystem needs it, severity with the exploitability caveats from triage, affected versions, credits to the reporter, and a link to the fixed release.
Tell your users where they actually look. Release notes, a mailing list, a security page, an RSS feed, a Slack or Discord announcement. Publishing the advisory is not notifying users.

The measure of a good fix-and-release contract is the person running your software in production who finds out what to do without reading a research write-up.

the AI wrinkle

The AI-driven shift in vulnerability discovery is real, and it cuts both ways.

More reports are now generated by models pointed at codebases, and some of them are genuinely good: real bugs, real reproduction steps, reachable paths that a human reviewer missed. Others are confident, well-formatted, plausible-sounding findings with no reachable impact — a stack trace, an invented threat model, and a severity score chosen for drama.

Two things change:

Triage volume goes up without triage quality going up with it. A process that assumed a few thoughtful reports a month now gets a stream of synthetically detailed ones. That is fine as long as triage is evidence-based: does the repro actually work against a supported version? Is the code path reachable in a default deployment? Is the described impact real, or does it assume an attacker who already has the access the finding claims to escalate?

False positives get expensive because they look like real work. Every convincing-but-wrong report costs an engineer a day. Track that cost. If a share of your inbound reports never reproduce, that is a process input, not an annoyance — it tells you where your intake needs a reproduction requirement enforced harder.

The upside is equally real. AI-assisted review is genuinely good at finding the class of bug that humans skim past: missing authorization checks, unsafe deserialization, off-by-one in parsing, weak validation at boundaries. The maintainers who benefit are the ones whose triage process can absorb a higher volume without lowering the bar.

Which is the whole point of an operations contract. It is the thing that lets you say "this is credible" or "this is not" quickly, and move on either way.

a practical checklist for maintainers

[ ] SECURITY.md points to one canonical private intake channel and states response timelines.
[ ] Private vulnerability reporting is enabled on every actively maintained repo.
[ ] One named owner for triage, with a documented backup.
[ ] A severity assessment template: impact, exploitability, affected versions, default-config reachability.
[ ] A written disclosure window with defaults and an escalation path for active exploitation.
[ ] An embargo list discipline: smallest group, audited access, no public forks or PRs.
[ ] A private fix procedure: advisory branch, focused reviewers, regression test required.
[ ] A release procedure that ships the fix, the advisory, the CVE, the mitigation, and the notification.
[ ] A public-leak playbook: canned response, thread lock, move to private, no confirmation of exploitability.
[ ] Credit and thank reporters, including the ones who file a false positive in good faith.
[ ] A quarterly game day: walk a synthetic report through the whole path and time it.

None of this requires a security team. It requires someone to write down the decision that would otherwise be made by five people in a panic under time pressure.

A bug ticket asks "what should we build next." A vulnerability report asks "what do we do in the next 24 hours, and who decides." Different queues, different clocks, different consequences.

Write the contract before the reporter finds the door.

References

CNCF/TAG Security: Handling vulnerability reports — recipe card
CNCF: The AI-driven shift in vulnerability discovery
OpenSSF: Vulnerability Disclosures Working Group repo
OpenSSF: Vulnerability Disclosures group overview
GitHub Docs: Repository security advisories
GitHub Docs: About privately reporting a security vulnerability
CISA: Vulnerability disclosure policy template
FIRST: PSIRT Services Framework v1.1

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

the revolut breach is an automation boundary problem

Paulo Victor Leite Lima Gomes — Tue, 15 Sep 2026 16:47:45 +0000

Revolut did not get hacked.

Someone asked for customer data from an email that looked like it came from a government agency, and Revolut sent it.

That is the whole story, and it is worse than a hack.

what actually happened

Revolut confirmed it disclosed sensitive customer data to fraudsters who submitted fraudulent information requests from a legitimate government agency email domain. In its own words, it identified "a sophisticated external impersonation scam where an unauthorised third party utilised a legitimate government agency domain email to submit fraudulent requests for information."

The exposed data is the kind that cannot be reissued: passport and driver's licence copies, verification selfies, dates of birth, postal and email addresses, phone numbers, bank statements, IBANs, withdrawal records, and transaction histories including Bitcoin activity.

Revolut says a limited number of customers were affected, that it notified them directly, and that its systems and customer funds were not compromised. On detection it blocked the sender and alerted the government agency, law enforcement, data protection, and financial regulators.

The attackers appear to have gone after high net worth individuals, many of them in crypto, and an extortion payment was reportedly demanded.

None of this is new in shape. Researchers linked a wave of similar incidents in 2021 and 2022 to the Lapsus$ group, which used compromised law enforcement accounts and forged emergency data requests to pull data out of Apple, Meta, and Discord. The FBI issued an alert in 2024 about fraudulent emergency data requests, noting a growing market on criminal forums for access to compromised email accounts specifically to send them.

So the pattern is documented, the tactic is known, and it still worked.

the weak link was identity, not cryptography

Everything in that pipeline probably worked exactly as designed. TLS terminated correctly. The domain authenticated. The ticket was created, the approval probably existed, the audit log was written.

None of that answers the only question that matters: is the human on the other end who they claim to be?

Domain authentication proves a mail server, not a person. SPF, DKIM, and DMARC tell you the message really came from that domain. They tell you nothing about who composed it, whether the mailbox is compromised, or whether an insider sold access to it. A valid domain is a weak signal dressed up as a strong one, because it is the only signal most teams look at.

The attacker did not defeat Revolut's security. They used the fact that the request was boring enough to be processed and official enough to be trusted.

your security ends where your process begins

Every company has workflows that make decisions based on an external identity claim. A request from a regulator. A vendor onboarding email. A "support" phone call. A bank details change form with a letterhead attached. A legal letter asking for records.

Those dependencies are not failures by themselves. You cannot verify the world. But they are the boundary of your security model, and most teams have never drawn that boundary anywhere.

Here is the exercise that matters, and it is not a security tool purchase:

List every automated workflow that can be triggered by someone outside the company. Then mark, for each one, whether the trigger's identity is verified by you or merely asserted by them.

Asserted identity plus automation equals a breach waiting for a plausible email.

That single column usually explains incidents like this better than any threat model.

the channels we never treated as engineering

Look at the asymmetry in how we treat interfaces.

An API gets tokens, scopes, mTLS, network boundaries, rotation, rate limits, and a team that looks at it every day. If someone changes an API integration, it goes through review.

Email and phone calls got treated as plain data transfer. Not engineering. Just the way humans talk to companies.

But the moment an email can trigger a workflow that exports identity documents, email is not data transfer anymore. It is an unauthenticated control plane with a human-shaped interface. It is also the most automated channel in the company, because we wired inboxes into ticketing systems, compliance queues, and now AI agents that triage and summarise.

We hardened the channel we already understood and left the one that arrives as text.

That is the structural finding in this incident, and it applies far beyond Revolut.

guardrails, not reminders

If the root cause is a workflow that trusts an unverified channel, then "be more careful" is not a control. These are.

Tier by reversibility, not by category. If an action cannot be undone, it should never run fully automated. Handing over passport scans, selfies, and transaction histories is irreversible. That step needs a human with a name attached to it.

Separate routine from exceptional, and default the exceptional path to human. Automate the common case if you must. Anything unusual becomes a break-glass path with named approvers. Make "unusual" a computable property: new requester, broader data scope than previous requests, unusual volume, unusual urgency, unusual time of day.

Verify out of band, always. Call the agency on a number you already had, not one from the email. Use a portal with mutual authentication. If you must accept email, require signed requests with keys exchanged out of band. "The domain looked right" is not verification.

Use AI to screen, not to decide. Models are genuinely good at the anomaly detection humans skip under deadline pressure: pressure language, a request much broader than the last ten, first-time contact, mismatched signatures, formatting that does not match the agency's usual output. Let AI raise the flag and route to a human. Never let it be the final approver for an irreversible disclosure.

Cap the blast radius structurally. Ask why one request can return passports, selfies, statements, IBANs, and crypto transaction history together. Separate stores, shorter retention on biometrics, per-request record limits, and alerts on bulk document export turn a catastrophe into an inconvenience.

Log decisions as data. Who asked, what was disclosed, who approved, and on what evidence. If you cannot reconstruct that in an hour, you cannot answer a regulator in a week.

Rehearse the manual path. An untested review process becomes a rubber stamp the first time a legal deadline meets a tired engineer.

is revolut the villain here

Partly, and it is fair to say so. They owned the workflow, and the workflow handed over documents.

But look at what they did not own. The government's email domain. The agency's inability to be impersonated. And the assumption, shared across the industry, that a request arriving through an official channel is an official request.

If a legitimate domain can be used to request identity documents, and nobody in the loop is required to verify the requester, then every fintech running the same compliance process has the same exposure. Revolut is the one that got the email. It is not the only one that would have answered it.

Regulators have a part to play too. Lawful data requests should travel over authenticated channels: signed requests, registered endpoints, mutual TLS, an auditable registry of who is authorised to ask. Until that exists, companies are expected to be polite, fast, and legally compliant over a channel that proves nothing. That is a bad deal, and it is being paid for by customers whose passports are now circulating.

what to do on monday

Inventory every automated workflow that a third party can trigger.
Mark each trigger as verified or merely asserted.
Remove full automation from exceptional and irreversible paths.
Add out-of-band verification for any disclosure of identity documents.
Put AI in the screening layer, with a human on the approval.
Alert on bulk access to documents, selfies, and transaction history.

The lesson is not that Revolut trusted an email. The lesson is that a whole industry automated a channel that was never designed to prove identity, and then treated the resulting trust as a security control.

Fix the boundary first. Then automate.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

post-quantum tls is a platform migration, not a crypto project

Paulo Victor Leite Lima Gomes — Tue, 15 Sep 2026 15:00:18 +0000

Every few months someone asks me when quantum computers will break RSA.

I have stopped answering that question, because it is not the question engineering teams actually have.

The question they have is much less glamorous: do we know which of our services, SDKs, middleboxes, payment integrations, and certificate workflows will tolerate a bigger handshake, a hybrid key exchange, and eventually post-quantum signatures? Most teams cannot answer that today. And 2026 is the year the cloud providers started answering it for them, by changing the defaults.

That is the whole story. The quantum timeline is a distraction. The migration is already arriving through the boring doors: managed TLS endpoints, SDK defaults, CDN edge configuration, OS crypto libraries, and certificate tooling.

the narrow technical shift

Strip away the hype and the change is small and specific.

TLS 1.3 key exchange is currently dominated by X25519, an elliptic-curve Diffie-Hellman variant. It is fast, small, and well understood. The post-quantum concern is not that someone recorded your traffic and can decrypt it now. It is that a future quantum computer could decrypt recorded traffic later, which is exactly why anything with a long confidentiality lifetime, like a banking session log or a signed document, gets uncomfortable first.

The industry response was never "replace X25519 with something quantum-safe." It was hybrid: run the classical curve and the post-quantum key encapsulation together, and combine the results. If either holds, the session holds. That is what ML-KEM (FIPS 203, the standardized descendant of CRYSTALS-Kyber) provides, and it is why the IETF draft on ML-KEM for TLS 1.3 exists in the first place.

The practical consequence is size. A hybrid key share is much larger than an X25519 key share. That means:

bigger ClientHello messages
more bytes before the handshake completes
more chances to hit fragmentation, MTU limits, or middleboxes that "helpfully" drop what they do not recognize
more chances for an old client to negotiate a fallback group and nobody notice

And here is the part people conflate: key exchange and signatures are different problems with different timelines. ML-KEM protects the session key. Post-quantum signatures and how they land in certificates and code signing is a separate migration with its own compatibility and trust-chain pain. You can ship the first without having solved the second, and you probably should, because the first is already being turned on for you.

what changed in 2026

This stopped being a standards-track slide deck this year.

AWS shipped ML-KEM hybrid post-quantum TLS support across KMS, ACM, and Secrets Manager, and it is explicit that the older CRYSTALS-Kyber support will be removed across AWS service endpoints in 2026. That second sentence is the one to underline. This is not an opt-in curiosity anymore. It is a controlled API surface with a deprecation calendar attached.

Cloudflare documents post-quantum support for edge-to-origin TLS, including X25519MLKEM768 for key agreement and ML-DSA for origin authentication, with clear notes about where it is supported and where it is constrained. Microsoft shipped Windows platform support for ML-KEM hybrid TLS groups and is openly talking about an accelerated migration path for critical products and services toward 2029. The IETF draft for ML-KEM in TLS 1.3 is active.

And then there is the measurement reality. A June 2026 measurement paper looking at post-quantum readiness across more than 32,000 domains found the internet is not uniformly ready, with particular lag around banking and government TLS 1.2 endpoints and post-quantum certificate adoption. I find that more useful than any roadmap slide, because it says the failure modes will be uneven and depend on what your specific clients do.

translate it into platform work

Here is where I push back on how most teams are framing this.

If PQC lives only in a security-owned ticket, it will get treated as a cryptography review that produces a PDF and no changes. That is a mistake. The actual work is platform work, and it looks a lot like every other platform migration you have done badly before.

Inventory your outbound clients and TLS stacks. Not your externally facing load balancers, which are usually the easy part, but everything that makes an outbound TLS connection. Application runtimes, language crypto libraries, JDK versions, Go and Rust toolchains, database drivers, message bus clients, cron jobs, batch exports, and the one internal tool that has not been rebuilt since a migration ago. Different stacks gain hybrid group support at different times, and some old ones never will.

Test service-to-service paths end to end. A handshake does not happen between two applications. It happens through whatever is in the middle: proxies, API gateways, service meshes with their own TLS origination, CDNs, WAFs, egress filters, and vendor middleboxes that terminate and re-establish TLS. Those are where the surprises live. Payment and fintech integrations are the highest-stakes version of this, because a partner that pins groups, inspects traffic, or terminates in something old will fail in a way that looks like "the vendor is down."

Watch the right signals. This migration is observable, which is the only good news in the story. Track negotiated group, not just protocol version. Track handshake size and handshake latency, because hybrid key exchange changes both. Track fallback and retry counts, because a silent fall back to a classical group is the most likely failure mode and it will look like success unless you instrument it. Track TLS error rates by client version and by dependency.

Split certificates and code signing from key exchange. Do not let an ML-KEM rollout turn into an ML-DSA certificate plan. Hybrid key exchange is mostly a library-and-config change. Post-quantum certificates and code signing involve CA support, trust stores, chain sizes, and signing infrastructure that your build pipeline may not tolerate yet. Separate owners, separate timelines, separate proof.

Do not hand it to security alone. Security should define the standard and the target state. Platform should own the inventory, the rollout mechanics, the fallback policy, and the observability. Application teams own their own clients. If nobody owns the list of things that must still work, the list will be incomplete at exactly the wrong moment.

"turn it on" is not a strategy

My biggest skepticism about how this is being sold is the implied simplicity. Enable hybrid groups, prefer PQC, done.

That is not a strategy, because it cannot answer three questions:

What actually negotiated? If you cannot show, per path, which group was used, you do not know whether you are post-quantum or whether a proxy quietly negotiated something classical on your behalf.

What fell back, and why? Fallback is not automatically a failure, but an unobserved fallback is. Browsers and clients will happily downgrade. If you are not measuring it, you are guessing.

What broke? Bigger handshakes hit real constraints: MTU and fragmentation, connection setup latency budgets, throughput on high-connection-count services, and any queue or timeout that was tuned against a smaller handshake. You will find these in a canary, or you will find them in production.

A migration you cannot observe is a migration you cannot finish. You will end up with a partial rollout, a permanent exception list, and a security posture that only exists on the diagram.

a small checklist to start without panic

You do not need to rewrite anything this quarter. You need to know things you currently do not know.

List every TLS client you operate, with the runtime and crypto library version behind each one.
Pick three paths: one internal service-to-service, one through a proxy or mesh, one to an external partner or payment integration.
Turn on hybrid key exchange in a non-production environment and capture what negotiated, what fell back, and how big the handshake got.
Add negotiated group and handshake metrics to your existing TLS observability before you roll anything out.
Write down your fallback policy explicitly: are silent classical fallbacks acceptable, and for how long?
Track the AWS CRYSTALS-Kyber removal timeline and any provider deprecation notices for the endpoints you depend on.
Keep certificate and code-signing PQC work in a separate track with its own owner.
Give the whole thing a name, an owner, and a date. A migration without an owner is a rumor.

None of this requires predicting quantum computing timelines. It requires knowing your own system, which is the same work that makes every other migration survivable.

The teams that treat post-quantum TLS as a platform inventory problem will barely notice when the defaults flip. The teams that wait for the cryptography debate to resolve will discover, under pressure, that the change already shipped in a dependency they do not control.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

post-quantum tls is a platform migration, not a crypto project

Paulo Victor Leite Lima Gomes — Tue, 15 Sep 2026 14:00:24 +0000

Every few months someone asks me when quantum computers will break RSA.

I have stopped answering that question, because it is not the question engineering teams actually have.

the narrow technical shift

Strip away the hype and the change is small and specific.

The practical consequence is size. A hybrid key share is much larger than an X25519 key share. That means:

bigger ClientHello messages
more bytes before the handshake completes
more chances to hit fragmentation, MTU limits, or middleboxes that "helpfully" drop what they do not recognize
more chances for an old client to negotiate a fallback group and nobody notice

what changed in 2026

This stopped being a standards-track slide deck this year.

translate it into platform work

Here is where I push back on how most teams are framing this.

"turn it on" is not a strategy

My biggest skepticism about how this is being sold is the implied simplicity. Enable hybrid groups, prefer PQC, done.

That is not a strategy, because it cannot answer three questions:

What actually negotiated? If you cannot show, per path, which group was used, you do not know whether you are post-quantum or whether a proxy quietly negotiated something classical on your behalf.

What fell back, and why? Fallback is not automatically a failure, but an unobserved fallback is. Browsers and clients will happily downgrade. If you are not measuring it, you are guessing.

A migration you cannot observe is a migration you cannot finish. You will end up with a partial rollout, a permanent exception list, and a security posture that only exists on the diagram.

a small checklist to start without panic

You do not need to rewrite anything this quarter. You need to know things you currently do not know.

List every TLS client you operate, with the runtime and crypto library version behind each one.
Pick three paths: one internal service-to-service, one through a proxy or mesh, one to an external partner or payment integration.
Turn on hybrid key exchange in a non-production environment and capture what negotiated, what fell back, and how big the handshake got.
Add negotiated group and handshake metrics to your existing TLS observability before you roll anything out.
Write down your fallback policy explicitly: are silent classical fallbacks acceptable, and for how long?
Track the AWS CRYSTALS-Kyber removal timeline and any provider deprecation notices for the endpoints you depend on.
Keep certificate and code-signing PQC work in a separate track with its own owner.
Give the whole thing a name, an owner, and a date. A migration without an owner is a rumor.

None of this requires predicting quantum computing timelines. It requires knowing your own system, which is the same work that makes every other migration survivable.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

post-quantum tls is a platform migration, not a crypto project

Paulo Victor Leite Lima Gomes — Tue, 15 Sep 2026 12:00:32 +0000

Every few months someone asks me when quantum computers will break RSA.

I have stopped answering that question, because it is not the question engineering teams actually have.

the narrow technical shift

Strip away the hype and the change is small and specific.

The practical consequence is size. A hybrid key share is much larger than an X25519 key share. That means:

bigger ClientHello messages
more bytes before the handshake completes
more chances to hit fragmentation, MTU limits, or middleboxes that "helpfully" drop what they do not recognize
more chances for an old client to negotiate a fallback group and nobody notice

what changed in 2026

This stopped being a standards-track slide deck this year.

translate it into platform work

Here is where I push back on how most teams are framing this.

Do not hand it to security alone. Security should define the standard and the target state. Platform should own the inventory, the rollout mechanics, the fallback policy, and the observerability. Application teams own their own clients. If nobody owns the list of things that must still work, the list will be incomplete at exactly the wrong moment.

"turn it on" is not a strategy

My biggest skepticism about how this is being sold is the implied simplicity. Enable hybrid groups, prefer PQC, done.

That is not a strategy, because it cannot answer three questions:

What actually negotiated? If you cannot show, per path, which group was used, you do not know whether you are post-quantum or whether a proxy quietly negotiated something classical on your behalf.

What fell back, and why? Fallback is not automatically a failure, but an unobserved fallback is. Browsers and clients will happily downgrade. If you are not measuring it, you are guessing.

A migration you cannot observe is a migration you cannot finish. You will end up with a partial rollout, a permanent exception list, and a security posture that only exists on the diagram.

a small checklist to start without panic

You do not need to rewrite anything this quarter. You need to know things you currently do not know.

List every TLS client you operate, with the runtime and crypto library version behind each one.
Pick three paths: one internal service-to-service, one through a proxy or mesh, one to an external partner or payment integration.
Turn on hybrid key exchange in a non-production environment and capture what negotiated, what fell back, and how big the handshake got.
Add negotiated group and handshake metrics to your existing TLS observability before you roll anything out.
Write down your fallback policy explicitly: are silent classical fallbacks acceptable, and for how long?
Track the AWS CRYSTALS-Kyber removal timeline and any provider deprecation notices for the endpoints you depend on.
Keep certificate and code-signing PQC work in a separate track with its own owner.
Give the whole thing a name, an owner, and a date. A migration without an owner is a rumor.

None of this requires predicting quantum computing timelines. It requires knowing your own system, which is the same work that makes every other migration survivable.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

post-quantum TLS is a platform migration, not a crypto project

Paulo Victor Leite Lima Gomes — Tue, 15 Sep 2026 10:32:04 +0000

Post-quantum TLS stopped being a cryptography conference topic and became ordinary platform work some time in 2026.

Most engineering teams did not notice, because it arrived the way most infrastructure changes arrive: as defaults.

A cloud SDK bump. A CDN flag flipped at the edge. A KMS endpoint that negotiates something different than it did last quarter. A browser quietly preferring a hybrid group on every TLS 1.3 handshake. Nobody got a migration project. Everybody got a migration surface.

The quantum-timeline argument is a distraction here. Whether RSA falls in 2030, 2035, or later than anyone alive cares about is a legitimate research question and a completely useless planning input for a platform team. The engineering problem is not "when does quantum break RSA?" The problem is:

Do we know which of our services, SDKs, middleboxes, payment integrations, and certificate workflows actually tolerate larger handshakes, hybrid key exchange, ML-KEM defaults, and eventually post-quantum signatures?

That question has a boring, testable answer. That is what makes it a platform problem.

the narrow technical shift nobody explained clearly

Let me compress the crypto down to the part platform engineers need.

TLS 1.3 has two cryptographic jobs:

Key agreement — both sides derive a shared secret so the rest of the session can be encrypted.
Authentication — the server proves who it is, usually with an RSA or ECDSA certificate signature.

Post-quantum work is hitting these two at different times, with different maturity, and different operational blast radius. Conflating them is how teams end up with a two-year plan that should have been a two-week test.

Key agreement is the part already shipping. The dominant approach is hybrid: keep the classical X25519 exchange and add an ML-KEM (formerly Kyber) component alongside it. The session secret stays safe as long as either component holds. Cloudflare's implementation is the one most people will meet first — X25519MLKEM768 is now a standard group in TLS 1.3, supported at the edge and documented for edge-to-origin paths.

The practically relevant property of hybrid key exchange? Nothing breaks because it's post-quantum. It breaks because it's bigger.

Signatures and certificates are the slower half. ML-DSA exists and is being integrated, but post-quantum certificate authentication touches CA hierarchies, trust stores, client compatibility, device firmware, and the whole certification lifecycle. That is a genuinely multi-year migration. It is also not what most of the "we support PQC" announcements are about, which is why reading them carefully matters.

IETF work on ML-KEM for TLS 1.3 is active through 2026, so the wire format is close to settled. Good news: you can test now.

why this is already on your platform, whether you planned it or not

The reason I think platform teams should care right now is not standards activity. It is that the defaults are moving underneath you.

AWS already supports ML-KEM hybrid post-quantum TLS for KMS, ACM, and Secrets Manager, and has signaled that older CRYSTALS-Kyber support will be removed across AWS service endpoints in 2026. That is a deprecation with a date, which is the most reliable form of "you will deal with this."
Cloudflare documents PQC across its TLS stack, including X25519MLKEM768 and ML-DSA for origin authentication.
Microsoft has shipped Windows platform support for ML-KEM hybrid TLS groups and is talking publicly about accelerating migration of critical products toward 2029.
Measurement work from mid-2026 across tens of thousands of domains shows readiness is deeply uneven — banking and government endpoints lagging, post-quantum certificate adoption near zero.

That last point is the most useful one for anyone building fintech infrastructure. The interesting question is never "does PQC work?" It obviously works in a lab. The interesting question is where in your call graph it stops working, because that is where your production traffic goes.

translate it into platform work

Here is the honest version of the migration.

inventory outbound clients and TLS stacks

Every service that opens a TLS connection is a client, and most of them are invisible. Go's crypto/tls, Java's JSSE, Node's OpenSSL bindings, Python's ssl, Rust's rustls, plus every vendor SDK that bundles its own stack. Count the language runtimes, then count the SDKs that don't respect the runtime's defaults.

That second number is usually the surprise.

test service-to-service paths through every middlebox

This is where the migration actually gets hard, because the interesting failures live in components nobody considers TLS clients:

reverse proxies and load balancers
API gateways
service meshes with mTLS everywhere
CDN edge-to-origin links
WAFs doing TLS inspection
payment and banking integrations with fixed TLS profiles
old appliances that will never get a firmware update

A middlebox that reconstructs or inspects TLS can choke on a ClientHello it doesn't recognize. Some will reject unknown key share groups. Some will negotiate down. Some will fail in a way that only shows up under load.

watch the right signals

You cannot migrate what you cannot observe. The measurements that matter during a PQC rollout are not CPU graphs:

handshake size on the wire
handshake latency, especially cold connections across regions
TLS error rates split by client version and destination
negotiated group per connection — this is the number that tells you whether the hybrid path is actually being used
fallback rates, because a silent fallback to classical key exchange looks identical to success if you only check for errors

That fallback point deserves emphasis. A connection that quietly negotiates X25519 instead of X25519MLKEM768 is working. It is also not post-quantum. If your only signal is "did the request succeed," you will report a green migration that never happened.

plan certificates as a separate track

Key exchange and signatures are different projects with different timelines. Hybrid key agreement can be enabled, measured, and rolled back in weeks. Post-quantum certificate chains touch CA operations, trust stores, hardware, and code signing, and they are a genuinely long-horizon program.

Do not let the first one create fake urgency for the second, and do not let the second block the first.

don't make this a security-team ticket

This is the mistake I'd push back on hardest. If PQC lands in the security backlog as a single ticket titled "quantum readiness," it will sit there until a cloud provider forces the issue at a bad time.

The work is distributed by nature:

platform owns the runtime and library inventory
service teams own their SDKs and integration tests
networking owns proxies, gateways, and middleboxes
security owns the crypto policy and the deprecation timeline awareness
SRE owns the observability and rollback path

That is a coordination problem, not a crypto problem. Treating it as crypto is how it stays unowned.

"turn it on" is not a strategy

The skeptical core of this post: enabling hybrid post-quantum TLS is a one-line config change in most stacks, and that is exactly why it is dangerous.

If you flip the flag and nobody can answer these, you haven't migrated anything:

Which clients negotiated the hybrid group, and which silently fell back?
Which services failed to connect, and did they fail loudly or retry down to classical?
What does the handshake look like through the proxy, the mesh, and the CDN?
Can we revert without a full deploy?
Do we know the before/after handshake size and latency numbers for our real traffic, not a benchmark?

That is the standard I'd hold a PQC rollout to. Not "we enabled it." "We can prove what negotiated, what fell back, and what broke."

a practical starting checklist

Small on purpose. This should be days of work, not a program.

List every TLS stack you ship. Runtimes, SDKs, proxies, sidecars, appliances. Note who owns each.
Pick one internal call path — a low-risk service-to-service link through your gateway — and enable hybrid key exchange there.
Instrument the negotiated group per connection. If you can't see it, stop and fix that first.
Record baseline handshake size and latency before the change, and compare after. Cold connections across regions, not localhost.
Test the middleboxes deliberately. Force the new group, watch the proxy, mesh, and any TLS-inspecting appliance. Break it on purpose in staging.
Write the rollback down. One flag, one revert, one documented path back to classical.
Track the deprecations. Kyber removal, SDK changes, CDN defaults. These are the real deadlines; the quantum timeline is not.
Separate the certificate track and give it a real owner with a multi-year horizon.

Do that and you will be ahead of most of the industry for a fraction of the cost, because the industry is currently waiting for a reason to start.

The cloud providers are not waiting. They are making Post-quantum TLS the default quietly, endpoint by endpoint, and the only question that matters is whether you find out from a rollout you ran or from an incident you didn't.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

post-quantum TLS is a platform migration, not a crypto project

Paulo Victor Leite Lima Gomes — Tue, 15 Sep 2026 10:00:36 +0000

Post-quantum TLS stopped being a cryptography conference topic and became ordinary platform work some time in 2026.

Most engineering teams did not notice, because it arrived the way most infrastructure changes arrive: as defaults.

That question has a boring, testable answer. That is what makes it a platform problem.

the narrow technical shift nobody explained clearly

Let me compress the crypto down to the part platform engineers need.

TLS 1.3 has two cryptographic jobs:

Key agreement — both sides derive a shared secret so the rest of the session can be encrypted.
Authentication — the server proves who it is, usually with an RSA or ECDSA certificate signature.

The practically relevant property of hybrid key exchange? Nothing breaks because it's post-quantum. It breaks because it's bigger.

IETF work on ML-KEM for TLS 1.3 is active through 2026, so the wire format is close to settled. Good news: you can test now.

why this is already on your platform, whether you planned it or not

The reason I think platform teams should care right now is not standards activity. It is that the defaults are moving underneath you.

AWS already supports ML-KEM hybrid post-quantum TLS for KMS, ACM, and Secrets Manager, and has signaled that older CRYSTALS-Kyber support will be removed across AWS service endpoints in 2026. That is a deprecation with a date, which is the most reliable form of "you will deal with this."
Cloudflare documents PQC across its TLS stack, including X25519MLKEM768 and ML-DSA for origin authentication.
Microsoft has shipped Windows platform support for ML-KEM hybrid TLS groups and is talking publicly about accelerating migration of critical products toward 2029.
Measurement work from mid-2026 across tens of thousands of domains shows readiness is deeply uneven — banking and government endpoints lagging, post-quantum certificate adoption near zero.

translate it into platform work

Here is the honest version of the migration.

inventory outbound clients and TLS stacks

That second number is usually the surprise.

test service-to-service paths through every middlebox

This is where the migration actually gets hard, because the interesting failures live in components nobody considers TLS clients:

reverse proxies and load balancers
API gateways
service meshes with mTLS everywhere
CDN edge-to-origin links
WAFs doing TLS inspection
payment and banking integrations with fixed TLS profiles
old appliances that will never get a firmware update

watch the right signals

You cannot migrate what you cannot observe. The measurements that matter during a PQC rollout are not CPU graphs:

handshake size on the wire
handshake latency, especially cold connections across regions
TLS error rates split by client version and destination
negotiated group per connection — this is the number that tells you whether the hybrid path is actually being used
fallback rates, because a silent fallback to classical key exchange looks identical to success if you only check for errors

plan certificates as a separate track

Do not let the first one create fake urgency for the second, and do not let the second block the first.

don't make this a security-team ticket

The work is distributed by nature:

platform owns the runtime and library inventory
service teams own their SDKs and integration tests
networking owns proxies, gateways, and middleboxes
security owns the crypto policy and the deprecation timeline awareness
SRE owns the observability and rollback path

That is a coordination problem, not a crypto problem. Treating it as crypto is how it stays unowned.

"turn it on" is not a strategy

The skeptical core of this post: enabling hybrid post-quantum TLS is a one-line config change in most stacks, and that is exactly why it is dangerous.

If you flip the flag and nobody can answer these, you haven't migrated anything:

Which clients negotiated the hybrid group, and which silently fell back?
Which services failed to connect, and did they fail loudly or retry down to classical?
What does the handshake look like through the proxy, the mesh, and the CDN?
Can we revert without a full deploy?
Do we know the before/after handshake size and latency numbers for our real traffic, not a benchmark?

That is the standard I'd hold a PQC rollout to. Not "we enabled it." "We can prove what negotiated, what fell back, and what broke."

a practical starting checklist

Small on purpose. This should be days of work, not a program.

List every TLS stack you ship. Runtimes, SDKs, proxies, sidecars, appliances. Note who owns each.
Pick one internal call path — a low-risk service-to-service link through your gateway — and enable hybrid key exchange there.
Instrument the negotiated group per connection. If you can't see it, stop and fix that first.
Record baseline handshake size and latency before the change, and compare after. Cold connections across regions, not localhost.
Test the middleboxes deliberately. Force the new group, watch the proxy, mesh, and any TLS-inspecting appliance. Break it on purpose in staging.
Write the rollback down. One flag, one revert, one documented path back to classical.
Track the deprecations. Kyber removal, SDK changes, CDN defaults. These are the real deadlines; the quantum timeline is not.
Separate the certificate track and give it a real owner with a multi-year horizon.

Do that and you will be ahead of most of the industry for a fraction of the cost, because the industry is currently waiting for a reason to start.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

post-quantum TLS is a platform migration, not a crypto project

Paulo Victor Leite Lima Gomes — Tue, 15 Sep 2026 09:01:10 +0000

Every post-quantum TLS discussion eventually turns into a fight about dates.

When will a cryptographically relevant quantum computer show up? Is it 2030, is it 2040, is it never, is "harvest now, decrypt later" actually a thing for my threat model? Someone brings up Shor's algorithm, someone else brings up the storage cost of keeping ciphertext for a decade, and forty minutes later the meeting ends without anyone writing a single line of configuration.

I have started to find that debate genuinely uninteresting.

Not because the risk is fake. Because it is not the problem that engineering teams actually have to solve this quarter.

The problem teams have is this: post-quantum TLS is no longer a research topic that lives in a standards committee. It is arriving as ordinary platform surface area — cloud provider defaults, SDK flags, CDN behavior, operating system crypto libraries, and eventually the certificate workflows that hold your mTLS paths together. And the surface is arriving before most teams have an inventory of the things it will touch.

That is the migration. Not the calendar.

what is actually changing in the handshake

Strip the drama away and the change is narrower than it sounds.

TLS today authenticates and agrees on keys using classical public-key cryptography. Key agreement usually comes from something like elliptic curve Diffie-Hellman, and authentication comes from RSA or ECDSA signatures in the certificate chain. Quantum computers threaten the math underneath both of those assumptions, but for different reasons and on different timelines.

The first migration wave is about key agreement, and it is hybrid.

In practice that means a classical algorithm such as X25519 is combined with a post-quantum key encapsulation mechanism, ML-KEM (the standardized descendant of CRYSTALS-Kyber). Cloudflare's edge-to-origin documentation names the group as X25519MLKEM768. AWS, Microsoft, and the IETF work on ML-KEM for TLS 1.3 all point at the same shape.

Hybrid is the important word. We are not ripping out classical crypto overnight. We are adding a post-quantum component next to it, so a connection still holds up if either half turns out weaker than expected. That is a sensible engineering choice and it is also why the migration looks harmless in a design review.

It is not harmless in production.

The handshake gets bigger. A post-quantum key share adds hundreds of bytes to the ClientHello, which means the first flight can split across multiple TCP packets, which means every middlebox on the path gets an opportunity to do something creative. Some stacks will negotiate the new group. Some will fall back to classical. Some will just fail, in a place that never appeared on an architecture diagram because the diagram ended at "load balancer."

AWS published benchmark numbers suggesting the performance cost is manageable, especially with TLS connection reuse. Good. That is one provider's workload, not yours. Your connection patterns, retry behaviour, proxy chain, and mobile clients are the only benchmark that counts.

And keep one boundary sharp: key exchange is not authentication.

ML-KEM protects the key agreement. Post-quantum signatures — ML-DSA and friends — are a separate migration for certificates, client certificates, mTLS verification, code signing, internal CAs, and HSMs. Negotiating a hybrid key share does not make any of that quantum-safe. When a dashboard collapses both into one green check mark, someone is about to make a bad decision.

the defaults are already moving

The reason I would put this on a platform roadmap instead of a research backlog is that other people are already making the decision for you.

AWS supports ML-KEM hybrid post-quantum TLS for KMS, ACM, and Secrets Manager, and has been explicit that clients need to be updated to offer ML-KEM when talking to AWS service endpoints. It has also flagged that older CRYSTALS-Kyber support is going away across AWS service endpoints in 2026. Read that again slowly: one of the three services is the thing your workloads call to decrypt secrets and bootstrap. That is not a lab endpoint.

Cloudflare documents post-quantum key agreement between its edge and origins, and separately covers post-quantum authentication toward origins with ML-DSA, including the awkward detail that presenting a post-quantum certificate does not help if the verifier still happily accepts classical ones on the same trust path.

Microsoft is shipping ML-KEM hybrid TLS groups at the Windows platform level and talking about accelerating migration of critical products and services toward 2029. The IETF draft for ML-KEM key agreement in TLS 1.3 is alive and moving.

None of those are opt-in research previews you can safely ignore. They are the boring defaults forming underneath your services.

this is platform work wearing a security costume

The failure mode I expect is ownership, not technology.

Security teams will correctly frame the risk, publish a target state, and hand over a document. Then the actual work lands in TLS library versions, runtime base images, ingress controllers, sidecar proxies, managed load balancers, trust stores, SDK upgrades, retry logic, dashboards, and rollback switches — and none of that is crypto. It is platform plumbing.

So the first deliverable is not a quantum readiness strategy. It is an inventory.

Start with who initiates TLS and with what:

Java services on the JDK TLS stack, and Java services on the AWS CRT HTTP client, which are not the same client
Node.js borrowing OpenSSL through the runtime
Go using the standard library
Rust on rustls or native-tls
Python sitting on a system OpenSSL or a bundled wheel
mobile apps pinned to whatever the OS decides
vendor SDKs that ship their own HTTP client and quietly ignore your config
sidecars and service mesh data planes doing outbound TLS on behalf of a service
CI jobs, batch workers, and that one CronJob everybody forgot

Then map the destinations. Cloud APIs like KMS, ACM, Secrets Manager, STS, and S3. Identity providers. Observability vendors. Webhook targets. Internal APIs behind gateways and meshes. And in a fintech context, payment processors, card networks, and banking partners, where TLS requirements are often contractual, occasionally bizarre, and held together by a runbook written by someone who left two reorganisations ago.

Those partner paths are where a crypto migration becomes a support incident.

test the path, not the box

The classic mistake here is proving one component and declaring the route safe.

"The service supports TLS 1.3." Great. Does the whole path support the handshake you intend to negotiate?

"The origin supports X25519MLKEM768." Great. Does your current Cloudflare configuration actually negotiate it to the origin, on the hostname that matters, with the same rules?

"The SDK has a flag." Great. Is that SDK the HTTP client your production service actually ends up using, or did a transitive dependency pick a different one?

"The library supports ML-DSA." Great. Does your private CA, renewal pipeline, HSM, mTLS verifier, deployment automation, and rollback plan agree?

What you want are tests that look like production paths, not component unit tests:

browser to CDN to origin
edge to origin with your real caching and WAF rules in front
service to KMS and Secrets Manager in every environment, including the one that only exists for incident response
service to payment or banking partner endpoints
pod through mesh sidecar through egress gateway to an internal API
mobile app through a corporate network to your API gateway

The word "through" is carrying all the weight in those bullets. TLS migrations rarely fail at the endpoints. They fail at the thing in between that was never supposed to care.

"turn it on" is not a strategy

Here is the skeptical part, and it is the part I would defend hardest.

Enabling post-quantum key agreement is not an action unless you can prove what happened afterwards. Otherwise you have changed a setting and acquired a feeling.

The minimum useful telemetry:

negotiated TLS version
negotiated key exchange group
handshake failure rate, split by client runtime, SDK version, region, and egress path
HelloRetryRequest rate, because that is where extra round trips and latency show up
fallback rate to classical key exchange
TLS handshake latency, and connection reuse behaviour
ClientHello size distribution where your stack lets you see it
certificate chain and signature algorithm wherever authentication is in scope

You will not get all of that on day one. Almost nobody can. But if your only signal is "the service still looks up," you are not testing a migration, you are guessing about one.

And the failure mode I fear most is not a loud outage. It is quiet partial success. The flag is on in one region and not another. Browser traffic negotiates hybrid, service-to-service stays fully classical. The edge path got upgraded while origin authentication stayed old all the way down. Everything reports healthy, and the only thing that actually changed is the confidence level in a slide.

Security migrations love partial success, because partial success produces screenshots. Production needs evidence.

certificates are a separate workstream

Certificates deserve their own plan, not a bullet inside "enable PQ TLS."

The June 2026 measurement work across 32,011 domains is a useful reality check here. It found real adoption of modern protocols and hybrid post-quantum key exchange, but also stubborn TLS 1.2 usage in critical sectors like banking and government, and no hybrid post-quantum certificate adoption in the observed set.

That is exactly the shape I would expect. Key exchange moves first, because browsers, CDNs, cloud providers, and TLS libraries can drag a lot of that surface forward at once. Certificate trust infrastructure moves slowly, because it is federated, regulated, audited, pinned in strange places, and painfully operational.

For fintech teams this cuts both ways. Cloud providers and browsers pull you forward. Partners, legacy clients, compliance constraints, and external integrations hold you back. A workable plan has to be modern enough to negotiate the new defaults and conservative enough not to break the business path that is not ready — and it has to know which path is which.

So keep it separate:

key exchange first, where the platform supports it
certificate and signature inventory in parallel
mTLS verification rules reviewed explicitly, not assumed
private CA capability, HSM support, and renewal automation checked
certificate pinning found, and either removed or updated on purpose
partner TLS requirements written down instead of remembered

Certificate pinning deserves a special mention. If an old mobile app, an embedded client, or a partner integration pins certificate or algorithm assumptions, you want to discover it before a routine security change becomes a customer-visible incident.

rollback, then rollout

Post-quantum TLS should roll out like anything else that touches connection establishment.

Small scope. Known clients. Clear metrics. A rollback switch. No hero deploys.

For outbound clients that might mean hybrid key agreement for one service talking to KMS in one environment, then expanding by service class. For edge-to-origin, it might mean specific origins before zone-wide behaviour. For a mesh, it might mean proving it in a canary namespace that shares the same ingress, egress, and observability path as production.

The rollback questions should be boring enough to answer in one sentence each:

how do we disable hybrid key agreement for this client?
how do we force classical fallback if a partner path breaks?
how do we detect that fallback happened?
who is allowed to change the setting at 2am?
which metric tells us the rollback worked?
what user-visible behaviour triggers the rollback?

If nobody can answer those, the rollout is not ready, no matter how good the readiness deck is.

the checklist I would actually run

If I owned a platform this quarter, I would not start a "quantum-safe transformation programme." I would start with eight boring things.

Build the TLS client inventory. Services, runtimes, TLS libraries, SDK versions, sidecars, mobile clients, CI jobs, batch workers. Write down the outbound destinations too.
Flag the security-critical paths. KMS, Secrets Manager, ACM, identity, and anything payment-adjacent will move early, whether or not you planned for it.
Test hybrid key exchange outside production. Real client libraries, real proxies, realistic connection reuse. Measure latency and failure rates, not just success.
Add negotiation telemetry. Negotiated version and group, fallback, HelloRetryRequest, handshake latency. Without this, every claim about readiness is vibes.
Attack the middleboxes. CDNs, WAFs, API gateways, meshes, load balancers, corporate proxies, partner gateways. That is where a boring TLS change becomes an incident.
Split certificates out. ML-KEM key agreement and ML-DSA signatures are different migrations. Treat CA, mTLS, HSM, pinning, and renewal as their own track.
Write rollback before rollout. A crypto migration without a rollback path is a production experiment with a better acronym.
Keep security and platform in the same room. Security owns the risk. Platform owns the machinery. Product teams own the partner dependencies. Splitting that too cleanly turns migration into archaeology.

None of this requires panic. It requires inventory, evidence, and the willingness to be boring about it.

the punchline

Post-quantum TLS is not waiting for your organisation to finish arguing about quantum timelines.

It is showing up in provider changelogs, SDK flags, CDN defaults, operating system crypto libraries, and partner questionnaires. Some of it will be opt-in. Some of it will become preferred behaviour. Some of it will arrive as one line in a release note that quietly changes what production negotiates on a Tuesday afternoon.

The teams that handle this well will not be the ones with the most dramatic quantum roadmap. They will be the ones who can answer simple questions:

What do our clients actually support?

What did this connection negotiate?

Where did it silently fall back?

Which path broke, and did the telemetry even notice?

Can we turn it off?

That is the migration. Not prophecy, not hype, not another argument about dates.

Just platform work that gets a lot easier if you start before the default changes under you.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

post-quantum TLS is a platform migration, not a crypto project

Paulo Victor Leite Lima Gomes — Mon, 14 Sep 2026 15:02:29 +0000

The least useful post-quantum TLS conversation is the one where everyone argues about when a quantum computer will break RSA.

It is fun in the way all prediction fights are fun. Someone has a chart. Someone has a more skeptical chart. Someone says "harvest now, decrypt later" with the face of a person who has said it in eight meetings this quarter.

Fine.

But for engineering teams, that is not the interesting problem anymore.

The interesting problem is much more boring and much more dangerous:

Do we know which of our clients, SDKs, proxies, service meshes, CDNs, KMS integrations, payment providers, middleboxes, observability tools, and certificate workflows will tolerate the post-quantum TLS migration when the defaults start moving under us?

That is the work.

Not because quantum doom arrives tomorrow morning with a calendar invite. Because the platform surface is already changing. AWS has ML-KEM hybrid post-quantum TLS support in KMS, ACM, and Secrets Manager. Cloudflare documents post-quantum key agreement between its edge and origins. Microsoft has ML-KEM and ML-DSA in its crypto platform surface, hybrid TLS in SymCrypt-OpenSSL, and Windows TLS support on the roadmap. The IETF TLS work for ML-KEM in TLS 1.3 is active enough that this is not "future crypto" in the abstract anymore.

This is becoming normal migration work.

And normal migration work is where production breaks.

the narrow change is not that mystical

Let us remove the drama for a second.

TLS today usually relies on classical public-key cryptography during the handshake. The client and server agree on keys using mechanisms like elliptic curve Diffie-Hellman. Quantum computers, if they become strong enough, are a problem for those public-key assumptions.

Post-quantum TLS changes the key agreement side of the handshake so that the connection can resist that future attack class. In practice, the migration path most platforms are using first is hybrid key exchange: keep a classical algorithm like X25519 and combine it with a post-quantum algorithm like ML-KEM.

The hybrid part matters. It means we are not throwing away the classical mechanism overnight. We are adding a post-quantum component while preserving the current security properties if one side of the hybrid story turns out to be weaker than expected.

That sounds tidy. It is not free.

The handshake gets bigger. More bytes move at connection startup. ClientHello messages may split across packets. Some intermediaries and old TLS stacks will behave badly, because protocol ossification is basically the internet's hobby. Some connections will negotiate the new group. Some will fall back. Some will fail in places nobody had on the architecture diagram because the diagram stopped at "load balancer."

AWS measured this as a manageable performance cost for its KMS benchmark, especially when TLS connection reuse is enabled. That is good news. It is also not a permission slip to skip testing. Benchmarks from a cloud provider are not a substitute for your own connection patterns, your own proxies, your own mobile clients, and your own suspicious enterprise network path that somehow still matters because the CFO uses it.

The other important distinction: key exchange is not certificates.

ML-KEM helps with key agreement. Post-quantum signatures are the separate authentication problem. Your certificate chain, client certificates, mTLS setup, code signing, internal CAs, HSMs, and certificate rotation workflows do not become quantum-safe just because one TLS connection negotiated a hybrid key share.

This is exactly where I expect teams to get sloppy.

"We turned on PQC" will be used to describe three different things:

hybrid key agreement on inbound browser traffic
hybrid key agreement on service-to-service traffic
post-quantum authentication through certificates or signatures

Those are not the same migration. If a dashboard flattens them into one green check mark, be suspicious.

the cloud default will arrive before the spreadsheet is perfect

The reason to start now is not panic.

The reason to start now is that cloud defaults have a habit of becoming production defaults while the backlog still says "investigate."

AWS is already explicit that customers need to update TLS clients and SDKs to offer ML-KEM when connecting to AWS service HTTPS endpoints. For services like KMS and Secrets Manager, that is not an academic endpoint. That is the path your applications use to decrypt secrets, fetch configuration, generate data keys, and bootstrap sensitive workloads.

Cloudflare is also a good preview of the operational shape. It supports X25519MLKEM768 in the edge-to-origin path and documents the fact that adding ML-KEM can split the ClientHello across two packets. That tiny sentence is a whole migration hiding in plain sight.

Can your origin handle it?

Can the load balancer in front of the origin handle it?

Can the WAF handle it?

Can the appliance nobody wants to own handle it?

Can the old Java service using a pinned runtime handle it?

Can the fintech partner endpoint handle it?

This is why I do not like framing post-quantum TLS as a security team project. Security should absolutely drive the risk framing and target state. But the actual migration is platform plumbing: TLS libraries, SDK versions, runtime images, ingress controllers, sidecars, managed load balancers, trust stores, certificate issuance, client retry behavior, dashboards, and rollback switches.

That is platform work.

If only the cryptography people own it, the migration will produce beautiful documents and then die at the first strange proxy.

inventory beats speeches

The first useful deliverable is not a quantum readiness strategy deck.

It is an inventory.

Start with outbound clients. Which services initiate TLS connections, and with which runtime stacks?

Java with JDK TLS
Java with AWS CRT
Node.js with OpenSSL through the runtime
Go with the standard library
Rust with rustls or native-tls
Python with OpenSSL through the system or a bundled package
mobile clients pinned to OS behavior
vendor SDKs with their own HTTP clients
sidecars doing outbound TLS on behalf of the service

Then map the destinations.

AWS KMS, ACM, Secrets Manager, STS, S3, and other cloud APIs
payment processors
card networks and banking partners
identity providers
observability vendors
webhook targets
internal APIs behind meshes or gateways
customer-controlled endpoints

This is the part where fintech teams should pay attention. Payment and banking integrations are often full of TLS constraints that nobody wants to touch unless a certificate is expiring. Some partners still have very specific TLS requirements. Some mutual TLS setups are held together by a certificate runbook last edited by a person who left three reorganizations ago. Some "temporary" proxies became permanent infrastructure by surviving long enough.

Post-quantum TLS will find those places.

Better you find them first.

test the path, not the box

A common mistake in migrations like this is testing one component and declaring the path safe.

"The service supports TLS 1.3."

Good. Does the whole path support the actual handshake you intend to use?

"The origin supports X25519MLKEM768."

Good. Does Cloudflare negotiate it to the origin through your current configuration?

"The SDK has a flag."

Good. Is that the HTTP client your production service actually uses, or did the dependency injection layer quietly choose a different one?

"The certificate library supports ML-DSA."

Good. Does your certificate authority, renewal pipeline, HSM, deployment process, mTLS verifier, and rollback plan support it too?

You need end-to-end tests that look like production paths:

browser to CDN to origin
Cloudflare edge to origin
service to AWS KMS
service to Secrets Manager
service to payment provider
service through mesh sidecar to internal API
mobile app to API gateway
batch job through corporate egress proxy

The word "through" is doing a lot of work there.

TLS migrations do not only fail at endpoints. They fail at the thing between endpoints that was not supposed to care.

observability needs to know what negotiated

"Turn it on" is not a strategy.

It is barely even an action unless you can prove what happened after you turned it on.

For post-quantum TLS, the minimum useful telemetry is:

negotiated TLS version
negotiated key exchange group
handshake failure rate
HelloRetryRequest rate
fallback rate to classical key exchange
TLS handshake latency
connection reuse behavior
ClientHello size distribution where you can measure it
errors by client runtime, SDK version, region, and egress path
certificate chain and signature algorithm where authentication is in scope

You probably will not get all of that on day one. Fine. Start with what your proxies, load balancers, service mesh, CDN, and client libraries can expose.

But if the only signal is "the service still seems up," you are flying blind.

The scary failure mode is not always total outage. The scarier one is false confidence. A team believes it is running post-quantum key agreement because the setting is enabled somewhere, but most traffic is falling back silently. Or one region negotiates the new group and another does not. Or browser traffic looks modern while service-to-service traffic is still entirely classical. Or the shiny edge path is upgraded, but the origin authentication path is still old RSA all the way down.

Security migrations love partial success because partial success produces screenshots.

Production needs evidence.

certificates are their own migration

Cloudflare's origin documentation is useful because it refuses to hide the awkward part: post-quantum signatures are a separate track.

It talks about ML-DSA for origin-facing authentication features, not just ML-KEM key agreement. It also calls out downgrade behavior: presenting a post-quantum certificate is not enough if the verifier still accepts classical certificates in the same trust path.

That should make every platform team slightly uncomfortable, in a healthy way.

Certificate workflows are usually older than people admit. They cross team boundaries. They include public CAs, private CAs, mTLS, device certificates, HSMs, Kubernetes secrets, ingress annotations, Terraform modules, emergency renewal docs, and maybe a spreadsheet called certs-final-v3.xlsx if your organization has a sense of humor by accident.

Do not bundle all of that into "enable PQ TLS."

Plan it separately:

key exchange migration first where the platform supports it
certificate and signature inventory in parallel
mTLS verification rules reviewed explicitly
private CA capability checked
HSM and KMS support checked
renewal and rollback rehearsed
certificate pinning found and removed or updated
partner requirements documented

Especially certificate pinning. If there is an old mobile app, embedded client, or partner integration pinning assumptions about certificates or algorithms, you want to discover it before a security migration turns into a customer-support incident.

the banking/government lag is a warning

The June 2026 measurement paper on post-quantum readiness is useful because it shows the internet doing what the internet does: migrating unevenly.

Across 32,011 domains, the authors found real adoption of modern protocols and hybrid post-quantum key exchange, but also stubborn TLS 1.2 usage in critical sectors like banking and government. They also found no hybrid post-quantum certificate adoption in their observed set.

That is exactly the pattern I would expect.

Key exchange can move first because browsers, CDNs, cloud providers, and TLS libraries can push a lot of that surface forward. Certificates are slower because trust infrastructure is messy, regulated, audited, pinned, vendor-dependent, and painfully operational.

For fintech teams, this matters for two reasons.

First, you will be pulled forward by cloud providers and browsers.

Second, you will be held back by partners, legacy clients, compliance constraints, and external integrations.

The migration plan has to handle both directions at the same time. You need to be modern enough to negotiate the new defaults where available, and conservative enough to avoid breaking business-critical paths that are not ready yet.

That is not a crypto debate.

That is compatibility engineering.

rollback is part of the design

Post-quantum TLS rollout should look like every other serious platform rollout.

Small scope first. Known clients first. Clear metrics. Rollback switch. No hero deploys.

For outbound clients, that may mean enabling hybrid TLS only for one service calling KMS in one environment, then expanding by service class. For edge-to-origin, it may mean testing selected origins before relying on zone-wide behavior. For service mesh, it may mean proving behavior in a canary namespace with the same ingress, egress, and observability path as production.

The rollback question should be boring:

How do we disable hybrid key agreement for this client?
How do we force classical fallback if a partner path breaks?
How do we know fallback happened?
Who is allowed to change the setting?
What metric tells us the rollback worked?
What customer-facing behavior would trigger rollback?

If nobody can answer those, the rollout is not ready.

And yes, this can feel absurd. We are talking about preparing rollback behavior for a future-facing cryptographic migration that most users will never notice.

That is platform engineering. Most of the work is making sure users never notice.

what i would do now

If I owned a platform today, I would not start with a grand "quantum-safe transformation program."

I would start with a small, practical checklist.

1. Build the TLS client inventory. List services, runtimes, TLS libraries, SDK versions, sidecars, mobile clients, and outbound destinations. Do not forget CI jobs and batch workloads.

2. Identify cloud service paths. Pay special attention to KMS, Secrets Manager, ACM, identity, storage, and payment-adjacent services. Security-critical endpoints will move early.

3. Test hybrid key exchange in non-production. Use real client libraries, real proxies, and realistic connection reuse. Measure handshake latency and failure rates.

4. Add negotiation telemetry. At minimum, learn which TLS version and key exchange group were negotiated where your stack exposes it. Without this, every claim is vibes.

5. Exercise middleboxes. CDNs, WAFs, API gateways, service meshes, load balancers, corporate proxies, and partner gateways are where boring TLS changes become incidents.

6. Separate certificate planning. ML-KEM key agreement and ML-DSA signatures are different migration tracks. Treat private CA, mTLS, HSM, certificate pinning, and renewal flows as their own workstream.

7. Write rollback instructions before rollout. A crypto migration without rollback is just a production experiment with a better acronym.

8. Keep security and platform in the same room. Security owns the risk. Platform owns much of the machinery. Product teams own the traffic and partner dependencies. Splitting those too cleanly is how migrations become archaeology.

None of this requires panic.

It requires inventory, evidence, and boring discipline.

the punchline

Post-quantum TLS is not waiting for your organization to finish debating quantum timelines.

It is arriving through provider defaults, SDK options, CDN behavior, operating system support, TLS library releases, and partner requirements. Some of it will be opt-in. Some of it will become preferred behavior. Some of it will show up as a minor-looking changelog entry that quietly changes what production negotiates on a Tuesday.

The teams that handle it well will not be the ones with the most dramatic quantum slide deck.

They will be the ones that can answer simple questions:

What do our clients support?

What did this connection negotiate?

Where did it fall back?

Which path broke?

Can we roll it back?

That is the migration.

Not hype. Not prophecy. Not a religious war about timelines.

Just another piece of platform work that becomes much easier if you start before the default changes.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

post-quantum TLS is a platform migration, not a crypto project

Paulo Victor Leite Lima Gomes — Mon, 14 Sep 2026 14:03:27 +0000

The least useful post-quantum TLS conversation is the one where everyone argues about when a quantum computer will break RSA.

Fine.

But for engineering teams, that is not the interesting problem anymore.

The interesting problem is much more boring and much more dangerous:

That is the work.

Not because quantum doom arrives tomorrow morning with a calendar invite. Because the platform surface is already changing. AWS has ML-KEM hybrid post-quantum TLS support in KMS, ACM, and Secrets Manager. Cloudflare documents post-quantum key agreement between its edge and origins. Microsoft is putting ML-KEM hybrid TLS support into Windows. The IETF TLS work for ML-KEM in TLS 1.3 is active enough that this is not "future crypto" in the abstract anymore.

This is becoming normal migration work.

And normal migration work is where production breaks.

the narrow change is not that mystical

Let us remove the drama for a second.

That sounds tidy. It is not free.

The other important distinction: key exchange is not certificates.

This is exactly where I expect teams to get sloppy.

"We turned on PQC" will be used to describe three different things:

hybrid key agreement on inbound browser traffic
hybrid key agreement on service-to-service traffic
post-quantum authentication through certificates or signatures

Those are not the same migration. If a dashboard flattens them into one green check mark, be suspicious.

the cloud default will arrive before the spreadsheet is perfect

The reason to start now is not panic.

The reason to start now is that cloud defaults have a habit of becoming production defaults while the backlog still says "investigate."

Can your origin handle it?

Can the load balancer in front of the origin handle it?

Can the WAF handle it?

Can the appliance nobody wants to own handle it?

Can the old Java service using a pinned runtime handle it?

Can the fintech partner endpoint handle it?

That is platform work.

If only the cryptography people own it, the migration will produce beautiful documents and then die at the first strange proxy.

inventory beats speeches

The first useful deliverable is not a quantum readiness strategy deck.

It is an inventory.

Start with outbound clients. Which services initiate TLS connections, and with which runtime stacks?

Java with JDK TLS
Java with AWS CRT
Node.js with OpenSSL through the runtime
Go with the standard library
Rust with rustls or native-tls
Python with OpenSSL through the system or a bundled package
mobile clients pinned to OS behavior
vendor SDKs with their own HTTP clients
sidecars doing outbound TLS on behalf of the service

Then map the destinations.

AWS KMS, ACM, Secrets Manager, STS, S3, and other cloud APIs
payment processors
card networks and banking partners
identity providers
observability vendors
webhook targets
internal APIs behind meshes or gateways
customer-controlled endpoints

Post-quantum TLS will find those places.

Better you find them first.

test the path, not the box

A common mistake in migrations like this is testing one component and declaring the path safe.

"The service supports TLS 1.3."

Good. Does the whole path support the actual handshake you intend to use?

"The origin supports X25519MLKEM768."

Good. Does Cloudflare negotiate it to the origin through your current configuration?

"The SDK has a flag."

Good. Is that the HTTP client your production service actually uses, or did the dependency injection layer quietly choose a different one?

"The certificate library supports ML-DSA."

Good. Does your certificate authority, renewal pipeline, HSM, deployment process, mTLS verifier, and rollback plan support it too?

You need end-to-end tests that look like production paths:

browser to CDN to origin
Cloudflare edge to origin
service to AWS KMS
service to Secrets Manager
service to payment provider
service through mesh sidecar to internal API
mobile app to API gateway
batch job through corporate egress proxy

The word "through" is doing a lot of work there.

TLS migrations do not only fail at endpoints. They fail at the thing between endpoints that was not supposed to care.

observability needs to know what negotiated

"Turn it on" is not a strategy.

It is barely even an action unless you can prove what happened after you turned it on.

For post-quantum TLS, the minimum useful telemetry is:

negotiated TLS version
negotiated key exchange group
handshake failure rate
HelloRetryRequest rate
fallback rate to classical key exchange
TLS handshake latency
connection reuse behavior
ClientHello size distribution where you can measure it
errors by client runtime, SDK version, region, and egress path
certificate chain and signature algorithm where authentication is in scope

You probably will not get all of that on day one. Fine. Start with what your proxies, load balancers, service mesh, CDN, and client libraries can expose.

But if the only signal is "the service still seems up," you are flying blind.

Security migrations love partial success because partial success produces screenshots.

Production needs evidence.

certificates are their own migration

Cloudflare's origin documentation is useful because it refuses to hide the awkward part: post-quantum signatures are a separate track.

That should make every platform team slightly uncomfortable, in a healthy way.

Do not bundle all of that into "enable PQ TLS."

Plan it separately:

key exchange migration first where the platform supports it
certificate and signature inventory in parallel
mTLS verification rules reviewed explicitly
private CA capability checked
HSM and KMS support checked
renewal and rollback rehearsed
certificate pinning found and removed or updated
partner requirements documented

the banking/government lag is a warning

The June 2026 measurement paper on post-quantum readiness is useful because it shows the internet doing what the internet does: migrating unevenly.

That is exactly the pattern I would expect.

For fintech teams, this matters for two reasons.

First, you will be pulled forward by cloud providers and browsers.

Second, you will be held back by partners, legacy clients, compliance constraints, and external integrations.

That is not a crypto debate.

That is compatibility engineering.

rollback is part of the design

Post-quantum TLS rollout should look like every other serious platform rollout.

Small scope first. Known clients first. Clear metrics. Rollback switch. No hero deploys.

The rollback question should be boring:

How do we disable hybrid key agreement for this client?
How do we force classical fallback if a partner path breaks?
How do we know fallback happened?
Who is allowed to change the setting?
What metric tells us the rollback worked?
What customer-facing behavior would trigger rollback?

If nobody can answer those, the rollout is not ready.

And yes, this can feel absurd. We are talking about preparing rollback behavior for a future-facing cryptographic migration that most users will never notice.

That is platform engineering. Most of the work is making sure users never notice.

what i would do now

If I owned a platform today, I would not start with a grand "quantum-safe transformation program."

I would start with a small, practical checklist.

1. Build the TLS client inventory. List services, runtimes, TLS libraries, SDK versions, sidecars, mobile clients, and outbound destinations. Do not forget CI jobs and batch workloads.

2. Identify cloud service paths. Pay special attention to KMS, Secrets Manager, ACM, identity, storage, and payment-adjacent services. Security-critical endpoints will move early.

3. Test hybrid key exchange in non-production. Use real client libraries, real proxies, and realistic connection reuse. Measure handshake latency and failure rates.

4. Add negotiation telemetry. At minimum, learn which TLS version and key exchange group were negotiated where your stack exposes it. Without this, every claim is vibes.

5. Exercise middleboxes. CDNs, WAFs, API gateways, service meshes, load balancers, corporate proxies, and partner gateways are where boring TLS changes become incidents.

7. Write rollback instructions before rollout. A crypto migration without rollback is just a production experiment with a better acronym.

None of this requires panic.

It requires inventory, evidence, and boring discipline.

the punchline

Post-quantum TLS is not waiting for your organization to finish debating quantum timelines.

The teams that handle it well will not be the ones with the most dramatic quantum slide deck.

They will be the ones that can answer simple questions:

What do our clients support?

What did this connection negotiate?

Where did it fall back?

Which path broke?

Can we roll it back?

That is the migration.

Not hype. Not prophecy. Not a religious war about timelines.

Just another piece of platform work that becomes much easier if you start before the default changes.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

post-quantum tls is a platform migration, not a crypto project

Paulo Victor Leite Lima Gomes — Mon, 14 Sep 2026 12:01:33 +0000

The least useful question about post-quantum TLS is still the one people like asking first:

When will quantum computers break today's public-key cryptography?

I get why the question is attractive. It sounds strategic. It lets everyone argue about timelines, threat models, nation states, and whether the whole thing is hype. It also lets engineering teams postpone the boring work, because if the scary computer is far enough away, the migration can stay in the "future crypto" bucket.

That bucket is leaking.

Post-quantum TLS is already turning into ordinary platform migration work. Not because every company suddenly needs to panic about quantum attacks tomorrow morning, but because cloud providers, browsers, operating systems, CDNs, SDKs, cryptographic libraries, and compliance teams are starting to expose the surface area now.

AWS supports ML-KEM hybrid post-quantum TLS for KMS, ACM, and Secrets Manager. Cloudflare documents post-quantum key agreement between visitors, its edge, and origins. Microsoft has Windows platform support for ML-KEM hybrid TLS groups and post-quantum APIs. The IETF TLS work is active. The measurements say internet readiness is uneven, especially in sectors that should know better.

That is the migration signal.

The engineering problem is not "when does quantum break RSA?"

The engineering problem is "do we know which of our services, SDKs, middleboxes, payment integrations, certificate workflows, and observability paths will tolerate the TLS ecosystem changing underneath them?"

Most teams cannot answer that yet.

what is actually changing

The first wave is mostly about key exchange.

In normal TLS 1.3 today, clients and servers use classical elliptic-curve key agreement such as X25519 or P-256 to establish shared secrets for the connection. Post-quantum TLS introduces key establishment based on ML-KEM, the NIST-standardized key encapsulation mechanism that came out of the Kyber work.

The practical deployment pattern is usually hybrid key exchange. The client and server combine a classical algorithm with ML-KEM, so the connection is protected as long as at least one side of the hybrid construction remains sound. That is why you see names like X25519MLKEM768: familiar X25519 plus ML-KEM-768.

This sounds exotic until you translate it into production behavior:

the TLS ClientHello can get larger
the server response can get larger
handshakes do a little more cryptographic work
clients and servers need compatible TLS stacks
middleboxes that make assumptions about handshake size or extensions can misbehave
fallback behavior starts to matter a lot
observability needs to show what actually negotiated

AWS's measurements are a useful sanity check here. In their KMS benchmark, enabling hybrid post-quantum TLS added roughly 1,600 bytes to the handshake and a small amount of compute. With TLS connection reuse enabled, the measured request-rate impact was almost invisible for that workload. Without connection reuse, the penalty was larger but still not dramatic.

That is good news, but it is not permission to stop thinking.

Your workload is not AWS's benchmark. Your network path may have old proxies. Your mobile clients may use older TLS libraries. Your service mesh may terminate and re-originate TLS. Your fintech partner may still be on TLS 1.2. Your payment gateway may have a device in the path that nobody has touched since a migration three org charts ago.

"The crypto is fast enough" and "our platform is ready" are different claims.

signatures are a separate migration

One trap in this conversation is mixing key exchange with signatures and certificates.

Hybrid ML-KEM in TLS is about establishing the connection secrets. It helps with the "harvest now, decrypt later" concern: an attacker records encrypted traffic today and hopes to decrypt it later with a quantum computer.

Post-quantum signatures are a different problem. Certificates, certificate chains, hardware security modules, code signing, device identity, private PKI, certificate transparency, ACME workflows, load balancers, origin authentication, and audit requirements all get involved.

Cloudflare's origin documentation is interesting because it points at both sides of the house: post-quantum key agreement to the origin, and ML-DSA for origin authentication in supported paths. That is exactly how this will land in real platforms. First the key exchange knob appears. Then certificate and signature paths start appearing. Then someone asks why the team treated it as one ticket.

Do not treat it as one ticket.

Key exchange, public TLS certificates, private service certificates, client certificates, KMS/HSM integrations, and code-signing chains should be planned separately. They share vocabulary, but they do not share the same blast radius, owner, tooling, or rollback story.

If security creates a single epic called "enable PQC", platform teams should split it before the work starts.

the cloud default problem

The reason this matters now is not that every team needs to flip every switch today.

The reason is that platform defaults have a way of becoming production defaults before anyone has finished the inventory.

AWS is a good example. It already supports ML-KEM hybrid TLS on security-critical services like KMS, ACM, and Secrets Manager, and it says older CRYSTALS-Kyber support will be removed across AWS service endpoints in 2026. AWS customers using older clients can fall back to classical key agreement when the old Kyber support disappears, but that sentence should make platform teams uncomfortable.

Fallback is not the same as readiness.

If your KMS client silently falls back to classical TLS and nobody records it, you did not migrate. You just failed quietly in the safest available direction. That may be the right runtime behavior, but it is a terrible migration signal.

The same pattern shows up with CDNs and origins. Cloudflare has supported post-quantum hybrid key agreement for visitor-to-edge TLS 1.3 for years, but edge-to-origin support depends on the origin stack, protocol, and configuration. An internet user may have a post-quantum-protected connection to the edge while your origin path remains classical. Or your browser path may be ready while a server-to-server client is not.

That split is normal. It is also easy to misunderstand.

Platforms need to know where TLS terminates, where it restarts, which negotiated group was actually used, and which policy decided the fallback. Without that, "we enabled PQC" is just a sentence in a slide deck.

inventory before ideology

The practical starting point is not a cryptography debate. It is inventory.

Start with outbound clients. Which services talk to AWS KMS, Secrets Manager, ACM, payment providers, identity providers, banks, partners, and internal APIs over TLS? Which SDK versions do they use? Which HTTP clients? Which TLS libraries? Which container base images? Which runtime versions?

This is where the real mess appears.

A Java service using the AWS SDK with a modern CRT client is a different migration target from an old JVM using a default TLS provider. A Rust service using rustls is different from a Go service pinned to an old toolchain. A mobile app with embedded networking code is different from a backend worker. A legacy appliance behind a private link is different from a Lambda function. A payment integration with strict certification is different from a disposable internal dashboard.

Then map the termination points:

public edge
CDN
WAF
load balancer
API gateway
service mesh sidecar
ingress controller
outbound proxy
corporate proxy
private connectivity
payment and banking partners
KMS, HSM, and secrets services

Every TLS termination point is a policy point. Every re-origination point is a place where the post-quantum property may stop and start again.

That is the platform view. It is less glamorous than reading algorithm names, but it is the view that prevents production surprises.

middleboxes are where optimism goes to die

TLS migrations are rarely broken by the happy path.

They are broken by the thing in the middle that nobody remembers owning.

Post-quantum key exchange makes this worse because larger handshakes and newer TLS extensions stress old assumptions. Some boxes inspect ClientHello messages. Some enforce brittle allowlists. Some have buffer limits. Some do TLS interception. Some fail open, some fail closed, and some fail in a way that looks like random packet loss at 2 percent of traffic.

If you work in fintech, this should feel familiar. The clean architecture diagram says service A calls partner B over TLS. The production path says service A calls an outbound proxy, then a network appliance, then a private connectivity service, then a partner gateway, then something on the other side that nobody is allowed to inspect directly.

The only honest way to migrate that is to test the real path.

Not just "curl from my laptop."

Test from the actual workload environment. Test through the actual proxy. Test with the actual SDK. Test the payment provider sandbox and, when allowed, a controlled production path. Test with connection reuse on and off. Test with the same retry behavior the service uses in anger.

And when the fallback happens, record it.

observability is the migration control plane

Here is the part I would be annoying about in a design review: if nobody can tell what negotiated, nobody has enabled anything meaningful.

A post-quantum TLS rollout needs observability before rollout. At minimum, teams should be able to answer:

Which TLS version negotiated?
Which key exchange group negotiated?
Did the client offer ML-KEM or a hybrid group?
Did the server select it?
Did the connection fall back to classical key exchange?
Which client library and version made the connection?
Which proxy or load balancer handled it?
Did handshake failures, latency, or retry rates change?
Did connection reuse hide a handshake problem until scale changed?

Some of this data lives in load balancer logs. Some lives in CDN analytics. Some can be exposed by TLS libraries. Some may require synthetic probes. Some may need targeted packet captures in test environments.

The exact implementation matters less than the discipline: negotiate, observe, prove, then expand.

"Turn it on" is not a strategy. "We can prove 97 percent of KMS traffic negotiated X25519MLKEM768, 3 percent fell back because of these client versions, and here is the upgrade plan" is a strategy.

That sentence is also the difference between platform engineering and theater.

the readiness gap is real

The internet is not moving as one clean block.

A 2026 measurement study across 32,011 domains found that modern protocols like TLS 1.3 and QUIC are spreading, but a meaningful slice of domains still rely on TLS 1.2, with banking and government called out among the sectors where the gap matters. The same paper looked at negotiated TLS parameters, key exchange, and certificates, which is exactly the sort of messy operational evidence this migration needs.

That finding matches the platform intuition. Consumer browsers and big CDNs can move quickly. Large cloud providers can move their managed endpoints. But enterprise clients, partner integrations, regulated systems, old JVMs, TLS-terminating appliances, and private PKI workflows move slowly.

So the rollout will be uneven.

Uneven rollouts are where compatibility assumptions become incidents.

This is why I dislike the framing of PQC as a security team's future project. Security should absolutely drive the risk model and migration pressure. But the work touches platform ownership: runtime images, SDK baselines, service meshes, gateway configuration, certificate automation, observability, change management, and rollback.

If the only team with a ticket is security, the migration is already under-scoped.

what I would do first

I would not start by mandating post-quantum TLS everywhere.

I would start by making the platform able to see it.

Pick one important but bounded path. AWS KMS is a good candidate for many teams because it is security-sensitive, heavily used, and now has concrete client configuration. Enable hybrid post-quantum TLS in a controlled environment. Record the negotiated group. Measure handshake latency and error rates. Verify that connection reuse behaves the way you think it does. Then try the same thing through your real service runtime, not a toy client.

From there, build the inventory:

services that can offer hybrid ML-KEM today
services blocked by old SDKs or TLS libraries
paths that terminate at the CDN only
edge-to-origin paths that can negotiate hybrid key agreement
proxies and middleboxes that need explicit testing
partner integrations that need certification or support confirmation
certificate workflows that will be affected later by post-quantum signatures
dashboards that can prove negotiation and fallback

That gives you a migration map instead of a slogan.

It also gives security something better than "we are waiting for the industry." It gives them dates, owners, blockers, and evidence.

the small checklist

If you want a non-dramatic starting point, this is the checklist I would put in front of a platform team:

Inventory outbound TLS clients, SDKs, runtimes, and TLS libraries.
Identify every TLS termination and re-origination point.
Separate key exchange migration from certificate and signature migration.
Pick one bounded path, such as KMS, and test hybrid ML-KEM end to end.
Capture negotiated TLS version, key exchange group, fallback, latency, and errors.
Test through real proxies, gateways, service meshes, CDNs, and partner paths.
Check connection reuse assumptions before trusting benchmark numbers.
Track old SDKs and clients that silently fall back to classical key exchange.
Add dashboards before broad enablement.
Treat payment, banking, KMS, HSM, secrets, and private PKI paths as first-class migration surfaces.
Write the rollback story before turning defaults on.

None of this requires panic.

It does require refusing the comfortable story that post-quantum TLS is just a crypto library upgrade. It is not. It is a platform migration with cryptography inside it.

The teams that do the boring inventory now will have a quiet advantage later. When the defaults move, they will already know which clients can negotiate, which paths fall back, and which certificate workflows are a separate project.

Everyone else will discover their TLS architecture from error rates.

That is a lousy way to learn.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

post-quantum tls is a platform migration, not a crypto project

Paulo Victor Leite Lima Gomes — Mon, 14 Sep 2026 10:33:27 +0000

The least useful question about post-quantum TLS is still the one people like asking first:

When will quantum computers break today's public-key cryptography?

That bucket is leaking.

That is the migration signal.

The engineering problem is not "when does quantum break RSA?"

Most teams cannot answer that yet.

what is actually changing

The first wave is mostly about key exchange.

This sounds exotic until you translate it into production behavior:

the TLS ClientHello can get larger
the server response can get larger
handshakes do a little more cryptographic work
clients and servers need compatible TLS stacks
middleboxes that make assumptions about handshake size or extensions can misbehave
fallback behavior starts to matter a lot
observability needs to show what actually negotiated

That is good news, but it is not permission to stop thinking.

"The crypto is fast enough" and "our platform is ready" are different claims.

signatures are a separate migration

One trap in this conversation is mixing key exchange with signatures and certificates.

Do not treat it as one ticket.

If security creates a single epic called "enable PQC", platform teams should split it before the work starts.

the cloud default problem

The reason this matters now is not that every team needs to flip every switch today.

The reason is that platform defaults have a way of becoming production defaults before anyone has finished the inventory.

Fallback is not the same as readiness.

That split is normal. It is also easy to misunderstand.

inventory before ideology

The practical starting point is not a cryptography debate. It is inventory.

This is where the real mess appears.

Then map the termination points:

public edge
CDN
WAF
load balancer
API gateway
service mesh sidecar
ingress controller
outbound proxy
corporate proxy
private connectivity
payment and banking partners
KMS, HSM, and secrets services

Every TLS termination point is a policy point. Every re-origination point is a place where the post-quantum property may stop and start again.

That is the platform view. It is less glamorous than reading algorithm names, but it is the view that prevents production surprises.

middleboxes are where optimism goes to die

TLS migrations are rarely broken by the happy path.

They are broken by the thing in the middle that nobody remembers owning.

The only honest way to migrate that is to test the real path.

Not just "curl from my laptop."

And when the fallback happens, record it.

observability is the migration control plane

Here is the part I would be annoying about in a design review: if nobody can tell what negotiated, nobody has enabled anything meaningful.

A post-quantum TLS rollout needs observability before rollout. At minimum, teams should be able to answer:

Which TLS version negotiated?
Which key exchange group negotiated?
Did the client offer ML-KEM or a hybrid group?
Did the server select it?
Did the connection fall back to classical key exchange?
Which client library and version made the connection?
Which proxy or load balancer handled it?
Did handshake failures, latency, or retry rates change?
Did connection reuse hide a handshake problem until scale changed?

The exact implementation matters less than the discipline: negotiate, observe, prove, then expand.

"Turn it on" is not a strategy. "We can prove 97 percent of KMS traffic negotiated X25519MLKEM768, 3 percent fell back because of these client versions, and here is the upgrade plan" is a strategy.

That sentence is also the difference between platform engineering and theater.

the readiness gap is real

The internet is not moving as one clean block.

So the rollout will be uneven.

Uneven rollouts are where compatibility assumptions become incidents.

If the only team with a ticket is security, the migration is already under-scoped.

what I would do first

I would not start by mandating post-quantum TLS everywhere.

I would start by making the platform able to see it.

From there, build the inventory:

services that can offer hybrid ML-KEM today
services blocked by old SDKs or TLS libraries
paths that terminate at the CDN only
edge-to-origin paths that can negotiate hybrid key agreement
proxies and middleboxes that need explicit testing
partner integrations that need certification or support confirmation
certificate workflows that will be affected later by post-quantum signatures
dashboards that can prove negotiation and fallback

That gives you a migration map instead of a slogan.

It also gives security something better than "we are waiting for the industry." It gives them dates, owners, blockers, and evidence.

the small checklist

If you want a non-dramatic starting point, this is the checklist I would put in front of a platform team:

Inventory outbound TLS clients, SDKs, runtimes, and TLS libraries.
Identify every TLS termination and re-origination point.
Separate key exchange migration from certificate and signature migration.
Pick one bounded path, such as KMS, and test hybrid ML-KEM end to end.
Capture negotiated TLS version, key exchange group, fallback, latency, and errors.
Test through real proxies, gateways, service meshes, CDNs, and partner paths.
Check connection reuse assumptions before trusting benchmark numbers.
Track old SDKs and clients that silently fall back to classical key exchange.
Add dashboards before broad enablement.
Treat payment, banking, KMS, HSM, secrets, and private PKI paths as first-class migration surfaces.
Write the rollback story before turning defaults on.

None of this requires panic.

It does require refusing the comfortable story that post-quantum TLS is just a crypto library upgrade. It is not. It is a platform migration with cryptography inside it.

Everyone else will discover their TLS architecture from error rates.

That is a lousy way to learn.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.