CA Compromise Readiness Scorecard

You have a current inventory of the roots and intermediate CAs your systems trust — not just "the OS default bundle".

You can map a compromised intermediate CA to the specific services, certificates and client applications that depend on it.

The inventory covers non-OS trust stores: application and language stores (e.g. Python certifi, Go, Node, the JVM cacerts, Rust webpki), container base images, appliances and IoT.

You track which CA issued each of your own public certificates, so you know your own exposure if that CA is distrusted by browsers.

The inventory is refreshed automatically or on a defined cadence, not a one-off spreadsheet that has since gone stale.

You know which of your client types honour revocation at all, versus those that ignore it (e.g. curl verifying only against a static cert.pem with no revocation check).

For clients that can use it, OCSP (ideally OCSP stapling) or CRL checking is actually enabled and failures are handled meaningfully — not soft-failed into "allow".

You understand that browser revocation mechanisms (Mozilla OneCRL / CRLite, Chrome CRLSets, Apple/Microsoft revocation) are browser-side and do NOT cover your servers, scripts, containers or appliances.

Server-to-server and API/backend TLS calls are included in your revocation thinking — not just user-facing browser traffic.

You can roll out an updated OS ca-certificates package (the distro trust bundle) across your server and workstation fleet quickly via patch/config management.

Container and VM base images are rebuilt and redeployed on a cadence that refreshes their embedded trust store, rather than shipping the same stale bundle for months.

Application and language trust stores (certifi, cacerts, bundled PEM files) are patched through dependency management, not left frozen at whatever shipped originally.

You have a tested way to add an explicit distrust / removal for a specific CA across the fleet, not only to add new trust.

Appliances, network gear and IoT with their own trust stores have a known (even if slow) update path, and you know which cannot be updated at all.

Certificate issuance and renewal are automated (e.g. ACME), so re-issuing many certificates at once does not depend on manual steps.

Certificates are relatively short-lived, which both limits blast radius and keeps the renewal path exercised and trusted.

You can switch issuing CA (or use a backup/secondary CA) without a major re-architecture if your primary CA is compromised or distrusted.

You have a complete, current inventory of your own certificates with expiry and issuer, so re-issuance can be driven systematically.

You monitor Certificate Transparency (CT) logs for certificates issued for your domains, and alert on issuance you did not request.

CAA DNS records restrict which CAs are allowed to issue for your domains.

You have a defined channel to learn about CA incidents promptly (vendor advisories, root-program / CA bug trackers, security feeds) rather than finding out from an outage.

TLS/certificate validation failures across clients are logged and visible, so a wave of failures after a distrust event is detected and attributable.

You know where certificate / public-key pinning is in use, and the risk it carries: a pin to a distrusted CA can turn into a self-inflicted outage.

A single CA compromise is not a single point of failure for your most critical paths (e.g. via mTLS with your own issuing CA, or multi-CA strategies where warranted).

Internal / private PKI (your own roots and intermediates) is governed with the same inventory, rotation and distrust-agility expectations as the public CAs you rely on.

You have a specific playbook for "a CA or intermediate we trust is compromised / being distrusted", separate from a generic outage runbook.

That playbook has been exercised (tabletop or drill), including the awkward case where browsers are fine but backend/fleet clients still trust the bad CA.

You have mapped the vendors, SaaS and upstream services you depend on whose own CA exposure could affect you, and know how you would learn of their status.

A communications plan exists for a CA-trust incident: who decides, who informs customers/users, and how you explain partial impact (browsers vs other clients).