Internal access without VPNs shifts the identity control point

At a glance

What this is: Teleport’s VNet post shows how internal TCP access can be moved away from VPNs and into identity-aware proxying with role and session controls.

Why it matters: It matters because IAM, NHI, and access governance teams have to control private-resource reachability by identity and policy, not by implicit network trust.

👉 Read Teleport's guide to VNet use cases for internal access without VPNs

Context

VPN replacement for internal access is not just a network design choice. It changes where access decisions happen, shifting control from network position to authenticated identity, assigned roles, and session policy.

That distinction matters for IAM and NHI governance because private APIs, registries, and dev tools are often consumed by both people and machine workflows. When the access path becomes identity-aware, governance has to follow the actor and the entitlement, not the subnet.

Teleport’s VNet example is about reducing friction without removing control, but the broader security question is whether teams can keep authorization explicit when the network layer stops being the primary gate.

Key questions

Q: How should security teams replace VPN access for internal services without widening privilege?

A: Replace VPN reachability with explicit identity policy at the access layer. Define roles, labels, and session limits for each private API, registry, or tool, then verify that users only receive the minimum path needed for their work. The goal is to keep connectivity familiar while making authority narrow, visible, and reviewable.

Q: Why do private APIs and registries need tighter access governance than a VPN model provides?

A: VPNs usually answer where a connection comes from, not whether the actor should reach a specific service. Private APIs and registries need tighter governance because they often carry sensitive data, automation tokens, or build assets. Identity-aware controls let teams restrict reach by role and session rather than by network membership alone.

Q: What breaks when internal DNS names are preserved but access governance is not updated?

A: The migration can look complete while stale privilege remains hidden in scripts, certificates, and hardcoded endpoints. Preserved DNS names are useful for continuity, but they can also keep old trust assumptions alive if access policy, offboarding, and review cycles are not updated at the same time.

Q: How do teams know if their internal access model is actually zero trust?

A: A practical test is whether each connection is authenticated, authorized, and constrained before the private service is reached. If network location still decides access, the model is not zero trust. If roles, labels, and session policy determine access every time, the control point has moved to identity.

Technical breakdown

Identity-aware proxying for private TCP access

VNet works by creating a local virtual IP subnet and routing traffic through an access layer that checks authentication, roles, labels, and session restrictions before forwarding the connection. This is different from a VPN, which often grants broad network reach once connected. Here, the enforcement point sits in front of the private service, so access is evaluated per request or session rather than by network membership. That makes the control model closer to zero trust than to perimeter access, because connectivity is conditional and auditable instead of implicit.

Practical implication: map internal services to explicit role and session policies before you retire VPN-based access paths.

Custom DNS zones and virtual IP mapping

Custom DNS zones let existing internal hostnames continue working while traffic is transparently mapped to virtual IPs. The key technical value is continuity: scripts, Git clients, TLS certificates, and developer tooling do not need to be rewritten when access moves off the VPN. DNS still resolves the familiar name, but the traffic is redirected through the identity-aware access layer instead of a flat tunnel. That reduces migration friction, yet it also means DNS becomes part of the access design, not merely a naming layer.

Practical implication: inventory internal hostnames and certificate dependencies before migration so policy changes do not break automation.

RBAC, label-based permissions, and session restrictions

The control stack described in the post combines RBAC with label-based permissions and session restrictions. RBAC answers who gets a class of access, labels narrow that access to specific services or environments, and session restrictions constrain how the connection behaves once established. That layered approach is useful for private APIs and registries because it separates reachability from authority. If the policy model is weak, VNet simply becomes a nicer front end for the same overexposure problem. The technical gain comes from narrowing privilege before the connection is proxied.

Practical implication: treat VNet as an authorization boundary and review labels and session limits with the same rigor as privileged access.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

VPN removal is an identity governance change, not a convenience feature. Once internal access moves through an identity-aware proxy, the security question shifts from network location to entitlement precision. That means the governance model has to understand who or what is reaching a private service, under which role, and with what session constraints. For practitioners, the main conclusion is that VPN retirement is really an access-model redesign.

Internal resource access becomes auditable only if the policy boundary is the real enforcement point. A tunnel can hide overbroad reach behind network trust, while an identity layer can expose each decision to logging and review. But that benefit only exists if labels, roles, and session restrictions are actually aligned to the service being accessed. Practitioners should assume the access layer is the control plane and govern it accordingly.

Custom DNS creates continuity, but continuity can conceal stale privilege assumptions. Preserving old hostnames and TLS continuity is operationally useful, yet it can also allow legacy access paths to survive longer than their original governance model. The problem is not DNS itself, but the possibility that name stability outlives entitlement review. Practitioners need to treat hostname continuity as a lifecycle issue, not just a migration tactic.

Network trust is no longer a defensible access assumption for private developer resources. This model was designed for environments where network membership implied trust. That assumption fails when access is mediated by identity-aware proxying, because the actor can connect from anywhere while authority still depends on policy. The implication is that teams must rethink how they define reachability, privilege, and review in private infrastructure.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, showing that governance gaps often sit in behaviour as much as tooling.
• If internal access is moving off VPNs, the next control question is not just who can connect but how quickly exposed credentials, hostnames, and access paths are discovered and removed.

What this signals

Internal access control is converging with workload and human identity governance. As private services become reachable through identity-aware routing, the same entitlement model has to cover engineers, automation, and service-to-service workflows. Teams that still separate network access from identity governance will miss overexposure that now sits above the transport layer.

With 32.4% of security budgets now going to secrets management and code security in one NHIMG-cited research set, the market signal is clear: access problems are increasingly being treated as identity problems rather than infrastructure problems. That shift makes private-service governance, certificate continuity, and session policy part of the same operational conversation.

Identity blast radius: the practical measure is no longer how far a network tunnel reaches, but how much authority a connected actor can exercise once inside. For teams adopting identity-aware internal access, the question becomes whether every internal hostname, registry, and API is still bounded by least privilege and reviewable policy.

For practitioners

• Map private services to identity policy before migration Inventory internal APIs, registries, and development endpoints, then assign explicit roles, labels, and session restrictions to each service before removing VPN dependencies.
• Review hostname continuity as a governance dependency List every internal DNS name, TLS certificate, and scripted endpoint that will survive the transition so stale access paths do not remain hidden behind familiar names.
• Separate developer convenience from privileged reach Allow CLI and registry workflows to remain familiar, but constrain them with service-specific authorization so convenience does not become broad network exposure.
• Audit session policy for private tool access Check whether session restrictions limit copy, download, terminal, or command behavior in ways that match the sensitivity of the API or registry being reached.

Key takeaways

• VPN replacement changes the control point from network location to identity and session policy, which is a governance redesign rather than a transport tweak.
• Internal APIs, registries, and DNS-based service names remain high-risk if roles, labels, and access reviews are not updated alongside migration.
• Teams should treat identity-aware internal access as a zero-trust boundary and verify that every connection is explicitly authorized before a private service is reached.

Key terms

• Identity-aware proxying: An access pattern where authentication and authorization happen before traffic reaches a private service. Instead of trusting a network connection once it is established, the proxy evaluates identity, policy, and session constraints for each request or session.
• Virtual IP subnet: A locally routed address space that makes internal services appear reachable on a private network path without exposing them directly. In practice, it lets developer tools connect to internal systems while the access layer enforces policy and logging behind the scenes.
• Session restriction: A control that limits what a connected user or process can do after access is granted. It can constrain commands, file movement, copy actions, or terminal behavior, which reduces the damage possible if an allowed session is misused or overextended.

What's in the full article

Teleport's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of how VNet routes CLI and application traffic through a local virtual IP subnet
• Specific workflow details for private container registry push and pull operations without VPN access
• Custom DNS zone behavior for preserving internal hostnames during VPN migration
• Developer tooling examples showing how cURL, Docker, Git clients, and Postman behave in the new access model

👉 The full Teleport post covers the developer workflows, DNS mapping behavior, and registry access examples in more detail.

Deepen your knowledge

Internal access governance, private-service authorization, and session restriction design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are replacing VPN-based access with identity-aware controls, it is worth exploring.