Offboarding Access: Separate Former Users from the Automations They Owned

Disabling a person's main account doesn't necessarily stop every way they can access a system. They may have active application sessions, direct vendor accounts, personal access tokens, shared credentials, or scheduled jobs created under their identity.

At the same time, removing everything abruptly can break legitimate business automation. A useful offboarding process separates the former user's access from the organisation's ongoing workflows. Revoke what should end, transfer what should continue, and verify both outcomes.

Begin with a purpose and an owner

Record who authorises the offboarding, when it takes effect, and which systems are in scope. Use the organisation's approved employment, membership, or incident process. Don't infer permission to remove access from an unrelated chat message or an ambiguous name.

Assign one coordinator and named owners for important systems. An identity administrator may control the directory while another team manages a vendor account or source-code organisation. A checklist without accountable owners can leave gaps between those systems.

Treat this as a controlled lifecycle change. Preserve records needed by the organisation and follow applicable retention or legal-hold requirements with qualified advice where necessary. Access removal and deletion of business records are different actions.

Build the effective-access inventory

List directory membership, application roles, direct logins, sessions, tokens, recovery options, shared credentials, and owned automation. Include cloud consoles, code hosting, storage, email, support platforms, and locally managed services.

Microsoft's access-revocation guidance explains that identity and application access can require separate actions. Enforcement timing and token behaviour depend on the service. Don't promise instant universal removal merely because the central directory shows an account disabled.

For a sanitised inventory table, CSV Viewer can help a reviewer see systems and assigned owners. Keep real identity details, credentials, and private infrastructure in approved internal records.

Revoke the person's usable access

Follow each provider's documented process for account restriction, session revocation, group removal, and application access. Review direct vendor accounts that aren't governed by the central identity provider. A clean directory inventory may miss those entirely.

Rotate shared credentials when the departing person knew them and they remain in use, according to your approved process. Avoid replacing a shared secret in a way that silently breaks every dependent service. Inventory its consumers and coordinate the transition.

Check recovery channels and secondary authentication methods. Removing an ordinary login while leaving a personal recovery address can create an unintended route back into the account. Record the actual resulting state rather than merely the action submitted.

Transfer automation deliberately

Identify scheduled tasks, integration grants, webhook endpoints, deployment jobs, and service credentials associated with the person. Decide which workflows remain necessary and who will own them. Don't transfer a personal token by copying it to a new employee.

Create or use an appropriate organisational identity where the platform supports it, with only the permissions the workflow needs. Reauthorise the integration through the approved owner and test it before retiring the old grant where continuity matters.

Use a synthetic ownership manifest for review:

{
  "workflow": "example-nightly-report",
  "previous_owner": "former-team-member",
  "new_owner": "reporting-service",
  "continuity_tested": false,
  "old_access_revoked": false
}

This is illustrative metadata, not a real account instruction. JSON Formatter improves readability but doesn't verify either checkbox. Require observed evidence before marking the transition complete.

Verify both denial and continuity

Use an authorised test method to confirm the former identity can no longer perform the relevant operations. Check sensitive services directly, not just the central admin status. Don't use another person's live credentials casually for testing.

Then run the transferred workflow with synthetic or otherwise approved inputs. Confirm its owner, permissions, outputs, and failure notifications. A job that still runs under the old identity isn't a successful transfer even if it produces the expected report.

Record delays or exceptions explicitly. Some systems enforce changes at different times or need manual follow-up. A pending item should stay pending with an owner and deadline, rather than disappear into a general “offboarding done” statement.

Review indirect and shared relationships

Look at shared mailboxes, group memberships, external collaboration spaces, SSH access, and device enrolment where relevant. An account's access can come through more than one group or invitation. Remove the effective path, not just the most visible assignment.

Check whether external partners have their own records of the former contact. Update organisational contacts and ownership through authorised channels. Don't send messages to external parties unless your process and authorisation require it.

For deployment workflows moving away from a personal cloud credential, see GitHub Actions OIDC trust review. Federation can support a cleaner ownership model, but it still needs a deliberately restricted trust relationship.

Close with evidence, not a count of clicks

Keep the verified inventory, completed actions, continuity tests, and unresolved exceptions. Avoid retaining secrets in the evidence record. The coordinator should be able to explain which access ended and which business workflows were preserved.

Review the process periodically using a synthetic account. Systems change, and a once-complete checklist can become stale. The test should demonstrate denial and continuity across the actual services the team uses.

Conclusion

Offboarding is an effective-access change, not a single directory switch. Revoke human access, transfer necessary automation through proper ownership, and test both outcomes. A clear evidence record prevents “disabled” from being mistaken for “fully finished.”