An internal certificate authority can issue a certificate that every domain-joined server, VPN gateway and service mesh will trust, so a quiet misconfiguration in its templates or a root key nobody can account for is an identity compromise waiting to happen. This health check is a recurring, measurable review of your private PKI: the offline root, the issuing and intermediate CAs, their private keys and hardware security modules (HSMs), certificate templates or profiles, enrolment interfaces, revocation services and the people and machines that administer them. It turns the questions a PKI lead, internal auditor or CISO would ask into twelve metrics with formulas and thresholds you can compare quarter on quarter.
This page measures the CA itself; it does not explain how to design one. For hierarchy design, policy and practice statements use the Enterprise PKI Design and CA Hierarchy Guide and the ISO/IEC 27099 PKI Practices and Policy Framework Guide, and go back to them for each finding. The check is vendor-neutral and applies to directory-integrated CAs, open-source CA software and managed private CA services.
What this health check covers
An internal CA is the root of trust for most of your machine identities: server TLS, mutual TLS between services, device and user authentication certificates, code and document signing. NIST SP 1800-16B states plainly that internal CAs, where used, should be securely operated, and recommends keeping at least one backup internal CA. The review covers:
- CA keys and hierarchy: where each CA private key lives, whether the root is offline, and how much life each CA certificate has left.
- Issuance controls: which templates or profiles exist, who may enrol for them, and whether any allow a requester to choose an identity they do not own.
- Revocation services: whether certificate revocation lists (CRLs) and OCSP responders are current and reachable by relying parties.
- The CA as a privileged system: CA administrators, certificate managers, enrolment agents, the CA service accounts and the hosts the CAs run on.
- Recoverability: backups of the CA database and keys, and whether a restore or replacement has been proven.
Who runs it: the PKI lead or PKI operations collects the data; security architecture or identity governance reviews it; the CISO or head of infrastructure signs off. What it is not: a formal audit against your certificate policy (CP) and certification practice statement (CPS), a review of the tooling that renews end-entity certificates (that has its own certificate lifecycle manager health check), or a penetration test. Teams searching for a "PKI health check", "internal CA audit checklist" or "certificate authority security review" can use the metrics table as-is.
Key takeaways
- The CA is tier 0. Anyone who can sign with an issuing CA key, or approve a dangerous template, can impersonate servers and often users; MITRE ATT&CK tracks this abuse as T1649 Steal or Forge Authentication Certificates.
- Templates are the most common weak point. Count templates that let the requester supply the subject while granting an authentication purpose, and drive the number to zero.
- Revocation only works if it is published. A CRL that expired yesterday, or an unreachable OCSP responder, fails open or breaks services; measure freshness, not configuration.
- CA certificate expiry is a slow outage. Track the runway of every root and issuing CA certificate against the longest certificate it still issues.
- An untested restore is not a backup. Measure the date of the last successful CA restore or replacement drill, not the backup job status.
How to use this template
Copy the metrics table and findings log into your own tracker and run this Internal PKI and certificate authority health check at the cadence below. Collect each figure from the data sources described, score it against the green, amber and red bands, and record every amber or red result as a finding with an owner and a due date. Keep each completed review: the trend across quarters tells you more than any single score. Replace bracketed text with your own values.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| CRL and OCSP freshness check | Daily automated, weekly review | PKI operations | PKI lead | Publication times, next-update values, responder probe results |
| Template and enrolment permission review | Monthly, and on every template change | PKI operations | PKI lead | Template export with purposes, subject settings and enrolment rights |
| Full metrics review (this page) | Quarterly | PKI lead | CISO or head of infrastructure | Metrics table, raw extracts, findings log |
| CA role recertification | Quarterly | Identity governance | PKI lead | CA administrator, certificate manager, auditor and enrolment agent lists with decisions |
| Offline root inspection and CRL re-signing | At each scheduled root CRL issuance (at least annually) | Key custodians (two people) | PKI lead | Ceremony log, seal numbers, witness signatures |
| CA restore or replacement drill | Annually | PKI lead | CISO | Drill plan, timings, issues, sign-off |
Store raw extracts with each quarter's results. When a figure is challenged you need the population, not only the percentage.
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. "CA" means every root, intermediate and issuing CA in your private hierarchies, including CAs in test and lab environments that issue certificates trusted in production.
| ID | Metric | Formula | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| PKI-01 | CA register completeness | CAs found in trust stores, directory publication points and issuance logs that are in the CA register with an owner ÷ all CAs found | Trust store exports from managed devices, directory PKI containers, CA register | 100% | 95% to below 100% | Below 95%, or any unknown CA trusted in production |
| PKI-02 | Hardware-protected CA keys | CAs whose signing key is held in an HSM or equivalent non-exportable hardware ÷ all CAs | HSM key inventory, CA cryptographic provider configuration | 100% for root and issuing CAs | Root and issuing CAs at 100%, lab or other subordinate CAs below | Any root or issuing CA with a software-held key |
| PKI-03 | Root offline status | Days in the quarter the root CA host was powered on or network-connected outside a recorded ceremony | Ceremony log, physical access log, root host event log | 0 | 1 to 2 days, all with a ceremony record | Over 2 days, any connection without a ceremony record, or root kept online |
| PKI-04 | CA certificate runway | For each CA: remaining validity of the CA certificate minus maximum validity of certificates it issues; report the lowest value | CA certificate exports, template or profile validity settings | 12 months or more | 6 to below 12 months, with a renewal plan | Below 6 months, or no plan |
| PKI-05 | Dangerous templates | Published templates or profiles that let the requester supply the subject or subject alternative name and allow client authentication, smart card logon or any purpose ÷ published templates | Template or profile export, enrolment permission lists | 0 | Present, each requiring manager approval and limited to a named group | Any without manager approval, or any enrollable by broad groups such as all users or all computers |
| PKI-06 | Unused published templates | Published templates with no issuance in the last 180 days ÷ published templates | CA issuance database, template list | Below 10% | 10% to 25% | Above 25% |
| PKI-07 | CRL freshness margin | For each CA: time remaining before the published CRL's next-update value at the moment of the check; report the lowest | CRL distribution point probes from several network locations | At least 50% of the CRL validity period remaining | 25% to below 50% | Below 25%, any expired CRL, or any distribution point unreachable |
| PKI-08 | OCSP responder availability | Successful OCSP probes with a valid signed response ÷ probes in period, per responder | Synthetic monitoring results, responder logs | At least 99.9% | 99% to below 99.9% | Below 99%, or responder signing certificate within 14 days of expiry |
| PKI-09 | Privileged CA roles | Accounts holding CA administrator, certificate manager or enrolment agent rights that are not on the approved role list, or held by one person in two conflicting roles ÷ accounts with any CA role | CA security settings export, directory group membership, approved role list | 0 | Exceptions with expiry and approver | Any unapproved holder, or a single person who can both approve templates and issue against them |
| PKI-10 | CA service and host credentials | CA service accounts, HSM partition credentials and enrolment interface secrets past rotation policy or with interactive logon allowed ÷ all such credentials | Service account inventory, HSM user list, secrets store metadata | Below 5% | 5% to 15% | Above 15%, or any HSM credential known to one person only |
| PKI-11 | Issuance anomalies investigated | Issuance alerts (new template used, high-value subject such as a domain controller or administrator name, volume above baseline) triaged within 24 hours ÷ alerts raised | CA audit log in the SIEM, alert queue | 100%, with CA logs received from every CA in the last 24 hours | 90% to below 100%, or 100% with a CA silent in the SIEM for 24 hours to 7 days | Below 90%, or any CA with no events in the SIEM for 7 days |
| PKI-12 | Proven recoverability | Months since a successful restore of each issuing CA (database and key) or a replacement drill; report the highest | Drill records, backup job logs, HSM backup records | 12 months or less | Over 12 to 24 months | Over 24 months, never tested, or key backup held in one location only |
Once these are stable, consider adding the share of issued certificates using algorithms and key sizes approved by your key management policy (NIST SP 800-57 Part 1 Rev. 5 gives the baseline) and the time from a revocation request to its appearance in a published CRL.
How to collect the data
Pull every figure from system exports and probes, never from a questionnaire answered by the team being measured.
- Find every CA. Export trusted root and intermediate stores from a sample of managed servers and endpoints, list CA objects published in the directory, and collect the issuer of every certificate seen in network or discovery scans. Reconcile against the CA register (PKI-01). Lab CAs whose roots appear in production trust stores count.
- Prove where keys live. For each CA, read the cryptographic provider configuration and match the key label to the HSM key inventory (PKI-02). A key marked exportable, or a software provider, is a software key regardless of what the design document says.
- Read the root's history. Compare the ceremony log with physical access records and the root host's own event log (PKI-03). Two-person presence should show in both.
- Calculate runway. Export each CA certificate's expiry and the longest validity any of its templates or profiles allow (PKI-04). A CA cannot issue a certificate that outlives it, so short runway silently shortens what it issues.
- Export templates with their settings. For each published template capture: purposes (extended key usage), whether the subject or subject alternative name comes from the request, whether manager approval or authorised signatures are required, and which groups may enrol (PKI-05, PKI-06). The live template audit guide shows the fields to look at for directory-integrated CAs.
- Probe revocation from the outside. Fetch each CRL from each distribution point listed in issued certificates, from at least two network locations, and record the next-update value. Send OCSP requests for a known good and a known revoked certificate (PKI-07, PKI-08).
- Export CA roles and credentials. List the CA's security settings, resolve nested group membership, and list service accounts, HSM operator and partition credentials and enrolment interface secrets with created, rotated and last-used dates (PKI-09, PKI-10).
- Check log flow and alerting. Query the SIEM for issuance, template change, role change and CA configuration events from each CA in the last seven days, then pull the alert queue (PKI-11).
- Review the last drill. Read the drill record for each issuing CA: what was restored, from which backup, how long it took and what failed (PKI-12).
Red flags that need action now
- A template enrollable by all users or all computers that accepts a requester-supplied subject alternative name and allows client authentication.
- An issuing or root CA private key held in software, or a key backup file stored on a file share or in a ticket.
- The root CA is a running virtual machine on the general server estate, or is joined to the domain.
- A CRL past its next-update time, or an OCSP responder returning errors, for any CA that issues authentication certificates.
- A CA certificate in the trust store of production systems that nobody can name an owner for.
- Certificates issued for domain controller, administrator or service names from a template not designed for them.
- CA audit logging off, or no CA events in the SIEM for seven days.
- Enrolment agent rights unrestricted, so the holder can request certificates on behalf of any user.
- An issuing CA certificate with less than six months of validity and no renewal date.
If a red flag suggests the CA has already been misused, move to the Encryption Key Compromise Playbook and treat it as an incident, not a finding.
Findings log
Record each amber or red result and each red flag. Keep the log with the quarter's evidence and carry open items forward.
| ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-PKI-01 | [e.g. Two published templates allow requester-supplied subject with client authentication, enrollable by all authenticated users] | PKI-05 | [Critical] | [PKI operations lead] | [Date] | [Open] |
| HC-PKI-02 | [e.g. Secondary CRL distribution point unreachable from branch networks] | PKI-07 | [High] | [Network owner] | [Date] | [Open] |
| HC-PKI-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
| Finding type | Where to fix it |
|---|---|
| Unknown CAs, unclear hierarchy, CA runway | Enterprise PKI Design and CA Hierarchy Guide, Certificate trust stores and root CA management |
| Software-held CA keys, missing key backups | HSM Deployment and Operations Guide, Cryptographic Key Management Guide |
| Dangerous or unused templates | Template audit guide, Certificate Management Policy Template |
| Stale CRLs, OCSP failures | Certificate Revocation Guide |
| CP/CPS gaps, role separation, ceremonies | ISO/IEC 27099 PKI Practices and Policy Framework Guide, Privileged Access Management Guide |
| Unproven recovery, plan to replace the hierarchy | Internal PKI and certificate authority migration playbook |
Framework mapping
| Area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | CIS Controls v8.1 |
|---|---|---|---|
| CA inventory and runway (PKI-01, 04) | ID.AM-02, PR.AA-01 | CM-8, SC-17 | Control 1, Control 2 |
| Key protection and root (PKI-02, 03) | PR.DS-01 | SC-12, SC-12(1), SC-13 | Control 3 |
| Templates and revocation (PKI-05 to 08) | PR.AA-01, PR.PS-01 | SC-17, IA-5 | Control 4 |
| Roles and credentials (PKI-09, 10) | PR.AA-05 | AC-2, AC-6, IA-5 | Control 5, Control 6 |
| Monitoring and recovery (PKI-11, 12) | PR.PS-04, DE.CM-09, PR.IR-03 | AU-2, AU-6, CP-9 | Control 8, Control 11 |
Related guides
- Enterprise PKI Design and CA Hierarchy Guide: the design this check measures.
- PKI and Certificate Lifecycle Maturity Model: place the quarter's results on a maturity level.
- Machine Identity, PKI and Certificate Lifecycle Guide: the end-entity lifecycle that depends on these CAs.
- Identity Security Metrics Guide: how these figures roll up into identity reporting.
- Signing keys and certificates in breaches: why CA and signing keys are prime targets.
- Internal PKI and certificate authority migration playbook: when findings point to rebuilding the hierarchy.
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
- MITRE ATT&CK: Steal or Forge Authentication Certificates
- CIS: Critical Security Controls v8.1
Related NHI Mgmt Group resources: Enterprise PKI Design and CA Hierarchy Guide, ISO/IEC 27099 PKI Practices and Policy Framework Guide, PKI and Certificate Lifecycle Maturity Model, Certificate Revocation Guide.