Who should own stale-account remediation in an enterprise?

IAM or IGA should own the workflow, with HR and business managers supplying validation and security defining the control standard. If ownership is split too widely, accounts survive longer than they should, and attackers get more time to exploit the leftover access.

Why This Matters for Security Teams

Stale-account remediation is not just an IAM cleanup task. It is a control over how long unused access remains available to attackers, auditors, and insiders who inherit access long after the original business need has ended. In practice, the problem often spans HR data, manager validation, privileged access workflows, and application owners, which is why unclear ownership creates delay and policy drift. NIST’s NIST Cybersecurity Framework 2.0 treats governance and identity hygiene as operational discipline, not one-off tickets. NHI Management Group research also shows how lingering identity risk compounds: the Ultimate Guide to NHIs — Why NHI Security Matters Now reports that 91.6% of secrets remain valid five days after notification, underscoring how slowly remediation can move when ownership is fragmented.

The practical question is not who can approve removal, but who is accountable for driving it to closure. IAM or IGA is usually the right operating owner because it already understands entitlement lifecycle, evidence, and enforcement. Security defines the standard, while HR and business managers provide the business signal that access is no longer required. In practice, many security teams encounter stale access only after an audit finding, a resignation, or a breach review, rather than through intentional lifecycle control.

How It Works in Practice

The cleanest model is a three-part ownership structure. IAM or IGA owns the workflow and metrics, HR owns authoritative joiner-mover-leaver data for employment status, and business managers validate whether access is still needed for a role or project. Security sets the control baseline: how quickly stale access must be reviewed, what evidence is required, and which accounts are high risk. The operating owner then automates the workflow and escalates exceptions.

That usually means stale-account detection is driven from identity signals such as inactivity thresholds, leaver events, and privileged account exceptions. IAM/IGA runs the queue, while HR and managers confirm whether the account should be retained, converted, or disabled. For privileged or shared access, PAM should be in the loop because service account, admin accounts, and break-glass credentials often need different handling than standard user identities. Current guidance suggests using one system of record for the workflow and one clear approver path, rather than letting each application owner invent a different process.

• Use HR as the authoritative source for employment termination and status changes.
• Use IAM or IGA to detect, route, disable, and evidence remediation.
• Use business managers to validate exceptions and project-based access.
• Use security to define SLAs, risk tiers, and control testing criteria.
• Use PAM for privileged accounts and higher-impact remediation paths.

For broader NHI lifecycle control, NHI Management Group’s Guide to the Secret Sprawl Challenge is a useful reminder that stale access is often a sprawl problem as much as a policy problem. This aligns with the lifecycle discipline described in Ultimate Guide to NHIs, where visibility, rotation, and offboarding are treated as linked controls. These controls tend to break down when ownership is split across too many ticket queues because no single team can prove closure or enforce deadlines end to end.

Common Variations and Edge Cases

Tighter ownership often increases coordination overhead, requiring organisations to balance faster removal against business exceptions and approval latency. That tradeoff is real, especially in matrixed enterprises where contractors, temporary staff, and shared operational mailboxes do not fit a simple leaver flow. Best practice is evolving, but current guidance suggests keeping the control owner singular even when validation is distributed.

Edge cases deserve explicit handling. Service accounts should not be remediated using the same review path as employee accounts because application dependencies, scheduled jobs, and integration tokens can fail if disabled blindly. Shared accounts are another exception: they usually need migration to named identities or tightly governed PAM controls rather than repeated attestations. Dormant but mission-critical accounts may also require a formal exception register with expiration dates, compensating controls, and periodic review.

The most common failure mode is not technical inability but diffuse accountability. If IAM “processes” the workflow while HR, app owners, and security each expect someone else to close the loop, stale access survives longer than policy intended. That is why ownership should stay operationally centralized, even when the decision inputs are distributed.

Related resources from NHI Mgmt Group

• Who should own IPv6 transition risk in an enterprise network?
• Who should own remediation when Office 365 identity risk is found?
• Why do stale credentials and unmanaged service-account keys matter so much in cloud environments?
• Who should own digital identity assurance in the enterprise?