Role Changes and JHED Permission Drift: What Happens When Access Outlives the Job
A person’s institutional identity and institutional responsibilities do not always change at the same speed.
Someone may keep the same JHED identity while moving:
- to another department;
- into a different job;
- from one project to another;
- from a student role to an employee role;
- from an internal role to an external collaboration model.
Identity continuity is useful.
Permission continuity can be more complicated.
The problem begins when access assigned for an old role survives after the role itself has changed.
One identity can support many roles over time
A JHED identity is associated with a person rather than a single application.
That allows institutional systems to recognize the same individual as their relationship changes.
However, applications often grant access based on the user’s current role.
The identity can remain stable while the permissions attached to it should change.
This is where administrators need to separate:
Who the person is
from
What the person currently does
What is permission drift?
Permission drift occurs when access gradually becomes disconnected from the user’s current responsibilities.
For example:
- A user joins Department A.
- The user receives access to Application X.
- The user later moves to Department B.
- Application X access remains active.
- No one reviews whether the permission is still needed.
The original access may have been completely appropriate.
The problem is that the organizational context changed.
Role changes are common risk events
Major changes can include:
- internal transfers;
- promotions;
- project reassignment;
- graduation;
- changes in employment classification;
- the end of temporary assignments;
- changes in sponsorship.
Each event can require some permissions to be added and others to be removed.
The difficulty is that onboarding is often more visible than offboarding.
Organizations frequently have clear procedures for granting new access. Removing access that is no longer needed can receive less attention.
Access should not automatically follow every identity change
A stable identity is valuable.
Creating a new account for every department transfer would create duplicate records and administrative confusion.
But keeping the same identity should not mean automatically preserving every historical permission.
The ideal model is:
Stable identity
Dynamic authorization
The person remains recognizable to the institution while access changes with the institutional relationship.
The hidden challenge of accumulated roles
Users who have worked across multiple areas may have accumulated access through:
- department membership;
- project groups;
- application roles;
- temporary approvals;
- sponsored access;
- direct administrator assignments.
A current manager may know the user’s present responsibilities but not every historical permission.
That is why periodic review can be valuable.
Managers are not the only source of information
A role change can involve multiple owners.
The manager may know that the user’s job changed.
The application owner may know which permissions are sensitive.
The identity team may know that the affiliation record changed.
The access administrator may be responsible for making the technical update.
Without coordination, each party can assume someone else removed the old access.
A role-change checklist
When a person’s institutional role changes, access administrators should consider:
Identity
Does the person retain the same institutional identity?
Current role
What is the new relationship with the institution?
New access
Which resources are now required?
Old access
Which permissions are connected to responsibilities that ended?
Temporary access
Are there project or collaboration permissions that should expire?
External access
Has the person moved into or out of a sponsored or guest relationship?
Ownership
Who confirms the final access state?
The same issue can affect returning users
Returning affiliates create a related challenge.
The original institutional identity may still be the correct identity, but the user’s new affiliation can require a different access profile from the previous one.
The identity should not be confused with the old permission set.
Returning with the same JHED identity does not mean every previous entitlement should automatically be restored.
Permission removal is part of access quality
Removing unnecessary access is not a sign that the account has failed.
It is evidence that the access model is adapting to the user’s current role.
The goal is not to give a person the largest possible collection of permissions.
The goal is to align access with the current legitimate need.
The central lesson
A JHED identity can remain consistent across a person’s institutional history.
The permissions connected to that identity should remain open to change.
Identity continuity helps systems recognize the person.
Access governance ensures that the person can only use resources appropriate to the current relationship and responsibilities.
Related articles:
- JHED Access Reviews
- The JHED Account Lifecycle
- Managing External Collaborator Access
- JHED Authentication vs. Authorization
