Notifications
Clear all
Topic starter
08/06/2026 4:41 pm
TL;DR: Internal access to APIs, registries, and legacy DNS-based services can be routed through identity-aware controls instead of VPNs, with access decisions enforced by RBAC, labels, and session restrictions before proxying, according to Teleport’s VNet blog. That shift matters because network location no longer tells you who can reach a private resource, which pushes IAM and PAM teams to govern access at the identity layer rather than the network layer.
NHIMG editorial — based on content published by Teleport: 3 VNet use cases to simplify internal access without VPNs
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Teleport's guide to VNet use cases for internal access without VPNs →
VNet for internal access: are your controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
08/06/2026 6:26 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Internal access without VPNs shifts the identity control point
