How should organisations shut down remote access when employees or contractors leave?

How to shut down remote access as part of offboarding

Remote access should be disabled as a termination task, not as a follow-up cleanup item. The practical objective is to remove every path an ex-employee or ex-contractor could still use to reach corporate systems, including VPN, ZTNA, remote desktop, RMM, vendor portals, and any shared support tooling. This is where the offboarding workflow must be coordinated across HR, IT, security, and the business owner.

That coordination matters because remote access is often broader than a single login. A departing user may have one direct account, but also cached sessions, federated access, trusted devices, service portal enrolments, recovery methods, or contractor sponsorships that keep access alive unless each layer is checked and revoked.

One useful benchmark is the principle behind NIST SP 800-207 Zero Trust Architecture, which treats access as continuously verified rather than assumed to remain valid after initial sign-in. For offboarding, that means the end state is not “the account is disabled” but “no remaining trust path can be used from outside or inside the network.”

Which access paths should be closed first?

Start with the identities and control points that can still open a remote session. That usually means directory accounts, VPN or ZTNA entitlements, SSO application access, remote desktop gateways, privileged access brokers, RMM tools, and any third-party remote support relationship. If the user was a contractor or supplier, close sponsor-based access and partner access at the same time, because those relationships often outlive the worker’s direct account.

Do not rely on one closure action to remove all reachability. Revoking a primary account does not necessarily kill open sessions, API tokens, remembered devices, or separately managed vendor access. For a remote-access-heavy environment, a complete shutdown should also invalidate active sessions, rotate or revoke exposed credentials where needed, and confirm that inherited access through groups, roles, or delegated admin paths has been removed.

The Remote Access Identity Guide is useful here because it frames remote access as an identity and trust problem, not just a connectivity problem. The most common miss is leaving a secondary path intact, such as dormant VPN entitlements or a remote support route that was provisioned outside the normal joiner-mover-leaver process.

For contractors and other external users, the strongest control is to make revocation part of the same termination event that removes physical badge access and internal system access. NHIMG’s Third-Party, B2B and Contractor Access Guide is directly relevant because it covers sponsorship, time limits, and offboarding for external access relationships that often remain active after the business need ends.

What usually goes wrong during remote-access offboarding?

The most common failure is partial revocation. Teams disable the human account, but leave a VPN profile, a remotely managed device, a contractor support portal, or an RMM agent that still authenticates the endpoint. Another common failure is delay, where the business believes IT will “pick it up later,” which creates a window in which the former user can still connect legitimately.

Remote access also fails cleanly only when ownership is clear. If no one can answer which systems the person could reach, which support tools they used, and whether they had privileged or shared access, the offboarding step becomes guesswork. That is especially risky for contractors and vendors, because remote access is often granted through a mix of direct accounts, group membership, and temporary exceptions.

Remote access tooling should also be checked for hidden persistence. RMM platforms, remote support products, and approved bastion paths can all survive the user departure unless they are explicitly tied to an owner, an expiry date, and a removal process. The right question is not whether the account was disabled, but whether the person can still reach production systems through any approved or shadow remote path.

Because remote access abuse frequently hinges on valid credentials rather than malware, teams should assume that any leftover access is security-relevant until proven otherwise. The SonicWall SSL VPN account compromises 2025 case shows why intact remote access after departure is dangerous: if valid credentials can still be used, the access path itself becomes the attack surface.

Practitioner Guidance

What to verify: Confirm that termination triggers revocation in every place remote access can be granted, not just in the HR or directory system. The cleanest check is to validate that the former user cannot authenticate to any VPN, ZTNA, remote support, bastion, or SSO-backed application after the cutoff time.

Implementation sequence: Remove access in a fixed order when timing matters: disable interactive access first, terminate active sessions next, then revoke remote entitlements, then review shared or delegated access, and finally confirm the result from an independent test account or monitoring view. If a contractor or vendor is involved, coordinate with the sponsor so no business exception keeps the path open.

Decision rule: If the departing person had privileged access, remote support access, or access to production systems, treat credential rotation and session invalidation as mandatory follow-up work, not optional hygiene. If the person only had low-risk access to non-production systems, still verify that no remote management channel or reuse path remains available.

Practitioner takeaway: The goal is not just to remove the account, but to remove every remotely reachable trust path fast enough that departure does not become a period of residual access.

Related resources from NHI Mgmt Group

• What happens when security teams try to scale access controls across employees, contractors, and remote workers without a unified policy layer?
• What happens when former employees, contractors, or vendors keep access after they leave?
• How should security teams secure remote access without slowing down employees who work from anywhere?
• What are the best practices for reducing over-permissive remote access for contractors and employees?