When an employee changes roles, organizations often grant the new access quickly and leave the old permissions in place. That gap can turn a routine transfer into years of unnecessary access, while standard review screens make it hard to tell which entitlements still matter. My read is that the problem is less about missing technology than missing ownership: no one is clearly responsible for removing access when its purpose ends.
The imbalance is built into the workflow. A new manager requests permissions, an approver signs off and the employee can get to work. When those permissions are no longer needed, there may be no request, deadline or assigned person to trigger their removal. The cost of leaving access in place is largely invisible in the moment. The cost of removing something an employee still needs is immediate, usually arriving as a support ticket.
Transfers create an access blind spot
Consider an employee who moves to another team. Their new manager approves the access required for the new job, but permissions from the previous role remain. Months later, a reviewer may see an account name and entitlement without knowing whether the employee used that access last week or last year. The review question—does this person still need it?—offers little evidence to support a decision.
In that situation, retaining access can feel safer than removing it. A reviewer may worry that revocation will disrupt work, while approving a long list of existing permissions takes little effort. If the review tool gives no usage history, it makes confirmation the path of least resistance. Repeating that process allows old permissions to accumulate, even when the employee's responsibilities have changed.
Role based access control helps assign permissions to job functions, but it doesn't necessarily remove direct access, group memberships or folder rights accumulated over time. Updating someone's role can therefore leave a second layer of access untouched. Termination procedures at least create a clear event that starts offboarding; an internal transfer may trigger no comparable review.
Why the accumulation matters
Unused permissions don't prove that an account has been compromised, and breach figures shouldn't be treated as direct evidence of the effect of stale access. The 2026 Verizon Data Breach Investigations Report identifies vulnerability exploitation as the most frequently used breach method, at 31% of breaches, while credential abuse accounted for 13%. Those figures don't measure leftover permissions. They do, however, make a related point relevant to access management: after an account is compromised, its privileges help determine what an intruder can reach.
There is also a distinct risk when people leave an organization. In an online survey of 1,000 American workers conducted in March 2023, PasswordManager.com reported that 58% of respondents who said they had used a former employer's passwords had never changed those passwords after leaving. That's a limited survey, not a measure of how often stale access leads to incidents. It does underline why offboarding needs to cover credentials and permissions, rather than treating an HR checklist as the whole job.
Transfers deserve attention alongside departures because they can leave access active without triggering a formal exit process. NIST SP 800-53 Rev. 5 includes account management and least privilege controls that address account reviews, transfers and terminations, and access limited to what a person's role requires. The practical challenge is making those expectations part of everyday role changes, where leftover permissions can otherwise go unnoticed.
Make removal part of the transfer
A useful first step is to treat every position change as a reason to review and remove access. When HR records a transfer, the outgoing and incoming managers can receive the employee's access list and a specific question: what will this person no longer need? A short, defined review—ten minutes, for example—gives both managers a clear task and a chance to catch access that doesn't fit the new role.
That review works best when each entitlement has an identifiable owner. Access to a project folder, a production environment or another sensitive system should point to a named person who can decide whether it remains necessary. A shared email address doesn't provide the same clear accountability. When ownership is recorded alongside the account and the applications it can reach, teams can more easily trace dependencies and identify what needs attention after a role change.
Set an expiration date when access is granted. The date might match the end of a project or, when no end date is known, fall three months after issuance. The owner can renew the entitlement when there is still a reason to keep it; if that person is unavailable, their manager can handle the review. The default should let access expire unless someone actively confirms its need, instead of silently renewing it because nobody took action.
Put usage evidence in front of reviewers
Access reviews become more useful when they show recent activity alongside each permission. Organizations can draw last-login and last-activity timestamps from identity provider and application logs, then sort entitlements so the least-used access appears first. That gives reviewers a concrete prompt: an entitlement hasn't been used for seven months, so what justifies keeping it?
Low activity is a reason to ask, not an automatic reason to revoke. Some legitimate access is used only occasionally. Quarterly financial close accounts and emergency “break glass” accounts, for example, may have long stretches without activity. Those permissions still need a named owner and a note explaining their purpose, so a reviewer can distinguish deliberate, infrequent use from forgotten access.
The workflow also needs to connect review decisions with the action that follows. If a reviewer attests to access in one tool but has to go elsewhere to rotate, vault or retire credentials, they may confirm the entitlement and leave it untouched. Keeping attestation, rotation, vaulting and retirement within one process can make the selected action easier to complete. That remains dependent on the data available: some applications don't maintain useful usage logs, and activity alone can't explain why an entitlement exists.
Start with one sensitive system
Organizations don't need a new platform to begin. This quarter, choose one system that stores sensitive data and produce a report of its least recently used access. Start with employees who changed roles in the past year, since their permissions may not have been reviewed as part of the transfer. Send the system owner the list of users who haven't used the system in six months and ask whether each person still needs access.
That focused review can reveal where the process breaks down: missing owners, entitlements with no clear purpose, or applications that don't provide activity records. It also gives managers a practical basis for extending the approach to other systems. The lasting improvement comes from making access removal an assigned part of every role change, then giving reviewers enough context to act with confidence.
