Offboarding is complete only when access and ownership are resolved

Disabling the primary directory account is necessary, but it does not prove that offboarding is complete. Completion means access is no longer usable, active sessions and credentials are handled, company assets are recovered or reassigned, and business-owned resources have a new accountable owner.

CISA’s identity and access guidance describes join, move and leave events as lifecycle work and recommends promptly terminating accounts and privileges when a person separates. It also points to the value of a record showing the accounts and privileges associated with that individual. The operational challenge is turning that principle into evidence across systems that may not share one identity source.

Define the offboarding trigger and authority

Start with a trusted personnel event: termination, resignation, contract expiry or role change. Record who can initiate it, when technical action should occur and whether the case has special timing or legal requirements.

Planned departures and urgent terminations may use the same checklist but different sequencing. For an urgent case, logical and physical access may need to be removed at a coordinated time. For a normal transition, ownership transfer may begin before access is revoked.

The workflow should not infer an employment decision. HR or another authorized business process supplies the status and effective time; IT and security carry out the approved technical scope.

Build the checklist around dependencies

A useful checklist follows the identity beyond the main account.

Identity and authentication

• Disable or remove directory and application-local accounts as policy requires.
• Revoke active sessions, refresh tokens and remembered devices where supported.
• Remove MFA methods and recovery routes that should no longer work.
• Check privileged, emergency and secondary accounts linked to the person.
• Record applications that cannot be reached or verified.

Single sign-on helps centralize access, but it does not automatically cover local accounts, API keys, shared credentials or services outside federation.

Roles and entitlements

• Remove group membership and direct permissions.
• End temporary and just-in-time grants.
• Revoke vendor, cloud, repository and administrative access.
• Check entitlements held directly inside important applications.
• Confirm that delegated access and mailbox permissions are addressed.

The NCSC recommends a joiners, movers and leavers process so access can be revoked or changed when no longer needed. A mover deserves the same discipline: changing departments should remove old privileges, not only add new ones.

Credentials and non-human dependencies

People often create or maintain credentials used by workloads. Identify:

• API keys and personal access tokens;
• SSH keys and certificates;
• automation accounts and scheduled jobs;
• secrets stored in build or deployment systems; and
• shared credentials the person knew or could retrieve.

Do not delete a working automation credential before understanding its dependencies. Transfer ownership, rotate the secret and verify the dependent service. The objective is to remove personal control without causing an unmanaged outage.

Devices and physical assets

• Recover company devices, badges, keys and removable media.
• Decide how corporate data on a permitted personal device is removed.
• Preserve information subject to an authorized legal or investigation hold.
• Reassign, retire or securely erase returned equipment according to policy.
• Record assets that are missing, damaged or cannot be reached.

Remote wipe is consequential. Verify the target, ownership and applicable policy before approval, especially where personal data or a mixed-use device may be affected.

Business ownership

Access removal can leave operations without an owner. Transfer:

• application and cloud-resource ownership;
• shared mailboxes, calendars and distribution groups;
• repositories, deployment approvals and signing responsibilities;
• service, vendor and domain-administration contacts;
• open tickets, risks and control evidence; and
• AI agents, MCP servers or automation workflows attributed to the person.

This is the difference between an account checklist and an operational offboarding process.

Record completion as evidence, not assumption

For each target, retain:

• the source identity and effective separation time;
• the intended action;
• the system that received it;
• the observed result and time;
• the person or policy that approved a sensitive step; and
• an owner and due date for every exception.

“Request sent” is not the same as “access revoked.” Where an API or integration cannot confirm the result, the workflow should create a manual verification task rather than record success.

A worked example: an administrator who owns automation

Consider a departing infrastructure administrator who owns a cloud project, holds repository access and created several automation credentials.

At the effective time, the directory account and active sessions are disabled. Repository and cloud entitlements are checked separately. The cloud project is transferred to a service owner. Personal access tokens are revoked. Automation secrets are rotated one at a time, and each dependent job is tested after rotation. The laptop is recovered and its device record reconciled.

The case closes only when those results are verified or each unresolved item has an accountable exception owner. A failed secret rotation is not hidden inside a generally “successful” offboarding status.

How Simorin connects the workflow

Simorin’s Offboarding brings account suspension, linked-service access removal, session and token revocation, ownership transfer and completion verification into one operational scope.

Identity Directory supplies identity and lifecycle context. Credential Lifecycle addresses credentials and their rotation or revocation checks. These are separate responsibilities: changing a directory status does not demonstrate that a personal token stopped working or that a service has a new owner.

For each connected service, verify the supported action, required permission and returned evidence. Keep consequential actions behind the customer’s approval boundary. If a service is not connected or does not support the required operation, route the item to a named person instead of implying automation.

The relevant IT Asset Management & Protection discussion should use a representative leaver record, not a generic demonstration. That makes it possible to expose application-local roles, personal credentials, device dependencies and ownership gaps before they become a real separation incident.

The completion rule

Use a simple final test: can the former user still authenticate, exercise a permission, use a credential, control a company asset or remain the only owner of an operational dependency?

If the answer is unknown, offboarding is not complete. It is an exception that needs an owner, evidence and a deadline.