What should federal teams do when a user changes role or leaves?

What the revocation problem really is

When a user changes role or leaves, the operational problem is not just disabling a login. Federal teams need to treat the person’s access as a bundle of connected trust paths, then remove each one in a way that matches how that person actually worked. That includes badges, digital credentials, online accounts, shared workflows, delegated admin access, and any machine-to-system permissions the user could still reach.

The reason this is so important is simple: access rarely lives in one place. It is usually mirrored across directories, applications, remote access paths, certificates, tokens, and downstream integrations. If one path remains active, the old role can linger long after the personnel action is complete, which creates an avoidable security and audit problem.

Why every connected system must be updated

Role change is a partial transition, not a clean cut. A transfer may preserve some access, but it should remove what is no longer justified and reissue or reapprove what remains. A departure should go further and remove every active path that could still authenticate, authorize, or delegate access on the former user’s behalf.

This is where many programs fail: they focus on the primary account and miss secondary permissions, cached tokens, inherited group membership, app-specific entitlements, or access granted through a shared automation flow. Federal teams should assume that access can survive in more than one control plane and verify revocation in each of them, not just the source system.

For the underlying control logic, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful because the access control and identification controls reinforce the need to remove access promptly and keep authorization aligned to current duties.

What good offboarding and role-change handling looks like

Good practice is to drive the process from the personnel action, not from a help desk ticket after someone notices a problem. The revocation decision should be tied to the effective date of the role change or separation, with a clear owner for identity updates, application entitlements, remote access, certificate-based access, and any delegated machine access that the person could still influence.

Practically, that means teams should validate three things: first, that the user’s primary credentials no longer work where they should not; second, that any remaining access is explicitly approved and limited to the new role; and third, that downstream systems have actually picked up the change. The first two are policy decisions, but the third is an implementation check, and it is often the one that reveals hidden gaps.

Federal teams should also pay attention to timing. The longer old access survives, the more likely it is to be reused accidentally, abused maliciously, or left behind in an exception path that nobody owns. NIST Cybersecurity Framework 2.0 supports this lifecycle view because access governance is part of a broader identify-protect-detect-respond posture, not a one-time admin task.

Risk and Threat Considerations

Residual access after a role change or departure is a classic exposure path. If a former user still has valid credentials, cached sessions, delegated access, or a still-authorized machine path, the organization may not realize that the trust boundary has already changed.

Failure mechanism: A stale entitlement, token, certificate, or delegation chain remains active after the personnel action, so systems continue to trust the old identity state even though the business no longer does.

Impact: The result can be unauthorized access, privilege abuse, lateral movement, failed audit evidence, and delayed incident detection if the lingering access is used before it is discovered.

Practitioner Guidance

What to verify: Verify revocation in both the source identity system and the downstream applications that cache or mirror access. If the user had elevated, remote, or delegated access, confirm that those paths are removed separately rather than assuming the primary account change covered them.

Decision rule: If the user is leaving, remove access first and reconcile exceptions later. If the user is changing role, preserve only the minimum access needed for the new job and treat every retained permission as a fresh approval, not an inheritance.

Practitioner takeaway: The safest assumption is that access persists until each connected system proves it has been removed, so the control objective is complete trust-path revocation, not merely account disablement.

Related resources from NHI Mgmt Group

• How should security teams run user access reviews when a file platform has frequent role changes and granular folder permissions?
• Why does weak de-provisioning create access risk even after a user leaves or changes role?
• How should teams implement user lifecycle management across onboarding, role changes and offboarding?
• How should teams reduce the risk of orphaned service accounts and stale tokens?