Who should own non-human identity governance when service accounts and tokens drift?

Why This Matters for Security Teams

When service accounts and tokens drift, the question is not just who approves access. It is who can explain why the credential still exists, who can revoke it without waiting on a queue, and who notices when usage no longer matches the original purpose. That is why ownership has to sit close to the application or platform, with security defining policy and watching for exceptions through NIST Cybersecurity Framework 2.0.

This problem is bigger than housekeeping. NHIs outnumber human identities by 25x to 50x in modern enterprises, and the Ultimate Guide to NHIs shows that only 5.7% of organisations have full visibility into service accounts. In that environment, “shared responsibility” often becomes “no responsibility,” especially when secrets live across code, CI/CD, and platforms rather than in a single vault. In practice, many security teams encounter the ownership gap only after a stale token is already being used outside its original purpose.

How It Works in Practice

The most reliable model is a three-part split: the application or platform team owns the credential lifecycle, security owns the policy baseline, and an IAM or governance function enforces standards across the estate. The owner must be the team that understands the business process behind the NHI, because only that team can answer whether the service account is still needed, whether the integration changed, and whether the token can be safely revoked.

Operationally, this means every non-human credential should have a named owner, a documented purpose, an expiry or review date, and a revocation path that is actually executable by that owner. The guidance in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs aligns with current best practice: inventory first, map the credential to the workload, then verify rotation, offboarding, and exception handling. NIST control thinking also supports this split, especially where NIST SP 800-53 Rev 5 Security and Privacy Controls expects accountable management of access and system components.

• Assign ownership to the workload team, not a central queue.
• Tag each service account or token with purpose, system, environment, and expiry.
• Require periodic attestations from the owner that the credential still has a valid business use.
• Automate revocation when the application is retired, changed, or no longer producing expected usage.
• Escalate drift when the credential is active but the owner cannot explain the current need.

The practical test is simple: if the team that owns the workload cannot revoke the token, then the organisation does not really know who owns the identity. These controls tend to break down in shared platform estates where dozens of services reuse one token family because no single team can safely separate dependencies.

Common Variations and Edge Cases

Tighter ownership controls often increase coordination overhead, requiring organisations to balance clean accountability against deployment speed. That tradeoff is real, especially for shared middleware, managed SaaS connectors, and legacy batch jobs where one service account supports several downstream systems. There is no universal standard for this yet, but current guidance suggests the owner should be the team with the strongest ability to explain business need and act on revocation, even if that means formalising exceptions.

One recurring edge case is a token created by one team but embedded by another in automation. Another is a platform-managed identity that spans multiple application owners, which can blur accountability unless there is a clear service catalog entry and escalation path. The 52 NHI Breaches Analysis and Guide to the Secret Sprawl Challenge both reinforce the same lesson: drift becomes dangerous when ownership is assumed instead of assigned.

For very high-churn environments, governance should favour short-lived credentials and explicit review windows over permanent exceptions. The aim is not to centralise every decision, but to make it impossible for an NHI to remain active without a named business owner and a current justification.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• How should security teams govern non-human identities alongside human accounts?
• What is the difference between managing human accounts and non-human identities?
• Who should own non-human identity governance in a distributed environment?