An OCSP Status Request is a TLS extension used to ask whether a certificate has been revoked. In practice, it becomes part of the trust validation path, so defects in request handling can affect service availability as well as certificate checking.
Expanded Definition
OCSP Status Request is a TLS extension that asks a certificate issuer or responder whether a certificate has been revoked, usually during the handshake. In NHI environments, it matters because machine-to-machine sessions often depend on certificate validation at scale, where a failed or delayed revocation check can break service continuity or quietly weaken trust decisions.
This term sits at the intersection of certificate lifecycle control and runtime availability. It is related to OCSP stapling, but not identical: the status request signals that the client wants revocation information as part of the TLS exchange, while the server-side response handling determines how that information is delivered. Definitions are consistent in standards bodies, but operational usage varies across platforms, proxies, and service meshes. The NIST Cybersecurity Framework 2.0 reinforces the need to manage trust services as part of resilience, even though it does not name this extension directly.
For NHI governance, the important distinction is that OCSP Status Request is not a credential itself. It is a validation mechanism that supports certificate-based trust for agents, workloads, and APIs. The most common misapplication is treating OCSP availability as optional, which occurs when teams deploy certificate validation without planning for responder outages, timeouts, or fail-open behavior.
Examples and Use Cases
Implementing OCSP Status Request rigorously often introduces handshake latency and dependency risk, requiring organisations to weigh stronger revocation awareness against the operational cost of an additional live check.
- A service mesh enables certificate-based mutual TLS between workloads and uses OCSP Status Request to confirm revocation before allowing east-west traffic.
- An API gateway validates client certificates for partner integrations and fails closed when a responder returns an indeterminate status, reducing trust in stale certificates.
- A privileged automation agent connects to a secrets platform over TLS, and the platform requires revocation checking so replaced certificates cannot continue to authenticate.
- A production outage occurs when a revocation responder becomes unreachable, showing why timeout policy and fallback behavior must be tested before deployment.
These use cases align with the broader NHI lifecycle concerns described in the Ultimate Guide to NHIs, especially where certificate rotation and visibility intersect with runtime trust. For protocol context, the TLS status extension is described in the IETF’s RFC 6066, which defines the extension mechanism used during the handshake. In practice, teams also use OCSP guidance to understand responder behavior and revocation semantics.
Why It Matters in NHI Security
OCSP Status Request matters because revoked certificates are often the first signal that a workload, integration, or automation path has become untrusted. When status checking is bypassed, overloaded, or misconfigured, organisations can continue to accept certificates that should no longer be valid, turning a revocation event into a persistence opportunity. This becomes especially important in NHI estates where certificates are issued, rotated, and delegated at machine speed.
The risk is amplified by the scale of NHI sprawl. NHI Mgmt Group reports that NHIs outnumber human identities by 25x to 50x in modern enterprises, and 91.6% of secrets remain valid five days after the organisation is notified, showing how slowly trust material is often remediated in practice. That same operational lag affects certificate-based trust chains, which is why the Ultimate Guide to NHIs treats visibility and revocation as governance issues, not just PKI settings.
Organisations typically encounter the operational importance of OCSP Status Request only after a certificate compromise, responder outage, or failed cutover, at which point revocation handling becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Certificate trust validation and revocation handling are core NHI lifecycle controls. |
| NIST CSF 2.0 | PR.DS-6 | Protecting and validating trust data includes certificate status checks. |
| NIST Zero Trust (SP 800-207) | SC-23 | Zero trust relies on continuous trust evaluation, including certificate status. |
Verify certificate revocation paths and fail-safe behavior for workload identities during TLS validation.
Related resources from NHI Mgmt Group
- What is the difference between network trust and request-level identity trust?
- Why do access-request workflows matter for NHI governance?
- How should organisations use AI in access request approval without weakening control?
- What is the difference between access request automation and access governance?
