Best practices to secure your tailnet

Tailscale has many security features you can use to increase your network security. This page provides best practices for using these features to harden your Tailscale deployment.

See also an overview of Tailscale’s security, including how Tailscale builds in security by design, and internal controls we use to help keep your information safe.

Baseline practices

Baseline practices are widely applicable and high-value steps to improve security.

Upgrade Tailscale clients in a timely manner

Upgrade Tailscale clients regularly, in a timely manner. Tailscale frequently introduces new features and patches existing versions, including security patches.

Manual updates are required for Linux and Windows devices; updates for iOS, Android, and macOS devices are automated. Use the Machines tab of the admin console to see devices in your tailnet, what version of Tailscale they are running, and if they can be updated. You can also filter for machines that have an update available by using the version:update-available filter.

Subscribe to security bulletins

Subscribe to Tailscale’s security bulletins. Tailscale publishes security bulletins to disclose security issues affecting Tailscale. If you’re directly affected by a security issue, and we have your contact information, we will contact you.

Subscribe via RSS or follow @TailscaleSec on Twitter.

Set a contact for security issue emails

Set a contact for security issue emails. If you’re directly affected by a security issue, and we have your contact information, we will contact you. If no email is set for a security contact, Tailscale uses the default behavior, which is to send security issue emails to the tailnet owner email address.

If you want multiple users to be notified, consider using an email group. For example, use, instead of, for security issue notifications.

If you are using GitHub as your identity provider, we have no contact email information unless you add an email address to your contact preferences.

Enable MFA in your identity provider

Enable multi-factor authentication in your identity provider for authenticating to Tailscale, ideally using a hardware token. Tailscale relies on your existing identity provider to authenticate users. Any authentication settings from your identity provider are automatically used by Tailscale, including MFA and context-aware access.

Follow your identity provider’s documentation for how to enable multi-factor authentication.

Define ACLs

Use access controls to define the connections you want to allow in your network, based on job function and following the principle of least privilege. Tailscale’s ACLs allow you to define what users, groups, IP addresses, CIDRs, hosts, and tags can connect to each other in your network. Using ACLs, you can define role-based access controls for users accessing services in your network in terms of user identities, rather than in terms of IP addresses. Follow the principle of least privilege to ensure users are only granted access to the intended resources.

Restrict access to users based on job function and what they need to access. See ACL samples for common scenarios.

Use groups in ACLs

Use groups to manage your users. Using groups allows identities to be controlled based on job function. If someone leaves an organization or changes roles, you can adjust the group membership rather than update all of their ACLs.

Define groups in ACLs for sets of users, and use these as part of access rules. Enable user & group provisioning to sync users and groups from your identity provider, to automatically add or suspend users, and use groups in ACLs.

Use tags in ACLs

Use tags to manage devices. Using tags allows you to define access to devices based on purpose, rather than based on owner. If someone leaves an organization or changes roles, common devices they have set up, like a server, will not need to be reconfigured.

Define tags in ACLs, and use these as part of access rules. Use an auth key with an ACL tag so that a device is automatically tagged when it is authenticated.

Use check mode for Tailscale SSH

Verify high-risk Tailscale SSH connections with check mode. Check mode requires certain connections, or connections as certain users (such as root), to re-authenticate before connecting. This allows the user to access these high-risk applications for the next 12 hours or for a specified check period before re-authenticating again. Check mode is only available for Tailscale SSH connections.

In an ACL’s ssh rule, set the action field to check to configure check mode for your high-risk Tailscale SSH connections.

Advanced practices

Advanced practices may not be widely applicable. They may also include features which require more configuration or a more advanced knowledge of security and networking.

Use ACL tests in ACLs

Write tests to ensure access controls don’t change unexpectedly. ACL tests let you ensure that your access controls are as expected, so that after making a change, an important permission isn’t accidentally revoked, or a critical system accidentally exposed.

Define ACL tests in ACLs. These are automatically validated when an ACL is updated.

Assign Admin roles

Assign user roles for managing Tailscale as appropriate, based on job function and for separation of duties. Tailscale provides multiple user roles that restrict who can modify your tailnet’s configurations. These allow for separation of duties between admins who can modify users and devices, such as IT administrators, and those who can modify network configurations, such as the networking team.

Assign the roles of Admin, Network Admin, IT Admin, and Auditor in the users tab of the admin console.

Enable device authorization

Require devices to be approved before they join your network. You can require that new devices be manually reviewed and approved by an Admin before they can join the network. This can be used to ensure only trusted devices, such as workplace-managed laptops and phones, can access a network.

Enable device authorization from the settings tab of the admin console.

Customize node key expiry

Require users to rotate keys by re-authenticating their devices to the network regularly. Devices connect to your tailnet using a public node key which expires automatically after a period of time, forcing keys to rotate. By default, Tailscale requires devices to re-authenticate every 180 days, but some organizations may have a need for stricter controls.

Modify key expiry from the settings tab of the admin console.

Protect your network boundary

Restrict access to your private network, e.g., using a firewall. Tailscale allows you to easily connect your devices no matter their local area network, and ensures that traffic between your devices is end-to-end encrypted. However, Tailscale does not protect your devices from any other traffic.

Set up a firewall for your network or for your device. See Using Tailscale with your firewall for additional configuration information.

Enable HTTPS

Obtain public TLS certificates for internal web tools hosted on your network. Connections between Tailscale nodes are already secured with end-to-end encryption. However, browsers are not aware of that because they rely on verifying the TLS certificate of a domain. By getting a TLS certificate from a public CA for your internal web tool, you avoid confusing your users with browser security warnings.

Configure HTTPS for your tailnet from the feature settings tab of the admin console. Note that certificates are added to the Certificate Transparency log, so machine names should not contain private information.

Remove unused API and auth keys

Regularly remove API and auth keys that are no longer needed for your network. This prevents leaked keys being used to add unauthorized users or devices to your network.

View existing API and auth keys from the key settings tab of the admin console, and remove those you no longer need. If you are using an auth key to only authenticate a single device, consider using a one-time auth key.

Prevent DNS rebinding attacks

Ensure a Host header is present for HTTP services. Web services available in a tailnet over HTTP (not HTTPS) may be susceptible to DNS rebinding attacks, where a Tailscale node visiting a malicious web page can be triggered to run a client-side script and attack other nodes in the tailnet. HTTP services can detect DNS rebinding attacks by validating the Host header of incoming HTTP requests is allowlisted.

Set a Host header field in HTTP request messages sent to a HTTP service running in your tailnet. For example, in the HTTP request message, set:

GET /resource HTTP/1.1

This could also be a MagicDNS fully qualified domain name, for example:


Last updated

WireGuard is a registered
trademark of Jason A. Donenfeld.

© 2023 Tailscale Inc.

Privacy & Terms