AI Does Not Prevent Disasters. It Buys Time.

The brief for this cycle was "how AI can prevent/help natural disaster from happening." Half of that sentence is wrong.

AI does not stop a river, a cyclone, or a fault. It can, in a growing set of places, buy time — hours for a flood, days for a storm track, seconds for a quake if you are not at the epicenter — and then map what broke so the next truck is not a guess. Whether anyone spends that time is still a human job: cash, sandbags, a bus, a closed road.

On 7 July 2026 the ITU, UNDRR, WMO and IFRC published Leveraging AI to Enhance Multi-Hazard Early Warning Systems, a practical annex to the UN's Early Warnings for All (EW4All) push since COP27. Google's crisis-resilience write-up of the same day is the most concrete public inventory of what is actually in production. This post is a map of those jobs. It is not a product roundup, and it is not a claim that models "prevent" weather.

Four jobs, not one slogan

Lump "AI for disasters" into one slide and you get hype. Split it and you can audit a pitch.

1. Forecast the hazard. Rain, river stage, cyclone track, fire weather, flood extent. This is the grown-up layer: hydrology models, nowcasts, WeatherNext-class atmosphere models. It is also where local gauges still beat a global prior.

2. Get the warning to a phone that can act. Common Alerting Protocol (CAP) feeds into Search, Maps, and Android. Public Alerts from national services. This is dissemination, not meteorology. A perfect forecast that dies in a PDF is not an early warning system.

3. Spend the lead time. Anticipatory action: cash before the water, sandbags, pre-positioned shelter. This is the part vendors skip. GiveDirectly paying families in Kogi State, Nigeria, before a forecast flood is the honest success story — not because a model is magic, but because someone wired money while shops were still open.

4. Map the damage. Satellite plus building footprints plus a damage classifier, so UNOSAT is not hand-tracing 400,000 roofs. This is response, not prevention. It starts after the event.

If a vendor mixes 1–4, ask which job they actually run, on whose authority, and what happens when the model is wrong.

A December 2025 SAPEA evidence review for EU science advice said the same thing in plainer language: AI is strongest on standard, data-heavy, frequent hazards — floods, wildfires, droughts — and weakest where events are rare, labels are thin, or physics does not give you a precursor. That is a product constraint, not a temporary bug.

Floods: the operational case

River floods are where AI early warning has left the demo.

Google Flood Hub is the public face: coverage on the order of two billion people across more than 150 countries in basins with significant flood risk. UN OCHA stood up a Floods Anticipatory Action Programme in Adamawa, Nigeria, on those river forecasts. When the model crosses a threshold, the programme is supposed to trigger early interventions (shelter, not a tweet). GiveDirectly used the same class of forecast in Kogi State to send cash transfers before the water, so households could leave and buy sandbags.

That is "help." It is not "prevent the flood." The river still comes. The difference is whether the household still has a working ATM.

Two caveats belong next to the coverage number:

• Ungauged basins still need local data. A WMO pilot with hydrological services in Czechia, Nigeria, Uruguay and Vietnam found that stuffing local streamflow into a global AI model materially improves forecasts where gauges are sparse. Google open-sourced a hydrology modeling framework and a Groundsource dataset for urban flash floods so agencies can keep their own observations. The lesson is not "delete the hydrologist." It is "the global prior is a starting weight."
• Urban flash floods are a different product from large-river stage. Do not sell a basin model as a storm-drain model.

If you run a city: buy the forecast only if it is wired into a playbook with a budget. A dashboard is not anticipatory action.

Cyclones: days, if the track is the question

During the 2025 Atlantic season the US National Hurricane Center used Google's WeatherNext model. For Hurricane Melissa (October 2025) it had a historic Jamaican landfall about five days out, which Jamaica's Met Service could actually put on air. Five days is a lot of time for a small island. It is not a guarantee of a quiet week, and it does not move the storm.

Treat track skill and intensity skill as different products. A landfall call that is early and a wind-field call that is late are not the same win. Do not quote one as the other.

Wildfires: see it sooner, not put it out

The operational AI job on fire is detection and perimeter, not suppression.

Google tracks fire boundaries from satellite imagery in Search and Maps in 34 countries. FireSat, with the Earth Fire Alliance and Muon Space, is a purpose-built constellation aimed at faster detection before a start becomes a run. Additional FireSat birds launched from Vandenberg on the day of the UN report (7 July 2026). That is a sensor program. It does not rain.

If you sell "AI will prevent wildfires," you are selling weather control. If you sell "the duty officer sees a start in minutes instead of hours," you are in the real market. Fuel, wind, and crews still decide the rest.

Earthquakes: seconds, not days

Earthquakes are the clean counter-example, and they should stay in every brief so the flood story does not colonize the whole category.

Nobody has a reliable earthquake prediction product. What exists is early alerting after the rupture has started: P-waves, dense sensors, a few seconds to tens of seconds for people away from the epicenter. Google's Android Earthquake Alerts treat phones as a seismometer network. When earthquakes hit Venezuela in June 2026, the system alerted millions of users outside the epicenter so they could take cover before the strong shaking arrived. That is real. It is also not a forecast you can evacuate a city on.

Do not put "earthquake prediction" on a platform list next to "flood forecast." They are not the same maturity, and pretending they are gets people killed.

After: maps that save weeks

Once the water or wind has happened, the bottleneck is counting damage fast enough for logistics.

UN Global Pulse's DISHA workflow, with Google Open Buildings and a building-damage model, is in use with UNOSAT. Google says it has been deployed 11 times. On Hurricane Melissa it assigned preliminary damage scores to more than 385,000 buildings. After the February 2026 floods in Colombia, UNOSAT crossed AI building maps with radar flood extent so humanitarian agencies had a picture instead of a backlog.

This is not early warning. It is the fourth job. Keep it in the stack because it is where computer vision actually earns its keep — and because it is the job most "prevention" decks quietly skip when they need a pretty map.

A short test for any disaster-AI pitch

1. Which of the four jobs is this? Forecast, alert, anticipatory action, or damage map. If the answer is "all of them," it is a brochure.
2. What is the lead time, in the hazard's own units? Days for a basin flood. Hours for flash flood. Seconds for a quake. "Real time" is not a unit.
3. Who is allowed to spend the warning? A finance ministry, a Red Cross cash programme, a fire duty officer. If there is no spender, the model is a screensaver.
4. What happens when it is wrong? False alarm fatigue is how you lose the next real event. A review budget — like cricket's DRS — is the grown-up design. Fully automatic alerts with no human-call band will be ignored or, worse, trusted.

What to steal if you build software

You are probably not a met service.

• Steal the anticipatory cash lesson, not the globe. Wire the forecast to a payment or a ticket, with a human threshold.
• Steal the local gauge lesson: a global model plus your own stream is better than either alone. Keep the observations.
• Steal the seconds vs days lesson: product maturity is lead time, not model size. Do not ship earthquake-prediction copy.
• Steal the damage map lesson: computer vision on a known building layer beats a chatbot summarizing tweets.

If you are a board or a ministry: buy a forecast only with a CAP feed, a playbook, and a budget line that can move before the crest. If the analyst cannot query what the public just saw, you paid for a cartoon.

What not to do

Do not say AI prevents natural disasters. Do not equate Flood Hub coverage with "the world is warned." Do not sell wildfire detection as suppression. Do not put earthquake prediction in a 2026 roadmap. Do not skip false-alarm cost. Do not treat a satellite damage score as a cadastral survey.

A simple map

Job	What exists in 2026	What it is not
Forecast floods / some storms	Flood Hub-class rivers; WeatherNext tracks	Weather control
Alert	CAP → Search / Maps / Android	A substitute for a siren network
Spend the time	OCHA / GiveDirectly-style anticipatory cash	Automatic
Detect fire	Perimeters, FireSat	Putting the fire out
Quake	Seconds outside epicenter	Prediction
After	UNOSAT / DISHA building scores	Prevention

The UN report is useful because it is boring in the right way: pillars, not miracles. AI helps where the data is dense and the action is already funded. Everywhere else it is a prototype with a keynote.

If you only remember one line: the model buys time; a human still has to spend it.

More at amtocbot.com.

AI in Cricket: Competitive, Watchable, Still Human

Cricket adopted computer vision before most sports called it AI. Hawk-Eye started as a broadcast graphic. Then umpires started arguing with the graphic. Then the graphic became part of the laws of the game.

The interesting question in 2026 is not "does cricket use AI?" It does. The question is which jobs it makes more competitive, and which jobs it only makes louder.

This post is a map of those jobs: officiating, broadcast, strategy, and the club game. It is not a product roundup.

What "AI" actually means on a cricket field

Three different systems get lumped together.

1. Tracking and sensors. High-speed cameras triangulate the ball. Microphones pick up snick. Infrared cameras show contact. That stack is the Decision Review System: Hawk-Eye for path, UltraEdge / Snickometer for sound, Hot Spot for heat. Paul Hawkins built the tracking company after a Ph.D. in AI; the product on TV is computer vision plus a lot of calibration.

2. Event coding and analytics. Ball-by-ball logs, wagon wheels, matchup tables, predicted shot maps. Vendors in this layer (CricViz is the name most fans have heard) turn the stream of deliveries into something a coach can argue with. Broadcast win-probability graphics sit here too.

3. Production and fan surfaces. Player tracking overlays, free-viewpoint replays, auto-cut highlights, fantasy and second-screen products. The India–Afghanistan T20Is in September 2026 are a useful snapshot: Quidich Spatio (AR on a stabilised drone plus optical tracking), ultra-motion cameras, volumetric free-viewpoint. That is not umpiring. That is making the same 22 yards watchable on a phone.

If you mix those three, you get hype. If you keep them separate, you can ask a better question: did this system change a result, a plan, or only a replay?

Officiating: more accurate, not automatic

DRS is the most visible AI product in cricket because it is allowed to overrule a human in public.

It is also narrower than the ads. Ball-tracking projects a path; it does not "know" LBW. UltraEdge shows a spike; someone still has to decide whether that spike is bat, pad, or ground. The on-field umpire's call remains a designed feature, not a bug: the sport chose a band of uncertainty instead of a fully automated strike zone.

That choice is the live debate across sport. Tennis moved to electronic line calling. Football is inching toward semi-automated offside. Cricket kept a human in the loop and put a review budget on the players. The competitive effect is real — fewer howlers, more specialist review craft — and it is still a human contest about when to spend a review.

Club-level DRS products (Crik.ai and similar) try to bring a cheap version of that stack to grounds without six broadcast cameras. Treat claimed accuracy numbers as vendor claims until an independent league publishes them. The direction is right: fairness should not only exist on TV.

Broadcast: the game became a data product

For a viewer, AI in cricket mostly means graphics.

Trajectory, pitch maps, predicted swing, "what's the percentage?" after a wicket. Those overlays are why T20 is easier to watch if you did not grow up with the sport. They are also why a quiet Test session can feel like a dashboard.

The production race in 2026 is volumetric and POV: a 3D twin of the pitch so a director can put a virtual camera inside the shot. That makes cricket more interesting on a second screen. It does not make a batter more competitive. It makes the audience more competitive for attention.

If you run a league, this is COGS. If you run a team, it is only useful when the same tracking feed reaches the analyst before the next over.

Strategy: the quiet stack

The competitive edge is not the TV graphic. It is the file the analyst opens at 7 a.m.

• Auction and squad construction: which player is mispriced relative to role, venue, and death-over skill.
• Matchup tables: this batter vs this length, this spinner vs the short boundary.
• Load and availability: wearables and bowling-workload models, so you do not burn a quick on the wrong night.
• Opposition scouting at volume: computer vision that codes events from video when you do not have a full Hawk-Eye install.

NV Play's Vision AI is a useful example of the last one: automatic ball trajectories and event coding from video, aimed at analysts, streamers, and levels of the game that never had a broadcast truck. Grassroots platforms (CricHeroes, smartphone coaching) sit even further down: a club that can see line-and-length without a statistician.

None of this replaces a captain. It changes what a captain is allowed to not remember.

What actually makes the contest better

A short test for any cricket-AI pitch:

1. Does it change a decision that used to be a coin flip? DRS on LBW and run-out: yes. A new graphic of the same lbw: no.
2. Does it change preparation? Matchup data and workload: yes, if the team actually uses it. A "AI coach" chatbot: usually no.
3. Does it change who can play? Cheap tracking and scouting at club level: maybe the most important long-term effect, and the least televised.
4. Does it keep the human argument? Cricket's product is uncertainty with rules. Fully automated umpiring would be more accurate and less cricket. The interesting design is where you leave the argument.

What to do with this if you build software

If you are not a board or a broadcaster:

• Steal the DRS lesson, not the overlay. Put a review budget on irreversible agent actions. Keep a human-call band.
• Steal the analytics lesson: log the job (the delivery), not the vibe. Ball-by-ball is just event sourcing with better marketing.
• Steal the grassroots lesson: a phone camera plus a model beats a 40-person scoring team for 90% of games. Most sports still have not noticed.

If you are a board: buy tracking that feeds both TV and the dressing room. If the analyst cannot query what the viewer just saw, you paid for a cartoon.

What not to do

Do not call a win-probability graphic "AI umpiring." Do not sell a club an international DRS stack. Do not pretend fantasy-league clickstream is the same as player development. Do not skip the calibration: Hawk-Eye is famous because the cameras are placed and maintained, not because a model is magic.

A simple map

Job	System	Competitive effect
LBW / nick / run-out	DRS (track + audio + heat)	Fewer howlers; review as a skill
Story on TV	Overlays, free-viewpoint, ultra-motion	More watchable; not more runs
Plan the next over	Event data, matchups, load	Quiet, large if used
Find the next player	Video coding, club apps	Wider funnel

Cricket got good at AI by accident: it needed to see the ball. The sports that will copy it are the ones that pick a job that small.

More at amtocbot.com.

Claude Text Watermarks and EU Provenance: What Publishers Should Disclose

On 14 August 2026 Anthropic published how it will watermark future Claude text. The short version: new models will mark outputs; a mark is a likelihood, not a confession; you still have to say when you used the model. The long version is Article 50 of the EU AI Act, a July 2026 Code of Practice, and a detection API that is not shipping yet.

This post is for people who publish with Claude, ship a product on the Claude API, or have to write a disclosure line that will survive legal review. Sources: How Claude’s text watermark works (14 August 2026) and How Claude marks AI-generated content.

Two clocks

The EU rule for providers serving its market is already on. Anthropic’s implementation is staggered.

When	What actually happens
2 August 2026	EU marking obligation for AI providers serving the EU market. Anthropic’s cutoff for “new models mark at launch.”
July 2026	Anthropic and other major providers signed the EU Code of Practice on Transparency of AI-Generated Content (~190 signatories).
14 August 2026	Anthropic explained the method: SynthID-Text-style token-choice watermark; C2PA credentials on supported files.
Coming months	Detection API “soon.” Older models (launched before 2 August 2026) get marking during a transition period.

If your stack is still Sonnet 4 / Opus 4.x, do not assume every paste is already watermarked. Anthropic is explicit that models launched on or after 2 August 2026 support marking at launch, and that pre-cutoff models are “in progress.” Independent testers in mid-August reported nulls on some current Claude names; treat that as “not yet,” not as “never.”

What the watermark is (and is not)

Claude still picks the next token from the same candidate list. On low-stakes choices (“overcast” vs “grey”), the source of the randomness is a key plus recent tokens instead of a plain RNG. Google DeepMind published the family as SynthID-Text in Nature in 2024. Anthropic says internal tests and DeepMind’s own thumbs-up study showed no practical quality hit, no extra tokens, no extra price, no hidden characters.

It does not:

• Identify a user, org, or chat
• Prove a human did not write the piece
• Prove a different model wrote it (other vendors have other keys, other methods)
• Survive a full rewrite
• Work well on short samples, dense facts, or “fix only the grammar” edits
• Sit heavily in code, where the next token is often forced

A translation Claude writes is fully watermarked, because Claude chose every word. A proofread of your draft may not register at all.

Files are a different channel. Supported images (PNG, JPG, SVG, and similar) get a C2PA signed content credential in metadata: Claude was involved. That is not woven into pixels. Strip metadata, screenshot, or re-save and it is gone. Anthropic will offer a drop-a-file checker; any C2PA-aware tool can read the label.

Marks apply worldwide on supported models, including API, Claude, Claude Code, Cowork, Tag, and cloud partners (AWS, Google Cloud, Microsoft Foundry). Provenance metadata may not exist on every platform.

What publishers should disclose

The watermark is the provider’s Article 50 marking duty. Your duty as a deployer or publisher is separate. Anthropic says: if you build on Claude, assess what Article 50 requires of your product. Do not wait for their detection API to write your user-facing sentence.

A workable 2026 policy for a blog, newsletter, or docs site:

1. Say when Claude (or any model) drafted or substantially rewrote the piece. A machine-readable mark is not a substitute for a human-readable line. Readers and regulators will not run a detector on every URL.
2. Do not claim “this is 100% human” just because a detector is quiet. Pre-cutoff models, short blurbs, heavy edits, and other vendors all produce silence.
3. Do not claim “Claude wrote this” just because a detector fires. Anthropic’s own FAQ: a mark means Claude was likely involved — author, heavy editor, or translator. It is not a plagiarism verdict and not a quality score.
4. Keep file provenance if you ship Claude-generated images. Prefer formats that retain C2PA. Do not treat a PNG screenshot as equivalent.
5. If you are in the EU market or selling into it, write the disclosure into the CMS template, not into a one-off author bio. The Code of Practice is about systems, not hero posts.

For API products: the watermark is at the model, so it is in the text you receive. You still need your own UI disclosure if you present that text as your product’s output. You cannot “turn off” the token-choice mark on a supported model.

What not to do

Do not treat a forthcoming detection API as a cheating oracle for students or employees. Do not fire someone, reject a paper, or nuke a PR because a likelihood score moved. Do not strip C2PA and then claim the image is unmarked in a legal sense — the Act cares about the act of marking, not about whether you later flattened the file. Do not assume US-only traffic exempts you; Anthropic is applying marks globally because it cannot yet scope by region. Do not wait for “older models to catch up” before you write the disclosure sentence.

A simple map

Signal	What it supports	What it does not support
Claude text watermark (supported model)	“Claude was likely involved in some of these tokens”	Authorship, cheating, other vendors, short text
C2PA on a Claude file	“This file was processed by Claude, and whether it was tampered with after signing”	A screenshot, a re-encoded JPEG, a PDF print
Your published disclosure line	What a reader and a regulator can actually use	Nothing, if you skip it and hope the watermark is enough
Third-party “AI detectors” (style tells)	A different, noisier guess	Anything you would bet a job on

The EU rule is a provider marking rule plus deployer transparency. Anthropic is doing the first with SynthID-style text and C2PA files. You still own the sentence on the page. Write it now. Update it when the detection API actually exists.

This post is part of our operator notes on shipping AI. Follow the series at amtocbot.com.

AI as Infrastructure: Value Moves Up-Stack

For a few years the AI conversation was about who had the biggest model. That is the wrong altitude now. Models still matter, the way CPUs still matter — as a layer you buy, swap, and budget for. The margin is moving up the stack: into products, workflows, evaluation, and the data those products sit on.

This post is for people who ship software, buy inference, or have to explain to a board why "we use GPT/Claude/Grok" is not a strategy. It is not a market-sizing deck.

The stack, in one picture

At Davos 2026, NVIDIA's Jensen Huang described AI as a five-layer cake: energy, chips, computing infrastructure, models, and applications. Each layer has to be built and paid for. The application layer is the only one end users touch, and it is the reason the four layers underneath exist.

Two things follow.

First, the bottom of the cake is capital-intensive and crowded. Hyperscalers are pouring unprecedented capex into data centers, accelerators, and networking. That spend is real. It is also not where most product companies will differentiate.

Second, inference is now the production workload. Training still happens, but the day-to-day cost of AI is tokens out the door. Industry commentary through 2026 has inference taking a majority of AI compute, with agentic and reasoning workloads as the fastest-growing slice. If you run a product, you are in the inference business whether you meant to be or not.

Why models commoditize

A model is a capability. Capabilities leak.

Open weights, falling inference prices, and "good enough" alternatives mean the gap between the frontier API and the second-best option keeps shrinking for a large class of tasks. Routing, distillation, and small specialists eat the middle. The brand of the model still matters for a few flagship surfaces. It does not matter for most internal workflows.

That is the same pattern as cloud VMs, then containers, then managed databases. The undifferentiated layer gets cheaper and more interchangeable. Buyers stop paying a premium for "we have compute" and start paying for "this job is done."

What does not commoditize as fast:

- Proprietary data you can legally use in the loop

- Evaluation that matches the actual job (not a public leaderboard)

- Workflows that already live in the customer's day

- Distribution: the place the user already is

- Trust, audit, and on-call when the model is wrong

Those sit above the model.

Where the margin actually is

If the model is infrastructure, the product is the control plane.

Think of inference the way you think of a database. You do not advertise "we use Postgres." You advertise the workflow: the ticket that closes, the draft that ships, the claim that is coded, the incident that is triaged. The database is a line item. The workflow is the company.

Three practical consequences:

1. Switching cost lives in integration, not in the model card. Prompt libraries, tool schemas, eval sets, and human review queues are the lock-in. If those are thin, a competitor can swap your model next quarter.

2. Unit economics are tokens plus people. An agent that spends $0.04 of inference and $4 of human cleanup is not an agent product. It is a demo. Measure cost per completed job, not cost per million tokens.

3. Routing is a product decision. Different jobs want different models: cheap/fast for classification, stronger/slower for irreversible actions, local for data that cannot leave. The routing policy is yours. The vendors will all claim to be the only layer you need.

What to do this quarter

If you run a product or an internal platform:

- Treat the model API as a vendor, with a backup. Write a one-page "we can switch in 30 days" test and actually run it on one workflow.

- Put evals next to the feature, not in a slide. A frozen set of real tickets/emails/PRs beats a public benchmark.

- Own the workflow artifact: the ticket, the document, the PR, the claim. That is the up-stack asset.

- Budget inference as COGS, not as R&D theater. If you cannot say cost per successful task, you cannot say whether the feature should exist.

If you buy AI for a team:

- Ask "which job gets shorter?" not "which model is smartest?"

- Prefer tools that sit in the existing system of record. A new chat window is the down-stack move.

If you invest or advise:

- The crowded trade is GPUs and frontier brands. The quieter trade is the control plane: eval, routing, permissions, and industry workflow.

- Be suspicious of stories that stop at "we have access to a model." That is table stakes in 2026.

What not to do

Do not freeze the architecture on one vendor's chat API. Do not skip evals because the demo was impressive. Do not confuse "employees have Copilot seats" with "we captured workflow margin." Do not wait for the model layer to stabilize before you own the job — the model layer is supposed to keep moving. That is what infrastructure does.

A simple map

Layer	What you buy	Where the margin is
Energy / chips / clusters	Capex, cloud commit	Hyperscalers and hardware
Models	API or weights	Labs, briefly; then price
Inference serving	Tokens, latency, region	Utilities, unless you own routing
Apps and workflows	Completed jobs	You, if you own the loop

The punchline is not that models are worthless. It is that they are becoming plumbing. Plumbing has to be reliable, billed, and replaceable. The company that wins is the one whose product still works when the pipe is swapped.

This post is part of our operator notes on shipping AI. Follow the series at amtocbot.com.

How WebSockets Work — LearningTechBasics

LT LearningTechBasics @amtocbot

How WebSockets Work

Upgrading a one-shot request into a two-way live wire.

📅 2026-08-14⏱️ ~5 min read🏷️ Networking · WebDev

Plain HTTP is request-response: the client asks, the server answers, done. WebSockets keep the connection open so either side can send messages at any time — ideal for chat, live data, and games.

A

🌐

Browser

B

🖥️

Server

1HTTP Upgrade: websocket

2101 Switching Protocols

3↔ frames flow freely

4either side sends anytime

Legend — how to read this diagram

A · BPartiesthe two sides of the exchange

1–nOrdereach message, numbered in sequence

1 2 3Walkthroughnumbered steps below run in order

From HTTP to a live socket

1. Upgrade request. The browser sends a normal HTTP request with an Upgrade: websocket header.
2. 101 response. The server agrees and switches protocols on the same TCP connection.
3. Full duplex. Both sides now send lightweight frames whenever they want.
4. Close. Either side sends a close frame to end the conversation.

When to reach for them

Push, not poll. No repeated requests asking 'anything new?' — the server just tells you.

Low overhead. Frames are tiny compared to full HTTP requests.

Not always needed. For occasional updates, Server-Sent Events or polling may be simpler.

One-line mental model:

Start as HTTP, then upgrade the same connection into a persistent two-way channel.

Found this useful? Three ways to go deeper — start free.

Free · Weekly One tech idea, in your inbox

The same clear explainers, delivered weekly. No spam, unsubscribe anytime.

Subscribe free →

Guide · $39 The Open-Source AI Stack

120+ page production guide: local LLMs, fine-tuning, RAG, and domain-specific AI.

Get the guide →

Consulting Need this built properly?

AI implementation, fine-tuning and RAG done right. Free 30-minute strategy call.

Book a call →

Made by LearningTechBasics · @amtocbot · One tech idea, clearly explained · #LearningTechBasics

Let's Encrypt's Post-Quantum TLS Timeline: What Site Owners Change, and When

On 3 June 2026, Let's Encrypt published its plan for a post-quantum-safe Web PKI. The short version: your current certificates do not change today. The long version is a timeline, a new certificate design, and one server setting that actually matters this year.

This post is for people who run websites, terminate TLS, or maintain ACME clients — not for cryptographers. Source: A Post-Quantum Future for Let's Encrypt (Andrew Gabbitas, 3 June 2026).

Two different post-quantum problems

TLS does two jobs. Encryption hides the bytes. Authentication proves you reached the right server.

Encryption is the urgent one. An attacker who records traffic today can try to decrypt it later, once a cryptographically relevant quantum computer exists. That is the "harvest now, decrypt later" problem. The fix is already shipping: hybrid post-quantum key exchange, typically X25519MLKEM768 (classic X25519 plus NIST's ML-KEM). Major browsers and operating systems already support it. If your server does too, those connections are protected against future decryption of recorded sessions.

Authentication is slower to migrate. A quantum computer has to forge a signature in real time, not retroactively. Let's Encrypt still treats it as work that has to start now, because root programs, libraries, and ACME clients take years to move, and because governments have put dates on the wall: NSA CNSA 2.0 aims national-security systems at 2030–2035; NIST's draft guidance would deprecate RSA-2048 and P-256 after 2030 and disallow them after 2035; the EU roadmap targets high-risk systems by the end of 2030 and broad migration by 2035. Google and Cloudflare have both said they will migrate their own services by 2029.

Why not just put ML-DSA on every certificate?

The obvious next step is to replace RSA/ECDSA signatures with ML-DSA, the NIST-standardized post-quantum signature scheme. Size kills that as a default for the public web.

ML-DSA-44 signatures are about 2,420 bytes. RSA-2048 signatures are 256 bytes; ECDSA P-256 signatures are 64 bytes. Public keys grow as well. A typical Web PKI handshake today carries five signatures and two public keys. Swap those for ML-DSA and one handshake can exceed 10 kilobytes. Cloudflare's measurements show a meaningful share of real-world TLS connections fail at that size; the rest get slower. Let's Encrypt will not flip that on as the default.

They are tracking ML-DSA in X.509 (RFC 9881) and in TLS, and Go 1.27 adding ML-DSA to the standard library. Those pieces still matter. They are not the issuance path Let's Encrypt is betting on for web scale.

Merkle Tree Certificates instead

The path they announced is Merkle Tree Certificates (MTCs).

A conventional CA signs each certificate individually. An MTC CA issues certificates in batches. One signature covers the batch. Browsers keep a separately updated "landmark" of those batch signatures. In the common case, the TLS handshake then carries one signature, one public key, and one inclusion proof — smaller than today's handshake, even with post-quantum algorithms. If a client's landmark is stale, a larger "standalone" form is the fallback.

Transparency is not bolted on after issuance. The certificate only exists as a leaf in a published Merkle tree. Let's Encrypt has run Certificate Transparency logs (append-only Merkle trees) in production since 2019, so the data structure is not new to them.

Chrome has said MTCs are its preferred path for post-quantum certificates on the public web. Cloudflare and Chrome are already running a feasibility experiment against live traffic. The IETF PLANTS working group is standardizing the design.

The dates

Let's Encrypt's own targets, as of the 3 June 2026 post:

- Late 2026 — staging environment that issues MTCs - 2027 — production-ready environment

That is infrastructure readiness, not "every site on earth is post-quantum authenticated." Browsers, root programs, libraries, and ACME clients still have to land support. Let's Encrypt is in the PLANTS and ACME working groups while those standards settle.

What you should do now

If you operate a website or TLS terminator

1. Keep renewing Let's Encrypt certificates the way you do today. Issuance and renewal do not change.

2. Turn on hybrid post-quantum key exchange: X25519MLKEM768. This is the highest-leverage change in 2026. It does not require a new certificate. It does protect recorded traffic against later decryption.

3. Do not wait for post-quantum certificates before doing (2). Encryption and authentication are on different clocks.

If you maintain an ACME client or a certificate pipeline

Start tracking the PLANTS working group and the mtcs@chromium.org list. Some of the coming issuance changes will need client-side support. Clients that show up ready when staging opens will matter more than another blog post about algorithms.

If you are a security lead writing a 2026–2027 plan

Put "enable hybrid KEX on every public TLS terminator" in this quarter. Put "evaluate MTC / ACME client support" on the 2027 calendar, tied to Let's Encrypt's production target — not to a panic date in 2026. Post-quantum certificates from Let's Encrypt are promised to arrive the usual way: free, automated, ACME.

What not to do

Do not rotate to a paid CA just to "get PQ certs" in 2026. Public post-quantum certificates are not the bottleneck this year; handshake size and ecosystem readiness are. Do not disable classic certificates early. Do not treat a staging CA as production. Do not confuse "my CDN already does PQ key exchange" with "my origin certificate is post-quantum signed" — those are different layers.

A simple timeline

When	What actually changes for you
Now (2026)	Enable X25519MLKEM768 on servers. Certificates stay as they are.
Late 2026	Let's Encrypt staging MTCs. Watch if you run ACME software. Ignore if you only renew certs.
2027	Let's Encrypt production MTCs, if the ecosystem is ready. Plan ACME client upgrades.
~2029–2035	Broader industry and government deprecation windows for RSA-2048 / P-256.

The quantum transition is a change to the machinery under TLS, not a reason to stop using Let's Encrypt or to hand-issue certificates. Turn on hybrid key exchange this year. Let the CA, browsers, and ACME clients do the authentication migration on the published staging-then-production track.

This post accompanies our Let's Encrypt / post-quantum TLS notes. Follow the series at amtocbot.com.

Attention Is All You Need, Explained Simply

We published a plain-language walkthrough of the 2017 transformer paper — queries, keys, values, multi-head attention, and why no-recurrence mattered — with a companion animated explainer.