How should organisations handle access when employees change roles internally?

Why This Matters for Security Teams

Internal moves look simple on an org chart, but they often trigger the same access risks as a full onboarding. A person may keep old group memberships, collaboration spaces, admin consoles, and data exports while gaining new access for the next job. That creates privilege drift, slows audits, and makes it harder to prove that access matches current duties.

This is especially important in environments that rely on identity governance, JIT elevation, or shared operational tools. The issue is not just excess access, but delayed access removal when managers, HR, and IT do not share the same trigger. NHI Management Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which shows how easily hidden access can persist when lifecycle controls are weak.

Security teams should treat internal mobility as a lifecycle event with approval, revocation, and validation steps, not as an informal handoff. In practice, many security teams encounter privilege creep only after audit evidence is requested or a former team member is still able to access a system they no longer support.

How It Works in Practice

The cleanest approach is to make the move event the trigger for access changes across IAM, HR, and application owners. When a role change is approved, the workflow should remove access tied to the old role, provision access for the new role, and record the change for review. This is easier to enforce when access is mapped to role, attribute, or policy groups rather than granted one system at a time.

For most organisations, the practical sequence is:

• Confirm the effective date of the new role and the manager who approves it.
• Compare current entitlements to the target role and flag exceptions.
• Remove legacy access before or at the same time as new access is granted.
• Review shared accounts, delegated admin rights, and any access to sensitive data exports.
• Log the move in the identity system so later audits can show who approved what and when.

That sequence aligns with least privilege and Zero Trust principles because access is re-evaluated when duties change, not left to drift until an annual review. The OWASP Non-Human Identity Top 10 is focused on machine identities, but the same operational lesson applies: identity lifecycle events need explicit control points, or privilege accumulates faster than teams can review it. NHI Management Group’s 52 NHI Breaches Analysis reinforces how often unmanaged credentials and access paths survive beyond their intended use.

Teams should also watch for access that is embedded in collaboration tooling, SaaS admin panels, and local exceptions that bypass central IAM. These controls tend to break down when role changes are approved in one system but not propagated to downstream apps because entitlement ownership is split across multiple teams.

Common Variations and Edge Cases

Tighter mover controls often increase coordination overhead, requiring organisations to balance speed of transfer against the risk of lingering access. That tradeoff is real in fast-moving sales, engineering, and incident response teams, where a person may need temporary overlap between old and new responsibilities.

Current guidance suggests using short grace periods only where continuity is necessary, and making those exceptions visible and time-bound. In some cases, a worker may need to retain access to close out projects or support a handover. That should be documented as an exception with an expiry date, not left as an informal approval in chat.

There is no universal standard for every internal transfer pattern yet, especially in matrixed organisations where one employee reports to one manager but supports several functions. The safest approach is to define which access follows the person, which access follows the team, and which access must always be reapproved on move. Where privileged access is involved, many teams pair mover workflows with step-up approval and periodic recertification so exceptions do not become permanent. Organisations that skip this distinction often discover the gap only after a former role still has access to a sensitive app months later.

Related resources from NHI Mgmt Group

• How should security teams handle NHIs when employees leave or change roles?
• How should federal teams manage identity access when employees change roles or locations?
• Who should be accountable for SSH access when employees leave or change roles?
• How should organisations govern SaaS licenses alongside identity access reviews?