Who is accountable when unmanaged certificates or shadow PKI create trust gaps?

Why This Matters for Security Teams

Shadow PKI is not just a certificate hygiene issue. It creates unauthorised trust paths, weakens assurance, and makes it unclear which team is responsible when a certificate is issued, renewed, or left to expire. That ambiguity matters because certificates often sit inside service-to-service trust, VPN access, signing flows, and automated build pipelines, where a missed renewal can halt operations or a rogue trust anchor can enable abuse.

The practical question is ownership: who can inventory, approve, rotate, and retire certificates before they become invisible risk? Without named accountability, governance breaks down across identity, infrastructure, and platform teams, and audit findings usually arrive after the damage. NHIMG research shows certificate expiry is the leading cause of outages for 45% of organisations in The Critical Gaps in Machine Identity Management report, underscoring how often this is a lifecycle failure rather than a one-time misconfiguration. NIST guidance on control ownership and accountability in NIST Cybersecurity Framework 2.0 reinforces that trust mechanisms need explicit governance, not informal escalation paths. In practice, many security teams encounter unmanaged certificates only after a service outage or trust failure has already exposed the gap.

How It Works in Practice

Accountability for unmanaged certificates is best assigned by control domain, not by who noticed the problem first. Identity governance typically owns policy, approval, and certification of trust requirements. Infrastructure security owns the CA hierarchy, certificate authorities, and hardening of trust stores. Platform operations owns deployment, renewal automation, and service impact remediation. In mature environments, these responsibilities are documented in a RACI so that no certificate can be issued or trusted without an accountable owner.

Operationally, the first step is a complete inventory of certificates, CAs, and trust stores across endpoints, applications, CI/CD, and Kubernetes clusters. From there, teams should classify certificates by business criticality, expiry horizon, and issuance path. Certificate lifecycle automation should handle renewal and revocation, while policy checks enforce approved issuers and key lengths before deployment. This is where controls from NIST SP 800-53 Rev 5 Security and Privacy Controls become useful: they translate ownership into auditable control activities such as access enforcement, configuration management, and system integrity.

NHIMG’s NHI Lifecycle Management Guide and Ultimate Guide to NHIs — Regulatory and Audit Perspectives both emphasize that unmanaged trust assets become an identity governance issue once they can authenticate, sign, or encrypt on behalf of a system. The practical test is simple: if a certificate can establish trust, revoke access, or sign artifacts, it needs an owner, a renewal path, and a retirement trigger. These controls tend to break down when certificates are embedded in legacy appliances, third-party managed environments, or ad hoc scripts because no single team has reliable visibility into issuance and expiry.

Common Variations and Edge Cases

Tighter certificate governance often increases operational overhead, requiring organisations to balance trust assurance against deployment speed and platform complexity. That tradeoff becomes more visible in hybrid estates, where internal CAs, public CAs, cloud-managed certificates, and third-party PKI services coexist.

Best practice is evolving for environments where shadow PKI is created by developers, DevOps teams, or vendors outside central security workflows. Current guidance suggests treating these as shared-risk assets: platform teams may operate the tooling, but identity governance still needs approval authority and lifecycle oversight. In regulated environments, the accountability model may extend to legal or compliance owners when certificates support signing, encryption, or non-repudiation requirements.

NHIMG’s Top 10 NHI Issues highlights that visibility and ownership are recurring failure points, while the Ultimate Guide to NHIs — Key Challenges and Risks shows how quickly unmanaged credentials expand attack surface once they are trusted by automation. The main exception is highly delegated multi-tenant platforms, where the business may own the risk but not the certificate operations; in those cases, the contract must still specify who is accountable for inventory, renewal, and revocation.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?
• Why do collaboration tools create such a large secrets risk?