Why do expired or orphaned certificates create identity risk?

Why This Matters for Security Teams

Expired or orphaned certificates are not just housekeeping defects. They are proof that the organisation has lost track of where machine trust exists, who owns it, and whether it still matches business intent. That creates identity risk because certificates often authenticate service accounts, workloads, APIs, and internal systems that security tools treat as trusted by default. The Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why certificate sprawl deserves the same attention as privileged access.

Certificate lifecycle failures also create operational risk. In the SailPoint research published by NHI Management Group, 59% of companies report greater difficulty auditing machine identities because ownership and visibility are unclear, and 57% lack a complete inventory of those identities. That means expired certificates may linger unnoticed, while orphaned ones remain active long after the system or team that created them has changed. This is a governance failure, not just a technical one, and it is why OWASP Non-Human Identity Top 10 treats lifecycle and trust management as core issues. In practice, many security teams discover the problem only after a service outage, audit finding, or incident has already exposed the gap.

How It Works in Practice

Certificates create identity risk when their issuance, usage, and revocation processes drift apart. A certificate may still validate cryptographically even when the workload it authenticates has been retired, cloned, reassigned, or forgotten. In that state, the certificate becomes an orphaned trust artifact. If the certificate expires instead, the failure mode is usually availability first, then security, because teams rush to restore service and may reissue trust without fixing ownership, rotation, or inventory discipline.

Practitioners reduce this risk by treating certificates as part of the NHI lifecycle, not as static infrastructure objects. The most effective controls usually include:

• Maintaining a complete inventory of certificates, owners, workloads, issuance dates, and expiry dates.
• Linking each certificate to a named business or technical owner who can approve rotation or revocation.
• Automating renewal and revocation workflows so certificates are not managed through spreadsheets or ad hoc tickets.
• Using short-lived credentials where possible so trust expires with the task, not months later.
• Monitoring for certificates attached to decommissioned services, old CI/CD pipelines, or abandoned integrations.

The NHI Lifecycle Management Guide and the Guide to NHI Rotation Challenges both reinforce the same operational point: rotation only works when ownership, visibility, and revocation are already in place. That aligns with the broader identity discipline described in the NIST Cybersecurity Framework 2.0, which emphasises asset visibility, protection, and recovery. These controls tend to break down in highly automated environments with frequent service redeployments because certificate references are copied faster than ownership records are updated.

Common Variations and Edge Cases

Tighter certificate controls often increase operational overhead, requiring organisations to balance stronger trust hygiene against deployment speed and uptime pressure. The tradeoff is especially visible in CI/CD, Kubernetes, and multi-cloud estates where certificates may be created dynamically and used for very short periods. Best practice is evolving here, and there is no universal standard for how much human approval should sit in the loop for every machine-to-machine certificate event.

One common edge case is the expired certificate that still exists in a hidden dependency, such as an internal API, webhook, or legacy service mesh path. Another is the orphaned certificate that appears valid because the issuing authority remains trusted, even though the endpoint it authenticates has been decommissioned. In both cases, the risk is not limited to expiry. The larger issue is that the certificate may still confer access to systems, data, or automation paths that no one actively monitors.

This is why current guidance suggests pairing certificate management with broader NHI governance, including ownership attestation, vaulting, and periodic offboarding reviews. For organisations dealing with many machine identities, the most effective approach is usually to align certificate management with the same policy and inventory discipline used for service accounts and API keys, rather than handling it as a separate infrastructure task. For practical remediation patterns, the Top 10 NHI Issues and the Guide to the Secret Sprawl Challenge are useful references. The control breaks down fastest in environments where certificates are embedded in code, copied across tenants, or issued by teams with no central revocation authority.

Related resources from NHI Mgmt Group

• Why do JWTs create different risk than API keys in identity programmes?
• Why do expired certificates create such a high operational risk?
• Why do certificates still create identity risk even when the cryptography is sound?
• Why do weak or expired certificates create more than just compliance risk?