TL;DR: VPNs still expose remote enterprise access to broad trust, credential portability, and misconfiguration risk, while MASQUE relays narrow access to specific resources and device identity, according to Smallstep. The real shift is that remote access governance moves from network reach to application-scoped trust boundaries.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Smallstep's blog post: MASQUE relays are positioned as a tighter remote-access model than VPNs, with the central finding that broad VPN trust and portable credentials remain the core problem.
Why it matters: It matters because IAM, PAM, and NHI teams increasingly need remote access patterns that bind access to device identity and application scope rather than whole-network reach.
Context
Remote enterprise access is a governance problem as much as a transport problem. When VPNs grant broad internal reach after a single authentication event, they turn one successful login into a large trust boundary that is hard to constrain, especially when credentials are stolen, copied, or reused.
MASQUE shifts the access model by proxying specific application traffic instead of exposing an entire subnet. That makes it relevant to remote access identity because the control question changes from who can join the network to which device can reach which resource under what policy.
Key questions
Q: What breaks when VPN access is granted too broadly?
A: Broad VPN access turns one successful authentication event into wide internal reach, which makes stolen credentials far more valuable. The failure is not encryption, but the fact that a single login can expose multiple systems, services, and protocols that the user does not actually need. That creates an oversized blast radius and makes lateral movement much easier.
Q: Why do leaked VPN credentials still create lateral movement risk?
A: Leaked credentials remain dangerous because many gateways still translate a successful login into broad network trust. If the session lands inside the internal network with more reach than the task requires, the attacker can pivot from authentication to discovery and movement without needing another exploit.
Q: How can teams reduce blast radius for remote and machine access?
A: Teams can reduce blast radius by combining JIT access, PAM, and strong identity inventory. The goal is to ensure privileged access is approved for a short duration, tied to a named owner, and revoked automatically when the task ends.
Q: What is the difference between VPN access and MASQUE relay access?
A: VPN access typically grants a broad tunnel into an internal network, while MASQUE relay access proxies only the specific application traffic a policy allows. That means MASQUE can preserve encrypted connectivity without exposing the full network surface. For practitioners, the difference is the size of the trust boundary after authentication, not simply the transport protocol.
Technical breakdown
Why VPN trust breaks down at the network layer
VPNs authenticate a client and then commonly extend network reach far beyond the application the user actually needs. That model is efficient for connectivity but weak for governance because the access decision happens once, then persists across many internal targets. If credentials are portable, the trust relationship becomes portable too. The article’s core critique is not that VPNs cannot encrypt traffic, but that they often collapse identity, device trust, and network reach into a single coarse control plane. See the Remote Access Identity Guide.
Practical implication: Design remote access around resource scope and device trust, not around full subnet exposure.
How MASQUE relays change the trust boundary
MASQUE relays use HTTP/3 and QUIC to proxy application traffic without exposing the broader network behind it. The device connects to a relay, the relay forwards only the designated request, and the internal resource remains reachable without handing out a general-purpose tunnel. That architecture matters because the relay becomes an application-scoped enforcement point instead of a blanket network conduit. In governance terms, the access decision becomes narrower, more auditable, and easier to align with Zero Trust Architecture principles.
Practical implication: Map sensitive SaaS and internal apps to per-resource relay policies instead of relying on network-wide access lists.
Why portable credentials are the real VPN weakness
A stolen VPN credential is powerful because it is often transferable across devices and locations, even when the organisation believes it has device controls in place. The article highlights phishing, brute force, malware, and credential stuffing as the practical paths that make this risk persistent. Once the credential is accepted, an attacker can enumerate internal services, pivot laterally, and abuse the trust granted by the tunnel. This is why the problem is not just login security but the scope of what a successful login unlocks.
Practical implication: Treat credential portability as an access-scope problem and remove broad post-authentication reach wherever possible.
Threat narrative
Attacker objective: The attacker aims to turn a single compromised remote-access credential into broad internal access and downstream control of sensitive systems and data.
- Entry occurs when attackers obtain valid VPN credentials through phishing, brute force, malware, or credential stuffing.
- Escalation follows when the VPN grants broad internal reach and the attacker maps hosts, ports, and exposed services.
- Impact comes when the attacker pivots laterally, steals data, installs ransomware, or establishes persistence inside the network.
Breaches seen in the wild
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
- CitrixBleed 2 2025: CitrixBleed 2 leaked NetScaler session tokens from memory, letting attackers hijack VPN sessions and skip MFA at 100+ organisations.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Remote access trust should be judged by resource scope, not by login success. VPNs often still convert one authenticated user into a wide internal trust relationship, and that is the governance failure this article exposes. The issue is not encryption strength but the size of the post-authentication blast radius. Practitioners should treat broad tunnel access as an identity design defect, not a connectivity convenience.
Credential portability is the hidden control failure in legacy remote access. When a VPN credential can be copied to another device and still unlock the same network reach, device trust is only cosmetic. That is why remote access identity has become a governance problem, not just a transport issue. Security teams need to stop assuming that user identity alone can safely authorize remote access at network scale.
Application-scoped proxying is the better mental model for modern enterprise access. MASQUE-style relays represent a narrower access boundary because they expose only the traffic that a policy explicitly allows. That does not remove the need for strong device assurance, but it does reduce the default tendency to over-grant network reach. The practical conclusion is that access control should follow the application, not the subnet.
Identity blast radius: The most useful concept here is the distance between successful authentication and total reachable environment. VPNs often enlarge that distance; MASQUE relays reduce it by making the relay, not the network, the enforcement point. That distinction matters for any programme trying to align remote access with Zero Trust Architecture and least-privilege design.
Read next: Remote Access Identity Guide
What this signals
Remote access governance is shifting from network reach to resource reach. Programmes that still treat VPN login as the main control point are carrying too much trust inside the tunnel. The better design question is which device may reach which application, not which user may enter the network.
Identity blast radius is now a practical design metric. When a remote-access control grants more internal reach than the user needs, the security failure is structural, not incidental. Teams should expect policy design, device assurance, and application routing to converge around narrower, more observable access paths.
For practitioners
- Reduce post-authentication reach Replace broad subnet access with per-application or per-domain access policies so a successful login does not unlock unnecessary internal routes.
- Bind remote access to device identity Use hardware-backed client certificates and managed device posture signals so access decisions depend on the device as well as the user.
- Reassess VPN ACL complexity Review whether manually maintained ACLs are masking overbroad access and introducing configuration drift across firewalls and routers.
- Segment SaaS access by resource For SaaS applications that support allow lists, route only the required traffic through a relay rather than exposing the whole corporate network.
- Treat stolen credentials as portable reach Assume compromised VPN credentials can be reused from untrusted devices and remove any access pattern that depends on the credential alone.
Key takeaways
- VPNs remain risky when they convert one authenticated session into broad internal reach that attackers can reuse after credential theft.
- The article frames MASQUE relays as an application-scoped alternative that reduces the blast radius of remote access.
- For practitioners, the main decision is whether remote access is governed at the network layer or at the resource layer.
Related NHI Mgmt Group resources: Remote Access Identity Guide · Privileged Session Management Guide · SaaS Security Guide
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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on portable credentials and weak trust binding in remote access. |
| NHI-05 — Overprivileged NHI | VPNs often grant wider network reach than the user or device needs. | |
| Recommendation — Bind remote access decisions to stronger authentication and device trust signals, not credentials alone. Reduce granted access scope so remote sessions cannot traverse unnecessary internal resources. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about narrowing who can reach which assets after authentication. |
| Recommendation — Align remote access entitlements with least-privilege resource access and review them regularly. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Network Access — Zero Trust Network Access | MASQUE relays are presented as a ZTNA-aligned remote access pattern. |
| Recommendation — Adopt resource-specific access paths that verify device trust before granting network reach. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes stolen credentials enabling internal mapping and pivoting. |
| Recommendation — Map remote-access compromise paths to credential access and lateral movement detection. | ||
Key terms
- Access Blast Radius: Access blast radius is the amount of damage possible if an identity, credential, or permission set is misused or compromised. It is shaped by privilege scope, resource reach, lateral movement paths, and data sensitivity, and it is reduced by tight authorization and segmentation.
- Session-Scoped Access: Session-scoped access is permission that exists only for a defined task or time window and is expected to end when the task ends. For NHI governance, it reduces lingering authority and makes AI-driven activity easier to review, revoke, and investigate when behaviour changes.
- Persistent Credential: A persistent credential is a long-lived secret such as an API key, token, or service account that remains valid until it is rotated or revoked. In AI agent environments, persistent credentials create durable access paths that can survive task completion, hide in code or workflows, and widen blast radius when exposed.
- Device Identity: Device identity is the cryptographic proof that a specific machine is the thing being accessed, independent of its IP address or current network. In fleet governance, it allows policy, audit, and revocation to follow the device across locations and transports.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org