TL;DR

This guide reflects common findings from security assessments of Tailscale deployments. Your network architecture and threat models will vary. Adapt these recommendations to your specific environment.

We read through many pages of Tailscale’s documentation and hardening practice guides to put this guide together, along with a CLI tool, tailsnitch, to help audit your configurations before penetration testers do.

Most growth-stage SaaS organizations face opportunistic attackers, not nation-states (or red teams) — yet. So calibrate your investment accordingly. Look at your Tailscale environment and do the following: replace the default permit-all ACL with explicit port-specific rules, add deny tests that block ACL changes exposing production databases, and set up webhooks so you know when your configuration changes.

If you're selling to enterprise, your ACL is basically audit evidence, so treat it that way. The many other things you can do to harden (segmentation, device posture checks, JIT access, Tailnet Lock) are valuable but should be prioritized based on your actual threat model and operational capacity.

What’s Your Actual Threat Model?

Before touching your ACL configuration, answer these things:

1. Who’s realistically coming after you?

Most growing B2B SaaS companies face opportunistic criminals and occasionally targeted cybercrime. If you’re not in a sensitive industry or handling lots of sensitive data, you’re probably not dealing with nation-state actors - though you will be dealing with pentesters.

Opportunistic criminals hit anyone with exposed services or leaked credentials—automated scanning, credential stuffing, commodity malware.

Targeted cybercrime groups go after companies with valuable data or ransom capacity using spear phishing, purchased access, and living-off-the-land tools.

Competitors and industrial espionage target trade secrets and customer lists through social engineering and insider recruitment.

Nation-state adjacent actors focus on defense contractors and critical infrastructure with supply chain attacks, zero-days, and long-term persistence.

2. Are you selling to enterprise customers?

Doesn’t matter who’s coming after you if you’re going after big fish. Sophisticated enterprise security reviewers ask:

• How do you segment access to customer data?
• What controls prevent a compromised developer from accessing production?
• How do you detect unauthorized access to your infrastructure?
• Show us your network access policies and how you enforce least privilege.

Your Tailscale configuration becomes audit evidence. A default permit-all ACL will generate findings and delays. Treat the hardening in this guide as a business requirement, not a security nice-to-have.

Threat actors are actively using Tailscale in malware campaigns—pairing it with RDPWrapper for persistent remote access, connecting compromised hosts to attacker-controlled networks, and using it alongside kernel driver exploits. The binary is legitimate and signed, so traditional AV doesn’t flag it. Your security controls need to account for authorized tools being weaponized.

Easy Things to Misunderstand

ACLs Are Enforced at the Destination

Tailscale ACLs are directional and define: "source X can initiate connections to destination Y on port Z." ACLs are enforced at the destination device — when a connection arrives, the destination checks: "Is this incoming connection from a permitted source?" If not, it's dropped.

This matters because a compromised device retains all the permissions its owner already has. The attacker doesn't need to pivot through bastion hosts or proxy through segmented networks — they connect directly to whatever the ACLs already permit. They can scan from the compromised machine, trying every port on every reachable host.

Write ACLs assuming the source device is compromised.

Subnet Routers Expose Everything Behind Them

Subnet routers act as gateways between your tailnet and networks where you can’t (or don’t want to) install the Tailscale client on every device - think AWS VPCs, legacy infrastructure, printers, or managed services like RDS. They extend your tailnet’s reach while respecting your ACLs, but they’re also high-value targets: compromise one router advertising a /16, and you can reach everything behind it.

A single subnet router advertising 10.0.0.0/16 can turn a compromised laptop into a pivot point for your entire AWS VPC - databases, internal services, everything on that network segment.

Endpoint Logs Can Be Spoofed

Tailscale’s network flow logs are generated by individual nodes without validation. The documentation explicitly states this information can be spoofed by malicious nodes. If your detection relies solely on endpoint logs, a sophisticated attacker can evade it. You could compare logs from infrastructure you trust (servers, subnet routers) against logs from endpoints - any discrepancies would indicate tampering. But this is theoretical for most organizations.

Threat Scenarios and Appropriate Responses

A) Opportunistic Attack via Phished Developer

A commodity malware or initial access broker compromises a developer laptop through phishing. The attacker then uses an existing Tailscale session to scan an internal network.

They’re using automated tools, limited time before moving to next target, and have no specific knowledge of your environment.

What stops them

• Explicit ACLs that deny access to production (they can’t reach the important things)
• Port-specific rules (scanning finds nothing open)
• Increased friction causes them to move on

Required hardening

• Replace the default ACL with deny-all baseline
• Set explicit, port-specific rules for dev/staging
• Block standing production access for developer devices (use tests - read on)

These are table stakes. If you do nothing else, do this.

B) Targeted Attack on Your Infrastructure

A cybercrime group specifically targeting your company - maybe for ransomware, maybe because you have valuable customer data. They’ve done reconnaissance and know your tech stack.

Realistically, they’re using some custom phishing methods, persistence mechanisms, lateral movement tools, and a willingness to spend days or weeks in your environment.

What stops them

• Network segmentation that limits the blast radius of compromise
• Alerts that catches unusual access patterns, behavior, configuration changes
• Access controls that require elevation for sensitive resources
• Posture checks that block access when endpoint security flags issues

Required hardening (in addition to Scenario A)

• Function-based segmentation (frontend devs can’t reach backend infrastructure)
• Device posture integration with your EDR
• Webhook-based alerting on management plane changes
• ACL tests that prevent accidental exposure
• Webhooks to alert you for unusual actions

C) Sophisticated Actor or Compliance-Driven Security

Either you’re facing a sophisticated adversary (nation-state adjacent, well-resourced industrial espionage, or maybe a red team) or your compliance requirements demand defense-in-depth regardless of any immediate threat.

You now get to address supply chain attacks, zero-days, insider threats, long-term persistent access, and the concern of compromise to Tailscale’s infrastructure itself.

What stops them

• Removing Tailscale from the trust chain (Tailnet Lock)
• Cryptographic device verification
• Extensive monitoring and anomaly detection
• Assume-breach architecture

Required hardening (in addition to Scenarios A and B)

• Tailnet Lock with customer-controlled signing nodes
• App connectors replacing subnet routers where possible
• Cross-referenced logging between endpoints and servers
• Regular access reviews and penetration testing

Hardening Implementation by Priority

Non-Negotiables

Replace the default ACL

The default policy—"src": ["*"], "dst": ["*:*"] means every device can reach every other device on every port. This configuration will show up in your pentest reports and audit.

{
  "groups": {
    "group:engineering": ["alice@company.com", "bob@company.com"],
    "group:devops": ["charlie@company.com"]
  },
  "tagOwners": {
    "tag:dev": ["autogroup:admin"],
    "tag:staging": ["autogroup:admin"],
    "tag:prod": ["autogroup:admin"]
  },
  "acls": [
    // Engineering: specific ports on dev resources
    {
      "action": "accept",
      "src": ["group:engineering"],
      "dst": ["tag:dev:443", "tag:dev:8080", "tag:dev:3000"]
    },
    // Engineering: limited staging access
    {
      "action": "accept",
      "src": ["group:engineering"],
      "dst": ["tag:staging:443"]
    },
    // DevOps: broader staging access
    {
      "action": "accept",
      "src": ["group:devops"],
      "dst": ["tag:staging:22", "tag:staging:443", "tag:staging:5432"]
    },
    // Production: DevOps only, and consider removing standing access entirely
    {
      "action": "accept",
      "src": ["group:devops"],
      "dst": ["tag:prod:22", "tag:prod:443"]
    }
  ]
}

Common mistake to avoid

// This looks restrictive but still exposes all ports
{"src": ["group:engineering"], "dst": ["tag:prod:*"]}

Add deny tests for critical boundaries

This is super valuable and probably no one uses it. Tests run on every ACL change and if they fail, the change is rejected. This is an awesome feature.

{
  "tests": [
    // Production database must never be accessible to engineering
    {
      "src": "group:engineering",
      "deny": ["tag:prod-db:5432", "tag:prod-db:3306", "tag:prod-db:22"]
    },
    // Anti-lockout: DevOps must always reach bastion
    {
      "src": "group:devops",
      "accept": ["tag:bastion:22"]
    }
  ]
}

If someone accidentally broadens an ACL in a way that exposes production databases, the deploy fails. This is an awesome feature.

Don’t auto-approve subnet routes

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:vpc-router"]  // Only specific tagged infra can advertise
    }
  }
}

Don’t allow autogroup:member to auto-approve routes - everyone’s a member and you want to know when someone advertises a new subnet.

Audit your configuration before someone else does

We wrote tailsnitch to scan your tailnet for misconfigurations, overly permissive access controls, and security best practice violations. Run it before someone else finds the same issues in a less friendly format.

# Scan your current configuration
tailsnitch scan

This catches the obvious mistakes: wildcard port access (tag:prod:*), overly broad subnet route auto-approval, missing deny tests for sensitive resources. It won’t replace a proper security review, but it will flag the low-hanging fruit.

Meaningful Segmentation

Segment by function, not just environment, using tags

{
  "tagOwners": {
    "tag:frontend-dev": ["autogroup:admin"],
    "tag:backend-dev": ["autogroup:admin"],
    "tag:data-infra": ["autogroup:admin"]
  },
  "acls": [
    {
      "action": "accept",
      "src": ["group:frontend"],
      "dst": ["tag:frontend-dev:443", "tag:frontend-dev:3000"]
    },
    {
      "action": "accept",
      "src": ["group:backend"],
      "dst": ["tag:backend-dev:443", "tag:backend-dev:8080"]
    }
  ]
}

A compromised frontend developer's laptop shouldn’t be able to reach the backend infrastructure. Segmentation limits blast radius. Same lessons everyone largely ignores in standard networks. This is much easier in json, and makes a serious difference when an attacker has compromised some node.

Enable device posture checks if you have EDR.

If you’re paying for CrowdStrike/SentinelOne/Defender/Intune/JAMF, connect it:

"grants": [
  {
    // Only requirement to access development servers is Mac + stable Tailscale
    "src": ["autogroup:member"],
    "dst": ["tag:development"],
    "ip": ["*"],
    "srcPosture": ["posture:anyMac"]
  },
  {
    // Only devs can access production
    // and production access requires macOS is also up to date
    "src": ["group:dev"],
    "dst": ["tag:production"],
    "ip": ["*"],
    "srcPosture": ["posture:latestMac"]
  }
]

If EDR flags a device as compromised, network access is deauthorized or disabled automatically. This is the primary control against compromised endpoints actually being useful to attackers.

Time-Limited Production Access

Standing production access is the default because it’s easy. The goal is to make non-standing access easy enough that people actually use it. But be honest about what you’ll actually maintain. There are a spectrum of options:

Option: Manual process with teeth

A documented manual process that people follow beats a broken automation that everyone bypasses.

• Dedicated group:crownjewel-access that’s normally empty
• Request in Slack/ticketing system with business justification
• Admin adds user, sets a calendar reminder to remove
• Remove after the window (4 hours, end of incident, whatever)
• Audit monthly: anyone in the group who shouldn’t be?

This really only works if you have enough process discipline that calendar reminders get honored, and someone actually does the monthly audit.

Option: IdP-driven group sync

If your identity provider supports time-limited group membership (Okta, Azure AD, Google Workspace with the right setup), use that as your source of truth and sync to Tailscale groups.

• Access request goes through IdP’s workflow
• IdP adds user to group with automatic expiration
• Tailscale syncs the group membership
• Access disappears when IdP removes them

This might work if you’ve invested in your IdP and actually use its access management features.

Option: Set a device posture with expiring attributes

{
  "postures": {
    "posture:oncall-active": [
      "custom:oncallExpiry": "now()+8hr"
    ]
  }
}

Your PagerDuty/Opsgenie integration sets custom:oncallExpiry when someone gets paged. Access expires automatically.

This might work if your on-call tool has a good integration story and you can trust the webhook reliability. Untested. YMMV.

Tailscale SSH

Tailscale SSH lets you SSH into devices on your tailnet using Tailscale identity instead of managing SSH keys. Access is controlled through your ACLs, sessions are logged, and you eliminate the key management problem (keys left on machines, never rotated, copied to personal devices, punching IP holes, etc).

{
  "ssh": [
    {
      "action": "accept",
      "src": ["group:devops"],
      "dst": ["tag:prod"],
      "users": ["root", "deploy"]
    }
  ]
}

Check mode adds a human approval step before the session connects. This is useful for production access where you want someone to explicitly authorize the connection rather than relying purely on ACL membership.

{
  "ssh": [
    {
      "action": "check",
      "src": ["group:engineering"],
      "dst": ["tag:prod"],
      "users": ["deploy"]
    }
  ]
}

When someone tries to connect, the session hangs until it’s approved in the Tailscale console, requiring a user to sign in again with their identity provider. It’s lightweight JIT for SSH without bolting on external tooling.

Third-Party and Contractor Access

Third parties are where access control goes to die. Like “temporary” fixes, “temporary” access is never removed. The contractor or MSP with standing access to your AWS account. The vendor integration that got access for just a bit.

Third parties don’t fit cleanly into your employee groups, their access needs are often poorly defined, and nobody owns the relationship from a security perspective.

Create explicit third-party groups with expiration dates in the name

{
  "groups": {
    "group:vendor-acme-2026q2": ["contractor@acme.com"],
    "group:msp-cloudops": ["admin@cloudops-msp.com"]
  }
}

The date in the group name should be a forcing function so when Q3 rolls around, you have to consciously decide whether to create group:vendor-acme-2025q3 or let access lapse.

Scope third-party access as narrowly as possible

{
  "acls": [
    {
      "action": "accept",
      "src": ["group:vendor-acme-2025q2"],
      "dst": ["tag:acme-integration:443"]  // Only what they need, nothing else
       "srcPosture": ["node:tsReleaseTrack == 'stable'","ip:country in ['CA', 'US', 'GB', 'NL']", "node:tsAutoUpdate == true"]
    }
  ]
}

Use separate tags for resources that third parties touch

Don’t give vendors access to tag:staging. Create tag:vendor-acme-staging and put only the specific resources they need behind it. This prevents over provisioning and makes it obvious what they can reach.

Quarterly review

Put it on the calendar. For each third-party group:

• Is this engagement still active?
• Is the access scope still appropriate?
• Are the specific users still the right people?

This should help catch the MSP admin who left months ago but can still access your systems.

Visibility into Management Plane Changes

Network flow logs are useful but require significant investment to operationalize. And streaming is only available on Enterprise plans. For most, start with management plane visibility and know when your Tailscale configuration changes.

Set up webhooks for critical events

Tailscale supports webhooks for management plane events. Configure alerts for:

• nodeCreated — new device joined the tailnet
• nodeDeleted — device removed
• nodeApproved — device approval status changed
• userCreated — new user added
• userDeleted — user removed
• userRoleUpdated — permissions changed (especially promotions to admin)
• subnetIPForwardingEnabled / subnetIPForwardingDisabled — subnet router changes

Send these to Slack, PagerDuty, or wherever your team is going to see them. You don’t need fancy correlation, unless your SIEM is actually being managed. It’s more making sure someone notices when the configuration changes unexpectedly.

Example webhook events worth alerting on

• Any userRoleUpdated to admin/prod/crown jewel access → immediate Slack alert
• nodeCreated outside business hours → worth a look
• subnetIPForwardingEnabled → who just advertised a new route?
• userCreated when you’re not actively onboarding → investigate immediately

If you do have a SIEM or detection platform

Panther has published Tailscale-specific detection rules that you can use as a starting point. These cover scenarios like:

• Admin role granted
• New user added
• Policy (ACL) changes
• Device posture changes

Even if you don’t use Panther, the rule logic is a useful reference for what’s worth detecting.

High-Security Environments

Tailnet Lock (if you need it)

Tailnet Lock removes Tailscale’s coordination servers from your trust chain. New devices need cryptographic signatures from customer-controlled signing nodes before they can communicate.

This matters when

• Compliance frameworks that explicitly require customer-controlled key management
• Defense contractors or companies in sensitive industries with genuine nation-state concerns
• Enterprise customers who specifically ask about control plane trust in security reviews

Who can you trust

For the vast majority of organizations, trusting Tailscale’s coordination servers is a reasonable trade-off. Tailscale’s security model, SOC 2 compliance, and the operational overhead of managing your own signing nodes all factor in. If you’re not in a highly regulated industry and don’t have specific compliance requirements mandating customer-controlled keys, the Tailscale control plane is fine.

The operational burden of Tailnet Lock isn’t cheap - you need hardened signing nodes, a process for signing new devices, and a recovery plan if signing nodes become unavailable. For most, the overhead exceeds the risk reduction.

If you do enable it, know that pre-signed auth keys embed the private signing key. If that pre-signed auth key is leaked, it could compromise your entire Tailnet Lock security model.

Replace subnet routers with app connectors where possible. App connectors expose specific applications rather than entire subnets. If you’re advertising a subnet just to reach a few services, app connectors will reduce your exposure.

Operational Realities

Start Here

Regularly (that is, pick a cadence you’ll maintain)

• Look at the key lists and revoke anything that’s unused
• Check for unexpected subnet route advertisements
• Review webhook alerts from the past period

Periodically (monthly-ish)

• Review group memberships against current employee roster
• Check that offboarded employees are removed
• Review ACL changes
• Verify posture integrations are syncing

Quarterly

• Full access review - who can reach what?
• Third-party access review - is anything still needed? still scoped correctly?
• Review subnet router configurations
• Update ACL tests for any new resources

On employee departure (immediately)

• Remove from all Tailscale groups
• Delete user from tailnet
• Revoke any auth keys they created
• Remove their devices

Summary

For most growing organizations, the realistic hardening path looks like this.

1. First: Replace the default ACL with explicit, port-specific rules. Add deny tests for production databases. Set up webhooks for management plane alerts. Ensure everyone is using passkeys or Yubikeys to access Tailscale.
2. Next: Segment by function, connect device posture to your existing EDR, establish a documented process for time-limited production access (match complexity to what you’ll actually maintain), add check mode to SSH.
3. Then: Create explicit third-party access groups with built-in expiration, establish a realistic review cadence, and document your configuration for audits.

If you’re selling to enterprise, treat these things as a business requirement. Your ACL configuration will be audit evidence. Invest accordingly.

If you’re in a sensitive industry. Consider Tailnet Lock, app connectors, and extensive monitoring. For most companies, trusting the Tailscale control plane is a reasonable trade-off, but know your compliance requirements.

We don’t need perfect security. But it should match your threat model, operational capacity, and business requirements.

For implementation details, see the Tailscale Hardening Checklist.

‍