Should organisations treat access transfer differently from onboarding and offboarding?

How transfer differs from onboarding and offboarding

Transfer is not a partial offboarding or a delayed onboarding. It is a live change to an existing identity’s authority, so the security question is whether current access still matches the new role, team, system boundary, or business context. That makes transfer the point where privilege drift, inherited access, and separation of duties problems usually surface.

Because the identity already exists, transfer work should focus on changing entitlements, not just creating or deleting accounts. In practice, that means checking whether the mover still needs old-role access, whether new access is justified, and whether any standing permissions now violate least privilege.

Transfer also has a different evidence burden. Onboarding asks whether an identity should receive initial access, while offboarding asks whether access can be removed safely. Transfer asks whether access can be re-scoped without breaking business continuity, which is why it is often the most frequent test of identity governance.

Why transfer is the governance test that exposes access creep

Transfer matters because it is where organisations see the gap between nominal role change and real access change. A person or process can move functions, teams, or environments while retaining entitlements that were only correct in the previous state. Over time, that creates accumulated access that no longer reflects need.

IAM and IGA Basics is useful here because it frames transfer as an entitlement governance problem, not just an HR event. The same is true of Joiner-Mover-Leaver (JML) Guide, which treats movers as a distinct lifecycle state with its own provisioning and deprovisioning logic.

Mid-lifecycle change is also where organisations can miss separation of duties conflicts. A mover may now hold a role that should not overlap with their prior approvals, admin rights, or operational responsibilities. If transfer is handled like a routine update, those conflicts remain invisible until audit, incident response, or a control failure forces the issue.

What good transfer handling looks like in practice

Good transfer handling starts with an access delta, not a blanket reissue. The new role should define what must be added, what must be retained, and what must be removed. That is particularly important for standing privileges, shared access paths, and any entitlement that crosses team or environment boundaries.

Workforce Identity Security Guide is relevant because it ties mover handling to user provisioning, deprovisioning, access recovery, and session risk. Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs reinforces the same lifecycle principle for non-human identities: transfer is the moment to reassess ownership, scope, and rotation, not just the account record.

For organisations with formal access reviews, transfer should trigger a recertification-style check for any entitlement that would be inappropriate in the new role. If the mover keeps legacy access, that exception should be explicit, time-bound, and owned by the business, not left as an inherited default.

Risk and Threat Considerations

Transfer is a common failure point because it preserves continuity while changing context. That makes it easy for excess access to survive role changes, and excess access is exactly what attackers and insiders benefit from when they later need a broader blast radius or an old permission path.

Failure mechanism: mover access is not re-scoped quickly enough, so old entitlements, standing privileges, or cross-functional permissions remain active after the role change. The result is privilege creep, unresolved separation of duties conflicts, and a wider exposure window than the new job actually requires.

Impact: the organisation keeps paying for access it no longer needs, and a future compromise can move farther than intended because the mover still has reach into systems, data, or approval paths tied to the prior role.

Practitioner Guidance

What to prioritise: treat transfer as a mandatory access revalidation event, not an administrative note. The first question is whether the new role changes system ownership, approval authority, or environment boundary, because those changes determine which permissions must be removed immediately.

What to verify: confirm that old-role access is explicitly reviewed, not implicitly retained, and that any exception has an owner and expiry. If the mover can still perform the old job after the move, the access model is probably too sticky.

Common mistake: teams often focus on adding the new access and forget to subtract the old access. That is the shortest path to privilege creep, and it is why movers are usually more operationally revealing than joiners or leavers.

Practitioner takeaway: transfer is where lifecycle governance proves whether least privilege is real, because the hardest part is usually removing obsolete authority while preserving business continuity.

Related resources from NHI Mgmt Group

• Should organisations treat AI agent access to AWS differently from CI/CD access?
• How should organisations connect onboarding, offboarding, and access requests in IAM?
• Should organisations treat agentic AI access differently from service account access?
• How should organisations verify identity across hiring, onboarding, access, and offboarding when work is increasingly hybrid or remote?