Identity management connects a person or service to accounts and permissions across your systems. The practical outcome is simple to describe: the right access is granted for a recorded reason, changes with the job, and is removed when the need ends.
Start with a list of applications, their owners, administrators and sign-in methods. Include contractors, external collaborators, shared resources and software integrations. A small team can begin with a controlled register before automating the workflow.
Keep authentication and permission separate
Authentication checks a claimed identity. Authorization decides what that identity can do. Provisioning creates or updates an account. Governance establishes who approves, reviews and removes its access.
Single sign-on can let an identity provider handle sign-in to several services. Each service still has roles, sessions and sometimes local accounts. An SSO connection by itself does not prove that account creation, permission changes or departure cleanup is automatic.
Microsoft's lifecycle workflow overview uses the joiner, mover and leaver model. Its implementation is product-specific; the same business questions apply when another provider or a manual checklist performs the work.
Build a register that can answer an access question
| Field | What it records | Why it matters |
|---|---|---|
| Identity and sponsor | Named worker, contractor or service; responsible manager. | Someone can confirm the continuing need. |
| Application and owner | Service name, tenant/account and approving owner. | Requests reach the person accountable for the data. |
| Role and reason | Actual permission level and task requiring it. | Reviewers can compare access with work. |
| Start, end and review | Approved effective dates and next review. | Temporary access has a defined limit. |
| Implementation evidence | Ticket, application result and reviewer. | An approval can be distinguished from a completed change. |
Store references to secrets in an approved vault, not the secrets themselves in the register. Keep the completed worksheet private. Names, system details and privileged roles can be sensitive even without passwords.
When someone joins
- Obtain an approved start date and role from the responsible manager. Confirm the person's identity through your established onboarding process.
- Choose a role baseline. Grant access to the tasks required now; record extra permissions separately.
- Create individual accounts and enroll supported authentication. Deliver initial access using the provider's secure invitation or enrollment process.
- Test the actual application permissions. Confirm a required task succeeds and an unrelated administrative task remains unavailable.
- Record the result, owner and review date. Give the user a route for reporting access problems.
A contractor's sponsor should approve an end date or recurring review before access starts. A service account needs a business owner and a technical owner, a defined purpose and a credential-management process.
When the role changes
Treat a role change as a comparison of old and new access. Grant approved new permissions and remove those whose purpose has ended. If there is a temporary overlap, record the reason and expiry.
Check shared folders, delegated mailboxes, API tokens and administrator roles as well as the main application. Groups and role inheritance can make effective permissions broader than a single visible setting.
When someone leaves
Coordinate the effective time with the authorized manager and any applicable retention obligations. Assign one coordinator to follow the whole checklist through completion.
- Block new sign-ins and disable affected accounts using each provider's supported process.
- Revoke sessions, refresh tokens and user-issued access tokens as applicable. Check local application accounts and external collaborator access separately.
- Transfer ownership of necessary files, calendars, automation and shared resources before deleting anything that must be retained.
- Retrieve managed devices and physical credentials. Rotate shared secrets that the departing person could access when required by the risk and your policy.
- Verify application results and preserve the completion record. Escalate failed changes rather than marking the whole departure complete.
Revocation behavior varies by application. Microsoft's workflow task definitions distinguish disabling accounts from revoking tokens and note limits for external sign-in sessions. Check token lifetime and session controls in each actual service; a directory change may take time to affect an existing session.
Review and automate after the manual process works
At an agreed cadence, ask each application owner to confirm retained access against current roles. Review privileged, external and inactive accounts with particular care. Record each decision as keep, change, remove or investigate, then track the implementation to completion.
Automate reliable triggers and repeatable actions. Keep error reporting, retries, an approval trail and a way to handle exceptions. Reconcile the automation's account list with the applications themselves so an unconnected service does not disappear from view.
The downloadable register includes a blank record, a fictional completed example and a departure checklist. Use it with the small-team policy template; agree on responsibility with any managed security provider.