A rollout is still VPN-like when users receive broad internal reach instead of application-specific access, when trust is based on network location rather than identity and context, and when privileged access depends on persistent connectivity. That pattern shows the control is preserving perimeter assumptions instead of enforcing request-level authorization and continuous verification.
How a VPN-style rollout shows up in day-to-day access
The clearest signal is that users can still “get on the inside” and then browse widely, instead of receiving a tightly bounded path to one application or service. Another tell is when policy decisions still hinge on network location, subnet, or gateway placement rather than identity, device state, and request context. That usually means the perimeter has been rebranded, not replaced.
A rollout can also look VPN-like when session duration and reach are effectively broad and persistent. If a user connects once and keeps reusable internal reach for hours, the control is still behaving like a tunnel, not a per-request trust decision.
That gap is exactly what NIST SP 800-207 Zero Trust Architecture tries to eliminate: access should be scoped to the resource and continually re-evaluated, not inherited from a durable network connection.
What to look for in the policy and architecture
A true zero trust rollout should change the access model, not just the access path. If the design still depends on a central gateway that grants broad east-west reach, if application segmentation is weak, or if the user sees one big internal network after login, the implementation is still perimeter-first. The control surface may be modern, but the trust model is old.
One practical check is whether the rollout enforces application-specific authorization at request time. If a user can authenticate once and then move between internal systems with little or no additional policy evaluation, the environment is preserving the same implicit trust that VPNs were built around.
For implementation detail, the Ultimate Guide to NHIs — Standards page is useful because it ties zero trust to identity-centric controls, and the Ultimate Guide to NHIs — Key Challenges and Risks section highlights the visibility and privilege failures that often show up when access is still too broad.
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 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations Are Managed | Broad access reveals weak authorization boundaries in a ZT rollout. |
| PR.AC-5 — Network Integrity Is Protected | VPN-like trust based on network location indicates weak network-based trust separation. | |
| Recommendation — Enforce resource-level permissions so sessions cannot inherit broad internal reach. Segment access paths so network location does not imply broad trust. | ||
| NIST Zero Trust (SP 800-207) | SC-1 — Policy Enforcement | Zero trust requires per-request policy checks instead of durable perimeter trust. |
| Recommendation — Place policy enforcement in the access path for every resource request. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Visibility and Discovery | Broad, persistent access often hides overly permissive identities and sessions. |
| NHI-03 — Privilege and Scope Control | VPN-like behaviour often persists when access is not tightly scoped to purpose. | |
| Recommendation — Inventory identities and sessions that still carry excessive reach. Restrict each identity to the minimum application scope required. | ||
| CIS Controls v8 | 6 — Access Control Management | A VPN-style rollout is fundamentally an access control failure, not just a network design issue. |
| Recommendation — Review and constrain access so users cannot traverse the environment broadly. | ||
Practitioner Guidance
What to verify: Test whether a granted session is bound to one application and one authorization decision, or whether it silently opens a wider internal route. If the latter is true, treat the rollout as incomplete even if the old VPN appliance is gone.
Common mistake: Teams often measure success by “can users connect?” instead of “what can each session reach?” That produces a cosmetic zero trust deployment with the same blast radius as the VPN it replaced.
Decision rule: If access is still broader than the task, redesign around resource-level policy and shorter-lived, context-aware authorization. If privileged users still need persistent connectivity to do their work, that is a sign the privilege model has not been broken apart yet.
Practitioner takeaway: A zero trust rollout is behaving like a VPN whenever connectivity is the control and authorization is secondary; the objective is to make trust narrow, explicit, and continuously rechecked at the application boundary.
Related resources from NHI Mgmt Group
- What is the difference between JIT access and Zero Trust for NHIs?
- What is the difference between zero trust and a traditional VPN model?
- What breaks when access reviews are still manual in a zero trust model?
- Why does legacy VPN create more risk for remote access than a zero trust model in cloud and SaaS environments?
