Topic starter
14/09/2026 10:10 am
TL;DR: Built-in router and NAS VPNs can work for small, static environments, but the article argues they break down on reliability, performance, security, and administration as teams grow, according to Tailscale. The practical issue is not encryption alone, but whether access can be governed, revoked, and scaled without creating a separate identity and network-control burden.
Editorial analysis by NHI Mgmt Group, based on content published by Tailscale: “Your built-in router VPN might be more trouble than it's worth”.
Key questions
Q: What breaks when router-based VPN access is managed with static profiles?
A: Static VPN profiles break governance first and connectivity second.
Q: Why do appliance VPNs become a risk when remote access scales?
A: They become risky because the same small device is doing too many jobs at once: routing, storage, tunnelling, and access control.
Q: How can security teams tell whether built-in VPN administration is failing?
A: Look for stale profiles, ad hoc allowlists, users sharing access credentials, and administrators handling access changes outside the main identity system.
Practitioner guidance
- Map remote access to identity lifecycle Ensure VPN access is granted, reviewed, and revoked through the same identity process used for email, collaboration, and application access.
- Measure appliance limits before rollout Test concurrent remote sessions, upload throughput, and failover behaviour under real usage instead of assuming the router or NAS can carry production access.
- Remove static profile sprawl Replace individually distributed VPN profiles and IP allowlists with centrally managed group-based policy so access can change when roles change.
Bottom line: Built-in router and NAS VPNs often create a second access system that is harder to govern than the identity stack teams already use.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/09/2026 10:11 am
Built-in VPNs create an access-governance problem, not just a connectivity problem. The article’s core point is that tunnelling alone does not equal governed access. Once access is expressed as static VPN profiles and IP allowlists, the remote-access layer stops behaving like part of identity governance and starts behaving like an isolated network exception. Practitioners should evaluate remote connectivity as an access-control system, not a transport feature.
A question worth separating out:
Q: Should remote access permissions live in the identity system or the network device?
A: They should live in the identity system whenever possible. Identity-backed access lets joiners, movers, and leavers follow the same lifecycle as other enterprise access, while a network-device model forces manual cleanup and creates a second authority that can easily drift from source-of-truth records.
👉 Read our full editorial: Built-in router VPNs create governance drag for small teams