Who should be accountable for orphaned certificate-based access?

Why This Matters for Security Teams

Orphaned certificate-based access is rarely a certificate problem alone. It is usually a governance failure where ownership, issuance, rotation, and revocation sit in different places, so no single team feels responsible when a workload is retired, replaced, or handed to a vendor. That gap matters because certificates often authenticate service accounts, APIs, and internal systems that security teams do not inspect as closely as human access.

Current guidance from the OWASP Non-Human Identity Top 10 treats non-human identity lifecycle control as a core risk area, not an administrative detail. NHIMG research shows why this matters operationally: in the Critical Gaps in Machine Identity Management report, 59% of organisations said auditing machine identities is harder because of unclear ownership and limited visibility. In practice, many security teams discover orphaned certificates only after a system shutdown, vendor transition, or certificate expiry incident has already caused access drift.

In practice, many security teams encounter orphaned certificates only after the workload they protected has already been decommissioned or quietly replaced.

How It Works in Practice

The accountable owner should be the team that can answer three questions at all times: what workload uses the certificate, who can revoke it, and what system or process proves it is still needed. That usually means shared accountability across the workload owner, the certificate authority or PKI operator, and the team running revocation or automation. If any one of those groups can approve changes but cannot see the full lifecycle, the certificate becomes orphaned by design.

Practically, good ownership depends on inventory, workflow, and enforced lifecycle controls. The most reliable model is to tie each certificate to a named business service, a technical owner, and an expiration or revocation workflow that is tested before the certificate goes live. The Ultimate Guide to NHIs notes that most identities are exposed to manual handling or excessive privilege, which is exactly where orphaned certificates hide. Aligning with NIST SP 800-53 Rev 5 Security and Privacy Controls helps because certificate issuance, access authorization, and revocation can be mapped to accountable control owners rather than left as background infrastructure tasks.

• Assign a named workload owner for every certificate, even when the certificate is issued by a central PKI team.
• Record the revocation path before issuance, including who approves, who executes, and what system confirms completion.
• Require renewal or revalidation to confirm the workload still exists and still needs access.
• Link certificates to asset lifecycle events such as retirement, migration, and vendor offboarding.

This guidance tends to break down in environments with shared infrastructure teams and unmanaged third-party integrations because no single party can see the end-to-end identity lifecycle.

Common Variations and Edge Cases

Tighter certificate ownership often increases operational overhead, requiring organisations to balance revocation speed against the risk of breaking active services. That tradeoff becomes visible in environments where certificates are embedded in CI/CD pipelines, legacy appliances, or partner-managed integrations.

There is no universal standard for this yet, but current guidance suggests that exception handling should never erase accountability. If a vendor installs the workload, the internal service owner still needs to own acceptance, monitoring, and offboarding. If a central platform team operates the CA, that team still needs visibility into certificate consumers and revocation triggers. The Ultimate Guide to NHIs and the Critical Gaps in Machine Identity Management report both point to the same practical issue: when ownership is unclear, certificates survive longer than the services they protect.

For high-change environments, best practice is evolving toward automated discovery, just-in-time revocation hooks, and periodic recertification of certificate dependencies. That approach is especially important where shared clusters, service meshes, or multi-tenant platforms obscure which team actually consumes a certificate.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• Who is accountable when access governance relies on parallel local processes?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?