Identity lifecycle: joining, moving and leaving with no step forgotten
Every joiner, mover and leaver touches accounts, groups and licences. I turn this into a repeatable process with Microsoft Graph PowerShell, so that nothing depends on a checklist sent by email.
Typical starting point
Manual onboarding and offboarding
Every joiner is a checklist by email. Every leaver is the hope that nobody forgets a step.
No overview of who may access what
People who change departments often keep their old rights. Answering the question takes days of manual work.
Active Directory and cloud identity side by side
Synchronisation exists, but ownership of an attribute is unclear. Automation needs that answer first.
What I implement
- Joiner: create account, set attributes, assign groups, assign licence
- Mover: change attribute, reassign, revoke the old
- Leaver: disable, revoke sessions, reclaim licence, hand over data, settle ownership, delete
- Automation through the Microsoft Graph PowerShell SDK
- Bulk changes from CSV with a dry run
- Analysis of sign-in and audit logs
What matters
The three events differ a lot in difficulty. A joiner gets noticed when it fails, because someone cannot work. Movers and leavers do not get noticed: old rights bother nobody until they become a problem. That is why leaving has the most steps and gets the most care, from the block through the licence to the question of who owns the data and groups afterwards.
On top of that come technical quirks you only meet by doing it yourself. Disabling an account with the Graph PowerShell SDK, for example, fails with an inconspicuous error message because the change is expected as a body object. I document such stumbling blocks so that your team does not have to search for them again.
Approach
1. Understand
How do joiners and leavers run today, who triggers them, who leads which attribute? Where do steps get lost?
2. Design
The steps per event, their order, and the separation of disabling (reversible, data stays) and deleting (final after a retention period).
3. Implement
Scripts first against test users, with a dry run as the default, and on the principle that a second run does no harm.
4. Hand over
A runbook, least-privilege permissions for the automation and a walkthrough, so that your team runs the processes itself.
What you get
- Documented processes for joiner, mover and leaver
- Scripts for your environment, as commented source
- Runbook with permissions and error handling
- Handover to your operations team
Link to regulations
Revoking rights when someone leaves, access control and logging are typical requirements of ISO 27001 and NIS2. A documented process provides technical evidence for them: scripts, logs and runbooks. It does not replace compliance advice and does not by itself make a company compliant.
Backed by
The lab runs through the process once with eight scripts: create, group, licence structure, change attributes, disable, delete. The stumbling blocks are documented. A script for bulk runs from CSV with complete offboarding is in progress and not yet published.
Common questions
Do we need an expensive IGA product for this?
Not to start with. For many smaller environments a documented process with Graph PowerShell is enough. Whether more is needed later depends on the scale.
Why not delete right away when someone leaves?
Disabling is reversible and keeps the data for retention. Deleting is the last step, after data and ownership are settled.
Does this work in hybrid environments?
I work within an existing synchronisation between Active Directory and Entra ID. I have not yet led a hybrid migration from the ground up.