A successful token-revocation operation is not proof that a departing worker has lost application access. Microsoft Entra documentation distinguishes preventing new tokens from ending existing access. The latter depends on the application's token and session model, including expiry and, where applicable, synchronization and configuration.
For the technology owner, that distinction should determine what counts as completed offboarding. Require evidence for each access boundary, with unresolved paths visible to the final approver. The checklist below is a recommended operating structure, grounded in CIS control guidance and provider-specific Microsoft Entra documentation.
Separate account state from application access
Keep account disablement, token revocation and application-session state separate in the record. For applications tied to Microsoft Entra ID, Microsoft's guidance says access-token-based access ends when the access token expires. An application can automatically revoke existing sessions when the disabled user state is synchronized, if configured to do so. The timing depends on that synchronization. Neither mechanism supports a universal immediate cutoff.
Record the disabled identity. Verify application access separately.
In Entra, distinguish preventing new tokens from ending existing access.
CIS notes that disabling instead may be necessary to preserve audit trails.
These actions are not interchangeable. Map provider-specific behavior before setting completion criteria.
Disablement, token revocation and deletion answer different completion questions.Define the trigger, owner and audit record
CIS Control 6 assessment guidance calls for a documented, preferably automated access-revoking process covering termination, rights revocation and role change. It recommends disabling accounts immediately at those events and notes that disabling rather than deleting may preserve necessary audit trails. This is control guidance, not evidence of adoption rates or measured effectiveness.
Before an event, appoint a workflow owner with authority to pursue incomplete checks and escalate exceptions. Define who authorizes the trigger, its effective time, the identities in scope and the accountable identity, application and device owners. Decide who can accept unresolved risk. Keep that approval distinct from technical verification.
Identify the system, account or device and the required action.
Name the accountable owner, effective time and action deadline.
Retain the operation result, timestamp and affected identifier.
Record the check, observed result, time and limits.
Retain closure evidence or assign an exception owner and follow-up date.
An editorial workflow recommendation, not a universal provider requirement.
Create one checklist record per access boundary, carrying ownership and evidence through to closure.Disable the identity and revoke renewal paths
Microsoft's Entra PowerShell offboarding guidance describes account disablement and authentication-token revocation as separate actions. Use those actions as a provider-specific example. For your identity platform, document the applicable operations and their limits before relying on them during an offboarding event.
- Recommended identity-owner checklist:
- Confirm the identities in scope against the authorized event. Check whether the worker has separately assigned administrative identities.
- Execute account disablement at the effective trigger time. Retain the operation result and resulting account state.
- Execute the provider's documented token-revocation operation. Record its scope, including whether and how it addresses refresh tokens or other renewal paths.
- Retain timestamps and affected identifiers for both actions. Record failed or ambiguous results as unresolved.
- Pass the results to application owners for verification. Keep deletion subject to the agreed retention decision.
Label the result narrowly: identity actions completed. For Entra-connected applications, actual access loss still depends on application behavior. A successful identity operation should not close the application checks.
Verify applications, sessions and tokens
Ask each application owner to document how access ends, not simply whether the application uses SSO. The Entra guidance makes application-level timing central: token expiry, synchronization and session-revocation configuration determine when the identity action takes effect in the application. Choose a verification method that addresses the relevant condition.
- Recommended application-owner checklist:
- Identify the relevant access tokens, application-managed sessions and dependencies on synchronized account state.
- Document the supported revocation action or expiry condition, including configuration dependencies. Do not impose a standard waiting period without support.
- Define an authorized verification method. Distinguish evidence of a blocked new sign-in from evidence that an existing session is rejected.
- Record the observed result, check time and limits. State which access paths the check covers.
- Where access loss depends on a later event, assign an owner and follow-up time. Keep the boundary pending until verified or explicitly recorded as an exception.
Extend the inventory beyond centrally managed identities. Are application-local accounts, service accounts, API keys, shared credentials or privileged-access arrangements associated with the worker? Who owns them, and are any business assets awaiting ownership transfer? Assign these questions to the responsible system owners. The guidance used here does not establish a provider-neutral procedure for those access paths, so require a locally supported action and verification method rather than prescribing one generic remedy.
Resolve device ownership and device status
The Entra PowerShell guidance separately describes removing device ownership and disabling a user device. Give each applicable action its own checklist entry and evidence. An identity-disable result does not establish that either device action occurred.
- Recommended device-owner checklist:
- Identify devices in scope and confirm who is authorized to change their ownership and status.
- In an Entra workflow, record applicable ownership-removal and device-disable actions separately.
- Retain each device identifier, operation result, timestamp and resulting state.
- In other environments, document supported local controls and their limits rather than assuming equivalent behavior.
- Assign unresolved questions about possession, locally stored data and further device handling to a named owner with a due time.
Do not use device disablement as the completion evidence for physical recovery, data erasure or removal of offline access. The cited Entra guidance does not establish those outcomes. Require separate procedures and evidence for whichever of those obligations are in scope.
Keep exceptions visible and test the workflow
Set completion states before the workflow runs. The Entra timing conditions make this distinction necessary: an executed revocation action and verified loss of access are different milestones. Record a pending dependency explicitly rather than hiding it inside a completed offboarding ticket.
Retain evidence and the scope of the completed check.
Record the dependency, accountable owner and follow-up time.
Assign remediation and a compensating-control decision.
Assign accountability and a due time. Do not mark verified.
Accepting an exception is a risk decision, not evidence that access has ended.
Match each verification result to a closure decision or required follow-up.For every exception, retain the affected boundary, reason, accountable owner, approver, due time and next verification step. Document the compensating control. If none is available, say so and escalate the risk decision. Append follow-up results without overwriting the original action record.
Periodically test the workflow through authorized exercises and record reviews. Check whether triggers reach the right owners, evidence distinguishes execution from access loss, and overdue exceptions remain visible. Use the results to correct the inventory, assignments and verification methods.
The final approver should be able to distinguish verified access loss from accepted uncertainty without reconstructing the ticket history. Require every in-scope boundary to show either verification evidence or an explicitly owned exception. Administrative closure must not erase an unresolved access risk.
