Notifications
Clear all
Topic starter
30/07/2026 10:51 pm
TL;DR: VPNs can be sufficient for small user groups, but they create coarse access, stale credentials, and incomplete audit data as environments grow, according to Teleport. Identity-based access shifts enforcement to per-application policy and named-identity audit trails, which aligns better with least privilege and compliance expectations.
NHIMG editorial — based on content published by Teleport: How to Access Internal Web Apps Without a VPN
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
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 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
- Map every internal app to an explicit authorization policy Inventory which apps are still reachable through broad VPN profiles, then define the exact identity groups, device conditions, and request paths that should be allowed for each application.
- Eliminate shared VPN credentials for application access Replace shared or group-level access patterns with named identities and app-scoped policy so revocation affects a single subject instead of an entire credential pool.
- Verify that audit logs show app-level actions Check whether logs record only connection metadata or whether they also capture the application, session timing, and actor identity needed for security review and compliance evidence.
What's in the full article
Teleport's full blog post covers the operational detail this post intentionally leaves for the source:
- Practical walkthrough of how the identity-aware proxy sits in front of internal web applications
- Examples of how browser-based access changes support and rollout burden for internal app users
- Discussion of how per-app least-privileged access is enforced and audited in Teleport's model
- Broader product context for how internal web apps fit alongside SSH, Kubernetes, and database access
👉 Read Teleport's guide to VPN-free internal web app access →
VPN-free internal web apps: what changes for IAM teams?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
30/07/2026 10:55 pm
VPNs fail as identity controls because they were built as network controls. Once access decisions are reduced to subnet membership and profile mapping, least privilege becomes a maintenance exercise rather than an enforcement model. That is why coarse VPN design so often survives only because nobody can economically maintain the finer segmentation it would take to make it safe. Practitioners should treat the gap as a control-model mismatch, not just a tooling limitation.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
A question worth separating out:
Q: Who should own the decision to move from VPN-based access to identity-based access?
A: IAM, security architecture, and compliance teams should own it together because the decision affects authorization design, logging quality, and access review evidence. The trigger is usually not a single feature gap but the point where auditability and least privilege no longer hold under the current VPN model.
👉 Read our full editorial: VPN-free internal web app access shifts control to identity
