Topic starter
30/07/2026 10:51 pm
TL;DR: Teleport argues that VPNs still work for small user groups, but they create coarse access, stale credentials, and incomplete audit trails as environments grow. Identity-based access shifts enforcement to per-application policy and named-identity logs, which better matches least privilege and compliance expectations.
Editorial analysis by NHI Mgmt Group, based on content published by Teleport: “How to Access Internal Web Apps Without a VPN”.
Key questions
Q: When should teams move from VPN access to identity-based access for internal web apps?
A: Teams should move when VPN profiles have become broad enough that users can reach far more than their job requires, or when audit evidence no longer shows which app was accessed.
Q: Why do VPNs create audit and compliance problems for internal apps?
A: VPNs often log that a user connected, but not which application they used or what they did inside it.
Q: What breaks when internal web access is controlled only through network profiles?
A: Broad profiles usually allow far more reach than a user actually needs, and tightening them manually leads to ACL drift, operational overhead, and inconsistent access boundaries.
Practitioner guidance
- Define app-level access boundaries Map each internal web app to the smallest identity or role set that actually needs it, instead of granting broad network membership.
- Replace subnet trust with request-time policy Place a proxy in front of internal apps so authorization happens on every request, not when the user joins the network.
- Eliminate shared VPN credentials Move away from credentials that outlive their intended use window and are reused across groups, especially where revocation currently requires group reissuance.
Bottom line: VPN access is often acceptable at small scale, but it becomes too coarse once organisations need app-specific control, stronger evidence, and tighter privilege boundaries.
What's in the full article
Teleport's full blog post covers the operational detail this post intentionally leaves for the source:
- The exact browser-based access flow for internal apps behind an identity-aware proxy
- The practical comparison between VPN-connected users and users who never join the internal network
- How named-identity audit logs map to compliance requirements such as SOC 2 and ISO 27001
- The access setup considerations for mixed technical and non-technical user populations
👉 Read Teleport's guide on VPN-free internal web app access →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
30/07/2026 10:55 pm
VPN access is a network convenience model, not an application governance model. The article shows that VPNs can be workable for small, stable user groups, but they become too blunt once access needs diversify. The deeper issue is not transport, but the fact that the control boundary sits at the network edge instead of the application boundary. Practitioners should treat that as a governance mismatch, not just a tooling preference.
A question worth separating out:
Q: How should IAM teams compare VPN access with identity-aware proxy access?
A: Compare them by the unit of control, the quality of the audit trail, and the amount of standing network reach they create. VPNs optimise broad connectivity, while identity-aware proxies optimise per-app authorization. For internal web apps, the better model is the one that reduces reachable surface without sacrificing named-user accountability.
👉 Read our full editorial: VPN-free internal web app access shifts control to identity