Notifications
Clear all
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.
NHIMG editorial — 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 shrunk from 13 months to 200 days, with further reductions targeting 100 days by March 2027 and 47 days by March 2028.
- Certificate expiry is the leading cause of outages for 45% of organisations.
- Only 38% have automated certificate lifecycle management in place.
Questions worth separating out
Q: How should security teams design certificate revocation for resilient PKI operations?
A: Security teams should design revocation so that status changes propagate quickly, remain checkable under load, and fail safely if a dependency goes down.
Q: Why do CRL and OCSP both matter in certificate governance?
A: They matter because they solve different parts of the same problem.
Q: What breaks when revocation infrastructure is stale or unreachable?
A: When revocation infrastructure is stale or unreachable, clients may keep trusting certificates that should already be invalid.
Practitioner guidance
- Treat revocation status as a monitored control Track CRL freshness, OCSP responder health, and certificate status propagation as explicit service-level signals.
- Require a fallback revocation model Use CRL, OCSP, or both based on environment, but do not leave a single point of failure in the trust path.
- Enforce OCSP stapling where clients support it For server estates, require stapled responses so browsers and clients do not need to contact the CA directly.
What's in the full article
Keyfactor's full post covers the operational detail this post intentionally leaves for the source:
- Step-by-step CRL publication and checking mechanics for browsers and applications
- OCSP stapling behaviour and why it changes client privacy and response flow
- Practical scenario guidance for server, IoT, and high-security deployments
- Monitoring considerations for CRL expiration, endpoint reachability, and response validity
👉 Read Keyfactor's explanation of CRL vs OCSP for PKI revocation governance →
CRL vs OCSP revocation checks: are your PKI controls keeping up?
Explore further
25/06/2026 10:56 am
Revocation governance is a trust-withdrawal problem, not a certificate-format problem. CRL and OCSP are simply two delivery models for the same control objective: telling relying parties that a certificate is no longer valid. The article makes clear that expiry is only the outer boundary, while revocation is the real mechanism that ends trust early. Practitioners should treat revocation as a lifecycle control with availability requirements, not as a checkbox inside PKI operations.
A few things that frame the scale:
- 59% of companies face greater difficulties auditing machine identities, primarily due to lack of clear ownership and limited visibility, according to The Critical Gaps in Machine Identity Management report.
- Only 38% have automated certificate lifecycle management in place, which helps explain why revocation status can remain operationally fragile even when the policy exists.
A question worth separating out:
Q: Who is accountable when certificate revocation fails to stop compromised trust?
A: Accountability sits with the team that owns certificate lifecycle governance, not just the protocol implementation. PKI operators, identity leaders, and infrastructure owners need to share responsibility for monitoring, escalation, and remediation when revocation status cannot be reliably enforced.
👉 Read our full editorial: CRL vs OCSP: what revocation means for PKI governance
