CRL vs OCSP: what revocation means for PKI governance

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Keyfactor's blog post: CRL and OCSP revocation status checks carry different trade-offs in freshness, performance, privacy, and resilience.

Why it matters: It matters because IAM and PKI teams need revocation controls that fit certificate lifetimes, device constraints, and outage tolerance rather than assuming expiration alone protects trust.

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.

Context

Certificate revocation is the control that tells relying parties a certificate should no longer be trusted before its expiry date. In PKI, that matters because certificates are not just time-bound credentials, they are trust anchors for authentication, encryption, and device or service identity.

CRLs and OCSP both answer the same question, but they do it with different operational assumptions. A CRL publishes a signed list on a schedule, while OCSP checks status per certificate in near real time, so the governance problem is not choosing a protocol in isolation but matching revocation mechanics to the environment.

For IAM and PKI teams, the real issue is revocation governance: how quickly status changes propagate, what happens when responders or distribution points are unreachable, and whether the trust model still holds when certificates are compromised or misissued before expiry.

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. OCSP gives near real-time status checks and reduces download overhead, but it depends on live responder availability and can expose user lookups. CRLs are easier to cache and preserve more privacy, but they rely on periodic updates and larger downloads. In practice, many teams combine both with stapling or short-lived lists.

Q: Why does certificate revocation matter if certificates already have an expiry date?

A: Expiry only sets the latest possible trust boundary. Revocation matters when a certificate is compromised, misissued, or no longer authorised before that date, because clients may still trust it until revocation status is communicated successfully. Without a working revocation path, the certificate remains usable longer than the organisation intended.

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. With CRLs, an expired or unreachable distribution point can break all checking. With OCSP, a responder outage can block or degrade individual status checks and create availability or fallback risk.

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.

Technical breakdown

How CRL publication creates a staleness window

A Certificate Revocation List is a signed data structure that a certificate authority publishes periodically to declare which certificate serial numbers are no longer trusted. Because clients cache the list until it expires, revocation checking is only as fresh as the last publication and the next successful download. That design is simple and broadly compatible, but it means a newly revoked certificate can remain accepted until the next CRL update. The operational failure mode is not cryptography, it is lag between revocation decision and client awareness.

Practical implication: Treat CRL freshness as a governance control, not a background detail, and monitor publication intervals as part of certificate lifecycle management.

How OCSP changes revocation from batch status to per-certificate lookup

OCSP asks the issuing authority about one certificate at a time and returns a live status of good, revoked, or unknown. That removes the need to download and parse a full revocation list, which helps constrained devices and reduces stale trust decisions. The trade-off is dependency on the responder at request time, so availability and latency become part of the trust path. In practice, OCSP shifts the revocation problem from file distribution to responder reliability and privacy exposure.

Practical implication: Use OCSP where per-request freshness matters, but verify responder resilience and privacy impact before making it the only status path.

Why stapling and dual-path revocation checks change the failure model

OCSP stapling lets the server cache a fresh OCSP response and present it during the TLS handshake, so the client does not need to query the responder directly. That improves performance and reduces privacy leakage while preserving real-time status checking. Running CRL and OCSP together adds redundancy, but it also creates a governance requirement: teams must know which control is authoritative when one path fails. The important design question is not protocol preference alone, but which outage or staleness scenario you are willing to absorb.

Practical implication: Define a fallback revocation path for each PKI environment and test what happens when either the distribution point or the responder fails.

Breaches seen in the wild

• GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
• NVIDIA code-signing certificates stolen 2022: Lapsus$ leaked two NVIDIA code-signing certificates; Windows still trusted them for drivers and attackers signed Cobalt Strike and Mimikatz with them.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Revocation freshness, availability, and privacy are a governance triangle: CRLs optimise broad compatibility and offline checking, OCSP optimises per-certificate freshness, and stapling reduces the client-side privacy cost. None of those properties is free, which means PKI teams are really choosing which trust failure they are willing to manage. The right answer varies by device class, service criticality, and operational tolerance.

Certificate lifecycle shortens the tolerance for slow revocation: as certificate lifetimes collapse, the margin for delayed status propagation shrinks with them. That increases the importance of monitoring, cache behaviour, and responder uptime because a short-lived credential can still be trusted long enough to matter if revocation lags. Teams should treat revocation latency as a control objective, not a protocol side effect.

Revocation governance should be environment-specific, not protocol-led: server fleets, mobile clients, IoT devices, and high-security regulated systems do not share the same failure tolerance. A one-size PKI decision usually forces the wrong trade-off somewhere else in the estate. Practitioners need a revocation policy that is explicit about which trust path is prioritised under load, outage, and privacy pressure.

CRL and OCSP are complementary control planes, not competing doctrines: the healthiest PKI designs use revocation mechanisms according to the failure mode they are trying to absorb, not the branding of the protocol. The governance decision is whether the organisation can tolerate stale acceptance, responder dependency, or both. That question belongs in identity architecture reviews, not only in certificate operations.

From our research library:

• 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.
• Read next: Machine Identity, PKI and Certificate Lifecycle Guide

What this signals

Revocation latency is becoming the real PKI control problem: as certificate lifetimes shorten, the time between a revocation decision and trusted client awareness matters more than the expiration date itself. Teams should watch CRL freshness and OCSP response health as core trust signals, not back-office telemetry.

CRL vs OCSP is really a question of where the trust failure lands: CRLs shift risk toward stale acceptance and publication lag, while OCSP shifts risk toward responder dependency and privacy. Practitioners need to decide which failure mode is acceptable per environment before incidents force the answer.

Revocation governance now sits alongside machine identity lifecycle discipline: certificate status handling is not separate from identity governance, because revoked credentials that remain trusted still behave like live access. That is why short-lived certificates, automated monitoring, and explicit fallback policy belong in the same control conversation.

For practitioners

• 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.
• Use stapling where client privacy matters Let servers staple a fresh OCSP response when you need near real-time status without exposing per-user certificate checks to the CA.
• Document a fallback revocation model State which mechanism is authoritative when CRL or OCSP becomes unavailable, and confirm that fallback behaviour is consistent across the estate.

Key takeaways

• 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.
• CRLs and OCSP solve the same problem with different operational trade-offs, so the right design depends on freshness, privacy, availability, and device constraints.
• PKI teams need monitored revocation paths and an explicit fallback model, or a revoked certificate can stay trusted longer than the organisation expects.

Key terms

• Certificate Revocation: The process of declaring a certificate untrusted before its scheduled expiration date. In PKI operations, revocation is what removes a compromised, misissued, or otherwise invalid certificate from the trust chain even though the certificate technically remains within its validity window.
• Certificate Revocation List: A Certificate Revocation List is a signed publication from a certificate authority that lists certificates that are no longer trusted before their natural expiry. It is used by relying systems to confirm current status, and it becomes operationally useful only when the list is reachable, current, and readable by the consuming toolchain.
• Online Certificate Status Protocol: Online Certificate Status Protocol is a per-certificate revocation check that asks the issuing authority for the current status of one certificate. It improves freshness over list-based checking, but it introduces responder dependency and privacy exposure because each query reveals the certificate being validated.
• OCSP Stapling: OCSP stapling is a server-side pattern where the web server fetches an OCSP response and includes it during the TLS handshake. It reduces client-to-CA traffic and improves privacy, but it still requires the server to refresh and present a current response reliably.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.