A certificate lifecycle manager (CLM) holds the accounts that order certificates for your domains, often the private keys behind them, and the credentials that install those keys on servers, load balancers and devices, so its compromise lets an attacker impersonate your services or take them offline. Unlike a compromised certificate authority, the CA itself is still trustworthy: the problem is that an attacker can ask it for certificates in your name, steal keys the CLM generated or stored, push their own keys to your endpoints, or revoke certificates en masse. This guide is a vendor-neutral response playbook for that scenario: triggers, triage, containment of CA accounts and deployment agents, deciding which certificates and keys to replace, revocation timing, rebuild, evidence and notification. It is for PKI engineers, incident responders and platform owners, and assumes the controls in Securing the certificate lifecycle manager itself. If the CA's own signing keys are involved, switch to the internal PKI and CA compromise playbook.
Key takeaways
- Cut the CLM off from the CAs first. Disabling its CA accounts and API credentials stops new rogue certificates; every other step depends on that.
- Use Certificate Transparency as your independent record. The CLM's own inventory may be altered, but publicly trusted certificates appear in CT logs regardless of who ordered them.
- Replace keys, not just certificates. Renewing on the same key pair leaves a stolen private key valid; generate new keys on the endpoint where you can.
- Revocation has a clock. CA/Browser Forum Baseline Requirements oblige a public CA to revoke within 24 hours after evidence of key compromise or a report that issuance was not authorised, so plan replacements before you report.
- Stage replacement to avoid an outage. Mass revocation without replacement is the outage the attacker might have wanted; order and deploy new certificates by service tier, then revoke.
What a CLM compromise looks like
| Compromise point | What the attacker can do | ATT&CK v20 |
|---|---|---|
| Admin console or API with admin rights | Order certificates, export stored keys, change policies (allowed domains, approvers, key sizes), alter inventory and audit settings | T1588.004, T1552.004 |
| Public CA account credentials or ACME account keys held by the CLM | Obtain publicly trusted certificates for your domains using domain validations the CA has already accepted | T1588.004 |
| Private CA connector or registration authority credentials | Issue internal client or server certificates usable for authentication | T1649 |
| Central key store (keys generated or escrowed by the CLM) | Decrypt traffic where forward secrecy is absent, impersonate services, sign code if code signing keys are held | T1552.004, T1553.002 |
| Deployment agents and device credentials (web servers, load balancers, appliances) | Install attacker keys and certificates on endpoints to enable interception; harvest device admin credentials | T1557 |
| Trust store management (where the CLM pushes root certificates) | Add an attacker root to clients | T1553.004 |
| Revocation and renewal functions | Revoke or let certificates lapse across the estate to cause outages | Impact without a dedicated technique |
Domain validation reuse is why stolen CA account access is dangerous. Under section 4.2.1 of the Baseline Requirements (version 2.3.1, checked November 2026), a CA may reuse domain validation data for up to 200 days for certificates issued from 15 March 2026, falling to 100 days from 15 March 2027 and 10 days from 15 March 2029. Within that period, whoever controls an account with valid validations can obtain certificates without touching your DNS. ACME (RFC 8555) likewise lets orders reuse unexpired authorisations the account has already completed.
Triggers and triage
Invoke this playbook for: a CT log entry for your domain that no team ordered; a CLM admin sign-in from an unknown device or network; a new CA connector, ACME account, API key or approver added without a change record; bulk export of private keys; policy changes such as an added domain, removed approval or weaker key type; deployment jobs to endpoints outside a change; unexpected revocations or renewals; or a CA telling you about suspicious orders.
- Preserve evidence: export CLM audit logs, order and approval history, deployment job logs and key export events, plus CA account activity from each CA's portal or API, before making changes.
- Pull the CT record: search CT logs for every certificate issued for your registered domains in the window and compare with CLM inventory. See the Certificate Transparency Monitoring Guide for Web Teams.
- Establish capability: which CA accounts, connectors, key stores and deployment targets the compromised identity could reach.
- Decide key exposure: if the attacker could export keys or read the key store or its encryption key, treat every key the CLM held as compromised.
- Check endpoints touched: list deployment jobs in the window and fingerprint the certificates currently served by those endpoints.
Containment in the right order
- Move responders out of band and confirm you can reach each CA's portal and the private CA directly, without going through the CLM.
- Disable CA access from the CLM: suspend or delete the CLM's API keys at each public CA, deactivate its ACME accounts (RFC 8555 section 7.3.6: once deactivated, the server must not accept requests authorised by that account key, and there is no reactivation), and disable registration authority credentials at the private CA. Ask public CAs whether they can also drop cached domain validations for your account.
- Restrict issuance with CAA: tighten CAA records to the CAs you will use for replacement, and where your CA supports RFC 8657, bind issuance to a new account with the accounturi parameter so stolen accounts cannot order. RFC 8657 notes the parameters only work if the CA recognises them.
- Stop deployment: disable deployment agents and rotate the credentials they use on servers, load balancers and appliances. Isolate agent hosts suspected of compromise.
- Lock the key store: restrict access to the CLM's key store and its encryption key to the response team. See the Encryption Key Compromise Playbook for the key-scoping steps.
- Restrict administration to named responders and remove attacker-created admins, approvers, API keys and connectors.
- Freeze automatic revocation jobs until the replacement plan is ready, so an attacker-scheduled revocation cannot cause an outage.
Deciding what to replace and revoke
| Certificate group | Action | Timing |
|---|---|---|
| Certificates in CT that no team ordered | Request revocation as not authorised; check where they are served (DNS, hosting) | Immediately; the CA must revoke within 24 hours of the report |
| Certificates whose private keys the CLM generated, stored or could export | New key pair on the endpoint, new certificate, deploy, then revoke the old one with reason keyCompromise | Tier 1 services within hours; report to the CA once replacements are ready, since the 24-hour clock starts on notice |
| Certificates deployed by agents in the window | Verify the served certificate and key match the expected inventory; replace where uncertain | First day |
| Code signing certificates held in the CLM | Revoke and assess signed artefacts. See the Compromised Code Signing Certificate Playbook | Immediately |
| Internal client and device certificates issued in the window | Revoke those not tied to a legitimate request; check authentication logs for their use | First day |
| Certificates whose keys were generated on the endpoint and never seen by the CLM | Normally keep; renew through the rebuilt CLM | Normal cycle |
Baseline Requirements section 4.9.1.1 lists the 24-hour cases: a written request from the subscriber, notice that the original request was not authorised, evidence of key compromise (CRLReason keyCompromise), a demonstrated method to compute the key, and domain validation that should not be relied upon. Short-lived certificates are excepted. Coordinate with each CA's revocation contact so the clock and your replacement plan line up. For revocation mechanics and client behaviour, see the Certificate Revocation Guide; for estate-wide replacement logistics, the CA Compromise and Mass Certificate Replacement Playbook.
Replacing at scale without an outage
- Tier the services: externally facing authentication, payment and API endpoints first; then internal service-to-service and mTLS; then the long tail.
- Generate keys where they are used: on the server, HSM or device, so the rebuilt CLM never holds them. Central key generation should be the documented exception.
- Use a clean issuance path: new CA accounts, new ACME account keys and fresh domain validations, ordered from a clean host while the CLM is rebuilt.
- Verify what is served: after each deployment, check the certificate fingerprint and key on the endpoint itself, not in the CLM inventory.
- Clean trust stores: if the CLM managed trust stores, compare every client trust store with a known-good list and remove unexpected roots. See the Certificate trust stores and root CA management guide.
Choosing the response depth
| Decision | Option A | Option B | Choose B when |
|---|---|---|---|
| Scope of key replacement | Replace only keys the attacker is shown to have exported | Replace every key the CLM held | Key export logging was off, altered, or the key store's encryption key was reachable |
| Issuance path during recovery | Keep the existing CLM after cleaning | Order manually or from a temporary clean host | The CLM host or its agents may run attacker code |
| Public CA accounts | Rotate API keys on existing accounts | Close the accounts and open new ones | The attacker could add users, approvers or domains to the account at the CA |
| Revocation timing | Revoke as each replacement is verified | Revoke all exposed certificates at once | Rogue certificates are being actively used for interception or phishing |
A smaller organisation with a few dozen public certificates can usually replace everything in a day from the CA portals and should prefer the stricter option throughout. A large estate with tens of thousands of internal certificates needs the tiered approach: full replacement for anything the CLM generated or deployed in the window, endpoint verification for the rest, and a short-lived certificate policy afterwards so the next exposure ages out quickly. Treat the CLM's own service accounts on servers, load balancers and appliances as non-human identities with owners and rotation, because they are how an attacker turns key theft into interception. See the Service Account Security Guide.
Eradication and rebuild
| Situation | Choose |
|---|---|
| A single admin or API key abused, key store and hosts untouched, logs intact | Clean in place: remove attacker objects, diff policy, connectors and approvers against a known-good export, rotate all CLM credentials |
| Key store or its encryption key reachable | Rebuild the CLM with a new key store and new keys; do not migrate stored private keys |
| Code execution on CLM servers or agents, or logs unreliable | Rebuild servers and agents from clean images; re-enrol agents with new credentials |
Restore configuration only from an export verified as pre-dating the window (CSF 2.0 RC.RP-03). Before reconnecting the rebuilt CLM to CAs, close the entry point, issue it new CA credentials, and re-establish approval policies with dual control for new domains, new CA connectors and key export.
Evidence and notification
- Preserve: CLM audit and order logs, key export events, deployment job logs, CA account activity, CT search results with timestamps, endpoint certificate fingerprints before replacement, and host images where code execution is suspected.
- CAs: report unauthorised issuance and key compromise through each CA's problem reporting route, with your replacement plan.
- Customers and partners: tell anyone who pins your certificates or keys, or trusts your private CA, before you rotate. See the Certificate Pinning.
- Regulators: if intercepted traffic may have carried personal data, legal must assess notification. See the Cyber Incident Reporting Requirements Map.
Detection and measurement
For 90 days after recovery, alert on: CT entries for your domains not matched to a CLM order; new CA accounts, connectors or approvers; key export events; deployment jobs outside change windows; policy edits that add domains or remove approvals; and spikes in revocation or renewal activity.
- CT-to-inventory match rate for publicly trusted certificates, target 100%.
- Time from declaration to all CA access disabled.
- Exposed keys replaced and old certificates revoked, by service tier.
- Share of certificates with keys generated on the endpoint rather than in the CLM.
- Endpoints verified by served fingerprint after replacement.
Common failure patterns
- Renewing on the same key: the new certificate carries the same public key, so the attacker's stolen private key works with it too.
- Revoking before replacing: mass revocation turns a security incident into a self-inflicted outage.
- Trusting the CLM inventory: rogue certificates ordered through a stolen account may never appear in it; CT will show them.
- Forgetting cached validations: a disabled user is not a disabled CA account; domain validations can outlive the response.
- Treating signing material as ordinary certificates: stolen code signing or token signing keys have wider consequences, as the GitHub Code Signing Certificate Theft and the Microsoft Storm-0558 Key Breach show.
Framework mapping
| Framework | Reference | Where it applies |
|---|---|---|
| NIST CSF 2.0 | RS.AN-03, RS.MI-01, RS.MI-02, RC.RP-03 | Scoping, containment, eradication, verified restoration |
| NIST SP 800-53 Rev. 5 | SC-12, SC-17, IA-5, IR-4, AU-9, CM-3 | Key management, PKI certificates, authenticators, incident handling, audit protection, change control |
| MITRE ATT&CK v20 | T1588.004, T1552.004, T1649, T1557, T1553.002, T1553.004 | Rogue issuance, key theft, certificate abuse, interception, signing and trust store abuse |
| CA/Browser Forum Baseline Requirements | 4.2.1, 4.9.1.1 | Validation reuse windows, revocation deadlines |
| IETF | RFC 8555 (7.3.6, 7.6), RFC 8657 | ACME account deactivation and revocation, CAA account binding |
Practitioner checklist
- Keep a list of every CA account, ACME account and RA credential the CLM uses, with how to disable each one directly at the CA.
- Monitor CT for all registered domains and reconcile against CLM orders daily.
- Publish CAA records and use accounturi where your CAs support it.
- Generate keys on endpoints by default and record which keys the CLM holds.
- Stream CLM audit and deployment logs to a SIEM the PKI team cannot change.
- Pre-agree revocation contacts and timing with each CA.
- Exercise a replacement of your top 20 certificates by service tier and time it.
- Keep a known-good export of CLM policy, connectors and approvers.
Standards and references
- CA/Browser Forum: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates
- IETF: RFC 8555, Automatic Certificate Management Environment (ACME)
- IETF: RFC 8657, CAA Record Extensions for Account URI and ACME Method Binding
- NIST: SP 1800-16, Securing Web Transactions: TLS Server Certificate Management
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
- CA/Browser Forum: Ballot SC081v3, schedule of reducing validity and data reuse periods
- MITRE ATT&CK: Obtain Capabilities: Digital Certificates
Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · Securing the certificate lifecycle manager itself · If your internal PKI and certificate authority is compromised · ACME and Automated Certificate Management Guide · If your secrets manager is compromised