What happens when remote access or VPN accounts are not properly decommissioned?

How Un-Decommissioned Remote Access Becomes a Persistent Entry Point

Remote access accounts only stop being useful when they are actually disabled, removed, or tightly constrained. If they remain active after a user leaves, a contractor rolls off, or a temporary need ends, they become dormant access paths that can still authenticate from outside the network. That matters because remote access usually sits close to high-trust systems and is often reachable from the internet.

When those accounts are not retired cleanly, the organisation keeps paying for an old trust decision. The account may still carry valid entitlements, device trust, VPN routing, or portal access, even though the business justification is gone. That is why decommissioning is not just housekeeping, it is part of access lifecycle control.

A useful way to think about it is that the account itself becomes a security dependency. If the password, token, or certificate tied to that access path is later exposed, the attacker does not need to invent a new route in. They can reuse the old one and arrive through a channel the environment already trusts.

Why Stale VPN Credentials Are So Attractive to Attackers

Attackers value stale remote access because it often bypasses the friction associated with fresh intrusion. A valid VPN or remote desktop account can look like ordinary user activity, especially if it is not bound to current employment status, current device posture, or strong multi-factor enforcement. That makes it a strong foothold for initial access and persistence.

Once inside, the attacker’s next step is usually not to stay on the remote gateway. It is to pivot. Remote access is useful because it can lead to internal browsing, credential harvesting, lateral movement, and access to applications that were never intended to be exposed externally. The original mistake is therefore amplified by the trust that remote entry creates.

For practitioners, the important point is that the failure is often invisible until someone reviews identity records, VPN logs, or termination workflows. If decommissioning is inconsistent, the environment can accumulate old access paths that remain active long after the business has forgotten them. NHIMG’s Remote Access Identity Guide is useful here because it ties dormant VPN accounts, MFA, ZTNA, and third-party access into one lifecycle view.

What Good Decommissioning Actually Removes

Proper decommissioning is broader than deleting a username. It should remove authentication capability, revoke active sessions where possible, strip associated entitlements, invalidate recovery paths, and close any alternate access routes that were created for the account. If any one of those pieces survives, the account may still be reachable in practice.

That is especially important for remote access because these accounts often sit at the edge of the trust boundary. A decommissioned user should not retain a live VPN profile, a portal session, a remembered device, or an emergency exception that quietly became permanent. If the environment still accepts the old identity, the retirement process has failed.

Good practice also means checking the upstream and downstream dependencies around the account. For example, shared admin paths, vendor access, and break-glass arrangements need separate governance because they often outlive the original owner or use case. NHIMG’s Break-Glass and Emergency Access Account Guide is a useful companion when the concern is whether exceptional access has become a permanent backdoor.

Risk and Threat Considerations

Stale remote access accounts create a long-lived exposure window because the organisation has already done the hard part for the attacker, it has preserved a trusted entry path. If credentials are stolen, guessed, reused, or recovered from an endpoint, the attacker can often authenticate without triggering obvious user-facing suspicion.

Failure mechanism: the access path remains valid after the legitimate need has ended, so compromise of the old credential, token, or portal login becomes a working route into the internal environment. From there, attackers can blend in, move laterally, and target higher-value systems using the organisation’s own remote access design.

Impact: the blast radius can extend well beyond the unused account itself, because remote access is frequently a bridge into broader network trust. The result can be data exposure, privilege escalation, ransomware staging, or long-term persistence that is only discovered during an incident review.

Practitioner Guidance

What to verify: treat remote access decommissioning as complete only when the identity, the remote access entitlements, and any authentication material have all been removed or invalidated. Also verify that the removal is reflected in directory, VPN, privileged access, and vendor-access records, not just in the HR offboarding ticket.

Decision rule: if the account can still authenticate to anything that reaches production or an internal management network, treat it as live access, not as an inactive record. In that case, prioritise revocation and session invalidation before spending time on whether the account has already been abused.

What good looks like: termination and access review processes should produce a short, auditable list of who still has remote access, why they have it, and when it will be removed. The healthiest state is a regularly reconciled inventory where dormant access does not survive normal employee, contractor, or vendor exit workflows.

Practitioner takeaway: remote access is only safe when the end of need is enforced as strictly as the start of need, because stale access turns past trust into present-day attack surface.

Related resources from NHI Mgmt Group

• Why do valid VPN or remote-access accounts increase post-compromise risk so much?
• What happens when remote access is used without MFA and a VPN?
• What happens when organizations allow remote SMB access without a VPN?
• What happens when remote admins need access from different clouds or merger environments without VPN dependencies?