VPN age-gating debate exposes enterprise remote access governance gaps

At a glance

What this is: This is an independent analysis of how the UK’s VPN age-gating consultation intersects with enterprise remote access, showing that the real risk is governance ambiguity around remote access controls, third-party access, and identity-based attack paths.

Why it matters: It matters because IAM, PAM, and security teams need to separate policy debate from operational exposure and decide whether remote access controls can still withstand stolen credentials, proxies, and unmanaged VPN clients.

By the numbers:

• Identity-based attacks accounted for 68.6% of incidents Expel investigated in 2025.
• Expel analysts found that 47.7% of identity incidents involving stolen credentials still resulted in access being granted.
• Expel’s SOC triaged nearly one million alerts across its customer base in 2025.

👉 Read Expel's analysis of VPN policy uncertainty and remote access identity risk

Context

VPN policy debates often focus on consumer privacy, but enterprises rely on the same remote access layer for workforce connectivity, third-party vendor access, and network segmentation. That creates a security governance problem: if VPN usage becomes harder to predict or control, IAM teams still have to prove who is connecting, from where, and under what trust assumptions.

The article’s core point is that the policy question will move slowly, while attackers continue to exploit remote access ambiguity now. In practice, that means identity controls, device trust, and proxy detection matter more than the regulatory outcome. For UK-based organisations especially, the starting position is not unusual, but it is operationally fragile.

Security teams that treat VPN use as a perimeter-only issue miss the identity dimension entirely. A VPN client, a proxy, and a credential stuffing attempt can look similar at the edge, which is why visibility and authentication policy have become part of remote access governance, not just network administration.

Key questions

Q: What breaks when VPN access is treated as trusted after login?

A: Broad VPN trust breaks containment. Once an attacker or compromised vendor session connects, flat network design can expose internal systems, management interfaces, and shared services that were never meant to be reachable from a remote entry point. Security teams should remove implicit post-login trust and limit access to specific assets and tasks.

Q: Why do proxies and consumer VPNs make credential attacks harder to stop?

A: Because they let attackers make malicious sign-ins look geographically normal. That weakens rules based only on source IP, country, or network reputation. The better control is to evaluate the full access context, including device compliance, account risk, MFA events, and whether the login pattern matches the user’s normal behaviour.

Q: How do you know if remote work security controls are actually working?

A: Look for fewer standalone passwords, consistent SSO adoption, enforced MFA or passwordless authentication, and access scopes that stay narrow after login. If users can still reach too many systems after authentication, the programme is secure at the front door but loose inside the building.

Q: Who is accountable when third-party or service access is still routed through a VPN?

A: The accountable team is the one that owns lifecycle governance for the access path, not just the network. If vendors or service accounts can keep using broad access after their task ends, the organisation has an offboarding failure, not simply an access-tool problem. Auditors will expect revocation discipline and traceable ownership.

Technical breakdown

Remote access trust models break down when VPNs can be mimicked

VPNs create an encrypted tunnel, but they do not prove intent, device trust, or user legitimacy on their own. Attackers routinely route through consumer VPNs or proxies to make stolen credentials look normal, which collapses geolocation-based controls and weakens conditional access decisions. The core issue is that transport privacy and identity assurance are not the same thing. Once a connection is accepted, the enterprise often relies on downstream controls to detect misuse, but those controls assume the access request was trustworthy at the start.

Practical implication: treat VPN presence as a transport layer, not as evidence of trust.

Why proxy-routed credential stuffing succeeds against remote access

Credential stuffing works when attackers can test large numbers of stolen username-password pairs against login portals until one succeeds. Proxy routing and unauthorized VPNs make that activity harder to distinguish from legitimate travel or remote work, especially when the organisation lacks strong device posture checks. In identity terms, the attacker is abusing authentication flow weakness, not exploiting the VPN itself. Once the first valid session is obtained, the next stage is often MFA enrolment, mailbox discovery, or cloud application pivoting.

Practical implication: correlate login source, device state, and MFA changes rather than reviewing sign-ins in isolation.

Remote access segmentation depends on identity lifecycle discipline

Many organisations still use VPNs to separate OT and IT, or to provide third-party access into legacy systems. That architecture can work, but only when access is tightly scoped, reviewed, and removed at the end of the relationship. Standing vendor credentials, old VPN profiles, and over-privileged accounts create a persistent foothold that bypasses the intended segmentation boundary. This is where NHI governance and PAM intersect with network design: a remote access tunnel is only as safe as the identities allowed through it.

Practical implication: align VPN access reviews, vendor offboarding, and privilege cleanup as one control set.

Threat narrative

Attacker objective: The attacker wants to turn ambiguous remote access into a durable identity foothold that enables broader compromise of enterprise systems and data.

1. Entry begins when an attacker uses stolen credentials against remote access portals or routes through proxies and unauthorized VPN applications to mask origin.
2. Escalation follows when the attacker successfully authenticates, enrolls MFA devices, or pivots into mail, cloud storage, or SaaS accounts.
3. Impact occurs when the attacker uses that foothold to move laterally, bypass trust assumptions, and expand access across remote workforce or third-party pathways.

NHI Mgmt Group analysis

Remote access governance is now an identity problem, not just a network problem. VPNs can hide transport origin, but they do not solve identity assurance, device trust, or privilege scope. That makes remote access one of the places where IAM, PAM, and security operations must converge, especially when third parties and legacy systems depend on the same pathway. Practitioners should treat remote access as governed identity infrastructure, not as a perimeter exception.

Proxy-routed sign-ins create a verification trust gap. When attackers can make stolen credentials appear to come from a plausible location, geolocation-based policy loses much of its value. The control failure is not simply that a login was blocked or allowed, but that the organisation assumed origin signals were more reliable than they were. This is exactly where phishing-resistant MFA, managed device policy, and behavioural correlation become decisive. Teams should assume origin spoofing will keep improving.

Standing third-party access is the most fragile part of remote connectivity. Vendors and contractors often sit outside device management, offboarding discipline, and continuous monitoring. That means remote access for third parties is frequently governed by exceptions rather than lifecycle controls, which is a poor fit for a threat environment that rewards persistence. The right question is not whether VPNs remain allowed, but whether access can be removed as quickly as it is granted. Practitioners should close the lifecycle gap first.

Remote access segmentation only works when identity scope is smaller than the tunnel. OT and IT segmentation can be undermined if the VPN account itself carries broad access or if old configurations remain active long after deployment. This is a named example of remote access trust drift: the gradual expansion of credentials, routes, and exceptions beyond the original security design. Security teams should re-baseline these architectures before attackers do it for them.

What this signals

Remote access is becoming a governance boundary where identity, device trust, and network policy converge. Teams that still manage VPNs as infrastructure-only risk underestimating how often stolen credentials and proxy routing defeat perimeter assumptions. The practical shift is toward continuous access evaluation, not static entry-point control, and that aligns with NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10 thinking where access scope and trust conditions must be explicit.

Remote access trust drift: over time, VPN exceptions, vendor tunnels, and legacy segmentation rules accumulate until the original control intent is no longer visible. That is the warning sign for security programmes: review whether identity lifecycle controls, offboarding, and privileged access policy still match how remote access is actually used. If they do not, the environment is already operating on inherited trust rather than governed trust.

The teams most exposed will be those that depend on remote access for third parties or operational environments without pairing it to managed-device policy and phishing-resistant authentication. That combination should become a standard baseline for high-risk access paths, not a special-case exception.

For practitioners

• Inventory every VPN client in use Build visibility into approved and unapproved VPN software on managed and unmanaged devices, then flag sign-ins from consumer privacy tools as a review condition. This is especially important where proxy use can mimic legitimate travel or remote work.
• Require managed devices for privileged remote access Apply conditional access so high-value accounts can authenticate only from enrolled, compliant endpoints with phishing-resistant MFA. Use this to reduce the chance that stolen credentials alone can open a session.
• Treat blocked proxy and VPN logins as incidents Investigate denied logins from suspicious geographies, TOR exit nodes, or unauthorized VPN applications as possible credential compromise rather than normal background noise. Repeated failures often precede successful access attempts within minutes.
• Reassess third-party and OT access paths Review vendor access, legacy VPN tunnels, and segmentation dependencies together so that offboarding, privilege reduction, and route cleanup happen as one control set. Focus on where remote access still relies on standing trust.
• Tie remote access reviews to identity lifecycle controls Synchronise VPN entitlements with joiner, mover, and leaver processes so old profiles, dormant accounts, and unmanaged certificates do not outlive their purpose. This matters most where remote access reaches sensitive or operational environments.

Key takeaways

• VPN policy debates are a reminder that remote access is an identity control surface, not just a connectivity layer.
• Expel’s data shows that stolen credentials and proxy-based access attempts are already operating inside the enterprise threat model, not outside it.
• The strongest response is to pair managed-device enforcement, phishing-resistant MFA, and lifecycle-aware third-party access reviews.

Key terms

• Remote Access Trust Drift: The gradual expansion of remote access privileges, tunnels, exceptions, and legacy pathways beyond the original security design. It usually happens when VPN access, vendor connectivity, and segmentation rules are rarely revisited, leaving organisations dependent on inherited trust instead of current risk decisions.
• Phishing-Resistant MFA: Phishing-resistant MFA uses authentication factors that cannot be easily replayed, intercepted, or socially engineered. In regulated environments, this usually means device-bound or cryptographic methods rather than push prompts or SMS codes, because the control must hold up under realistic attack conditions.
• Conditional Access: Conditional access is a policy model that decides whether an action should proceed based on context such as posture, resource sensitivity, timing, and scope. For AI agents, it must be evaluated at request time so a valid credential does not automatically equal permitted behaviour.
• Third-Party Access: Third-party access is access granted to vendors, contractors, or support partners who are not direct employees of the organisation. It is higher risk than internal access because accountability, device assurance, and access duration are harder to control, so it usually requires tighter time limits and stronger auditability.

What's in the full article

Expel's full analysis covers the operational detail this post intentionally leaves for the source:

• A breakdown of suspicious remote access behaviours seen in 2025 SOC cases, including unauthorized VPN applications and proxy-routed login attempts.
• The specific identity incident patterns behind the 68.6% figure, useful for teams comparing their own alert mix with Expel’s findings.
• The operational control recommendations for managed-device enforcement and blocked-login triage in real incident response workflows.
• The red-team observations behind remote access misconfigurations and access management failure points.

👉 Expel's full post covers the identity incident data, remote access indicators, and control recommendations in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives security practitioners a practical way to connect remote access risk with identity lifecycle controls.