Mutual TLS gives a service a strong signal about the certificate presented by a client. It does not automatically tell the service whether that certificate is still acceptable today. Certificate revocation is a separate status question, answered through OCSP, CRLs, or a short-lived certificate design. The difficult part is not enabling a checker. The difficult part is deciding what the service does when the checker cannot produce a fresh answer.
RFC 9325 describes a familiar operational reality: many TLS clients soft-fail OCSP, meaning they continue a connection when the responder is unavailable. For public web certificates, soft fail has practical tradeoffs. For client certificates that authorize access to an administrative API or a data plane, the same behavior can preserve access after a credential has been reported compromised. The team may believe it has revocation because a status query is configured, while the connection path fails open during an outage.
A useful policy separates three cases. A known-good response permits the connection under the service's normal authorization rules. A revoked or otherwise invalid response rejects it. An unavailable, stale, or malformed response needs a documented decision. High-risk paths should fail closed unless the team has an alternative identity signal with equal strength. Lower-risk paths may allow a bounded grace period, but the exception should be explicit, monitored, and tied to a specific deployment rather than hidden in TLS library defaults.
RFC 6960 defines OCSP request and response semantics. RFC 5280 explains how CRLs and freshness participate in certificate path validation. These are building blocks, not a complete operational model. OCSP stapling can reduce privacy and availability problems because the server presents a signed status response. It still needs a maximum age and a rejection rule. A cached "good" response from before a revocation event is a statement about an earlier moment, not a permanent fact.
Inventory the actual termination point. A load balancer may terminate mTLS, validate the certificate, and forward an identity header to an application. The application might trust a different port, a second proxy, or a service mesh sidecar. Each hop can have a different revocation policy. If the edge fails open but the application assumes the edge enforces revocation, the access decision is weaker than the architecture diagram suggests.
Log the certificate serial number or a stable fingerprint prefix, issuer, validation result, response source, response age, and the policy decision. Do not log the full certificate chain unless needed for a case. Alert on responder errors and on a sudden shift from fresh responses to stale ones. Monitor the response outcome as well as process health. A responder that returns HTTP 200 with an expired response is not healthy from the relying party's perspective.
Short-lived client certificates can reduce the need for revocation, but they do not remove the policy question. A stolen certificate is still usable until expiration unless another control blocks it. Bind the certificate to a workload identity where possible, rotate it automatically, and keep a revocation or deny path for emergencies. If the certificate is used for human access, pair it with device state or an interactive factor for sensitive actions.
Test the failure modes before an incident. Stop the responder in a staging environment. Present a stale response. Present a response signed by the wrong responder. Present a valid certificate with a serial that is not in the local cache. Record whether the connection succeeds and which component made the decision. The expected result should be written in the service's authorization documentation.
mTLS is a strong transport identity primitive. Its value depends on a current and explicit trust decision. A revocation checkbox without a failure policy can create a false sense of control. Teams should prefer a small number of clearly enforced paths, a fresh status rule, and a fail-closed outcome for operations that can change data or configuration.