Who should own deprovisioning when help desk access changes across teams?

Why This Matters for Security Teams

When help desk access changes across teams, the real risk is not the request itself but the gap between who approves it, who removes it, and who confirms it is actually gone. Identity governance has to own deprovisioning because access removal is a control function, not a local admin task. If ownership is unclear, orphaned help desk roles, shared admin paths, and lingering tokens can survive long after a team move.

This is especially important for non-human identities and delegated access paths, where the operational pattern is often broader than one application. NHIMG’s NHI Lifecycle Management Guide treats offboarding as a lifecycle control, not an endpoint cleanup exercise, and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs reinforces that revocation must extend across every connected system. The OWASP Non-Human Identity Top 10 also highlights how unmanaged access and stale secrets create durable exposure. In practice, many security teams encounter lingering help desk privilege only after a role change has already become a lateral movement opportunity.

How It Works in Practice

The cleanest model is a centralized deprovisioning workflow owned by identity governance, with HR, ITSM, or service desk teams acting as event sources rather than control owners. A team transfer, role change, or contract end should trigger a single workflow that determines what access must be removed, what must be retained, and whether compensating access needs to be issued elsewhere. That workflow should cover both human help desk entitlements and any connected non-human access such as scripts, automation accounts, or API tokens used by support tooling.

Current guidance suggests three control points:

• Trigger: a trusted source of record initiates the change event.
• Approval: identity governance validates scope and separation of duties before removal.
• Verification: access removal is confirmed in the directory, ticketing system, and downstream applications.

Where possible, pair removal with just-in-time access and time-bound elevation so help desk privileges do not persist by default. That lines up with the operational logic in the Top 10 NHI Issues, especially around excessive privileges and weak offboarding. For broader identity hygiene, NIST’s Digital Identity Guidelines remain useful for understanding assurance, reauthentication, and lifecycle discipline, even though they are not a help desk playbook. The practical test is whether deprovisioning removes access everywhere the identity can reach, not just in the primary directory. These controls tend to break down in environments with shared admin accounts, local overrides, or unmanaged SaaS connectors because revocation cannot be reliably propagated end to end.

Common Variations and Edge Cases

Tighter deprovisioning often increases coordination overhead, so organisations have to balance speed against completeness. That tradeoff becomes visible when support teams need emergency continuity, regional escalation coverage, or break-glass access during a handoff.

There is no universal standard for exactly which team should execute every downstream removal, but best practice is evolving toward a single accountable owner with delegated execution. In smaller environments, that owner may be IAM operations; in larger ones, identity governance usually sets policy while the service desk executes tasks under workflow control. The key is that no receiving team should be allowed to self-retain access simply because it is operationally convenient.

Edge cases also matter when access is embedded in shared mailboxes, remote support tools, privileged chat channels, or automation tied to a person’s former team. Those paths often escape routine reviews because they are not treated as “identity” by app owners. NHIMG’s 52 NHI Breaches Analysis shows why lifecycle blind spots are persistent, while the Ultimate Guide to NHIs — Key Challenges and Risks is a useful reminder that revocation failures often start as process gaps, not tool failures. In practice, the hardest cases are hybrid teams with local admin exceptions, because revocation gets delayed until someone manually reconciles access after the fact.

Related resources from NHI Mgmt Group

• How should security teams manage access reviews across multiple compliance frameworks?
• How should security teams govern access when lifecycle changes move faster than the platform can update?
• How should teams govern lifecycle changes across SaaS applications?
• How do IAM teams decide whether an AI security assistant needs its own access controls?