Treat remaining access as a security issue, not a paperwork issue. Revoke system access, confirm account deletion or disablement, and verify that any linked SaaS or application permissions were removed as part of the leaver process. The goal is to eliminate the gap between employment end and access end before it becomes an exposure path.
Why Offboarding Must End Access, Not Just Employment
When someone leaves, the security problem is not the resignation date itself, it is any surviving path back into systems, data, or workflows. A clean offboarding process treats employment end, access end, and credential end as the same operational event, then verifies that the account state actually changed everywhere it mattered.
The practical reason is simple: modern access is rarely limited to one directory entry. A departing employee may still have active access through SaaS admin panels, shared tools, API tokens, password managers, VPN profiles, delegated roles, or application-specific permissions long after HR records show the person is gone.
What Has to Be Removed, Disabled, or Confirmed
The minimum outcome is not just password reset or a note in the ticket. Teams should revoke active logins, disable or delete the primary account where policy allows, and remove every linked entitlement that could still authenticate or authorize the former employee. That includes direct application access, group membership, SSO assignments, privileged roles, and any standing permissions inherited from teams or projects.
Verification matters because access often persists in places offboarding checklists miss. Shared admin consoles, SaaS tenant permissions, service portals, and locally cached credentials can outlive the employee record unless someone explicitly confirms the account state in each system. The goal is a complete access stop, not a best-effort request.
Where access is tied to a device, session, or token, the offboarding review should also confirm that the old trust path is no longer usable. A disabled directory account is not enough if a long-lived session, a synced app token, or a separately managed password still grants entry.
How Teams Prevent Leaver Gaps From Becoming Exposure Paths
The strongest approach is to make offboarding a control that is checked, not assumed. That means the offboarding workflow should produce evidence that the account was disabled or removed, the major connected applications were reviewed, and any elevated or unusual permissions were explicitly cleared before the case is closed.
For teams that rely on central identity systems, the most effective habit is to treat termination as a privilege-change event with a deadline, not an administrative follow-up. If the access path can still be used after the employment relationship ended, the control has failed regardless of whether the person has already left the building.
Offboarding also needs an exception path for urgent departures. If there is any indication of conflict, misuse, or timing risk, the response should prioritize immediate access removal first and documentation second. The system state matters more than the paperwork trail when the access window is still open.
Risk and Threat Considerations
Residual access creates a straightforward exposure: a former employee may still be able to view data, make changes, or authenticate as if they were still trusted. Even without malicious intent, forgotten access can lead to accidental actions, policy breaches, or retention of access that no longer has a business justification.
Failure mechanism: Offboarding breaks when identity records are updated in one place but application permissions, tokens, or privileged memberships remain active elsewhere. That leaves a stale access path that can be used after employment ends, and the gap often persists because different teams own different systems.
Impact: The result can be unauthorized data access, unauthorized changes, lingering administrative capability, or later account abuse if the old access is discovered by another party. In practice, the longer the gap remains open, the more likely it is to become a durable exposure rather than a brief oversight.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers revoking and disabling credentials when staff leave. |
| AC-2 — Account Management | Directly governs disabling and removing user accounts during leaver processing. | |
| AC-6 — Least Privilege | Residual access after departure is a privilege exposure problem. | |
| Recommendation — Revoke authenticators and confirm credential lifecycle closure during offboarding. Disable or remove accounts promptly and verify account state across systems. Remove excess entitlements and privileged access at separation. | ||
| CIS Controls v8 | CIS-5 — Account Management | Prescribes managing lifecycle of accounts, including offboarding and access removal. |
| Recommendation — Automate offboarding to terminate accounts and related access paths. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Annex A control for removing access rights when employment ends. |
| Recommendation — Remove access rights promptly on termination and verify completion. | ||
Practitioner Guidance
What to verify: Confirm not only that the main account is disabled, but that all connected application permissions, group memberships, and elevated roles were removed. If the employee used multiple SaaS tools, verify each one rather than assuming directory deprovisioning propagated everywhere.
Decision rule: If a leaving employee had privileged, financial, customer, or production access, treat the case as high priority and require explicit closure evidence before acceptance. If the access was broadly delegated or duplicated across tools, verify the downstream entitlements individually rather than relying on one identity-system status.
Practitioner takeaway: Offboarding is complete only when the person can no longer authenticate, inherit, or reuse access anywhere that matters, and the organisation has proof of that state.
Related resources from NHI Mgmt Group
- How should security teams secure AWS access when employees still rely on on-premises Active Directory accounts?
- How do security teams know if unmanaged access is still active?
- How should security teams handle offboarding when employees still have valid access to third-party SaaS tools after an IdP disablement?
- How should security teams handle leaked AWS keys that still have active admin access?