Start with duties and an authorised request

An account represents a person or another identity in a system. Its entitlements are the permissions and memberships it holds. Giving a new employee “the same access as someone else” can obscure whether each permission is appropriate.

Record the role, approving owner and systems involved. When someone moves role, review the old access as well as the new requirements. ACSC system-access guidance ties access to business need and current duties. Guidelines for system access

Coordinate the change

The people responsible for employment changes and IT access need an agreed trigger, effective time and way to handle exceptions. Include the owners of applications outside the central directory. Also identify shared resources and integrations for which the employee has been responsible.

This is a process to design for the organisation. Contractors, urgent departures and work outside normal hours may need different arrangements. Do not interpret a framework’s removal timing as a universal employment-law deadline.

Disabling is different from ending every session

A session is an established interaction with an application. Its behaviour may differ from the account’s next sign-in. Microsoft explains that an application can control its own session token, so an Entra ID account action should not be described as immediately ending access everywhere. Application-side revocation may also be needed. Revoke user access in Microsoft Entra ID

That is a Microsoft-specific example of why verification matters. It is not a revocation procedure for every identity provider. An authorised identity administrator should determine what must be checked for the actual applications and configuration.

Preserve and transfer information deliberately

Blocking access, transferring ownership, retaining information and deleting an account are different decisions. Microsoft 365’s former-employee guidance separates access prevention from mailbox and OneDrive preservation or transfer. Its steps depend on the relevant products and arrangements. Overview: Remove a former employee and secure data

Decide who is authorised to receive business information before copying it elsewhere. Employee privacy, required retention and legal holds need appropriate specialist advice. This article sets no deletion timetable and gives no authority to inspect an employee’s private material.

An invented role-change example

An employee moves from finance to operations. The approved change adds the access needed for the new duties and reviews the old finance permissions. Later, when the employee leaves, the organisation coordinates the effective departure time, application checks and handover of shared business resources.

The example illustrates responsibilities. It does not assume every account is centrally managed or that a password reset completes offboarding.

A lifecycle checklist

  • Confirm the authorised trigger, owner and effective time.
  • List relevant accounts, roles, devices and shared resources.
  • Review both access being added and access no longer justified.
  • Assign application-specific revocation and verification work.
  • Agree information ownership, retention and handover.
  • Record completion evidence and unresolved exceptions.

Optional depth: include non-human dependencies

An integration may use credentials or resources managed by an employee without being that employee’s ordinary login. Ask the application owner how responsibility will transfer. Avoid breaking a business dependency through an unexplained account deletion. Identity, application and HR specialists should agree the detailed procedure before it is used.

  • MFA and passkeys — Plan authentication and recovery.
  • Least privilege and access controls — Design and review permissions.
  • What an integration involves: data, permissions and failure recovery — Consider integration ownership and dependencies.