What is the correct sequence when you must revoke a certificate after a key compromise?

What is the correct sequence when you must revoke a certificate after a key compromise?

Revocation marks a certificate invalid before its expiry, surfaced through CRL (Certificate Revocation List, RFC 5280) and OCSP. Because client-side revocation checking is famously unreliable, revocation alone is insufficient. Incident runbook.

— Revoke immediately through your CA with the correct reason code (keyCompromise), which CAs and CT monitors treat more seriously than 'unspecified'.
— Do not stop there: rotate to a fresh key pair and reissue, then deploy the new cert, because many clients soft-fail revocation checks and will keep trusting the old leaf.
— If you stapled OCSP, push the new cert so stapled status flips to 'revoked' for clients that do honor it.
— Treat the 24-hour CA/Browser Forum revocation deadline for key compromise as a hard clock, not a target.
— Audit CT logs to confirm no further certs exist for the compromised key, and tighten CAA to prevent reissuance through unexpected CAs.

Evidence vs. speculation: revocation propagation is best-effort; key rotation is the only step fully under your control.

Further reading: RFC 5280 section 5; CA/Browser Forum Baseline Requirements section 4.9.

Bottom line: revoke for compliance, but rotate the key as if revocation will not reach the attacker's client.