Offboarding brings the access model into focus. A person may have a central identity, separate application accounts, shared resources, devices, and responsibilities that need a new owner. I want the completion record to account for each of those paths. The result should be an orderly transfer of work and evidence that access has ended where it was supposed to end.
Source
Tokens complicate the meaning of access ended
NIST IR 8587, finalized September 15, 2026, addresses token and assertion protection across federation and API access. Its stated audience is federal agencies and cloud providers; it supplies useful technical questions beyond that setting.
I would ask how every important application ends access after identity changes, including existing sessions and delegated integrations. The proposal is to treat offboarding as a verification exercise across those paths, with product behavior documented explicitly.
Inventory the routes to access
Begin with the person’s central identity, then follow the applications and resources that identity can reach. Include direct application logins, active sessions, devices, shared credentials, delegated mailboxes, external guest accounts, and integrations the person owns.
Describe this figure
A map of the routes to access that start at one person’s central identity, the single directory status where offboarding begins. Seven routes fan out from it: application logins, separate accounts, some not behind single sign-on; sessions and tokens independently issued by the application; integrations the person owns, whose automations can keep working; devices, to be recovered or managed; shared credentials and password manager vault items; delegated mailboxes, calendars, and shared drives; and external guest accounts in other organizations’ tenants. The first three are highlighted and labelled as not ended by the identity change alone: each needs its own removal path and its own check.
Separate personal access from service ownership. Disabling an account that owns a scheduled workflow can interrupt work that needs to continue. Moving responsibility without addressing the former owner’s access creates a different gap. Both outcomes belong in the plan.
Use the approved departure time and coordinate with the people responsible for employment, information preservation, and business continuity. The technology checklist should implement those decisions without inventing its own retention or employment policy.
Source
Sequence the change
Prepare the inventory and destination owners in advance where appropriate. At the authorized time, perform the required identity and application changes, revoke supported sessions, recover or manage devices, and address credentials that were shared.
Check product-specific behavior. Microsoft documents that independently issued application session tokens are outside Entra’s direct revocation control. Application-level deprovisioning and session handling can therefore matter even after the central identity changes.
The lesson extends to the design of the checklist: every application needs an understood removal path. A single directory status should not stand in for all downstream results.
Proposal
Verify each important destination
For a critical application, inspect the account or membership in that application. Confirm the transfer of owned resources. Where the platform provides appropriate audit evidence, retain a reference to the action and observed result.
Use separate states for requested, completed, and verified work. A submitted removal job may still be processing. A device action may be pending because the device is offline. Those are meaningful distinctions for the person deciding whether the workflow is complete.
Verification should use authorized administrative views or approved test methods. There is no need to impersonate the departing person to demonstrate every result.
Record the boundaries
Removing future access cannot recall every previously downloaded file or unmanaged copy. Device status, application behavior, and the firm’s prior information-handling practices affect what can be established. Record those limitations and route material exceptions to the responsible owner.
Avoid claiming absolute completeness when part of the inventory remains uncertain. An open exception with a next action is more useful than a checked box that hides a dependency.
The completed record should show when access changes took effect, where they were independently checked, where information and workflows were transferred, and what still requires follow-up.
Offboarding is also feedback about the wider access model. Repeatedly discovering unknown accounts, personally owned integrations, or undocumented shared credentials suggests work to do before the next departure. Feed those findings into the service inventory and access review while the details are still clear.
Proposal
What I would test next
I would run an authorized test-account offboarding across a small set of important applications. Compare the central identity event with observed application and session behavior. Any difference should update the checklist and the claim we make at closure.