The Employee Left. The Access Did Not.
Modern access is distributed across human and machine identities. A mature Leaver process must discover and revoke every credential, token and trust relationship associated with the departing employee.
An employee leaves the organisation.
HR closes the employment record. The laptop is returned. The Active Directory account is disabled. Email access is removed.
Everyone assumes the access is gone.
But modern enterprise access is no longer limited to the corporate directory.
What about GitHub? Cloud platforms? SaaS applications? Personal access tokens? SSH keys? API credentials? CI/CD pipelines? Third-party portals?
This is where offboarding becomes more than an HR process.
It becomes an identity security problem.
Leaving The Company Does Not Mean Leaving Every System
A decade ago, disabling a corporate account might have removed most of an employee’s access.
Today, access is distributed.
Developers may have GitHub accounts connected to repositories. Engineers may hold cloud credentials. Administrators may have SSH keys. Business users may still have access to SaaS platforms that sit outside the central identity lifecycle.
Some of that access may be federated through the organisation’s identity provider.
Some may not.
And that difference matters.
If access exists outside the central identity lifecycle, disabling one account may not remove everything associated with the person.
That is how orphaned access is created.
Identity Lifecycle Is A Security Control
Joiner, Mover, Leaver processes are often treated as administrative workflow.
Create an account when someone joins.
Change access when they move.
Disable the account when they leave.
But from a security architecture perspective, the process is much more important.
It defines how trust is created, changed and removed.
The Leaver stage is particularly critical because the organisation is removing trust from someone who may previously have had significant access.
If that process only checks Active Directory, the organisation may be solving yesterday’s identity problem.
Modern identity governance must consider all the places where access exists.
The Hidden Problem Is Access That Does Not Expire
The most dangerous access is often the access that nobody remembers.
A personal access token created twelve months ago.
An SSH key added to a server during a project.
A cloud API key generated for testing.
A GitHub credential tied to a personal account.
A third-party portal that was never integrated with Single Sign-On.
These credentials may continue working long after the employee has left.
That is the real problem.
The user is gone.
The identity relationship is supposed to be gone.
But the credential remains valid.
Offboarding Should Trigger More Than Account Disablement
A mature offboarding process should not ask only:
“Has the user account been disabled?”
It should ask:
“What access, credentials, tokens and trust relationships were associated with this person?”
That means reviewing cloud access, SaaS platforms, source-code repositories, privileged accounts, service credentials, API tokens and any system where the employee may have created long-lived secrets.
For privileged or technical users, the process may need to go further.
Rotate shared credentials.
Revoke tokens.
Remove SSH keys.
Review service accounts they managed.
Check whether any automation still depends on credentials they created.
The objective is to remove the trust relationship completely.
Personal Accounts Create Another Risk
Developer platforms create a particular challenge.
An employee may contribute to corporate repositories using an account they personally own.
That may be convenient.
It may also create ambiguity.
Who owns the identity?
Who controls the recovery process?
Can the organisation revoke access immediately?
Does the employee retain tokens or local clones after leaving?
This is why enterprise use of developer platforms needs clear identity architecture.
Corporate access should be centrally governed where possible.
Privileged access should not depend on personal identities that the organisation does not fully control.
Access Reviews Should Not Wait For Someone To Leave
There is another lesson here.
If the organisation only discovers orphaned access during offboarding, the problem may have existed for years.
Regular access reviews are important because employees accumulate permissions over time.
A developer changes team.
A manager moves to another function.
A contractor finishes one project and starts another.
Old access remains because nobody removed it.
Eventually, the user may have permissions that no longer reflect their role.
The Leaver process should therefore be the final identity review.
Not the first one.
Machine Identities Make This More Complicated
The problem becomes even harder when people create machine credentials.
An employee may leave, but the API key they generated continues running.
A service account may still exist.
A CI/CD token may still deploy applications.
An automation workflow may still use credentials created under their ownership.
This is why machine identity governance is becoming as important as human identity governance.
The organisation needs to know not only who owns an account, but who owns the credentials created around it.
Because the human identity may disappear while the machine identity continues operating.
Final Thoughts
Offboarding is often treated as a checklist.
Return the laptop.
Disable the account.
Remove email.
Close the HR record.
But modern enterprise access is much broader than that.
Employees interact with cloud platforms, SaaS services, developer tools, APIs and automation systems. Each of those may create another form of trust.
The employee leaving should trigger the removal of that trust.
Not just the removal of one account.
Because the real risk begins when the organisation believes access has been revoked, but something somewhere is still working.
The employee left.
The access did not.
Question assumptions. Share knowledge. Build trust.
Share this article
If this perspective was useful, share it with your network.