Account administration is where security policy meets daily reality, and it is usually done by hand from memory. That works until the day it does not.
Joining
The checklist is longer than people expect:
- Account created with a consistent naming convention
- Correct licence assigned — not the most expensive one by default
- Group memberships appropriate to the role
- Access to the right shared mailboxes, sites and folders
- Multi-factor authentication enrolled before first use
- Device enrolled and policies applied
- Accounts on third-party systems the role requires
- Manager and department set correctly, because other systems read them
Use role templates, not copies
The common approach is to copy an existing user's permissions. It is quick and it is how permission creep spreads: the person copied had accumulated access from three previous roles, and now so does the new starter.
Define a template per role stating exactly what that role needs. New accounts are created from the template. Exceptions are requested and recorded rather than inherited silently.
This also makes review possible. You can compare actual permissions against the template and see what has drifted.
Moving
The stage that is almost always incomplete, because adding access is urgent and removing it is not.
Somebody moves from operations to finance. Their new access is granted on day one, because they cannot work without it. Their old access is removed... eventually.
After several internal moves you have people who can see most of the business, which is exactly the situation that turns a single compromised account into a serious incident.
The remedy is process rather than technology: a role change triggers both a grant and a revoke, and the revoke is part of the same request rather than a follow-up task.
Leaving
This carries the real risk, and it has two speeds.
Immediately
Block sign-in and revoke active sessions. Both, because blocking sign-in does not end sessions already established. A token can remain valid for hours.
Reset the password and remove multi-factor methods. A registered phone is a route back in.
Remove application passwords and access tokens for any connected services.
Wipe or collect devices. For company devices, remote wipe. For personal devices with company data, remove the company portion.
Then, deliberately
Convert the mailbox to shared. Colleagues retain access to correspondence, and it no longer consumes a licence. Set an auto-reply or forward as appropriate.
Reassign file ownership. Files in a personal drive disappear when the account is deleted. Transfer them to a manager or a shared location first — this is one of the most common causes of lost business information.
Reassign ownership of anything they owned. Groups, sites, teams, scheduled tasks, subscriptions, integrations. An orphaned service that nobody owns will fail at some point and nobody will know why.
Remove third-party accounts. The list nobody maintains: the accounting system, the CRM, the courier portal, the supplier extranet, the domain registrar. These are the accounts that remain active for years.
Reclaim the licence, once the mailbox conversion is done.
Delete the account only after your retention period, and record that you did.
The accounts that survive an offboarding are almost never the Microsoft ones. They are the third-party systems that were set up by one person and documented nowhere.
Automating it
Two levels, and most businesses should start with the first.
Level one: a script and a checklist. A parameterised script that performs the Microsoft 365 steps in the right order, producing a log of what it did, plus a checklist for the third-party systems. This alone removes most of the risk and takes little time to build.
Level two: triggered from your HR system. A leaver recorded in HR triggers the offboarding automatically at the right time. Better, and it requires an HR system with a suitable interface and a real conversation about who owns the trigger.
The approach for both is covered in automating employee onboarding.
The part automation cannot fix
Automation applies your list. It does not know about the systems that are not on it.
So the foundation is an inventory: every system holding a user account, who owns it, and how access is removed. Building this is unglamorous and it is the single most valuable piece of work in this area.
Review it whenever a new system is adopted. Most businesses can list their major systems and are missing four or five smaller ones, which are precisely the ones that get forgotten.
Verify afterwards
Automation that fails silently is worse than a manual process, because nobody is checking.
Run a monthly report: accounts with no sign-in for sixty days, licences assigned to blocked accounts, and group memberships that do not match the role template. That catches both the failures and the exceptions somebody granted and forgot.
Our security team builds joiner, mover and leaver processes for UK businesses, including the third-party inventory that makes them work. Start a conversation.
