A ghost certificate is a valid certificate that remains in circulation or on record without clear ownership or active tracking. These credentials often survive process changes, creating hidden trust exposure until they expire, break, or are discovered during an incident or audit.
Expanded Definition
A ghost certificate is not simply an expired or misissued certificate. It is a certificate that remains valid, discoverable, or trusted while its business owner, technical custodian, or lifecycle record has gone missing. In NHI security, that makes it a form of orphaned machine trust, because the credential can still authenticate services even when no one can confidently answer who approved it, where it is used, or whether it should still exist.
Definitions vary across vendors, but the operational distinction is consistent: a ghost certificate has active trust value without active governance. That sets it apart from routine certificate debt, because the problem is not only age or volume. It is the loss of ownership, inventory, and revocation accountability. This is why certificate governance has to be treated as part of broader NHI lifecycle management, not as a narrow PKI maintenance task. For a broader NHI framing, see Ultimate Guide to NHIs — What are Non-Human Identities and the identity control expectations in NIST Cybersecurity Framework 2.0.
The most common misapplication is treating a ghost certificate as a harmless leftover, which occurs when teams assume anything still technically valid must still be operationally owned.
Examples and Use Cases
Implementing certificate governance rigorously often introduces inventory and renewal overhead, requiring organisations to weigh reduced trust ambiguity against the cost of continuous discovery and ownership maintenance.
- A legacy service keeps a certificate in production after the application team is restructured, but no ticket, owner, or renewal contact survives the transition.
- A certificate issued for a short-lived internal tool is copied into a new pipeline and continues to authenticate workloads long after the original purpose is forgotten.
- A merger leaves duplicate certificate authorities and scattered records, and one certificate chain remains trusted even though the issuing business unit has been retired.
- An audit uncovers a certificate on a decommissioned endpoint that still validates with downstream services because revocation and asset removal were never tied together.
These scenarios are common precisely because certificate visibility is weak. In SailPoint’s report, 59% of companies said they face greater difficulty auditing machine identities because of unclear ownership and limited visibility, and 61% still rely on spreadsheets or manual tracking. That pattern is echoed in the Critical Gaps in Machine Identity Management report. For implementation context, the lifecycle discipline behind a ghost certificate is closely related to the identity inventory and rotation guidance in the NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Ghost certificates matter because they preserve trust after governance has failed. A certificate that no one owns can still authenticate API calls, secure sessions, sign traffic, or unlock internal services. That means the blast radius is not hypothetical: attackers, insiders, and broken automation can all abuse the trust path long after the original issuance context has disappeared. This is especially dangerous in NHI environments, where certificates often underpin service accounts, workloads, CI/CD flows, and partner integrations.
NHIMG research shows why this is a systemic control gap. In the Critical Gaps in Machine Identity Management report, only 38% of organisations reported automated certificate lifecycle management, while certificate expiry was the leading cause of outages for 45% of organisations. That combination of manual handling and weak visibility turns ghost certificates into operational and security liabilities. The NHI framing in Ultimate Guide to NHIs — What are Non-Human Identities reinforces the need for ownership, rotation, and offboarding as first-class controls.
Organisations typically encounter ghost certificate risk only after an outage, audit failure, or incident investigation, at which point the certificate becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret and certificate lifecycle failures that create orphaned machine trust. |
| NIST CSF 2.0 | PR.AA-01 | Addresses identity proofing and authentication asset governance for machine credentials. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuously verified and managed identities, including machine certificates. |
Track certificate issuance and ownership so active trust is always tied to a responsible system owner.
Related resources from NHI Mgmt Group
- How should teams manage shrinking certificate lifecycles in NHI environments?
- What is the difference between certificate management and NHI governance?
- Should organisations treat certificate expiry as an operational risk or a security risk?
- How should security teams govern certificate lifecycles across hybrid environments?
