Security teams should revoke remote access immediately during offboarding, not wait for the next periodic review. Any VPN keys, access tokens, or related permissions should be disabled or rotated so the former employee cannot continue to reach internal systems. That same process should be tied to onboarding and offboarding workflows, because access control is only reliable when it follows employment status changes.
Why Immediate Offboarding Matters More Than the Next Review Cycle
Remote access is a live privilege, not a courtesy. Once employment ends, any still-enabled VPN, token, certificate, or privileged network path becomes an unnecessary trust bridge into internal systems. The practical control is immediate revocation or rotation at the moment offboarding starts, then confirmation that the account is no longer usable rather than assuming a scheduled review will catch it later.
Where access is tied to remote support, admin tooling, or privileged sessions, delay creates a real exposure window even if the person is no longer inside the organisation. That is why many teams treat visibility gaps, sprawl, over-privilege, and unmanaged credentials as one lifecycle problem, not separate ones.
- Disable the remote path first, then handle any follow-on cleanup.
- Rotate any shared or reusable secret that may have been exposed to that employee.
- Verify that no alternate remote channel, backup account, or cached session still grants access.
What Teams Should Revoke, Rotate, and Verify
The minimum response is to remove the former employee’s ability to authenticate and to invalidate any secret material that could still authorize access. That includes VPN credentials, access tokens, SSH keys, certificates, device trust, and any delegated permissions that survive the primary account closure. If access is federated or inherited through a group, deprovisioning must reach the upstream control, not just the visible user record.
For teams that manage service-style access alongside employee accounts, the same logic applies to lifecycle and rotation discipline. NHIMG’s Ultimate Guide to NHIs is useful here because the operational failure mode is the same: access remains valid after the owner should no longer be trusted to use it.
- Confirm the account is disabled in the identity source, not only hidden in a local admin console.
- Revoke or rotate any credential that can still reach production, management planes, or remote support tooling.
- Check for shared credentials, cached VPN profiles, and long-lived tokens that were not issued to a single person.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Credential Rotation and Expiration | Former-user remote access depends on valid secrets and tokens. |
| NHI-03 — Offboarding and Deprovisioning | The question is directly about ending access when employment ends. | |
| NHI-06 — Visibility and Discovery | Teams must confirm no remote access path remains active after departure. | |
| Recommendation — Rotate or expire any credential that could still authenticate after offboarding. Tie termination events to immediate deprovisioning and access revocation. Inventory remote access paths so leaver accounts and secrets can be removed quickly. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication and Access Control | Revoking remote access is an access-control action tied to identity status changes. |
| PR.AA-05 — Least Privilege | Former employees should not retain any unnecessary remote privileges. | |
| PR.DS-01 — Data-at-Rest Protection | Remote access revocation helps reduce exposure to internal data and systems. | |
| Recommendation — Remove or disable authentication paths as soon as the user is no longer authorized. Restrict lingering access to the minimum necessary and revoke it at termination. Limit exposure by ensuring disconnected users cannot still reach sensitive resources. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Policy Enforcement Point | Remote access should be stopped at the enforcement point, not just at the user record. |
| Recommendation — Enforce termination decisions at the access gateway so revoked users are blocked immediately. | ||
| CIS Controls v8 | 5.3 — Account Management | Offboarding is an account lifecycle control problem. |
| 6.3 — Data Recovery | After remote access removal, teams should preserve evidence of completion and recovery paths as needed. | |
| Recommendation — Disable, remove, or review accounts promptly when employment ends. Maintain evidence that access removal completed and no fallback path remains active. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Stale employee access can be abused if valid accounts or tokens remain active. |
| Recommendation — Hunt for and remove any remaining valid accounts or credentials that still permit access. | ||
Practitioner Guidance
What to prioritise: Treat offboarding as an access-removal event, not an HR notice. The first question is whether any remote path can still authenticate or reuse trust after termination, because that determines blast radius.
What to verify: Require proof that the relevant access path is dead, not merely “scheduled for review.” The strongest evidence is a failed login or an expired secret after revocation, plus confirmation that any shared credential has been changed.
Common mistake: Teams often close the primary account but leave a token, certificate, VPN profile, or delegated role alive. That partial cleanup leaves a backdoor shaped like normal business access.
Practitioner takeaway: Offboarding is only complete when every remote authentication path and every reusable secret tied to the leaver has been invalidated, because stale access is still active access.
Related resources from NHI Mgmt Group
- How can security teams tell whether their remote access model is still too dependent on perimeter trust?
- How should security teams reduce breach risk when remote access still depends on passwords and weak MFA factors?
- How should security teams respond when an employee shows concerning behaviour but still has access?
- How should security teams replace remote control software for employee access to office workstations in telework setups?
