CA Compromise and Mass Certificate Replacement Playbook

When a certificate authority is compromised or distrusted, every certificate it issued becomes a liability at once, and organisations without a certificate inventory discover the problem through outages. Root programmes can block an intermediate within hours: in October 2026, after researchers found eight eMudhra intermediate CA private keys were trivially recoverable, Mozilla blocked them through OneCRL and Chrome blocked the TLS-capable ones on the day of discovery, 17 October, according to BleepingComputer's reporting. The CA/Browser Forum Baseline Requirements give CAs only 24 hours to revoke subscriber certificates after key compromise and seven days for subordinate CA certificates. This template gives [Organisation] a ready-to-adopt playbook for a public or private CA compromise, a root programme distrust decision, or any event that forces mass replacement of machine certificates. It covers TLS server and client certificates, mTLS service identities, device certificates and the trust stores that rely on them. Code signing is handled in a separate playbook.

How to use this template

Adopt, then tailor: copy sections 1 to 8 into your incident response plan and replace every [placeholder]. Add an appendix listing each CA you rely on, public and private, with the certificate counts and owners from your inventory.
Distinguish the scenarios: a compromised CA key (urgent, possible active misuse), a root programme distrust (scheduled or immediate loss of trust, usually without misuse) and an internal CA compromise (you are the CA) share most steps but differ in speed and who acts. Section 1 defines them.
Rehearse before you need it: the playbook is only as fast as your inventory and automation. The implementation guidance describes a tabletop and a live replacement drill.
Link related plans: use with the Compromised Code Signing Certificate Playbook for signing keys and the Certificate Revocation Guide for revocation mechanics.
Review annually and after every CA incident in the industry. Owner: [PKI Service Owner].

1. Scope and triggers

1.1 This playbook applies to all X.509 certificates used by [Organisation] systems, whether issued by public CAs, private enterprise CAs, cloud private CA services or vendor-managed CAs, and to all trust stores [Organisation] controls (operating systems, browsers under management, Java keystores, container base images, language runtimes, appliances, mobile apps with pinned certificates).

1.2 Scenarios:

Scenario	Typical speed	Who acts first	[Organisation] priority
A. Public CA or intermediate key compromise	Hours; browsers may block immediately	CA, root programmes	Replace affected certificates, check for forged certificates for our domains
B. Root programme distrust of a public CA	Immediate or a scheduled date	Root programmes	Migrate to another CA before the distrust date
C. Mass revocation for mis-issuance	24 hours to 5 days under the Baseline Requirements	CA	Reissue before revocation takes effect
D. Internal CA compromise	Immediate	[Organisation]	Revoke, rebuild the CA, reissue and redistribute trust anchors
E. Algorithm or key weakness	Days to months	Standards bodies, CA	Planned mass replacement

1.3 Triggers:

A CA notification of revocation or compromise affecting [Organisation] certificates.
A public announcement by a root programme (Mozilla, Chrome, Apple, Microsoft) blocking or distrusting a CA or intermediate we use.
A certificate transparency alert for a certificate for our domains we did not request. See the Certificate Transparency Monitoring Guide for Web Teams.
Evidence of exposure of an internal CA private key, HSM compromise or unauthorised issuance from an internal CA.
Monitoring showing a spike in TLS handshake failures, especially from one client population.

2. Roles and contacts

Role	Named owner	Responsibilities
Incident commander	[Name, deputy]	Declares the incident, sets priorities, approves risk acceptances
PKI service owner	[Name]	Inventory queries, CA liaison, issuance capacity, internal CA actions
Platform and application owners	[Rota]	Install replacement certificates, restart services, validate
Network and edge team	[Name]	Load balancers, CDNs, WAFs, VPN and proxy certificates and trust stores
Endpoint and trust store owner	[Name]	Push trust store updates and blocks to managed devices and images
Vendor manager	[Name]	Contacts SaaS and appliance vendors holding our certificates or trusting the affected CA
Communications lead	[Name]	Customer, partner and internal messages
Legal and compliance	[Name]	Contractual and regulatory notification decisions

2.1 Keep out-of-band contact details for each CA's revocation and support channels, and for at least one alternative public CA with which [Organisation] has an active account, in [location].

3. Detection and triage

3.1 Confirm the facts from primary sources: the CA's incident report, the root programme announcements and, for public CAs, the Common CA Database (CCADB) incident report. Record which certificates (root, intermediate, subscriber) are affected, by subject, serial number and fingerprint.

3.2 Query the inventory for every certificate chaining to the affected CA or intermediate, including expiry, owner, host, application, client population and whether it is managed by automation. Also list every trust store that contains the affected CA as a trust anchor for our own clients.

3.3 Check for misuse: search certificate transparency logs for certificates for our domains issued by the affected CA that we did not request, and review TLS interception or proxy logs for unexpected chains. Forged certificates would support adversary-in-the-middle attacks (ATT&CK T1557) using obtained or forged certificates (T1588.004, T1587.003).

3.4 Classify severity:

Critical: key compromise with evidence of misuse, or internal CA compromise.
High: browsers already blocking, or revocation within 24 hours to 7 days, affecting customer-facing services.
Medium: scheduled distrust date more than 30 days away.

3.5 Prioritise certificates: internet-facing services used by browsers first, then partner and API endpoints, mTLS between services, device certificates, and internal-only systems.

4. Containment

4.1 Public CA scenarios: request replacement certificates from an unaffected CA immediately for priority 1 services, using new key pairs. Do not reuse private keys from certificates issued under the compromised hierarchy.

4.2 Block the affected CA in trust stores [Organisation] controls once replacements are in place, or immediately if misuse is suspected: managed browser policies, operating system trust stores via endpoint management, Java and language runtime keystores, container base images and proxy trust lists. Note that root programme blocks may not reach software with its own certificate bundle or that does not check revocation; BleepingComputer reported that macOS's built-in curl may keep trusting the eMudhra intermediates because its bundle does not check revocation information.

4.3 Internal CA compromise: take the CA offline, preserve the CA server, HSM logs and issuance database for forensics, revoke the compromised CA certificate at the parent, publish an updated CRL, and stop all issuance from the affected hierarchy. Treat every certificate it issued as untrusted.

4.4 Freeze changes unrelated to the incident on affected platforms, and suspend automated certificate renewal jobs that would request certificates from the affected CA.

5. Eradication

5.1 Replace every affected certificate with a new key pair from an unaffected CA, working through the priority list. Use automation (ACME, EST, cloud certificate managers) wherever possible; manual replacement does not scale to thousands of certificates. See the ACME and Automated Certificate Management Guide.

5.2 Remove the affected CA from trust stores where [Organisation] decided it should no longer be trusted, and update pinned certificates or public keys in mobile apps and clients, which may require an app release.

5.3 Rebuild internal CAs from a clean environment with new keys in an HSM, new CA certificates and an updated hierarchy, then distribute the new trust anchors before reissuing leaf certificates. See the Enterprise PKI Design and CA Hierarchy Guide.

5.4 Rotate dependent credentials where certificates were used for authentication: mTLS client identities, device certificates, certificate-based service principals and federation signing certificates. Mimecast's 2021 incident shows the pattern: when a vendor certificate used to reach customer Microsoft 365 tenants was stolen, customers had to delete the connection, re-establish it with a replacement certificate and reset service account credentials. See the Mimecast Certificate Compromise.

6. Recovery

6.1 Validate each replaced service from outside and inside the network: chain served, expiry, key size, hostname coverage and handshake success from each client population (browsers, mobile apps, partner systems, legacy clients).

6.2 Watch for breakage caused by clients that pinned the old certificate, intermediate or key. GitHub's 2023 RSA SSH host key replacement broke some CI workflows that pinned the old key; see the GitHub RSA SSH Host Key Exposure. Expect the same with TLS pinning.

6.3 Restore automation pointing to the new CA, and confirm renewals succeed before closing the incident.

6.4 Rollback: keep the previous certificate available only for scenario B where trust has not yet been removed and a replacement causes a critical failure. Never roll back to a certificate whose key may be compromised.

7. Communication and notification

Internal: status updates to application owners at [interval], with the remaining certificate count by priority.
Customers and partners: notify those who pin our certificates, connect with mTLS or must update trust stores, with the new chain and fingerprints published through an authenticated channel.
Vendors: confirm that SaaS, CDN and appliance vendors holding our certificates or trusting the affected CA have acted.
Regulators and contracts: legal assesses whether outages or suspected interception trigger incident reporting under [applicable regulations] or contractual notice.
Do not tell users to click through certificate warnings.

8. Post-incident review

8.1 Within [10] working days, review: time from trigger to full replacement, certificates missing from the inventory, manual replacements that should be automated, pinning that caused breakage, and vendor dependencies.

8.2 Record metrics: percentage of affected certificates replaced within 24 hours and within 7 days, number of outages, number of certificates discovered outside the inventory, and time to update managed trust stores.

8.3 Update the CA appendix, the inventory and this playbook, and confirm an account with a second public CA remains active.

Implementation guidance

Know the external clock. CA/Browser Forum Baseline Requirements (version 2.3.1 at the time of writing) section 4.9.1.1 requires a CA to revoke a subscriber certificate within 24 hours for key compromise and certain other reasons, and within 5 days for others; section 4.9.1.2 requires revocation of a subordinate CA certificate within seven days of key compromise or misuse. Mozilla's Root Store Policy section 7.3 says Mozilla may disable or remove a certificate at any time, immediately or on a planned date, and section 7.4 limits root CA lifetimes. Your plan must work within those windows.

Capability	Why it decides the outcome	Target
Complete certificate inventory with owners	You cannot replace what you cannot find	All public and private certificates, discovered continuously
Automated issuance and renewal	Manual replacement at scale takes weeks	Majority of certificates replaceable without a human
Second CA ready to issue	Onboarding a new CA mid-incident is slow	Active account, validated domains, tested automation
Central trust store management	Blocks must reach every client you control	Endpoint, image and runtime trust stores updated within [24] hours
Minimal pinning	Pins turn replacement into an app release	Pin to multiple keys or avoid pinning
CT monitoring for our domains	Detects forged or unexpected issuance	Alerts within [1] hour

Build the inventory first: combine CT logs, network scanning, cloud certificate managers, load balancer and CDN APIs, internal CA databases and endpoint discovery. NIST SP 1800-16, Securing Web Transactions: TLS Server Certificate Management, gives a reference approach. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Automate and shorten lifetimes: automation built for short certificate lifetimes is the same automation that makes mass replacement possible. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
Design for CA agility: keep issuance profiles CA-neutral so switching CA is a configuration change. See the Crypto-Agility Guide.
Drill: run a tabletop of scenario A once a year and a live replacement of a sample of certificates to a second CA, measuring time and breakage.
Treat certificates as NHIs: every certificate is a machine identity with an owner, a lifecycle and a revocation path, and belongs in NHI governance.

Framework anchors: NIST SP 800-53 Rev. 5 SC-12 Cryptographic Key Establishment and Management, SC-17 Public Key Infrastructure Certificates, IA-5(2) Public Key-based Authentication, CM-8 System Component Inventory, IR-4 Incident Handling and SR-8 Notification Agreements; NIST CSF 2.0 ID.AM-02, RS.MA-01, RS.CO-02 and RC.RP-01; MITRE ATT&CK T1649 Steal or Forge Authentication Certificates for the internal CA case.

CA Compromise and Mass Certificate Replacement Playbook: Responding When a Certificate Authority Is Distrusted