A certificate lifecycle manager (CLM) is bought to stop expiry outages, but rolled out carelessly it becomes a single system that holds issuance rights, private keys and credentials for every certificate authority the organisation uses. This playbook sets out a vendor-neutral, phased rollout for a CLM platform: the decisions to make before connecting the first CA, the order in which to discover and onboard certificates, how to pilot automation, how to roll back and how to prove it is working. It is timed against the move to shorter public TLS certificate lifetimes, which makes manual renewal unworkable. It is written for PKI owners, platform engineering and security architecture teams. Certificate and PKI fundamentals are in the Machine Identity, PKI and Certificate Lifecycle Guide, moving from an existing tool is in the Certificate lifecycle manager migration playbook and recurring checks are in the Certificate lifecycle manager health check; this page covers the first implementation.
Key takeaways
- Treat the CLM as tier-zero infrastructure. It can request certificates from your CAs and often holds private keys, so its administrators, service accounts and CA credentials need the same protection as a domain controller or CA.
- Discovery before automation. You cannot automate what you have not found: network scanning, CA issuance records, Certificate Transparency logs and platform integrations together give the baseline inventory.
- Ownership is the real deliverable. Every certificate needs a named owning team and an application, or renewal alerts go nowhere and revocation decisions stall.
- Keys should stay where they are used. Prefer agents and ACME clients that generate keys on the endpoint over central key generation and distribution.
- Shorter lifetimes set the deadline. CA/Browser Forum Ballot SC-081v3 reduces maximum public TLS validity in steps to 47 days by March 2029, so automated renewal must cover public certificates before the 100-day step.
Before you start: decisions that are hard to change later
NIST SP 1800-16, Securing Web Transactions: TLS Server Certificate Management, describes a formal certificate management programme for medium and large enterprises, with prevention, detection and recovery capabilities. Write a short design record that answers the questions below before any CA is connected.
| Decision | Options | What to consider |
|---|---|---|
| Deployment model | Self-hosted; provider-hosted service; hybrid with on-premises connectors | Hosted services reduce operations but place CA credentials and inventory outside your boundary. Connectors inside each network zone avoid opening inbound paths. |
| Key generation location | On the endpoint (agent or ACME client); central generation and push; hardware module on the endpoint | Endpoint generation keeps private keys off the CLM. Central generation is sometimes needed for appliances that cannot run an agent; if used, restrict and log key export. |
| Automation protocol | ACME (RFC 8555); EST or SCEP for devices; vendor APIs; manual workflow | ACME suits servers and ingress; EST and SCEP suit devices and network gear. See the ACME and Automated Certificate Management Guide and the IoT and Device Certificate Provisioning (EST, SCEP) Guide. |
| CA strategy | One public CA; two or more public CAs; private CA hierarchy; cloud private CA | A second approved public CA is the fastest recovery from a CA distrust event. Private hierarchy design is in the Enterprise PKI Design and CA Hierarchy Guide. |
| Scope of first release | Public TLS only; public and private TLS; all certificate types including code signing, S/MIME and device | Start where outages hurt most, usually public TLS and internal service certificates. Code signing needs separate approval flows. |
| Policy enforcement | Monitor only; warn; block non-compliant requests | Begin in monitor mode, then enforce key type, key size, validity and allowed CAs per profile. |
Small versus large organisations: a small estate with mostly public web certificates can often meet its needs with ACME clients, CT monitoring and a simple inventory, and may not need a full CLM yet. A large estate with several CAs, appliances, Kubernetes clusters and private PKI benefits from a CLM's central policy, workflow and reporting, and should plan for connectors per network zone and integration with the change management system.
The rollout at a glance
| Phase | Main outputs | Exit criteria |
|---|---|---|
| 0. Design and governance | Design record, certificate policy profiles, role model, owner directory | Policy approved; CA list agreed; tier-zero controls designed |
| 1. Harden the platform | Admin access, service accounts, CA credential storage, logging, backups | Platform passes a security review before any production CA is connected |
| 2. Discover | Baseline inventory from scanning, CA records, CT logs and integrations | Inventory reconciled across sources; every certificate assigned or queued for an owner |
| 3. Pilot automation | Two or three applications renewing automatically | Renewal, revocation and rollback tested; no outage over an agreed soak period |
| 4. Production rings | Public TLS, then internal TLS, then devices and other types | Automated renewal coverage meets target for each ring |
| 5. Enforce and operate | Policy enforcement, metrics, runbooks, health check cadence | Non-compliant requests blocked; monthly reporting live |
Phase 0: design and governance
- Write the certificate policy profiles. For each certificate type define allowed CAs, key algorithms and sizes, maximum validity, subject naming rules and approval needs. Start from the Certificate Management Policy Template.
- Define roles. At minimum: platform administrator, policy administrator, CA connector administrator, requester, approver, auditor and break-glass. Keep platform administration and policy administration separate, in line with NIST SP 800-53 AC-5.
- Build the owner directory. Map applications to owning teams from the CMDB or service catalogue, so discovered certificates can be assigned automatically by hostname, namespace or tag.
- Agree renewal timing. NHI Mgmt Group recommends renewing at roughly two thirds of a certificate's lifetime, and following a CA's ACME Renewal Information window where offered. RFC 9773 (Standards Track, June 2025) lets the CA suggest a renewal window and lets clients mark the certificate a new order replaces.
Phase 1: harden the platform first
- Administrative access: administration only through privileged elevation with phishing-resistant MFA, no shared accounts and no standing access for humans in production. See the Cloud PAM and CIEM Guide for elevation patterns.
- CA credentials: store the API keys, ACME external account binding keys and enrolment credentials the CLM uses to reach each CA in a secrets manager or hardware module, scoped per CA and per profile. RFC 8555 Section 7.3.4 describes external account binding, where the CA issues a MAC key out of band to tie an ACME account to an existing customer account; treat that key as a privileged secret.
- Connector and agent identities: every connector, agent and integration is a non-human identity. Give each its own credential, scoped to its zone and the profiles it serves, with rotation.
- Private key handling: if the platform stores or escrows keys, protect them in a validated module and restrict export to a named role with approval and logging. Never escrow signing keys, as the OWASP Key Management Cheat Sheet advises.
- Logging: send administrative actions, policy changes, issuance, revocation, key export and connector authentication events to the SIEM.
- Backup and recovery: back up configuration and inventory, encrypt backups and test a restore before Phase 3.
What happens if this tier-zero system is breached is covered in If your certificate lifecycle manager is compromised; design Phase 1 so that playbook rarely has to be used.
Phase 2: discover and baseline
| Discovery source | Finds | Misses |
|---|---|---|
| Network scanning of TLS ports (443, 8443, 636 and others in use) | Certificates presented on reachable endpoints, including unknown issuers and self-signed | Certificates not yet deployed, client certificates, segments the scanner cannot reach |
| CA issuance records and APIs | Everything issued by connected CAs, including unused certificates | Certificates from CAs not connected or bought on a card |
| Certificate Transparency logs | Every publicly trusted certificate for your domains, including ones issued without approval | Private CA certificates |
| Platform integrations (load balancers, cloud certificate stores, Kubernetes, web servers) | Certificates bound to listeners and secrets, with deployment context | Unintegrated platforms |
| Endpoint agents and file system scans | Key stores and certificate files on servers | Hosts without agents |
Reconcile the sources into one record per certificate with issuer, expiry, key type, location, owner and application. The Certificate Inventory Register Template lists the fields. CT monitoring is covered in the Certificate Transparency Monitoring Guide for Web Teams. Expect the first baseline to surface expired certificates still deployed, weak keys and certificates from unapproved CAs: log them as findings rather than fixing them during discovery.
Phase 3: pilot automation
Choose two or three applications that represent your main patterns, for example a public website behind a load balancer, an internal service in a Kubernetes cluster and an appliance that needs a push integration. For each:
- Enrol in automated renewal with endpoint key generation where possible.
- Renew early on purpose and confirm the new certificate is deployed, the service reloads and monitoring shows the new expiry.
- Revoke a test certificate and confirm the replacement process and revocation status. See the Certificate Revocation Guide.
- Simulate a CA outage and switch the profile to the secondary CA.
- Roll back: confirm the previous certificate and key can be restored from the deployment target, and that manual renewal still works if the CLM is unavailable.
Keep the pilot in monitor mode for policy enforcement. NHI Mgmt Group suggests a soak period covering at least one full renewal cycle for each pilot application before moving on.
Phases 4 and 5: production rings and enforcement
- Ring 1, public TLS: highest outage risk and the first affected by shorter lifetimes. Under SC-081v3 maximum validity falls from 398 days to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029, and reuse of domain validation data falls to 10 days. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
- Ring 2, internal TLS and mTLS: service-to-service certificates from private CAs, including service mesh and cluster issuers. See the mTLS Guide.
- Ring 3, devices and other types: network devices, Wi-Fi and VPN client certificates through EST or SCEP; code signing only with separate approval and hardware-backed keys.
- Enforcement: switch profiles from monitor to block for key type, validity and allowed CAs once each ring's coverage target is met, and require changes to profiles through change management.
Where identity fits
Certificates are machine identities, and a CLM is an identity provider for machines. Each certificate should map to a workload and an owner, the same as any other non-human identity, and the CLM's own agents, connectors and CA credentials are high-value NHIs. MITRE ATT&CK T1649 Steal or Forge Authentication Certificates and T1552.004 Private Keys describe the attacker interest in exactly what a CLM manages. Where workloads can use federated tokens instead, compare options in Certificate vs Federated vs Secret Based Machine Identity.
Detection and measurement
| Event to alert on | Why |
|---|---|
| Issuance outside an approved profile or from an unapproved CA (CLM and CT logs) | Shadow issuance or misuse of CA credentials |
| Private key export or escrow retrieval | Key theft path |
| Policy profile change, new CA connector, new administrator | Persistence or weakening of controls |
| Bulk revocation or bulk issuance | Compromise or runaway automation |
| Renewal failure for a certificate inside its renewal window | Imminent outage |
Metrics that show the rollout is working:
- Automated renewal coverage: percentage of in-scope certificates renewed without human action, per ring.
- Owner coverage: percentage of discovered certificates with a valid owner.
- Expiry incidents: production incidents caused by expired or mis-deployed certificates per quarter (target: zero).
- Unknown issuance: certificates seen in CT or scans that were not issued through the CLM.
- CA switch time: time to reissue a defined critical set from the secondary CA in an exercise.
Common failure patterns
- Connecting CAs before hardening: the CLM goes live with shared admin accounts and CA API keys in its configuration, creating a single path to issue trusted certificates for any domain.
- Central key generation by default: private keys for thousands of endpoints sit in one database, turning a CLM breach into a mass re-key.
- Inventory without owners: alerts fire into a shared mailbox and certificates still expire.
- Automating renewal but not deployment: a new certificate is issued but never installed or the service never reloads.
- One CA only: a distrust or CA outage leaves no automated fallback. See the CA Compromise and Mass Certificate Replacement Playbook.
- Enforcing too early: blocking non-compliant requests before discovery is complete breaks legacy systems that nobody knew depended on them.
Framework mapping
| Area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | Other |
|---|---|---|---|
| Certificate policy and issuance | SC-17, IA-5(2) | PR.AA-01 | NIST SP 1800-16 |
| Key management | SC-12 | PR.DS-02 | NIST SP 800-57 Part 1 Rev. 5 |
| Inventory | CM-8 | ID.AM-08 | CT logs |
| Platform administration | AC-5 | PR.AA-01 | ATT&CK T1098 Account Manipulation |
| Logging and detection | AU-2 | DE.CM-09 | ATT&CK T1649, T1588.004 Digital Certificates |
| Configuration and enforcement | CM-2 | PR.PS-01 | Policy profiles |
Practitioner checklist
- Write the design record: deployment model, key generation location, protocols, CA strategy and first-release scope.
- Approve certificate policy profiles per certificate type.
- Harden the CLM as tier-zero before connecting any production CA.
- Store CA credentials and external account binding keys in a secrets manager, scoped per CA.
- Run discovery from at least four sources and reconcile into one inventory.
- Assign an owner to every certificate through the service catalogue.
- Pilot renewal, revocation, CA failover and rollback on representative applications.
- Bring public TLS under automated renewal before the 100-day validity step in March 2027.
- Alert on out-of-profile issuance, key export, profile change and renewal failure.
- Switch policy profiles from monitor to block once each ring meets its coverage target.
Standards and references
- NIST: SP 1800-16, Securing Web Transactions: TLS Server Certificate Management
- CA/Browser Forum: Ballot SC-081v3, Introduce Schedule of Reducing Validity and Data Reuse Periods
- IETF: RFC 8555, Automatic Certificate Management Environment (ACME)
- IETF: RFC 9773, ACME Renewal Information (ARI) Extension
- NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: General
- NIST: SP 800-53 Rev. 5
- OWASP: Key Management Cheat Sheet
- MITRE ATT&CK: Steal or Forge Authentication Certificates
Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · Certificate lifecycle manager migration playbook · Certificate lifecycle manager health check · Certificate Lifecycle Management RFP Template · ACME and Automated Certificate Management Guide