A certificate lifecycle manager can show a green dashboard while certificates it has never discovered expire, while renewal agents run with domain admin rights and while a quarter of its inventory has no owner anyone can reach. This health check is a recurring, measurable review of the platform you use to discover, issue, renew, deploy and revoke X.509 certificates: the lifecycle manager itself, its discovery scanners and agents, its connections to public and private certificate authorities (CAs), and the people and machines that administer it. It turns the questions an auditor, PKI lead or CISO would ask into twelve metrics with formulas and thresholds so results can be compared quarter on quarter.
This page measures; it does not explain how to build certificate lifecycle management. For lifecycle design, automation and policy, use the Machine Identity, PKI and Certificate Lifecycle Guide and, for certificate policy and practice statements, the ISO/IEC 27099 PKI Practices and Policy Framework Guide. Go back to them for every finding this review raises. The check is vendor-neutral: it applies to commercial platforms, cloud certificate services and in-house tooling built on ACME clients and scripts.
What this health check covers
Certificates are machine identities. The lifecycle manager is the system that holds the keys to issue, and often deploy, those identities at scale, so its health is both an availability question (outages from expiry) and an identity question (who or what can mint a trusted certificate). The review covers:
- Inventory and discovery: whether the platform knows about the certificates actually in use, internal and public, including CA chain certificates.
- Renewal and deployment: whether certificates are renewed and installed on time, automatically, and whether the platform is ready for public TLS validity falling in stages from March 2026 to 47 days by March 2029, as set by CA/Browser Forum Ballot SC-081v3.
- Issuance control: which CAs, templates and profiles the platform may use, and whether off-policy issuance is caught.
- The platform as a privileged identity: administrator accounts, CA connector credentials, agent and service accounts, and API tokens used by pipelines to request certificates.
- Crypto-agility: whether you could replace every certificate from one CA or with one algorithm in days, not months.
Who runs it: the PKI or machine identity lead collects the data; the identity or security architecture function reviews it; the CISO or head of infrastructure signs off. What it is not: a CA audit against a certificate policy, a TLS configuration scan or a penetration test, although those produce inputs to some metrics. Teams searching for a "certificate management audit checklist", "PKI health check" or "certificate expiry KPIs" can use the metrics table as-is.
Key takeaways
- Coverage before compliance. A renewal rate measured only over known certificates hides the outages; the discovered-but-unmanaged count is the first number to watch.
- Every certificate needs a reachable owner. NIST SP 1800-16B recommends group ownership rather than individuals; measure orphaned certificates and stale owner groups.
- Short lifetimes turn manual renewal into an outage source. Track the share of certificates renewed and deployed with no human step, by environment.
- The platform is a privileged non-human identity. Its CA connectors, agents and API tokens can mint trusted identities, so measure their privilege, rotation and use like any tier 0 credential.
- Prove crypto-agility with a drill. Time to replace all certificates from one issuer is a measured figure, not a statement in the policy.
How to use this template
Copy the metrics table and the findings log into your own tracker, then run this Certificate lifecycle manager health check at the cadence set out below. Collect each figure from the data sources described, score it against the green, amber and red thresholds, and record every amber or red result as a finding with an owner and a due date. Keep each completed review so you can compare results quarter on quarter: the trend matters as much as any single score.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Expiry horizon review (next 30 days) | Weekly | PKI operations | PKI lead | Expiry report, renewal tickets, escalations |
| Discovery reconciliation | Monthly | PKI operations | PKI lead | Scan coverage list, newly found certificates, CT log matches |
| Full metrics review (this page) | Quarterly | PKI or machine identity lead | CISO or head of infrastructure | Metrics table, raw extracts, findings log |
| Platform access recertification | Quarterly | Identity governance team | PKI lead | Admin, connector and token list with reviewer decisions |
| Crypto-agility drill | Annually, and after any CA distrust announcement | PKI lead | CISO | Drill scope, timings, certificates missed, lessons |
Keep raw extracts with each quarter's results for at least the life of your audit evidence cycle. When a figure is challenged, you need the population, not just the percentage.
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. Several timing thresholds follow the bracketed, adjustable suggestions in NIST SP 1800-16B (for example renewal at least 30 days before expiry, or before 80% of lifetime for certificates valid under 60 days). "In use" means presented by an endpoint or installed in a store found by discovery in the period.
| ID | Metric | Formula | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| CLM-01 | Managed coverage | Certificates in use that are under platform management ÷ all certificates in use found by discovery, CT log monitoring and CA issuance records | Platform inventory, discovery scan results, CA issuance exports, CT monitor | At least 95% | 85% to below 95% | Below 85% |
| CLM-02 | Discovery scope coverage | Network ranges, cloud accounts and key stores scanned in the last 30 days ÷ ranges, accounts and stores in the asset register | Discovery job configuration and run history, asset register, cloud account list | At least 95% | 80% to below 95% | Below 80% |
| CLM-03 | Orphaned certificates | Managed certificates with no owner group, or an owner group with no active members ÷ managed certificates | Platform inventory owner fields joined to directory group membership | Below 2% | 2% to 10% | Above 10% |
| CLM-04 | Expiry incidents | Count of service incidents caused by an expired end-entity, intermediate or root certificate in the quarter | Incident management records, post-incident reviews | 0 | 1, non-customer-facing | Any customer-facing, or more than 1 |
| CLM-05 | Late renewals | Certificates renewed and deployed less than 30 days before expiry (or after 80% of lifetime when valid under 60 days) ÷ certificates renewed in period | Platform renewal and deployment logs | Below 5% | 5% to 15% | Above 15% |
| CLM-06 | Hands-off renewal rate | Renewals completed and installed with no manual step ÷ all renewals in period, reported separately for public TLS, private TLS and other types | Platform renewal and deployment logs, ACME or enrolment protocol logs | At least 80% public TLS | 50% to below 80% | Below 50% |
| CLM-07 | Off-policy issuance | Certificates issued for your domains or from your private CAs outside an approved CA, template or profile ÷ certificates issued in period | CA issuance logs, CT monitor, approved CA and template list | 0 | Found and revoked within 24 hours | Any unresolved after 24 hours |
| CLM-08 | Weak or non-compliant certificates | Certificates in use with key size, algorithm, validity or wildcard use outside policy ÷ certificates in use | Platform inventory key and validity attributes, policy rules | Below 1% | 1% to 5% | Above 5% |
| CLM-09 | Platform standing administrators | Human accounts with permanent administrator or CA-connector management rights ÷ human accounts with any platform role | Platform role assignment export, PAM records | Below 5% and all MFA | 5% to 15% | Above 15%, or any admin without MFA |
| CLM-10 | Stale platform credentials | CA connector credentials, agent identities and API tokens older than the rotation policy, or unused for 90 days ÷ all such credentials | Platform credential and token inventory, secrets store metadata, platform audit log | Below 5% | 5% to 20% | Above 20% |
| CLM-11 | Audit log forwarding | Platform components (core, discovery, agents, CA connectors) whose audit events reached the SIEM in the last 7 days ÷ components deployed | Platform logging configuration, SIEM source inventory | 100% | Forwarding gaps under 7 days | Any component silent for 7 days or more |
| CLM-12 | Bulk replacement time | Hours to replace all certificates from one issuing CA in the last drill, and certificates missed ÷ certificates in drill scope | Drill records, platform deployment logs | Within 48 hours and 0 missed | Over 48 hours to 7 days, or above 0% to below 2% missed | Over 7 days, 2% or more missed, or no drill in 12 months |
Once these are stable, add revocation publication time (minutes from revocation request to updated CRL or OCSP status, as the ISO/IEC 27099 guide recommends testing) and the share of private keys for critical services held in an HSM or non-exportable store.
How to collect the data
Pull every figure from a system export, not from a questionnaire. Figures reported by the team being measured are not evidence.
- Build the true population. Combine three independent sources: the platform's own inventory export; discovery scan results across internal ranges, cloud load balancers, ingress controllers and key stores; and the issuance records of every CA you use, plus a Certificate Transparency log monitor for your public domains. Deduplicate by serial number and issuer. This drives CLM-01, CLM-07 and CLM-08.
- Reconcile scope against the asset register. Export the discovery job list with targets and last successful run, and compare it with the network range list, cloud account list and asset inventory (CLM-02). Treat a cloud account with no discovery job as uncovered, whatever the job count says.
- Join owners to the directory. Export certificate owner fields and resolve each to a group with active members. A named person who has left is an orphan (CLM-03). The Certificate Inventory Register Template gives a usable column set.
- Read the renewal log, not the expiry calendar. For CLM-05 and CLM-06 take each renewal event with its request time, issuance time, installation time, previous certificate's expiry and whether any step needed a person (an approval, a manual install, a file copy).
- Collect incidents. Search incident records and post-incident reviews for certificate expiry, chain and trust store causes (CLM-04). Include incidents where the expired certificate was outside the platform; those are coverage failures.
- Export platform access. List human roles with assignment type (standing or just-in-time), MFA status, and every non-human credential: CA connector accounts, agent or orchestrator identities, ACME account keys, API tokens used by CI/CD pipelines. Record created, last rotated and last used dates (CLM-09, CLM-10).
- Prove log flow. Read logging settings per component, then query the SIEM for events from each in the last seven days (CLM-11). Configuration alone does not prove forwarding.
- Run or review the drill. Pick one issuing CA (or one key algorithm) and replace every certificate it issued in a test or controlled production scope; record elapsed time and misses (CLM-12). The CA Compromise and Mass Certificate Replacement Playbook describes the scenario.
Red flags that need action now
- A customer-facing outage from an expired certificate that was not in the platform inventory.
- A certificate for one of your domains appears in Certificate Transparency logs from a CA not on your approved list, or not permitted by your CAA records.
- An issuing CA's private key, or a CA connector credential with issuance rights, is stored in plain text on an agent host or in a pipeline variable.
- A renewal agent or discovery account runs with domain administrator or cloud organisation administrator rights.
- A platform administrator account without MFA, or a shared administrator login.
- Certificates expiring in the next 14 days with no owner and no renewal ticket.
- Platform audit logging switched off, or no events in the SIEM from a CA connector for more than seven days.
- An API token used by a pipeline to request certificates that can request any name, rather than names it owns.
- A distrust announcement for one of your public CAs with no replacement plan and date.
Findings log
Record each amber or red result and each red flag as a finding. Keep the log with the quarter's evidence and carry open items forward.
| ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-CLM-01 | [Description, e.g. 14% of in-use certificates on load balancers in two cloud accounts not under management] | CLM-01, CLM-02 | [High] | [PKI operations lead] | [Date] | [Open] |
| HC-CLM-02 | [Description, e.g. CA connector service credential last rotated 26 months ago] | CLM-10 | [High] | [Platform owner] | [Date] | [Open] |
| HC-CLM-03 | [Description] | [ID] | [Critical / High / Medium / Low] | [Role] | [Date] | [Open / In progress / Closed / Risk accepted] |
Suggested due dates: critical within 7 days, high within 30 days, medium within 90 days. A risk acceptance needs a named approver and an expiry date.
Remediation map
Framework mapping
| Area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | CIS Controls v8.1 |
|---|---|---|---|
| Inventory and coverage (CLM-01 to 03) | ID.AM-02, PR.AA-01 | CM-8, SC-17 | Control 1, Control 2 |
| Renewal and expiry (CLM-04 to 06) | PR.DS-02, PR.PS-01 | SC-12, SC-17 | Control 4 |
| Issuance and certificate quality (CLM-07, 08) | PR.AA-01, DE.CM-09 | SC-12, SC-17, IA-5 | Control 3, Control 4 |
| Platform access and credentials (CLM-09, 10) | PR.AA-05 | AC-2, AC-6, IA-5 | Control 5, Control 6 |
| Logging and agility (CLM-11, 12) | PR.PS-04, DE.CM-09 | AU-2, AU-6, CA-7 | Control 8 |
Related guides
- Machine Identity, PKI and Certificate Lifecycle Guide: the lifecycle this check measures.
- PKI and Certificate Lifecycle Maturity Model: place the quarter's results on a maturity level.
- Certificate Outage and PKI Statistics Guide: context for expiry and outage figures.
- If your certificate lifecycle manager is compromised: what to do when a red flag turns out to be an incident.
- Certificate lifecycle manager migration playbook: when the findings point to replacing the platform.
- Identity Security Metrics Guide: how these metrics roll up into identity reporting.
References
- NIST: SP 1800-16B, Securing Web Transactions: TLS Server Certificate Management, Volume B
- NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- CA/Browser Forum: Ballot SC-081v3, Schedule of Reducing Validity and Data Reuse Periods
- CIS: Critical Security Controls v8.1
Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide, ISO/IEC 27099 PKI Practices and Policy Framework Guide, PKI and Certificate Lifecycle Maturity Model, If your certificate lifecycle manager is compromised.