Explain the internal working of certificate revocation in Venafi?

Revoking a certificate is a coordination problem as much as a technical one: TPP has to tell the CA to invalidate the certificate and make sure the endpoints relying on it stop using it, ideally before anyone tries to exploit the window in between.

Revocation can be triggered manually (a security team decides a key is compromised), automatically as part of a renewal that supersedes the old certificate, or by an integration that detects compromise elsewhere. Once triggered, TPP checks that the requester has revoke permission on that certificate's policy folder, then calls the issuing CA's revocation API so the certificate gets added to the CA's CRL and/or its OCSP responder starts reporting it as revoked.

In parallel, if the certificate was deployed via an orchestration connector, TPP can also proactively remove or replace it on the live endpoint rather than just waiting for clients to check revocation status themselves — which matters because not every client actually checks OCSP or CRL data reliably. Everything is written to the audit log, including who triggered the revocation and why, since that trail is often exactly what a post-incident review needs.