Updated 23 August 2026 — this article was rewritten with primary sources added and unsupported claims removed.
Replacing a corporate VPN with Tailscale is not really an infrastructure job, which is why it is possible without a sysadmin. The installation takes minutes. The part that takes thought is that a traditional VPN hands out the network, and Tailscale hands out access to named things — so somewhere in the migration you have to write down who is allowed to reach what. Most of the difficulty people hit is that nobody had ever written it down.
Decide what you are actually replacing
Start by listing the services people currently reach through the VPN: a database, an internal dashboard, a NAS, a couple of staging boxes. That list is the deliverable. A conventional VPN made it unnecessary because connecting put you on the LAN and everything on the LAN was reachable — the implicit policy was employees get the whole network, which is precisely the assumption modern access architecture is built to remove.
That framing is not a vendor invention. NIST’s zero trust architecture publication defines the model in which access is granted per-resource and per-session rather than by network location (NIST SP 800-207). Tailscale is one implementation of that idea; the list you just wrote is the resource inventory it needs.
The order that avoids locking yourself out
Do it in this sequence, because two of these steps are hard to reverse from the wrong side of a closed door.
First, install on your own machine and one target. Sign in with the identity provider you already use — that is the point, since accounts are then created and revoked where they already are. Confirm the two devices can reach each other before anything else changes.
Second, put the internal service behind it while leaving the old VPN running. Overlap is cheap and a cutover you cannot roll back is not. Only after the new path works for a real user on a real task should the old one come down.
Third, write the policy before you add the rest of the team. Adding people first and restricting later means running an open network in the interim, and it is the stage where most small migrations quietly stop.
Fourth, turn on device approval so a stolen credential alone cannot introduce a new machine. It is a setting, not a project.
The policy file is the actual product
Everything durable about the migration lives in the tailnet policy file. One detail is worth knowing before you copy an example from a blog post: Tailscale has moved to a newer syntax called grants, and states that ACLs “will not receive any new features” while continuing to work indefinitely (Tailscale documentation). Anything written today should use grants; older tutorials will show you the first-generation syntax without mentioning that it is frozen.
Write the policy in terms of tags rather than people. Tag a machine tag:db and grant a group access to that tag, and the rule survives the machine being rebuilt and the person leaving. Rules that name individual devices need editing every time reality changes, which means eventually they stop matching it.
The setting that changes the trust model
There is one feature worth understanding rather than just enabling, because it answers the obvious objection to any coordination-server design: what if the vendor is compromised? Tailnet Lock has trusted nodes in your network cryptographically sign new nodes, so you are not relying on the coordination server to distribute keys honestly. Tailscale’s own description is unusually direct — with it enabled, “even if Tailscale were malicious or Tailscale infrastructure hacked, attackers can’t send or receive traffic in your tailnet” (Tailscale documentation).
That is a meaningful claim and worth verifying against your own threat model rather than accepting on trust. If you are running anything where vendor compromise is a real concern, this is the control that addresses it, and it is off by default.
What to read, and in what order
- NIST SP 800-207, Zero Trust Architecture — the vendor-neutral definition of the model. Read the first two sections before evaluating any product that uses the phrase, so you can tell implementation from marketing.
- Tailscale policy file documentation — start here, and note the grants-versus-ACLs distinction before you copy any example you find elsewhere.
- Device approval — the control that stops a valid login from silently adding an unknown machine. One of the few settings worth changing on day one.
- Tailnet Lock — how to stop trusting the coordination server for key distribution. Relevant only if vendor compromise is in your threat model, but decisive if it is.
- The WireGuard protocol paper — the transport underneath. Worth skimming to understand why the tunnels are cheap enough to be always-on, which is what makes per-service access practical.
- RFC 8445, Interactive Connectivity Establishment — the NAT-traversal problem being solved when two machines connect directly. Useful when a connection refuses to go peer-to-peer and you need to reason about why.
Two adjacent problems are worth reading alongside this. Phishing-resistant authentication is the control that survives a user doing everything else wrong, which matters because QR-code phishing is designed to move the login onto an unmanaged phone. And the harder question underneath any vendor-run coordination service is verification: what a closed-source tool transmits is not something a customer can independently check.
Where this does not fit
Two cases genuinely argue for keeping a conventional VPN. If you need to reach appliances that cannot run an agent — older network hardware, some industrial equipment — you will be running a subnet router and inheriting some of the flat-network problems you were trying to leave. And if a compliance regime specifically requires a network boundary rather than per-resource authorisation, an auditor may not accept the substitution regardless of its technical merits.
Neither is a reason to avoid the migration for everything else. But both are reasons to check before you tell people the old VPN is going away.
