When a credit card gets stolen, the bank doesn't recall every card-reader in the world and update its firmware. They put the stolen card number on a list. Card readers check the list (sometimes), banks check the list (always), and the card stops working - eventually, mostly, depending on how much the merchant cares to check.
Certificate revocation works the same way, with the same drawbacks. A cert gets compromised, or misissued, or simply needs to die before its expiry date. The CA puts it on a list. Browsers check the list (sometimes, depending on which browser, which version, which network conditions). The cert stops working - eventually, mostly, with significant gaps in the middle.
Revocation has been an awkward, partly-broken part of public-key infrastructure for decades. The good news in 2026 is that the situation is finally improving, partly because of new approaches (CRLite, browser-pushed lists) and partly because shorter cert validity periods are making the whole problem matter less.
Here's how revocation works, what's broken about it, what's changed recently, and what your organisation should actually care about.
The problem revocation solves
Certs are valid for a defined period. Without revocation, that period is the only thing limiting their use.
Reasons a cert might need to die before its expiry: - Private key compromise. Someone got the private key. The cert can now be used by an attacker until expiry. - Misissuance. The CA issued a cert it shouldn't have - wrong domain, wrong subject, weak validation. - CA mistake. Internal CA error. The cert needs to be invalidated and reissued. - Service shutdown. A service is being decommissioned and you'd rather its cert not stay valid for any reason.
In each case, you need a way to tell the world "this cert is no longer valid, ignore it." That's revocation.
CRL - the original way
Certificate Revocation Lists. The original revocation mechanism.
The CA maintains a list of all revoked certs (by serial number). Clients download the list periodically and check certs against it.
Pros: simple, offline-capable.
Cons: the list gets big. As CAs issue more certs, the CRL grows. Browsers and operating systems don't want to download megabytes of revocation data on every connection. So clients either download infrequently (gap in coverage) or stop using CRLs entirely (gap in coverage).
Most modern browsers no longer use CRLs directly. They're still used in some enterprise PKI contexts and machine-to-machine systems.
OCSP - the real-time approach
Online Certificate Status Protocol. A response to CRL's size problem.
Instead of downloading the whole list, the client asks the CA in real time: "is this specific cert revoked?" The CA answers yes or no.
Pros: fresh information, small payload.
Cons: - Performance. Every TLS handshake now requires an extra round trip to the CA. Slow. - Privacy. The CA learns which sites you're visiting (you're asking about specific cert serial numbers). - Reliability. If the CA is down or slow, what does the browser do? "Hard-fail" means breaking the connection. "Soft-fail" means proceeding without revocation checking. Browsers chose soft-fail. Which means attackers who can block OCSP get a free pass.
Soft-fail OCSP, in practice, is "we don't really check."
OCSP Stapling - the compromise
OCSP Stapling lets the server fetch the OCSP response on the client's behalf and attach (staple) it to the TLS handshake. The client gets fresh revocation status without contacting the CA.
This fixes the performance and privacy problems. It does not fix the reliability problem if the server can't reach the CA. And it requires server-side support, which not all servers have configured.
OCSP Stapling is the right pattern for servers that want to provide revocation status without the OCSP downsides. It's well-supported in modern web servers but still under-deployed.
CRLite and browser-pushed lists
A newer approach: the browser maintains its own compressed revocation list, updated through the browser's normal update channel.
Mozilla's CRLite uses Bloom filter cascades to represent the entire set of revoked Web PKI certificates in a few megabytes. The browser ships the filter. Lookups are local. No network call required.
Chrome has a similar approach (CRLSets) but historically only covered a small curated subset of revocations rather than all of them.
These approaches solve the performance, privacy, and reliability issues at once. The trade-off is that the data is only as fresh as the last browser update. For browser revocation checking in 2026, browser-pushed lists are the direction of travel.
The Let's Encrypt OCSP deprecation
In 2024, Let's Encrypt announced they would deprecate OCSP service. As of 2025, they no longer provide OCSP responses for new certificates - they rely on CRLs (now available from Let's Encrypt) and browser-pushed revocation lists.
Why: OCSP's operational cost is significant. The privacy properties are bad. The reliability gap (soft-fail) means it doesn't really work anyway. Pulling the plug freed resources for things that actually improve security.
This was a meaningful signal from the largest public CA. Other CAs are weighing similar decisions. The OCSP era is winding down.
Why shorter certs make revocation matter less
Here is the structural reason the revocation problem is fixing itself.
When certs were valid for 2-3 years, a compromised private key was a 2-3-year problem. Revocation needed to work because the cert would otherwise be misusable for a long time.
With 90-day certs (now), and 47-day certs (by March 2029, per CA/Browser Forum Ballot SC-081v3), a compromised cert is a 90-day or 47-day problem. Revocation still matters, but the window of exposure is much smaller. The cost of revocation infrastructure starts to exceed the benefit it provides.
This isn't a reason to ignore revocation. It's a reason the industry is moving toward "shorter certs, browser-pushed revocation lists, OCSP deprecated" as the new default.
What to actually care about in 2026
For most teams:
- Enable OCSP Stapling on your web servers if it isn't already. It's free, helps performance, and supports the clients that still check OCSP. Watch your CA's revocation roadmap. If your CA is deprecating OCSP, make sure your monitoring isn't relying on it. Monitor for revocation events on your own certs. If a cert you issued gets revoked unexpectedly, you want to know fast. Don't depend on browser revocation checking to protect against compromised certs in your own infrastructure. Browsers are increasingly forgiving. Your internal monitoring needs to catch compromise, not the browser.
One small ask
Revocation in 2026 is a transitional moment - OCSP is winding down, browser-pushed lists are growing, and shorter cert lifespans are making the whole question less urgent. The practical action is to know what's in your environment, support the patterns that work (OCSP Stapling, CRLs where appropriate, monitoring), and not depend on patterns that don't (soft-fail OCSP). TLS Radar checks revocation status as part of its full cert health check, across all the mechanisms above. Free tier covers three domains, which is enough to see whether your current certs would be caught if revoked.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.