Who should own identity drift when access no longer matches business need?

Why This Matters for Security Teams

identity drift is not just an access review problem. It is a control failure that shows up when business roles change, applications evolve, or temporary access is never cleaned up. For NHIs, the risk is often amplified because service accounts, tokens, and API keys can persist long after the original use case has changed. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which means drift usually becomes privilege sprawl before it becomes visible in audits.

Security teams should treat ownership as a coordination problem, not a ticket-routing problem. IAM and IGA can define the control plane, but HR, application owners, and SecOps each hold part of the signal needed to decide whether access still matches legitimate need. The OWASP Non-Human Identity Top 10 reflects this reality: identity risk is rarely isolated to one workflow. In practice, many teams discover identity drift only after permissions have already outlived the business purpose that justified them, rather than through intentional lifecycle governance.

How It Works in Practice

Operational ownership should be split by function, with one team accountable for each stage of the drift lifecycle. IAM or IGA usually owns detection logic, certification workflows, and policy enforcement. HR owns employment and role-change triggers for human-linked access. Application owners validate whether access is still required for a service, integration, or environment. Security operations owns escalation when drift presents a threat, such as inactive but privileged credentials or unusual use after role change.

For NHIs, the strongest practice is to connect identity state to business context in near real time. That means tying provisioning and deprovisioning to source-of-truth events, using short-lived credentials where possible, and revoking access automatically when the business justification expires. NHI lifecycle controls in the Ultimate Guide to NHIs — Key Challenges and Risks are especially relevant here, because drift often begins with orphaned secrets or overbroad entitlements that no longer map to a current owner.

• Use HR events to trigger human access review, transfer, or removal.
• Use application ownership to confirm whether machine-to-machine access is still required.
• Use IGA to enforce certification cadences and track unresolved exceptions.
• Use SecOps to investigate stale high-risk access and accelerate remediation.

Current guidance suggests the most reliable model is shared accountability with a single named owner per control step, not a committee with no enforcement authority. These controls tend to break down in organisations with weak application ownership or where identity changes do not flow cleanly from HR and asset systems into IAM.

Common Variations and Edge Cases

Tighter ownership often increases operational overhead, requiring organisations to balance faster remediation against review fatigue and delayed business change. That tradeoff is real, especially in environments with high contractor turnover, federated business units, or large numbers of ephemeral NHIs.

There is no universal standard for this yet, but best practice is evolving toward risk-based ownership. For example, a stale low-risk access grant may stay with IAM and IGA for scheduled cleanup, while a privileged token used by a production workflow may need immediate SecOps escalation and application-owner sign-off. The 52 NHI Breaches Analysis shows why this matters: identity drift often becomes incident exposure when ownership is unclear and remediation stalls.

For organisations following the Top 10 NHI Issues, the main edge case is exception handling. Some access is intentionally persistent, but that exception should be explicit, time-bound, and reviewed against business need. If the control model cannot distinguish approved persistence from forgotten access, drift will keep accumulating under the guise of normal operations.

Related resources from NHI Mgmt Group

• Who should own privileged access governance in an identity programme?
• How should organisations govern SaaS licenses alongside identity access reviews?
• Why do SSO tools often fail to solve access governance on their own?
• Who should own access decisions when service management and IAM are connected?