Topic starter
08/06/2026 4:41 pm
TL;DR: Teleport says internal APIs, private container registries, and legacy DNS-based services can be reached through identity-aware routing instead of VPNs, with RBAC, labels, and session restrictions enforced before proxying. That shifts internal access governance from network location to identity and policy.
Editorial analysis by NHI Mgmt Group, based on content published by Teleport: “3 VNet Use Cases to Simplify Internal Access (Without VPNs)”.
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.
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.
Q: What breaks when internal access still depends on network location?
A: You lose precision over who can reach a private resource.
Practitioner guidance
- 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.
Bottom line: VPN removal does not remove the need for governance, it moves the decision point to identity, role, and session policy.
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
👉 Read Teleport's blog post on VNet use cases for internal access without VPNs →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
08/06/2026 6:26 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Internal access without VPNs shifts the identity control point
This post was modified 5 days ago by NHI Mgmt Group