ZTNA closes the remote access gap without a full SASE stack

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Twingate's blog post: Remote-first companies often already have IdP and endpoint controls, and ZTNA is the missing layer for least-privilege access to private resources.

Why it matters: This matters because identity teams and security architects need to align remote access design with the actual access problem, not a bundled networking platform that adds cost and complexity without changing privilege scope.

Context

Secure remote access is not the same problem as network replacement. When employees mostly use SaaS and cloud systems, the security question becomes how to grant access to private resources without exposing them to the public internet or forcing all traffic through a VPN or a broad SASE stack. That is an identity and access design problem as much as it is a network design problem, because the control point is who can reach what and under what conditions. Remote access identity guidance helps frame that distinction.

The practical issue is governance, not branding. Many mid-market organisations already have identity provider controls, MFA, and endpoint security in place, so the remaining gap is often the private application path. A purpose-built ZTNA layer can close that gap without requiring a full network re-architecture, which makes it easier to align access control with actual business use rather than with office-centric assumptions.

Key questions

Q: What is the difference between ZTNA and a VPN for remote access control?

A: A VPN typically places a user inside the network and then relies on perimeter trust, while ZTNA grants access only to specific resources based on identity and policy. ZTNA checks trust at each transaction, which reduces exposure if credentials or devices are compromised. That makes it better suited to cloud-first and hybrid work environments.

Q: Why does broad network access increase lateral movement risk?

A: Broad network access increases lateral movement risk because a compromised endpoint or account can reach many internal hosts, services and administrative interfaces across the trust boundary. Network segmentation, deny-by-default firewall rules, zero trust policies and strong authentication reduce the number of reachable targets and limit how far an attacker can move after initial compromise.

Q: How should teams decide between SASE and standalone ZTNA?

A: Teams should choose based on the access problem they need to solve: SASE combines secure connectivity, security inspection and policy enforcement, while standalone ZTNA focuses on application-level access to specific resources. If the goal is least-privilege access for private applications, ZTNA may be enough; if users also need integrated web, cloud and branch controls, SASE fits better.

Q: What should organisations check before replacing a VPN?

A: Before replacing a VPN, organisations should check which private resources must remain reachable, how users and service accounts authenticate, whether application-level access can replace full network access, and how segmentation, device posture checks and logging will work. They also need to confirm support for legacy protocols and admin access paths that still depend on network-level connectivity.

Technical breakdown

Why SASE and ZTNA solve different problems

SASE combines networking and security functions in one cloud-delivered model, but ZTNA is only one component of that stack. The distinction matters because SASE also includes SWG, CASB, and FWaaS, which are designed to inspect and steer general internet traffic. ZTNA, by contrast, is about authenticated access to specific private resources. In practice, that means the control objective is not full traffic consolidation but least-privilege application reachability. See the SASE and SSE Guide.

Practical implication: Scope the control to private-resource access first, then decide whether broader traffic inspection is actually required.

How outbound-only connectors change exposure

A ZTNA connector placed inside the private network creates an outbound path from the protected resource to the access broker, rather than opening inbound firewall rules to the internet. That architecture reduces exposed surface area because the application never needs to be published as a public endpoint. Access decisions are enforced per resource, so the user connects to only the specific service they are authorised to reach. See the Secure Remote Access Beyond VPN Guide.

Practical implication: Prefer access paths that remove inbound exposure instead of wrapping public services in compensating controls.

Why VPN-style network access expands blast radius

A VPN places a remote user onto the network, which means the user inherits the network's reachable surface once authenticated. If the device is compromised, the attacker can often explore additional internal systems beyond the original target. ZTNA breaks that assumption by authenticating each connection against policy and exposing only the intended resource, which sharply limits lateral movement opportunities. See the Remote Access Identity Guide.

Practical implication: Replace network-wide access models with per-resource authorisation when the goal is to contain compromise scope.

Threat narrative

Attacker objective: The attacker aims to turn one legitimate remote session into broad internal reach, enabling lateral movement and access to additional private systems.

1. Entry occurs when a remote user authenticates to a VPN or similar network-level access path that places the device inside the internal network.
2. Credential or session abuse follows if the endpoint is compromised, because the attacker inherits the same network position as the legitimate user.
3. Escalation happens when the attacker moves laterally from the original resource to other internal systems that were never meant to be reachable.
4. Impact is broader internal exposure, where one compromised remote session can lead to access beyond the intended application or environment.

Breaches seen in the wild

• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

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

ZTNA is the right control when the problem is private-resource access, not network consolidation. The most common mid-market mistake is buying a broad platform to solve a narrower access issue. That creates procurement drag and implementation overhead without changing the underlying authorisation model. Practitioners should treat the decision as an access governance problem first, then evaluate whether networking components are actually required.

Least-privilege remote access depends on per-resource policy enforcement. A VPN makes the network the control boundary, which is too coarse for most cloud and SaaS-heavy environments. ZTNA narrows the boundary to the application or service itself, which is far better aligned with modern identity governance. Remote access identity guidance is the right reference point when the question is who should reach what, not how to extend the LAN.

Standing network access is the wrong abstraction for hybrid work. When staff spend most of their time in SaaS and cloud services, the old assumption that they need broad internal network membership no longer holds. The governance consequence is clear: access should be issued to discrete resources, not to a generalized internal network that expands attack paths.

The real procurement question is whether consolidation improves control or just bundles unused capability. A SASE purchase can make sense where branch networking and traffic inspection are genuine requirements, but many smaller organisations do not live in that world. Security leaders should test every bundled component against actual use, because unused stack elements still create operational and budget friction.

Remote access architecture is now an identity architecture decision. Once remote work is the norm, the access layer becomes part of identity governance, because it determines how authenticated users are constrained after login. That makes ZTNA, IdP policy, and device posture complementary controls, not separate conversations. The programme implication is to govern access by resource and context, not by legacy network membership.

What this signals

Remote access governance is moving from network membership to resource entitlement. That shift matters because the control point is no longer the perimeter but the application-level policy that governs each session. Security teams should expect remote access design to become a joint decision between IAM and infrastructure owners, with device posture and identity policy doing the heavy lifting.

Zero Trust access becomes a practical control when organisations stop treating it as a full-network programme. The useful unit is the private resource, not the employee network. Once teams scope access by application, database, or environment, they can remove unnecessary exposure without forcing a broader re-platforming exercise.

For practitioners

• Define the access problem before buying the platform Map the exact internal resources remote staff need, then decide whether you need per-resource access or broader traffic inspection. If the main issue is secure access to private systems, a ZTNA layer is the control to evaluate first.
• Reuse existing identity and endpoint controls Inventory what your IdP, MFA, and endpoint security already enforce so you do not repurchase capability that is already in place. The goal is to close the remaining access gap, not to replace working controls with a larger stack.
• Remove network-wide access where the business does not need it Replace VPN-style broad network membership with policy-bound access to named applications, databases, or environments. That reduces lateral movement opportunities and keeps remote access aligned with least privilege.
• Test deployment scope against operational reality Estimate implementation effort, change management, and user impact before committing to a full SASE rollout. If traffic steering, branch routing, and web inspection are not core requirements, the platform is probably oversized for the problem.

Key takeaways

• Most mid-market organisations do not need a full SASE stack to solve remote access, because their real gap is usually private-resource entitlement.
• ZTNA changes the security boundary from the network to the specific resource, which sharply reduces lateral movement opportunity.
• Identity, endpoint posture, and per-resource access policy are the controls that matter most when the workforce is remote-first.

Related NHI Mgmt Group resources: Remote Access Identity Guide · Secure Remote Access Beyond VPN Guide · IAM and IGA Basics

Key terms

• SASE: A cloud-delivered architecture that combines networking and security capabilities such as SD-WAN, SWG, CASB, FWaaS, and ZTNA. It centralises enforcement across distributed environments, but it does not replace identity governance or privilege design. The model is operationally broad, not a substitute for entitlement control.
• Zero-Trust Network Access: Zero-Trust Network Access is a way to give users secure access to specific applications without placing them on the internal network. Access is granted only after identity, device posture, and policy checks, then limited to the requested resource. ZTNA reduces lateral movement by replacing broad network trust with per-session authorization.
• ZTNA: Zero Trust Network Access is a remote access model that grants users or devices access only after identity, context, and policy checks are satisfied. It reduces implicit trust by exposing specific applications or resources instead of the broader network, which makes it useful for telework, contractor access, and other situations where least privilege matters.
• VPN: A VPN is an encrypted connection that tunnels network traffic between a user device and a private network. It reduces exposure on untrusted networks, but it is not a complete security model by itself. Teams still need endpoint protection, identity controls, and access segmentation to limit the blast radius if a device is compromised.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. Explore it if you are responsible for access governance, privileged access, or machine identity controls.