On March 19, 2026, Let's Encrypt ran their first annual mass revocation drill. Roughly 3 million certificates were flagged as if they had been "incorrectly issued" and needed replacement. In staging, they were revoked outright. In production, no certificates were actually revoked, but the ACME Renewal Information (ARI) renewal windows for those certificates were shortened to signal an emergency renewal.
The result revealed something uncomfortable: most of the world's ACME clients would not have responded in time. Certbot only checks ARI when its scheduled job happens to run - which could be days or weeks after a signal. acme.sh, another popular client, has no ARI support at all. If this had been a real mass revocation event, a large fraction of the affected fleet would have failed silently until each certificate expired or until customers reported browser warnings.
Why the largest CA is drilling for mass revocation
Let's Encrypt didn't run this drill because a specific incident was imminent. They ran it because mass revocation is a category of event that will happen - to them, and to every other public CA - and the only question is whether the ecosystem is prepared when it does.
The trigger scenarios are well understood. A CA/Browser Forum Baseline Requirements change lands and a subset of already-issued certificates no longer complies. A validation methodology (like Multi-Perspective Issuance Corroboration, which is the actual cause of a mass revocation event at another CA weeks later - more on that below) turns out to have been implemented in a way that doesn't fully match policy. A vulnerability is found in software the CA depends on. In every case, the CA's contractual obligation is the same: revoke the affected certificates within a defined window, usually 24 hours to 5 days depending on the severity classification.
The March 2026 drill was Let's Encrypt saying: this will happen, we're going to test our ability to communicate it via ARI, and we want to see how the ecosystem responds. The answer was: the ecosystem responds unevenly. Some clients did the right thing automatically. Others didn't.
Two weeks later, the real thing hit
On April 3, 2026, a separate CA revoked approximately 1.7 million certificates within a 24-hour window following a compliance-driven mandatory revocation event. The root cause was a deviation in how Multi-Perspective Issuance Corroboration (MPIC) had been implemented in the CA's ACME validation pipeline. Validation had been performed and matched correctly; the methodology just didn't fully align with CA/Browser Forum policy requirements.
This wasn't a security breach. There was no indication of compromise or incorrect validation. The revocation was mandatory purely because of a compliance deviation. Every customer holding an affected certificate had to get a new one issued, deployed, and verified before the old one's revocation propagated to their visitors' browsers.
Two mass revocation events in two months, from two of the CA ecosystem's most competent operators. Neither was preventable by the customers holding the certificates.
What this means if you hold a public TLS certificate
Three uncomfortable observations from these two events.
Your certificate can be revoked for reasons you don't control. A CA/Browser Forum rule can change, a validation methodology can be found wanting, a vendor component can turn out to have a bug. Your certificate is fine one day and no longer trusted the next, through no action of yours.
Your renewal automation may not respond in time. The Let's Encrypt drill exposed that the two most popular ACME clients don't respond quickly to CA emergency signals. If you're relying on Certbot's default schedule to catch a shortened ARI window, you may miss it entirely. If you're using acme.sh, you'll definitely miss it. Even the ones that do respond may need hours to work through a large fleet.
Internal state checks won't tell you. Your monitoring script reads the certificate file from disk and sees a valid, non-expired cert. The revocation happens at the CA. Your customer's browser checks revocation status through OCSP or a distributed CRL feed and refuses to trust the certificate. Nothing changes on your server that a local check would catch.
External monitoring is the backup detection layer
Continuous external probing - the same TLS handshake a customer's browser would perform, from outside your network, with browser-equivalent validation logic - closes the gap between "the CA revoked the cert" and "you noticed and started responding." Routine, single-certificate revocations can go unnoticed for a while under soft-fail OCSP and the normal update cadence of browser-pushed lists like CRLite and CRLSets. A mass revocation event tends to get enforced faster, since browser vendors and CT monitors are watching the same signals - but there's no guaranteed SLA on that, which is exactly why waiting on it isn't a plan. The probe sees what your customer's browser sees, which is the only view that matters when the failure is at the trust layer rather than at your infrastructure.
This isn't a replacement for good renewal automation and it doesn't prevent the CA-side revocation from happening. It's the detection layer that tells you a revocation is in progress while you still have time to act, instead of finding out from a customer report or a spike in support tickets.
You can't stop your CA from revoking a certificate. Monitoring for revocation events on your own certificates - independently of whatever notice your CA sends - is the part you do control.
Detect CA-side revocations before customers do
TLS Radar checks revocation status as part of its full certificate health check, using continuous external probes with browser-equivalent validation logic that catch revocations, distrust events, chain breaks, and EKU rejections. Free tier covers three domains, which is enough to see whether your current certificates would be caught if revoked.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.