A breach now takes an average of 241 days to identify and contain, according to IBM’s 2025 Cost of a Data Breach Report, and a US company that gets hit pays $10.22 million on average once regulatory fines and downtime are added up. Most of that damage happens after the initial break-in, once an intruder is already inside the network and free to move sideways toward whatever they actually came for. A traditional VPN does not stop that. It checks you once at the front door, then hands you a wide-open lane to everything else on the subnet.
Zero trust network access flips that model. Instead of trusting anyone who gets past the login screen, it checks identity, device health, and context on every connection, then grants access to one resource at a time instead of an entire network segment. This tutorial builds a working ZTNA setup from the ground up, using Tailscale, a mesh VPN built on the WireGuard protocol with a free tier that now covers a real small team. By the end you will have tagged devices, a least-privilege access policy, locked-down SSH, an exit node for shared internet access, and a monitoring setup you could actually hand to an auditor.
Budget around 100 minutes for the full walkthrough, 15 steps in total. If you want the wider threat picture before diving in, our cybersecurity coverage hub tracks the breaches and CVEs that make this kind of hardening worth the afternoon.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Is Zero Trust Network Access, and Why It’s Replacing VPNs
Zero trust network access, usually shortened to ZTNA, is an access model built around one rule: never trust a connection by default, no matter where it comes from. Every request gets verified on its own terms, using the identity of the person, the health of the device, and the specific resource being requested. Nobody gets blanket access to a network. They get access to the one application or server their role actually requires, and nothing else.
That definition is not marketing language. It traces back to NIST Special Publication 800-207, published in August 2020 by NIST researchers Scott Rose and Oliver Borchert alongside Stu Mitchell and Sean Connelly of DHS. NIST 800-207 lays out zero trust architecture as a shift away from defending a perimeter and toward defending individual resources, since remote workers and cloud services stopped living inside a tidy office network years ago.
Compare that to a classic VPN. Once you authenticate, a VPN typically places you on the same logical network as everything else behind it. An attacker who steals one employee’s VPN credentials, or compromises one unpatched laptop, inherits that same reach. Network segmentation can limit the blast radius, but it is usually coarse, built around subnets rather than individual services, and it rarely accounts for whether the connecting device is actually trustworthy that day.
ZTNA tools solve this with per-resource access control instead of per-network access control. Many of them, including the one this tutorial uses, are built on WireGuard, the lightweight VPN protocol Jason Donenfeld created and merged into the mainline Linux kernel at version 5.6 in March 2020. WireGuard’s small codebase and modern cryptography made it fast enough to run always-on mesh connections between every device in a fleet, which is exactly the plumbing zero trust needs under the hood.
Why Zero Trust Can’t Wait: The 2026 Numbers
The case for zero trust is not hypothetical anymore. It shows up directly in breach economics. IBM’s 2025 Cost of a Data Breach Report puts the global average cost of a breach at $4.44 million, down 9% from $4.88 million the year before, but that average hides a sharp split based on detection speed. Breaches contained inside 200 days cost $3.87 million on average. Breaches that dragged on past 200 days cost $5.01 million, a 29% jump. Organizations that leaned heavily on AI and automation for detection cut their identification and containment time by 80 days and saved $1.9 million per breach compared to those that did not, per the same IBM report.
Adoption is climbing but still lags intent. Roughly 61% of organizations have launched a zero trust initiative of some kind, up from 24% in 2021, based on 2026 zero-trust market research. Gartner’s 2024 survey found 63% of organizations have partially or fully implemented a zero trust strategy, yet Gartner has separately estimated that only 10% of large enterprises will have a mature, measurable zero trust program in place by 2026, up from less than 1% in 2023. CIO.com reported that 81% of organizations plan to adopt zero trust by 2026. Financial services leads sector adoption at roughly 50%, with healthcare around 35% and manufacturing near 25%, according to 2026 industry survey data. Analyst estimates of the market itself vary by definition and scope, but the trajectory is consistent: Mordor Intelligence puts the global ZTNA market at $47.45 billion for 2026, up from $39.58 billion in 2025, and projects an 18.2% compound annual growth rate as adoption continues through the rest of the decade.
Put those numbers together and a pattern emerges. Most security teams agree zero trust matters. Few have actually finished building it. Straits Research puts global ZTNA spend at $4.84 billion for 2026, on a path to $26.52 billion by 2034, a trajectory that only makes sense if the gap between stated intent and actual deployment keeps closing. That gap is usually less about budget and more about the setup feeling too abstract to start. The rest of this tutorial closes that gap with an actual, working configuration.
Choosing a ZTNA Tool: Why This Tutorial Uses Tailscale
Tailscale is not the only way to build zero trust network access, and it is worth knowing the alternatives before committing an afternoon to one of them. The market splits roughly into hosted mesh VPNs, open-source self-hosted options, and enterprise SASE suites that bundle ZTNA with a lot of other networking and security tooling. MarketsandMarkets, defining the ZTNA software segment narrowly rather than folding in adjacent SASE spend, sized it at just $1.34 billion in early 2025 and expects it to reach $4.18 billion by 2030, a 25.5% compound annual growth rate that reflects how much of this space is still genuinely up for grabs among vendors like the ones below.
| Tool | Model | Self-Hostable | Best For |
|---|---|---|---|
| Tailscale | Hosted control plane, WireGuard mesh | No (control plane), yes via Headscale | Small teams wanting the fastest path to a working setup |
| Headscale | Open-source, self-hosted | Yes | Teams that want Tailscale’s client experience without a third-party control plane |
| Cloudflare Access | Hosted, part of Cloudflare’s Zero Trust suite | No | Teams already routing traffic through Cloudflare |
| Teleport | Open-source, infrastructure-focused | Yes | Engineering teams wanting session recording on SSH, Kubernetes, and database access |
| OpenZiti | Open-source ZTNA overlay network | Yes | Teams that want to embed zero trust directly into an application’s networking layer |
This tutorial builds on Tailscale for one practical reason: it gets a working, tagged, policy-enforced mesh network running in under two hours without standing up any extra infrastructure first. Headscale is worth a second look once you outgrow the hosted free tier or need the control plane inside your own network for compliance reasons, since it speaks the same client protocol and most of the commands below carry over directly. Everything from step 9 onward, the actual access control policy, is the part that matters most regardless of which control plane sits underneath it.
Prerequisites: What You Need Before You Start
You do not need an enterprise security budget for this. Tailscale’s free Personal plan was expanded on April 8, 2026, and now covers up to 6 users with unlimited devices, up to 50 tagged resources, and 1,000 ephemeral resource-minutes a month, a big jump from the previous cap of 3 users and 100 devices. That is enough to build and run everything in this tutorial for a real small team, not just a demo.
| Requirement | Version or Tier | Notes |
|---|---|---|
| Tailscale account | Free Personal plan | 6 users, unlimited devices, 50 tagged resources |
| Tailscale client | v1.102.1 or later | Latest stable as of July 31, 2026 |
| Admin devices | 2 or more | At least one laptop and one server or VM |
| Identity provider | Google, Microsoft, GitHub, or Okta | Whichever your team already uses for SSO login |
| Linux server or VM | Ubuntu 24.04 LTS | Used for the subnet router and exit node steps |
| Command line access | Bash or PowerShell | Basic comfort running install scripts |
| Time budget | ~100 minutes | Can be split across two sessions |
One more thing worth deciding upfront: who your identity provider is. Tailscale authenticates users through an existing SSO login rather than its own password system, so whatever multi-factor setup you already have on Google Workspace, Microsoft Entra ID, or GitHub carries straight into your ZTNA setup. If you have not enabled MFA on that account yet, do it before step one. Our passkey setup guide and YubiKey walkthrough both cover hardware-backed options that pair well with this.
Step 1-4: Set Up Your Control Plane and Install the First Node
Step 1: Choose your control plane approach. Every ZTNA mesh needs a coordination service that knows about every device, distributes keys, and pushes policy changes. Tailscale runs a hosted one for free at this tier. If you would rather self-host that layer, the open-source Headscale project implements a compatible control server you can run yourself. This tutorial uses Tailscale’s hosted control plane since it removes an entire piece of infrastructure you would otherwise have to patch and monitor yourself.
Step 2: Create your tailnet and lock down the admin login. Sign up at tailscale.com using your organization’s identity provider, not a standalone email and password. This single login becomes the root of trust for your entire zero trust network, so confirm MFA is already enforced on it before moving on.
Step 3: Install the client on your first device. On Linux, the official install script detects your distribution and sets up the right package repository automatically.
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale upRunning tailscale up prints a login URL. Open it, authenticate through your identity provider, and the device joins your tailnet, Tailscale’s term for your private mesh network. Full install instructions for macOS, Windows, iOS, and Android are in Tailscale’s official install docs.
Step 4: Confirm the node is connected. Run a status check before adding anything else.
$ tailscale status
100.101.102.1 admin-laptop [email protected] linux -
That 100.x address is your device’s stable tailnet IP. It stays the same no matter which physical network the laptop connects through, which is what makes writing access policy against it reliable later.
Step 5-7: Enroll Every Device Across Your Fleet
Step 5: Install the client on employee devices. macOS users can install through the App Store or a signed .pkg, Windows users run the standard installer, and mobile users grab the app from the iOS App Store or Google Play. Each install ends the same way: log in with the company identity provider, and the device appears in your tailnet.
Step 6: Install the client on servers and cloud instances. Headless machines cannot open a browser to click a login link, so generate a reusable auth key from the admin console under Settings, then Keys, and pass it directly.
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --authkey=tskey-auth-xxxxxxxxxxxx --hostname=app-server-01Set auth keys to expire and mark them single-use where possible. A long-lived reusable key that leaks in a CI log defeats the point of everything else in this tutorial.
Step 7: Clean up and verify your device list. Open the admin console’s Machines page and check every entry has a sensible hostname, an owner, and a key expiry date. Rename anything that still says “DESKTOP-4F92JX” before you forget which device it actually is. This list is your real asset inventory now, more accurate than most spreadsheets, since a device cannot fake its presence here.
Step 8-10: Write a Least-Privilege Access Control Policy
Step 8: Map out who needs to reach what. Before writing a single rule, list your resources (web app, database, admin panel, CI runner) and match each one to the people or services that legitimately need it. A simple spreadsheet works fine for this: one row per resource, one column per team or role, a checkmark wherever access is genuinely required. Most teams find at least one row where nobody can explain why a group has access, which is usually leftover from a project that wrapped up months ago. Skip this planning step and you will end up copying an overly broad example policy from a forum post and never tightening it, which is one of the pitfalls covered later in this guide.
Step 9: Write your base access control policy. Tailscale policies live in a single HuJSON file (JSON with comments) edited in the admin console’s Access Controls tab. Start from default-deny.
{
"groups": {
"group:engineering": ["[email protected]", "[email protected]"],
"group:admins": ["[email protected]"]
},
"acls": [
// Engineering can reach the staging web app on 443 only
{"action": "accept", "src": ["group:engineering"], "dst": ["100.101.102.5:443"]}
]
}Everything not explicitly allowed here is denied by default. That single property is what separates zero trust from a flat VPN subnet.
Step 10: Apply and validate the policy. Save the file in the admin console to push it live immediately to every connected device, no restart required. Before trusting it, test both a path that should work and one that should not, which the testing section below covers in more depth. Teams managing policy as code can instead apply the same file through Tailscale’s API or its Terraform provider, keeping the ACL in version control alongside everything else.
Step 11-12: Tag Devices for Micro-Segmentation
Step 11: Define tags in the policy file. Tags are the backbone of micro-segmentation here. Instead of writing rules against individual people or IP addresses, you write them against roles, like tag:webapp or tag:db, and assign devices to those roles. Tailscale’s own ACL policy reference documents every available field if you need something this tutorial does not cover, like time-based rules or app-layer HTTPS filtering.
{
"tagOwners": {
"tag:webapp": ["group:admins"],
"tag:db": ["group:admins"]
}
}Apply a tag to a device at enrollment time with tailscale up --advertise-tags=tag:webapp, or retroactively from the admin console.
Step 12: Rewrite your grants around tags instead of individual devices. This is where micro-segmentation actually happens.
{
"acls": [
{"action": "accept", "src": ["group:engineering"], "dst": ["tag:webapp:443"]},
{"action": "accept", "src": ["tag:webapp"], "dst": ["tag:db:5432"]}
]
}Now the database only ever accepts connections from the web app tier, and the web app tier only ever accepts connections from engineering. Add a new laptop to the engineering group and it inherits the right access automatically. Retire a server and its tag-based permissions disappear with it. Nobody has to remember to update a firewall rule by hand.
Step 13: Lock Down SSH With Identity-Aware Access
Static SSH keys are one of the quiet failure points behind lateral movement. A key gets copied to a laptop, the laptop gets sold or lost, and years later that key still opens a production server. Tailscale SSH replaces key-based access with identity-based sessions authenticated the same way as everything else on your tailnet, then logs each session for later review.
{
"ssh": [
{
"action": "check",
"src": ["group:engineering"],
"dst": ["tag:webapp"],
"users": ["ubuntu", "autogroup:nonroot"],
"checkPeriod": "12h"
}
]
}The check action forces re-authentication through your identity provider every 12 hours, so a stolen session cookie has a short shelf life. Enable it on the server with tailscale up --ssh, then retire your existing authorized_keys entries once you have confirmed the new path works.
Step 14-15: Add an Exit Node and a Subnet Router for Legacy Systems
Step 14: Add an exit node. An exit node routes a device’s general internet traffic through another node on your tailnet, useful for a remote worker who needs to appear on a trusted office IP range.
sudo tailscale up --advertise-exit-node
# On the client that wants to use it:
sudo tailscale up --exit-node=100.101.102.1Step 15: Add a subnet router for legacy, non-Tailscale devices. Not everything can run a client, think printers, older NAS boxes, or an internal appliance nobody wants to touch. A subnet router bridges an entire IP range into the tailnet through one gateway device.
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
sudo tailscale up --advertise-routes=10.0.1.0/24Routes still require manual approval in the admin console before traffic flows, which is intentional. It stops a compromised device from silently annexing a whole subnet into your zero trust network without review.
Enforce Device Posture and Identity Verification
Access control policy only works if you also trust the devices making the requests. Turn on device approval in the admin console so new nodes cannot join the tailnet automatically, someone has to look at each one first. Set key expiry to a sensible default, 90 days is common, so a laptop that vanishes for six months loses access instead of sitting there as a forgotten door into the network.
Reserve disabled key expiry for a short, deliberate list of hardened service accounts, never for a person’s laptop. Pair that with your identity provider’s own device compliance checks, screen lock enabled, disk encryption on, OS patched within some window, if your IdP supports pushing that signal into the login flow. Identity tells you who is connecting. Posture tells you whether their device deserves to.
Review the device list on a schedule, not just when something breaks. A monthly pass through the admin console catches the laptop a departed contractor never actually returned, or the test VM someone spun up in March and forgot about. Zero trust network access degrades quietly if the underlying device inventory drifts out of date, since a policy is only as trustworthy as the list of devices it applies to.
Monitor, Log, and Feed Your SIEM
A ZTNA setup you cannot observe is a policy you cannot prove. Tailscale’s admin console exposes audit logs covering login events, policy changes, and device approvals, plus network flow logs showing which tagged nodes talked to which other tagged nodes and when. Export both through the API to whatever platform already aggregates your logs. If you are choosing that platform, our Microsoft Sentinel vs Splunk vs Elastic comparison breaks down pricing and ingestion at different scales.
Treat these logs the way you would treat any other audit trail: shipped somewhere the source device cannot delete them from, retained on a schedule that matches your compliance obligations, and actually reviewed rather than just collected. Our AWS CloudTrail setup guide covers the same discipline applied to cloud API calls, and the two pair naturally if your infrastructure spans both.
Test Your Policy Before You Roll It Out
Do not trust a policy file just because it saved without an error. Confirm it behaves the way you intended on both sides, the connections that should succeed and the ones that should fail.
# Should succeed: engineering laptop reaching the web app
tailscale ping app-server-01
# Should fail: web app reaching the database directly, bypassing the app tier
tailscale ping db-server-01 --from=another-untagged-device
# Diagnose connectivity quality if a ping is slow or fails unexpectedly
tailscale netcheckIf a connection you expected to be blocked actually succeeds, the default-deny model has a gap somewhere, usually an overly broad tag grant or a leftover rule from an earlier draft of the policy. Fix that before it becomes real traffic, not after.
Migrating From an Existing VPN Without a Big-Bang Cutover
Most teams reading this are not starting from nothing. There is usually an existing VPN appliance, a pile of static firewall rules, and people who have gotten used to how it works, badly or not. Ripping all of that out on a single weekend is how rollouts turn into incidents. Run Tailscale alongside the existing VPN for a defined pilot window instead of replacing it outright on day one.
Start with one team and one application, not the whole organization and not every resource at once. Engineering is usually the easiest pilot group, since they are the most tolerant of a rough edge and the quickest to report one. Move that team’s access to the tagged, policy-based model from steps 8 through 12, leave everyone else on the old VPN, and watch for two things: complaints about broken access (usually a missing ACL rule) and, just as important, silence (which sometimes means nobody actually needed the access they used to have by default).
Expand team by team from there, porting each group’s real access patterns into tags and grants rather than copying the old VPN’s broad permissions wholesale. Keep the legacy VPN’s firewall rules intentionally frozen during this period so you have a known-good fallback if a tagged policy turns out to be missing something nobody thought to map in step 8. Decommission the old VPN last, once every team has been running on the new policy long enough that a rollback would be more disruptive than a fix.
The Complete Working Project: A Small-Team Reference Architecture
Put together, steps 1 through 15 produce a working four-role zero trust network: an admin laptop, engineering laptops, a tagged web app server, and a tagged database server, all governed by one policy file. Here is the consolidated version worth keeping as your starting template.
{
"groups": {
"group:engineering": ["[email protected]", "[email protected]"],
"group:admins": ["[email protected]"]
},
"tagOwners": {
"tag:webapp": ["group:admins"],
"tag:db": ["group:admins"]
},
"acls": [
{"action": "accept", "src": ["group:engineering"], "dst": ["tag:webapp:443"]},
{"action": "accept", "src": ["tag:webapp"], "dst": ["tag:db:5432"]},
{"action": "accept", "src": ["group:admins"], "dst": ["tag:webapp:22", "tag:db:22"]}
],
"ssh": [
{
"action": "check",
"src": ["group:admins"],
"dst": ["tag:webapp", "tag:db"],
"users": ["ubuntu", "autogroup:nonroot"],
"checkPeriod": "12h"
}
]
}Walk through what this actually enforces. Engineering can reach the web app on port 443 and nothing else. Only the web app tier can talk to the database, and only on the Postgres port. Only admins can SSH anywhere, and even then their session expires every 12 hours. Nobody has standing access to anything they are not actively using, which is the entire point of zero trust network access: access that exists only for as long as it is needed, scoped to exactly the resource it was granted for.
Zero Trust Network Access vs. Traditional VPN
| Factor | Traditional VPN | ZTNA |
|---|---|---|
| Trust model | Trust once, at login | Verify continuously, per request |
| Access granularity | Whole subnet or network | Individual application or service |
| Lateral movement risk | High once inside | Low, default-deny between resources |
| Device posture checks | Rarely enforced | Built into the access decision |
| Setup complexity | Moderate, hardware or gateway often needed | Moderate, mostly software and policy |
| Typical cost for a small team | $0-$500/month for appliances or licenses | Free tier available, scales per user |
| Auditability | Coarse connection logs | Per-resource flow logs and SSH session logs |
| Legacy device support | Native | Requires a subnet router bridge |
Neither model is obsolete. Plenty of teams run a subnet router bridging legacy gear precisely so they can retire the old VPN appliance entirely rather than run both side by side.
Common Pitfalls When Rolling Out Zero Trust Network Access
- Shipping a default-allow policy and never tightening it. A policy that grants broad access “just to get started” has a way of becoming permanent. Start from deny and add exceptions deliberately.
- Treating tags as a one-time setup. Tags need owners and a review cadence, otherwise a server gets retagged for a one-off test and keeps elevated access for a year.
- Skipping key expiry on personal devices. A laptop with a non-expiring key is a standing credential nobody is watching.
- Ignoring device posture. An unpatched, unencrypted laptop with valid identity credentials is still a risk, identity alone is not enough.
- Leaving MFA off the identity provider tied to the control plane. Every device’s access ultimately traces back to that one login. Protect it accordingly.
- No monitoring or log export. Without exported logs you cannot detect anomalies or prove compliance after the fact.
- Rolling out to the whole organization in one go. Pilot with one team, fix the ACL mistakes that only show up in real use, then expand.
Troubleshooting: 9 Common ZTNA Problems
Connectivity Problems
- Devices can’t see each other on the tailnet. Usually restrictive NAT on one side. Run
tailscale netcheckon both ends, traffic falls back to a relay (DERP) automatically, which works but adds latency. - High latency instead of a direct connection. Check
tailscale pingoutput for “via DERP” versus a direct peer address. Symmetric NAT or a blocked UDP port is the usual cause. - MagicDNS not resolving hostnames. Confirm MagicDNS is enabled in the admin console’s DNS tab and that the client has fully reconnected since enabling it.
- A device stuck offline after a key expiry. Re-authenticate it manually with
tailscale up, then extend or disable expiry only for accounts that genuinely need it.
Policy and Permission Problems
- ACL syntax errors blocking a policy push. The admin console’s editor validates HuJSON before saving. Read the inline error, it usually points at a missing comma or an unclosed bracket.
- A tagged device isn’t getting the right permissions. Confirm the tag was actually applied with
tailscale status, and that a matching ACL rule references that exact tag name, typos here fail silently. - Tailscale SSH connection refused. Confirm
--sshwas passed when the node came up, and that your ssh block’s src and dst match the connecting user’s group and the target’s tag.
Routing Problems
- Exit node traffic not routing correctly. Confirm IP forwarding is enabled on the exit node itself, not just on the client trying to use it.
- Subnet routes not being accepted. Routes require manual approval in the admin console even after being advertised. Check the Machines page for a pending-approval badge.
Advanced Tips for Scaling Beyond the Basics
Once the core setup is stable, a few upgrades pay off as the team grows. Turn on SCIM provisioning from your identity provider so new hires and departures sync automatically instead of relying on someone remembering to update the tailnet by hand. Teams running Kubernetes can use the official Tailscale operator to expose cluster services over the tailnet without a separate ingress controller. Tailscale Funnel and Serve let you publish one internal app to the public internet, or share it with a single teammate, without opening a firewall port or standing up a reverse proxy.
For CI/CD, generate ephemeral auth keys scoped to ten minutes and tagged specifically for build runners, so a compromised pipeline credential expires almost immediately instead of lingering. And treat your ACL file like application code: keep it in version control, run policy checks in CI before merging a change, and require review on any pull request that touches it. A ZTNA policy that anyone can edit unreviewed is not really zero trust.
Revisit the network flow logs from the monitoring section every so often with a simple question in mind: does this pattern of traffic still make sense? A service account suddenly reaching a resource it has never touched before, or a laptop connecting at 3 a.m. from a tag it was never assigned, is exactly the kind of anomaly a flat VPN log would bury in noise. Because zero trust network access logs traffic per tagged resource instead of per subnet, that kind of deviation stands out on its own instead of requiring a dedicated anomaly-detection tool to surface it.
Frequently Asked Questions
Is zero trust network access the same thing as a VPN?
No. A VPN typically grants access to a whole network segment after one login. ZTNA grants access to individual resources and re-verifies identity and device context on an ongoing basis. Many ZTNA tools, including Tailscale, use VPN protocols like WireGuard as the underlying transport, but the access model on top is different.
Do I need an enterprise product to implement zero trust?
No. This tutorial runs entirely on a free tier. Larger organizations often add enterprise ZTNA or SASE platforms for features like deep packet inspection or compliance reporting, but the core access model works at any budget.
How much does Tailscale cost for a small team?
The free Personal plan covers up to 6 users with unlimited devices, up to 50 tagged resources, and 1,000 ephemeral resource-minutes a month as of the April 2026 pricing update. Paid tiers add centralized billing, longer log retention, and SSO enforcement for larger teams.
Can ZTNA work with legacy, on-premises systems?
Yes, through a subnet router, covered in step 15. It bridges an entire legacy IP range into the tailnet through one gateway device, so equipment that cannot run a client is still reachable under the same policy.
What’s the difference between ZTNA and SASE?
ZTNA is the access control model itself. SASE (secure access service edge) is a broader category that bundles ZTNA with additional networking and security functions, like a cloud firewall and secure web gateway, delivered from the same platform. You can run ZTNA on its own, as this tutorial does, without adopting a full SASE stack.
Does zero trust eliminate the need for a firewall?
No. ZTNA controls who can reach a given resource over the tailnet. A firewall still has a role filtering unrelated traffic at the network edge, especially on servers exposed to the public internet independent of your tailnet.
How long does a full rollout take for a real organization?
The technical setup in this tutorial takes about 100 minutes. A full organizational rollout, including a pilot team, policy refinement, and training, typically takes several weeks to a few months depending on headcount and how many legacy systems need subnet routers.
What happens if the control plane goes down?
Devices that are already connected keep their existing peer-to-peer connections and cached policy for a period of time even if the coordination service is briefly unreachable. New device enrollment and policy changes pause until it recovers. Organizations with strict uptime requirements can evaluate a self-hosted control plane like Headscale as an alternative.
Is zero trust overkill for a five-person startup?
No, and it is arguably easier at that size than at 500 people. A five-person team can tag every resource and write a complete access policy in an afternoon, before technical debt and undocumented exceptions have a chance to accumulate. Waiting until headcount forces the issue just means retrofitting a policy onto infrastructure nobody fully remembers configuring.
Does zero trust network access help with compliance frameworks like SOC 2 or CMMC?
Yes. Least-privilege access, MFA-backed identity checks, and audit logging map directly onto access-control requirements in SOC 2 and the Department of Defense’s CMMC 2.0 framework, both of which increasingly expect evidence of continuous verification rather than a one-time perimeter check. A tagged ACL policy and exported audit logs give an auditor something concrete to review instead of a policy document describing intentions.
Treat the policy file from this tutorial as a living document, not a project you finish once. Revisit the access map from step 8 every quarter, prune tags nobody uses, and expand the pilot from a single team into the rest of the organization once its traffic settles down. This isn’t a passing trend to wait out either: ForInsights Consultancy, using the broadest definition of the market that includes adjacent SASE spend, tracked ZTNA at $51.59 billion in mid-2025 and projects $221.09 billion by 2034, a 26.5% compound annual growth rate. Zero trust network access works less like a product you install and more like a habit you keep, and the setup above gives you a working starting point that beats the file cabinet of standing VPN permissions it replaces.
Related Coverage
- How to Set Up a YubiKey: 13 Steps, 60 Min [2026]
- How to Set Up Passkeys: 13 Steps, 90 Min [2026]
- How to Set Up Vaultwarden: 12 Steps, 80 Min [2026]
- Microsoft Sentinel vs Splunk vs Elastic: $24K-250K [2026]
- How to Set Up AWS CloudTrail: 13 Steps, 70 Min [2026]
- CrowdStrike vs Defender vs SentinelOne: 100% MITRE [2026]
