Why does remote work increase identity risk even when the company has VPNs?

Why This Matters for Security Teams

VPNs still matter for transport protection, but they do not answer the harder question: who is allowed to do what once a login succeeds. Remote work expands that risk because access is now decided through identity, device trust, and session controls rather than physical network location. That means credential theft, token replay, and endpoint compromise can turn a valid session into broad internal access unless identity controls are enforced continuously.

NHIMG’s research shows that identity failures are not edge cases; the Ultimate Guide to NHIs notes that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage. That same pattern appears in remote access: the perimeter may be encrypted, but the identity layer can still be weak, over-permissive, or stale. The NIST Cybersecurity Framework 2.0 reinforces that access governance, authentication, and continuous monitoring are separate controls, not substitutes for one another.

In practice, many security teams discover the weakness only after a stolen VPN credential is used from a trusted-looking endpoint and the attacker has already moved laterally.

How It Works in Practice

The practical issue is that VPNs create an encrypted tunnel, but they do not validate whether the connecting user is on a managed device, using a healthy session, or operating within least privilege. Remote work increases exposure because the organisation must assume the endpoint may be hostile, the network may be untrusted, and the user’s session may be hijacked after authentication. That is why current guidance favours identity-centric controls layered with device posture and context, rather than relying on network location as a gate.

A stronger model uses MFA, conditional access, short-lived sessions, and explicit authorisation per request. For higher-risk environments, organisations also add just-in-time privilege elevation, session recording, and continuous risk scoring. The goal is to make access time-bound and task-bound, not permanently granted. For workloads and automations, the same principle applies to secrets and tokens: Top 10 NHI Issues highlights how long-lived credentials and excessive privilege persist long after the original use case has changed.

• Use device trust checks before granting session access.
• Bind access to user, device, application, and risk context.
• Prefer short-lived tokens over reusable static credentials.
• Enforce least privilege and remove standing admin access.
• Log and alert on impossible travel, token replay, and unusual resource access.

For identity architecture, standards such as SPIFFE are useful where workload identity must be proven cryptographically, while policy engines can evaluate access at request time instead of depending on pre-defined network trust. These controls tend to break down in bring-your-own-device environments with poor endpoint management because the organisation cannot reliably attest to the device or session state.

Common Variations and Edge Cases

Tighter identity controls often increase friction, requiring organisations to balance user productivity against the risk of account takeover and session abuse. That tradeoff is real, especially for contractors, executives, and high-mobility teams that need fast access across multiple systems.

There is no universal standard for every remote access scenario yet, but current guidance suggests a few patterns. First, VPN access should be treated as one control layer, not the decision point for trust. Second, remote work programs should distinguish between human access, service access, and automation access, because the same controls do not fit all three. Third, organisations with mature programs increasingly pair Zero Trust Architecture with continuous identity verification rather than assuming that a connected user remains trustworthy for the full session.

NHIMG’s 52 NHI Breaches Analysis shows how often valid credentials and weak governance are enough to enable compromise, which is why the remote-work problem is usually not “VPN weakness” but “identity overconfidence.” That distinction matters when third-party access, shared admin accounts, or unmanaged personal devices are involved. In those cases, the controls fail less because of the tunnel and more because the identity bound to it is too broad, too long-lived, or too easy to reuse.

Related resources from NHI Mgmt Group

• What is the difference between prompt injection risk and identity abuse in agents?
• Why do non-human identities increase identity blast radius?
• Why does MCP increase identity risk even when the protocol is secure?
• Why does hybrid work create more identity governance risk than fully remote work in some organisations?