Notifications
Clear all
Topic starter
23/06/2026 7:09 pm
TL;DR: VPNs hide IP addresses and encrypt traffic, but they do not eliminate tracking, endpoint risk, or the broader trust assumptions built into remote access, according to DigiCert. For identity teams, the real question is how VPN use fits into access governance, device trust, and zero-trust control design.
NHIMG editorial — based on content published by DigiCert: What is a VPN?
Questions worth separating out
Q: How should security teams govern VPN access in a zero-trust model?
A: Security teams should treat VPNs as one transport control inside a broader zero-trust design, not as the trust decision itself.
Q: When does VPN use create more risk than it reduces?
A: VPN use creates more risk when it becomes a shortcut to broad internal access, especially for users, contractors, or admins who do not need full network reach.
Q: What do security teams get wrong about VPN privacy?
A: Teams often overstate what VPN privacy actually delivers.
Practitioner guidance
- Classify VPNs as a transport layer control Document VPNs in your access architecture as encrypted transit, not as proof of user or device trust.
- Retire weak or legacy tunnelling protocols Inventory PPTP and any similar legacy configurations, then create a deprecation path to modern protocols with stronger cryptography and supportability.
- Separate privacy claims from security guarantees Update user guidance so VPN communications explain what is protected in transit and what still remains visible through browser history, cookies, and application logs.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- Protocol-by-protocol explanation of PPTP, L2TP, and OpenVPN setup choices
- Consumer-facing privacy and browsing use cases for home users and casual remote access
- Practical notes on free versus paid VPN services and where each tends to fit
- A short comparison between VPNs and Tor for users who want anonymity rather than private transport
👉 Read DigiCert's guide to VPNs, protocols, and privacy trade-offs →
VPNs and identity trust gaps: are your controls keeping up?
Explore further
25/06/2026 3:00 am
VPNs are a transport control, not an identity control. The article correctly describes encrypted tunnelling and IP masking, but those properties do not answer the harder governance question of who should have access under what conditions. That distinction matters because identity programmes still need authentication, device trust, least privilege, and revocation discipline. A VPN may reduce exposure on the wire, but it does not govern entitlement. Practitioner conclusion: remote access architecture should be evaluated as part of the identity stack, not as a substitute for it.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why VPN-centric thinking cannot substitute for identity governance.
A question worth separating out:
Q: How should organisations decide between VPNs and application-level access controls?
A: Organisations should prefer application-level access controls when the goal is to limit who can reach specific resources without exposing the whole network. VPNs can still have a role for legacy systems or secure transport, but they should not be the only control. The best design is usually narrow access, strong identity checks, and minimal network exposure.
👉 Read our full editorial: VPNs solve privacy, but not the identity trust problem
