Topic starter
21/10/2026 2:46 pm
TL;DR: Blocking a main account can still leave app sessions, tokens and offline devices with access during employee offboarding, according to Hexnode. Verification has to prove closure across identity, apps and devices before the workflow can be closed.
Editorial analysis by NHI Mgmt Group, based on content published by Hexnode: “How can IT automate employee offboarding across multiple systems?”.
Key questions
Q: Why do offboarding failures create accountability risk for identity teams?
A: Because the owner of the departure record, the identity workflow, and the device or application controls may all be different teams.
Q: Who should own access and data cleanup during employee offboarding?
A: Ownership should be shared across HR, IT, IAM, and the application business owner, because each controls a different part of the exit.
Q: What breaks when offboarding only disables the primary account?
A: The lifecycle control remains incomplete.
Practitioner guidance
- Build offboarding around approved HR triggers Start the workflow from an approved departure record, then lock the last working day and access cutoff time before any revocation begins.
- Revoke every access path, not just the primary account Disable accounts, remove permissions, revoke sessions, and separate administrator accounts and access tokens so secondary access does not survive the main account closure.
- Keep offline devices on the task list Treat laptops and other offline endpoints as active offboarding items until IT confirms device control actions or collects the hardware.
Bottom line: Blocking a main account does not fully offboard an employee if app sessions, tokens, or offline devices still retain access.
Glossary terms: Offboarding Workflow Automation, Access residue, Session revocation, Lifecycle Assurance
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
21/10/2026 7:00 pm
Offboarding is a lifecycle control, not an account toggle. The article reinforces a basic identity governance truth: departure risk lives across directories, applications, sessions, and devices. When teams mark offboarding complete after one account change, they are confusing a local action with an enterprise outcome. The practical conclusion is that lifecycle ownership has to cover every place the employee could still hold authority or data.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How do you know if offboarding automation is actually working?
A: Look for completed revocation logs, failed-task reporting, and evidence that licenses, groups, and app permissions were all removed together. If you only see a workflow marked complete, you do not know whether every downstream system received the change. Verification must prove closure, not just process execution.
👉 Read our full editorial: Offboarding automation fails when access and device gaps remain open
This post was modified 3 days ago by NHI Mgmt Group