What should organisations do when employees change roles or leave the organisation?

When Role Changes Turn Access Into Residual Risk

Changing jobs inside the organisation is not just an HR event; it is an access governance event. The old role may have opened systems, folders, queues, admin consoles, or production tools that the new role no longer needs, and those permissions become residual exposure if they are not reviewed promptly. When people leave, the issue is even sharper because every active account, token, or shared credential becomes a potential path back in if offboarding is slow or incomplete. NHI Management Group has found that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a strong indicator that entitlement cleanup is often weaker than leaders assume.

Organisations should treat movement and exit as mandatory reassessment points, not as informal handoffs. The question is not whether the user is trusted; it is whether the access remains necessary, traceable, and time bound. The OWASP Non-Human Identity Top 10 is especially useful here because it reinforces the broader lesson that stale access, unattended credentials, and poor lifecycle control create avoidable exposure, even when the original grant was legitimate.

In practice, many organisations discover lingering access only after a role change has already broadened someone’s effective reach beyond what the new job requires.

How Access Should Be Rebased During Moves and Offboarding

The practical response is to recertify access against the new role, then remove anything that is no longer justified. That means human accounts, privileged access, group memberships, shared folders, SaaS entitlements, remote access methods, and any standing exceptions should all be checked against current need. If the person is moving laterally, the objective is to narrow the blast radius quickly; if the person is leaving, the objective is to end all access paths cleanly and on time.

Time-bounded access matters because transition periods are where organisations most often leave extra privilege in place “just for now.” That approach becomes risky when temporary access is not tracked to an expiry date or owner. A good process sets a clear decision rule: if access is tied to the old role, remove it; if access is still needed for transition, explicitly approve it, assign an end date, and review it again before the deadline. For sensitive systems, separation of duties should be rechecked as part of the move, because a harmless-looking leftover permission can become an effective bypass when combined with the new role.

Offboarding should also include credential and session invalidation, not only account disabling. Active sessions, refresh tokens, SSH keys, API keys, certificates, and service-linked access can outlive a user-facing account if they are not explicitly revoked. The Ultimate Guide to NHIs is relevant here because it frames lifecycle discipline as a core control, not an administrative cleanup task.

• Reconcile the person’s current role against actual entitlements before the move completes.
• Remove access that is no longer required, rather than waiting for a later review cycle.
• Use explicit expiration for temporary access and exceptions.
• Revoke tokens, keys, and sessions as part of exit handling, not as a separate best-effort step.

These controls tend to break down when role changes are frequent and access ownership is split across HR, IT, and application teams because nobody owns the full entitlement picture.

Where Organisations Commonly Go Wrong

Tighter access cleanup can slow transitions if teams insist on manual approvals for every small change, so organisations need to balance speed against the risk of leaving broad access in place. The most common failure is assuming that disabling a primary login is the same as ending access everywhere else. In many environments, credentials, API keys, delegated permissions, and cached sessions remain live long enough to defeat that assumption. Another weak point is cross-environment access: if a person had both day-to-day access and elevated access for special tasks, the special access is often forgotten because it was treated as temporary rather than formally governed.

Current guidance suggests that offboarding should be verified, not merely initiated. That means there should be evidence that access was actually removed, not just that a ticket was opened. It also means organisations should be able to answer who approved any temporary continuation, when it expires, and what systems were checked. For teams managing a large estate, the right question is not whether every permission is perfect; it is whether any exception is visible, time limited, and owned.

Practitioner takeaway: the safest model is to make access follow the current job, not the historical relationship, and to treat every exception as a short-lived control that must be revalidated or removed before it becomes normalised.

Related resources from NHI Mgmt Group

• How should organisations automate access deprovisioning when employees change roles or leave?
• How should security teams handle NHIs when employees leave or change roles?
• Who should be accountable for SSH access when employees leave or change roles?
• How should organisations handle access when employees change roles internally?