Who is accountable when unmanaged privileged identities remain in the environment?

Why This Matters for Security Teams

Unmanaged privileged identities are not just housekeeping issues. They are active trust paths that can be used to modify systems, read sensitive data, or create more access. Once an identity exists with privilege, the environment assumes someone will review it, rotate it, or remove it. When that assumption is false, risk persists silently until an incident, audit, or outage exposes it.

This is why accountability has to be explicit. The service owner knows why the identity exists, the identity governance function can certify and revoke it, and the platform team controls the access plane. That division aligns with the concerns highlighted in the OWASP Non-Human Identity Top 10 and the operational patterns in the Top 10 NHI Issues. NHIMG’s research on lifecycle processes for managing NHIs shows that unmanaged identities usually persist because ownership is ambiguous, not because controls are entirely absent. In practice, many security teams encounter the problem only after an access review fails or an attacker abuses a forgotten account.

How It Works in Practice

Accountability needs to follow the identity through its full lifecycle: request, approval, issuance, use, review, rotation, and retirement. The service owner should be accountable for business justification and ongoing need. Identity governance should be accountable for certification, policy enforcement, and exception handling. The platform or PAM team should be accountable for technical implementation, including privileged access control, session protection, and revocation. This mirrors the control logic in the NIST Cybersecurity Framework 2.0, where identity and access responsibilities are expected to be assigned, monitored, and continuously improved.

Operationally, mature teams make ownership visible in the ticketing system, CMDB, identity inventory, or cloud control plane. They also require a named approver for exceptions, a renewal date for temporary access, and an offboarding trigger when the service is retired. For privileged non-human identities, this should include:

• One named business owner and one technical owner for every privileged identity
• Periodic certification tied to actual service usage, not just policy dates
• Immediate escalation when no owner can be identified
• Revocation workflows that work even if the original requester has left
• Logging that shows who approved, who used, and who decommissioned the identity

NHIMG’s NHI Lifecycle Management Guide and regulatory and audit perspectives both reinforce the same operational reality: if the identity is privileged, ownership cannot be implied, inherited, or left to platform memory. These controls tend to break down in fast-moving cloud environments where service accounts are created by automation and never re-enter a human review queue.

Common Variations and Edge Cases

Tighter ownership rules often increase process overhead, requiring organisations to balance faster delivery against stronger accountability. That tradeoff is real, especially in DevOps, ephemeral cloud workloads, and M&A environments where identities appear faster than governance can catalogue them.

Current guidance suggests treating unknown ownership as a remediation event, not an administrative nuisance. If no accountable owner can be confirmed, the identity should be quarantined, downgraded, or disabled based on risk. There is no universal standard for this yet, but best practice is evolving toward time-bounded exceptions and automated retirement for stale privileged access. This is especially important for service accounts that are inherited from legacy systems, created by third-party integrators, or embedded in automation pipelines. In those cases, the real owner may be a vendor, platform team, or application team that never formally accepted responsibility.

NHIMG’s key challenges and risks research is a useful reminder that fragmented identity estates create blind spots, while the lifecycle guidance shows why offboarding is often the weakest control. The practical lesson is simple: if privileged access cannot be tied to a current owner, it is already a governance exception and should be treated that way.

Related resources from NHI Mgmt Group

• Who should be accountable for identities that sit outside traditional IGA coverage?
• Who should be accountable when an unmanaged identity is used in a breach?
• Why do unmanaged identities increase IAM risk even when SSO and MFA are deployed?
• Who is accountable when a privileged admin account causes an incident?