Topic starter
25/06/2026 1:29 am
TL;DR: Certificate revocation sits at the center of PKI trust, yet CRLs and OCSP trade freshness, performance, privacy, and availability differently, according to Keyfactor. As certificate lifetimes shrink and revocation windows matter more, teams need revocation governance that matches the environment instead of assuming expiry is enough.
Editorial analysis by NHI Mgmt Group, based on content published by Keyfactor: “Certificate Revocation List (CRL) vs Online Certificate Status Protocol (OCSP): What You Need to Know”.
By the numbers:
- Certificates have been shrinking steadily from 13 months in September 2020 to 200 days in March 2026, with further reductions targeting 100 days by March 2027 and 47 days by March 2028.
- Let’s Encrypt announced in December 2024 that it would end OCSP support effective May 2025.
Key questions
Q: How should security teams choose between CRL and OCSP for certificate revocation checking?
A: Security teams should choose based on freshness, privacy, availability, and operational scale.
Q: Why does certificate revocation matter if certificates already have an expiry date?
A: Expiry only sets the latest possible trust boundary.
Q: What breaks when CRL or OCSP checks are unavailable in production?
A: Revocation decisions stop propagating reliably, which means clients can keep trusting certificates that should already be untrusted.
Practitioner guidance
- Map revocation requirements to certificate use cases Separate server, mobile, IoT, and high-security PKI estates because each has different tolerance for staleness, bandwidth, and responder dependency.
- Instrument CRL freshness and availability Track CRL publication cadence, expiration warnings, and CDP reachability so stale or unreachable revocation data is treated as an operational failure.
- Test OCSP responder failure paths Validate what browsers, applications, and devices do when the OCSP responder is slow, unreachable, or returns unknown status.
Bottom line: Certificate revocation is a trust decision, not a certificate housekeeping task, because compromised or misissued certificates remain dangerous until relying parties learn they are invalid.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 10:56 am
Revocation is a lifecycle control, not an expiry control: certificate validity only sets the outer boundary of trust. Once a certificate is compromised, misissued, or no longer authorised, the security model depends on how fast revocation reaches every relying party. That makes revocation status propagation part of identity governance, not an optional transport detail.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to the State of Secrets Sprawl 2026.
- According to the 2023 State of Machine Identity Management report, only 47% of companies have enough staff dedicated to their PKI.
A question worth separating out:
Q: What should teams do when their PKI needs both freshness and resilience?
A: Use layered revocation controls and make the fallback path explicit. OCSP stapling can reduce client-side dependency and privacy leakage, while CRLs provide a broader distributed status source. The key is to define which mechanism wins during outages, then test that behaviour in the environments that rely on it most.
👉 Read our full editorial: CRL vs OCSP: what revocation means for PKI governance