Internal access without VPNs shifts the identity control point

At a glance

What this is: This is a Teleport blog post on VNet use cases that shows how internal access can be routed through identity-aware controls instead of VPNs for APIs, registries, and DNS-based services.

Why it matters: It matters because IAM and PAM teams have to govern internal reachability at the identity layer when network location no longer tells them who should access a private resource.

👉 Read Teleport's blog post on VNet use cases for internal access without VPNs

Context

VPN-based internal access assumes the network boundary is the control point, but this article argues that assumption breaks down when engineers need direct access to private APIs, registries, and internal services from modern developer workflows. The governance problem is not connectivity alone; it is deciding who can reach what, under which identity, before traffic is proxied.

Teleport’s VNet model routes connections through identity-aware controls and replaces location-based trust with policy enforcement at access time. That places internal service access, developer tooling, and private infrastructure squarely in IAM and PAM territory, especially where teams are migrating off legacy VPNs or preserving internal DNS names during that shift.

Key questions

Q: How should security teams govern internal access when VPNs are removed?

A: They should treat internal reachability as an identity and policy problem, not a network-placement problem. The practical shift is to define which roles, labels, and session conditions allow access to each private API, registry, or internal service, then audit those entitlements like any other privileged access path.

Q: Why do identity-aware access controls reduce reliance on VPNs for private services?

A: Because they let the organisation decide access before traffic is proxied, based on authenticated identity and resource policy rather than on whether a device sits inside a trusted network. That reduces broad network trust while preserving direct access for approved workflows and tools.

Q: What breaks when internal access still depends on network location?

A: You lose precision over who can reach a private resource. Network location tells you very little about role, session context, or intended resource scope, so access reviews become blunt and exceptions accumulate as teams add more tunnels, firewall rules, and shared entry points.

Q: What is the difference between VPN-based access and identity-aware routing?

A: VPN-based access grants network presence first and often treats that as a proxy for trust, while identity-aware routing evaluates the user’s identity, role, and resource policy before permitting a connection. The latter narrows implicit trust and makes internal access decisions auditable at the control point.

Technical breakdown

Identity-aware routing replaces VPN network trust

VNet changes the trust boundary by mapping a user’s authenticated identity to a local virtual IP subnet and then proxying traffic to internal TCP services. Rather than allowing access because a device is on the right network, the control plane evaluates who the user is, what roles they hold, and which labels apply to the target resource. That makes access decisions explicit and auditable before the connection reaches the service. The practical difference is that internal reachability becomes a governed authorization event, not an implicit property of network presence.

Practical implication: move internal service access decisions into identity policy rather than relying on VPN membership as a proxy for authorisation.

RBAC, labels, and session restrictions govern private API access

The article describes a layered authorization flow where RBAC policies, label-based permissions, and session restrictions are checked before proxying a request to a private API or registry. That architecture matters because each layer limits a different risk: RBAC defines who may act, labels narrow which resources are in scope, and session restrictions constrain how access is exercised. For engineering teams, this is what turns private API and registry access into a controlled entitlement model rather than a loosely shared network path.

Practical implication: define resource labels and session constraints for internal endpoints so access reviews can evaluate intent and scope, not just network connectivity.

Custom DNS zones preserve internal name continuity during VPN migration

The DNS use case is about keeping existing internal hostnames working while the underlying routing model changes. VNet maps familiar names such as internal GitLab domains to virtual IPs locally, so scripts, clients, and automation do not need to be rewritten when access moves off a VPN. That preserves application continuity, but it also means the identity control point shifts without forcing a naming change. The key architectural issue is not DNS itself; it is whether the access policy attached to that name now enforces identity-aware governance.

Practical implication: treat DNS continuity as a migration aid, then verify that the hostname now resolves through identity policy rather than inherited VPN trust.

NHI Mgmt Group analysis

Identity-aware internal access changes the control point, not just the transport. The article’s core shift is that access to private services is no longer decided by being on the right network segment. That means the effective control point moves to authentication, role assignment, and session policy before proxying. For IAM and PAM teams, the important change is that internal connectivity becomes a governed entitlement model, not a perimeter exception.

Internal API access is a policy problem before it is a connectivity problem. Private APIs are often treated as engineering conveniences, but the article shows they are governed resources with access scope, session limits, and audit requirements. Once identity is the gate, the same policy logic can be applied across developer tools, CLI workflows, and backend integrations. The practitioner conclusion is that API access and infrastructure access now share one governance surface.

Identity blast radius: internal access tools now determine how far a compromised identity can move once network location stops being the boundary. When VPN access is replaced by identity-aware routing, the blast radius depends on role design, label hygiene, and session constraints rather than the broad reach of a tunnel. That shifts the security question from “who is on the VPN” to “what can this identity actually touch.” The practitioner implication is to model internal access by entitlement scope, not by network admission.

Custom DNS migration does not reduce governance requirements. Preserving legacy hostnames may reduce operational friction, but it can also mask a major architectural change if teams assume the old access semantics still apply. The control point has moved even though the name has not. The implication is that migration programmes need a policy review for every DNS-backed internal service, not just a routing change.

VNet-style internal access is converging IAM and PAM around service reachability. Once private services are accessed through identity-aware routing, privileged access no longer starts at an admin console alone. It begins wherever sensitive internal tools, registries, and APIs are exposed behind policy enforcement. The practitioner conclusion is that access governance must be designed for identity-scoped internal reachability, not just for privileged human logins.

What this signals

Identity-scoped internal access is becoming a governance baseline. Once private APIs, registries, and DNS-backed services are reachable through identity policy, teams need one entitlement model that spans developer tools, automation, and privileged sessions. That is a better fit for modern IAM and PAM programmes than separate network exceptions.

Internal access architecture now exposes identity blast radius more clearly. If a role can reach multiple private systems through a single policy path, compromise of that identity affects more than one service boundary. The practical question is no longer whether a user can connect, but how far that identity can move once connected.

For practitioners

• Map internal services to identity-scoped entitlements Inventory which private APIs, registries, and DNS-backed services still rely on VPN reachability, then define which identities and roles should reach each one through policy enforcement.
• Replace network membership checks with resource labels Use labels and role conditions to express which internal resources are in scope for a given identity, especially where access is currently inferred from subnet membership.
• Review session restrictions for developer tooling Apply session constraints to CLI, Docker, and Git-based access paths so privileged internal access is limited by session context instead of persistent network location.
• Validate DNS continuity against new access policy Test internal hostnames after VPN migration to confirm they resolve through the new virtual path and still enforce the intended authorisation boundaries.

Key takeaways

• VPN removal does not remove the need for governance, it moves the decision point to identity, role, and session policy.
• Private APIs and registries become more manageable when access is authorised before proxying rather than inferred from network location.
• Teams migrating off VPNs should validate hostname continuity and entitlement scope together, or they risk preserving old trust assumptions inside a new routing model.

Key terms

• Identity-Aware Routing: A routing model that decides whether traffic may reach a private resource based on the authenticated identity and policy context. In this pattern, the network path is not the trust boundary; entitlement and session policy are, which makes internal access auditable and scoped.
• 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.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

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

• Step-by-step examples for direct CLI access to private APIs through VNet
• Operational guidance for pushing and pulling from private container registries without VPN dependency
• Custom DNS zone mapping for preserving internal hostnames during VPN migration
• A walkthrough of how VNet audits access sessions for engineering workflows

👉 The full Teleport post covers direct API access, private registry workflows, and custom DNS migration details.

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.