Notifications
Clear all
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.
NHIMG editorial — based on content published by Tailscale: Your built-in router VPN might be more trouble than it's worth
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams govern router VPN access as user counts grow?
A: Treat every VPN profile as an access entitlement with an owner, scope, and expiry.
Q: Why do built-in VPNs create more risk when teams rely on static profiles?
A: Static profiles tend to outlive the people and devices they were created for, which creates entitlement drift.
A: When access depends on a traditional VPN, user experience and control quality can both degrade.
Practitioner guidance
- Map VPN profiles to named owners Inventory every router or NAS VPN profile and attach a business owner, device owner, or service owner so offboarding can be enforced rather than guessed.
- Eliminate shared access profiles Replace reuse of one profile for multiple people with individually assigned access and role-based policy so a single credential does not become a shared backdoor.
- Review IP-based allowlists Audit whether access is still controlled by static IP lists and narrow those rules to the smallest viable resource set for each user or group.
What's in the full article
Tailscale's full article covers the operational detail this post intentionally leaves for the source:
- A side-by-side explanation of reliability problems with router and NAS VPN servers in restrictive networks
- Practical performance trade-offs between server-based VPNs, split tunnelling, and direct peer-to-peer connectivity
- Examples of centralised access administration using identity-provider-backed groups and grants
- Configuration detail for exit nodes, subnet routers, and MagicDNS
👉 Read Tailscale's analysis of built-in router VPN limits and access governance →
Router VPNs and NAS tunnels: what are teams actually missing?
Explore further
14/09/2026 10:11 am
Built-in VPNs turn network access into an identity governance problem. The article’s core point is not that router VPNs are insecure by default, but that they create a separate access lifecycle with issuing, scoping, and revocation overhead. Once access is managed through profiles, the same governance failures seen in weak IAM programmes can appear in a network tool. Practitioners should treat those profiles as governed identities, not convenience settings.
A question worth separating out:
Q: What is the difference between centralised identity-based access and router profile access?
A: Centralised identity-based access ties permissions to a user or group that can be reviewed and revoked in one place. Router profile access ties permissions to device-local credentials and manual configuration, which fragments control. The first supports governance, while the second tends to create hidden access paths and slower offboarding.
👉 Read our full editorial: Built-in router VPNs create governance drag for small teams
