Business VPN & Zero Trust Access
Tailscale
Rest of world Report an error0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by Tailscale US Inc. · tailscale.com
Compare with NordLayer → Compare with NetBird → Report an error on this page Is this your product? →
Link to this page
Add ?theme=dark to the image address for dark backgrounds.
The badge shows the category and the month of the latest evaluation, and EU-Made where
that is the product’s provenance. It never shows a score.
Tailscale at a glance
- Vendor
- Tailscale US Inc.
- Headquarters
- Not stated on the vendor’s pages as of 5 Nov 2026
- Data hosting
- Not stated on the vendor’s pages as of 5 Nov 2026
- Free plan
- Yes, per the vendor’s own page source, captured 5 Nov 2026
- Panel verdict
- The AI panel rates Tailscale 3.5/5, the mean of 6 judges. Tailscale, a WireGuard mesh VPN with identity-based access control, scored highest on identity and policy at 8 across the bench, built on default-deny grants, MFA inherited from your own identity provider and SCIM group sync. how scores are made
- As of
- Vendor pages captured 5 Nov 2026; evaluated by the panel 6 Nov 2026. all sources
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
Tailscale, a WireGuard mesh VPN with identity-based access control, scored highest on identity and policy at 8 across the bench, built on default-deny grants, MFA inherited from your own identity provider and SCIM group sync. Access and connectivity, visibility and audit, and deployment and administration cluster at 7-8 — subnet routers, an API on every plan and tamper-detectable double logging, set against a fixed 90-day configuration-log cap. Architecture and assurance scores 7 across the bench on published cryptography detail and SOC 2 Type II, held down by audits available only on request and no public information on a status page or availability SLA. Sovereignty is weakest at 3-5: a US contracting chain — Tailscale US Inc., a Delaware corporation, with processing stated in Canada, Germany, the United States and the United Kingdom — against safeguards including a published DPA and standard contractual clauses, and no public information on EU hosting. Pricing transparency scores 5-7: Personal $0, Standard $8 per user per month and Premium $18 per user per month are public; Enterprise and extra ephemeral minutes are contact sales.
Speaks for it
- Identity and policy scored 8 across the bench, with sign-in via your own SAML or OIDC provider and MFA inherited from it.
- Default-deny grants expose named resources rather than whole networks, with SCIM group sync removing access with the directory.
- Configuration audit logs run on all plans, and connections logged on both source and destination make tampering detectable.
- Private keys never leave nodes, the coordination server exchanges only public keys, and node and relay code is open source.
- Pricing is published per tier: Personal $0, Standard $8 per user per month, Premium $18 per user per month, with 50 tagged resources included.
Held against it
- Sovereignty scored 3-5: contracting with Tailscale US Inc., a Delaware corporation, and processing stated in Canada, Germany, the United States and the United Kingdom.
- Configuration audit log retention is fixed at 90 days and cannot be configured.
- Latacora audits are available only on request, the vendor states it runs no bounty program, and we found no public information on a status page or availability SLA.
- Enterprise, extra ephemeral minutes and multiple tailnets are contact sales, so a larger deployment's annual cost is not computable from public pages.
- We found no public information on always-on auto-connect, clientless browser access for contractors, or named relay regions.
Best for
- You want per-resource access — default-deny grants tied to an identity provider you already run, with MFA and SCIM group sync inherited.
- Your team deploys clients via MDM such as Intune or Jamf and wants a REST API available on every plan.
- You connect multi-cloud and on-premises networks with subnet routers and want just-in-time access gated by device posture from EDR and MDM tools.
- You manage servers or CI/CD runners and want SSH authorized by tailnet identity instead of shared keys.
Avoid if
- Your compliance regime requires processing to stay within the EU — processing is stated in Canada, Germany, the United States and the United Kingdom.
- You need configuration audit logs kept longer than 90 days — retention is fixed at 90 days and cannot be configured.
- You require FIPS-validated cryptography — the vendor states its cryptographic implementations are not FIPS compliant.
- You must compute the full annual cost before committing — Enterprise, extra ephemeral minutes and multiple tailnets are contact sales.
The scores
| Criterion | Panel median |
|---|---|
| Access model & connectivity | 4 of 5 |
| Identity, access policy & device posture | 4 of 5 |
| Logs, audit trail & incident response | 3.5 of 5 |
| Deployment, API & administration | 3.5 of 5 |
| Architecture, reliability & security assurance | 3.5 of 5 |
| European sovereignty | 2 of 5 |
| Pricing transparency | 3.5 of 5 |
Access model & connectivity
Show reasoningHide reasoning
How this is scored
What the product connects and how: a managed gateway VPN with shared or dedicated gateways and dedicated static IPs, a peer-to-peer mesh between devices and servers, access per application or resource (ZTNA), site-to-site links between offices and cloud networks (AWS, Azure, Google Cloud), connectors behind a firewall without inbound ports, the protocols (WireGuard, IPsec, OpenVPN, a vendor protocol), split tunnelling and full tunnelling, always-on and auto-connect, clients for Windows, macOS, Linux, iOS, Android and ChromeOS, the gateway and relay locations, NAT traversal and relays, and access for contractors without a managed device.
0 — Gives no remote access of its own; a browser extension, a consumer VPN for anonymous browsing or a security tool that only filters traffic.
3 — A VPN client that connects users to one gateway or network; site-to-site, per-resource access, the clients per platform and the locations are basic or not described.
5 — Clients for Windows, macOS, Linux, iOS and Android, a modern protocol (WireGuard or IPsec), access to private networks through a gateway or connector without inbound firewall rules, split tunnelling, dedicated static IPs or self-run gateways, site-to-site or cloud network links, and the gateway or relay locations named.
8 — Access per application or resource rather than whole networks, peer-to-peer connections with relays as fallback, always-on and auto-connect, connectors for the major clouds and Kubernetes, gateways in many named regions, private DNS and split DNS, clientless browser access for contractors, and the protocol and encryption choices documented.
10 — Connectivity a distributed company runs on: every access model above in one product, high-availability gateways and connectors with failover documented, performance and throughput published per gateway type, post-quantum or equivalent key exchange documented, and an exit path to run the same network on self-hosted components.
The IT Lead
WireGuard peer-to-peer connections with DERP relays as fallback, subnet routers for site-to-site between our two plants, split DNS and MagicDNS, and default-deny grants that expose named resources instead of a whole network, on clients documented for Windows, macOS, Linux, iOS and Android with no inbound firewall ports — that is the ERP-and-file-server access I need. I found no public information on always-on or auto-connect behaviour or on clientless browser access for contractors, and the relay fleet is described only as running in multiple regions, not named ones. 2 5 13 14 20 21 22
The DevOps Engineer
This is the model I want for sixty servers and two clouds: WireGuard peer-to-peer mesh with STUN/ICE NAT traversal so nothing needs an inbound port, DERP relays only as fallback, and subnet routers bridging whole subnets including site-to-site between cloud networks. Clients are listed for Windows, macOS, Linux, iOS, Android, Chromebooks and more, MagicDNS and split DNS are documented, the Kubernetes Operator covers clusters, and high-availability subnet routers with failover are written up. We found no public information on always-on auto-connect, clientless browser access for contractors, or post-quantum key exchange, so it stops short of the top end. 2 4 13 14 20 21 22
The MSP Technician
A WireGuard mesh with peer-to-peer links and relay fallback, NAT traversal over STUN and ICE with no inbound firewall rules, subnet routers doing site-to-site between offices and cloud environments, split DNS with MagicDNS, a Kubernetes operator and app connectors, and clients for Windows, macOS, Linux, iOS, Android, ChromeOS and even Apple TV. High-availability subnet router failover is documented and the protocol and cipher choices are published in real detail. The relays are described only as running in "multiple regions" rather than named ones, and we found no public information on always-on auto-connect, published throughput figures, or clientless browser access for contractors. 20 21 22 13 14 12 4 2
The Operations Manager
A WireGuard mesh with peer-to-peer connections, encrypted relays as fallback, and NAT traversal that needs no firewall changes or open ports — which is exactly what keeps a freelancer connected from a hotel lobby. Subnet routers bring whole client networks in, clients exist for every platform my travelling people carry, and default-deny grants mean a freelancer reaches one project system and nothing else. We found no public information on always-on auto-connect, on clientless browser access for contractors who cannot install a client, or on the named locations of the relay regions. 20 21 22 13 14 5
The Information Security Officer
Peer-to-peer WireGuard connections with DERP relays as fallback, NAT traversal without inbound firewall ports, subnet routers for site-to-site links with split DNS and high availability, app connectors with a Kubernetes operator, and per-resource grants rather than whole-network access cover exactly the access model I want for control systems. The pages state relay servers run in multiple regions without naming the individual locations, and I found no public information on clientless browser access for contractors or always-on auto-connect behaviour. 2 5 12 13 14 20 21 22
The Skeptic
The captured pages document a WireGuard peer-to-peer mesh with DERP relays as fallback, clients for Linux, macOS, Windows, iOS, Android, Chromebooks and more, subnet-router site-to-site links into cloud networks with high-availability and fail-close behaviour stated, split tunnelling, exit nodes, MagicDNS and split DNS, and default-deny per-resource access. What I could not find: named relay regions, always-on or auto-connect, or any documented exit path to run the same network on a self-hosted coordination server. To the vendor's credit, traffic stays end-to-end encrypted even through relays and the relay code is open source. 2 13 14 20 21 22
Identity, access policy & device posture
Show reasoningHide reasoning
How this is scored
Whether access follows identity and the state of the device rather than the network: single sign-on with Microsoft Entra ID, Google Workspace, Okta or any OIDC/SAML provider, SCIM or directory sync so a leaver loses access, multi-factor authentication, groups and per-resource access policies, least-privilege defaults, device posture checks (operating system version, disk encryption, EDR or MDM status, managed device certificates), just-in-time or time-limited access with approval, session lifetimes and re-authentication, and access revoked when a device is lost.
0 — No user identity at all; a shared key or configuration file grants access to the whole network.
3 — User accounts with a password or one identity provider; groups, per-resource policies and device checks are basic or not described.
5 — Single sign-on with Entra ID, Google Workspace and Okta, multi-factor authentication, user groups, access policies that restrict groups to named networks, resources or ports, automatic or SCIM-based deprovisioning, and basic device posture checks such as operating system version.
8 — SCIM provisioning from the major identity providers, per-resource policies with least privilege by default, device posture from EDR or MDM tools (for example CrowdStrike, SentinelOne, Intune, Jamf), just-in-time access with approval and expiry, session re-authentication, policies kept as code, and the policy model documented.
10 — Access control a security team can audit and trust: continuous evaluation of identity and device state during a session, policies tested before they apply, emergency revocation documented, device identity bound to hardware, and the decision for every connection explainable from the logs.
The IT Lead
Sign-in goes through our own identity provider with MFA and context-aware settings inherited from it, Microsoft AD, Okta and Google named among the providers, and SCIM group sync keeps access tied to the account so a leaver disappears with their group. Grants are default-deny and directional down to users, groups, tags and hosts, the policy file can live in Git, users can be required to re-authenticate on a schedule, and device posture rules draw on operating system version plus synced EDR and MDM attributes with just-in-time access on top. I found no public information on hardware-bound device identity or a documented emergency revocation procedure. 2 5 12 15 16
The DevOps Engineer
Authentication is outsourced to your own OAuth2/OIDC/SAML provider with MFA inherited from it, SCIM group sync keeps access current, and policies are default-deny grants in one tailnet policy file I can drive through GitOps with GitHub or GitLab and the API. Device posture pulls pre-populated host facts plus synced EDR and MDM attributes (CrowdStrike is the worked example), just-in-time access is policy-file driven, and Tailscale SSH authorizes by tailnet identity instead of SSH keys — the shared bastion key can finally die. Terraform shows up for managing PAM resources rather than the whole tailnet, which is the one gap I care about. 2 4 5 12 15 16 21
The MSP Technician
Access hangs off our own identity provider rather than shared keys: SSO with any SAML or OIDC provider including Google, Microsoft, Okta and GitHub, MFA inherited from that provider, SCIM user and group sync so a leaver drops out, default-deny grants and ACLs, device posture from operating system version, custom attributes and EDR/MDM tools like CrowdStrike, just-in-time access tied to posture, and policy as code through GitOps or the API. Machine certificates are described as keys belonging semi-permanently to the device rather than hardware-bound, and we found no public information on emergency revocation procedures. 12 2 5 15 16 21
The Operations Manager
Login is outsourced to whatever identity provider we already use, with MFA inherited from it, and SCIM group sync means a departing freelancer loses access the moment I remove them from the directory — access ending with the contract is a settings change, not a project. Policies are default-deny grants naming the exact resource a group may touch, device posture can pull attributes from EDR and MDM tools, and just-in-time access with regular re-authentication is documented. 2 12 5 15 16 21
The Information Security Officer
Access follows identity and device state rather than the network: single sign-on with any SAML or OIDC provider with MFA inherited from it, SCIM group sync, default-deny grants scoped per resource, device posture from EDR and MDM tools including CrowdStrike, just-in-time access with approval and expiry, forced re-authentication periods, and policy as code through GitOps. That is the level I would accept for OT access, though I found no public information on hardware-bound device identity or a documented emergency revocation procedure. 2 3 5 12 15 16
The Skeptic
Identity is outsourced to the customer's own provider over SAML or OIDC, with MFA inherited, SCIM group sync, default-deny grants and ACLs with tests, GitOps policy management, device posture from operating-system, EDR and MDM sources, and just-in-time access tied to posture attributes with configurable re-authentication periods. For the top of the scale I would want documented emergency revocation and every connection decision explainable from the logs, and I found no public information on either. 2 5 8 12 15 16
Logs, audit trail & incident response
Show reasoningHide reasoning
How this is scored
What can be seen and proven afterwards: connection and access logs (who reached which resource from which device, when), admin and configuration audit logs, how long logs are kept per plan, log export and streaming to a SIEM (Splunk, Microsoft Sentinel, Datadog, an S3 bucket), alerts on unusual access, a view of active sessions and the ability to end them, DNS logs where DNS filtering is part of the product, and what the vendor states it does not log, such as the content of traffic.
0 — No logs of any kind; the admin cannot see who connected.
3 — A list of connected users or devices; access logs, admin audit logs, retention and export are basic or not described.
5 — Connection or access logs per user and device, an admin audit log of configuration changes, the retention period stated, log export by CSV or API, a view of active sessions or devices with the option to disconnect or revoke them, and a statement of what traffic data is and is not logged.
8 — Log streaming to named SIEM tools, network flow logs per resource, retention of a year or more stated per plan, alerts or webhooks on security events, logs filterable by user, device and resource, and the log schema documented.
10 — An audit trail that holds up in an investigation: every access decision and admin action recorded with its policy and reason, logs signed or tamper-evident, evidence suitable for ISO 27001, NIS2 or DORA audits, full export in an open format, and the customer able to keep logs entirely on its own infrastructure.
The IT Lead
Configuration audit logs on all plans record who changed what and when, are kept 90 days, cannot be extended in place, and export by API; network flow logs show which node talked to which resource but are a Premium and Enterprise feature. Streaming to Splunk, Datadog, Elasticsearch, Panther, Cribl and Axiom, or to a private endpoint on our own node, is documented, every connection is logged at both endpoints so tampering is detectable, and the pages state that packet contents and client operations are never logged. Retention of a year or more per plan is not something I found on these pages. 6 12 17 18 21
The DevOps Engineer
Configuration audit logs are on by default with actor, action, target and time, filterable in the admin console and exportable via API, and network flow logs cover node-to-node traffic with an explicit statement they contain no traffic contents. Streaming to named SIEMs — Splunk HEC, Datadog, Elasticsearch, Panther among others — plus webhooks and SSH session recording is documented, and every connection being logged on both source and destination makes tampering detectable. Configuration log retention is fixed at ninety days and cannot be configured, and we found no public information on alerts for unusual access or a live session view. 4 6 10 17 18 21
The MSP Technician
After an incident I can show a client who did what: configuration audit logs with action, actor, target and time on by default, filterable in the console; network flow logs that strictly exclude traffic contents; streaming to named SIEM tools including Splunk and Datadog; SSH session recording; and double logging on both endpoints that makes tampering detectable. The catch for incident response is that configuration logs are kept for only 90 days and that period cannot be configured in place, and we found no public information on alerting on unusual access. 17 6 18 21 4
The Operations Manager
Configuration audit logs ship on every plan with ninety days' retention, network flow logs and streaming to named SIEMs including Splunk and Datadog sit on the upper tiers, webhooks exist, and every connection logging on both endpoints makes tampering detectable. But the configuration-log retention is capped at ninety days and cannot be configured, and we found no public information on alerts for unusual access or a console view that lets me end a live session. 17 18 6 21
The Information Security Officer
Configuration audit logs are always on and record actor, action and target, network flow logs show node-to-node access, both stream to named SIEM systems including Splunk, and every connection is logged twice on source and destination with real-time streaming so tampering is detectable — which answers my auditor's question of who reached what. Retention is fixed at 90 days and cannot be extended in the product, failed login attempts and support-initiated changes are not captured, and I found no public information on alerts for unusual access. 6 17 18 21
The Skeptic
Configuration audit logs run on all plans with actor, action, target and time plus full policy diffs, network flow logs record node-to-node activity while strictly excluding packet contents, both stream to named SIEM tools or S3 and private endpoints, and double logging on source and destination makes tampering detectable. The caps are real though: ninety days fixed retention that cannot be extended in-product, failed logins live only in the identity provider, support-initiated changes are stated not to be logged, and I found no public information on alerts for unusual access. 6 17 18 21
Deployment, API & administration
Show reasoningHide reasoning
How this is scored
How the product is rolled out and run by a small IT team or a service provider: time to the first connection, deployment of clients through MDM (Intune, Jamf, Kandji) with preconfigured settings, a central admin console, a documented REST API, a Terraform provider or configuration as code, roles for administrators, several teams, sites or customer tenants in one account, a multi-tenant console for managed service providers, a self-hosted or on-premises edition, the update process for clients and gateways, and support channels and hours.
0 — No central administration; every client is configured by hand with no console.
3 — A web console to add users and gateways; the API, MDM deployment, admin roles and multi-tenant set-up are basic or not described.
5 — A central admin console, a documented REST API, client deployment through MDM with preconfigured settings, admin roles, several networks or sites in one account, client updates managed centrally, and support channels and response times stated per plan.
8 — A Terraform provider or configuration as code, a multi-tenant console for service providers or several organisations, granular admin roles, a self-hosted or on-premises edition documented for production, gateways deployable as containers or cloud images, and webhooks or integrations with ticketing and chat tools.
10 — Administration that scales across many sites and tenants: every setting reachable by API and code with parity stated, staged rollouts of client and gateway updates, a self-hosted edition with feature parity stated, reseller or MSP billing per tenant, and an exit path for configuration and users documented.
The IT Lead
Clients install and auto-update through MDM — Microsoft Intune and Jamf are named in the update methods — with system policies for preconfigured settings and selectable release tracks, which is the Intune-first rollout I want for 140 seats. The admin console with Owner, Admin, IT admin and Network admin roles, a REST API available on all plans, GitOps for the policy file, Terraform support, webhooks and multiple tailnets on request give my three-person team the levers it needs. I found no public information on a self-hosted or on-premises edition for production. 4 7 8 19 20
The DevOps Engineer
A documented REST API is on all plans with scoped tokens and trust credentials, admin roles split across Owner, Admin, IT admin and Network admin, MDM deployment written up in real detail for Jamf with preconfigured profiles, and centrally managed client updates across stable, release candidate and unstable tracks. The Kubernetes Operator deploys via Helm, multiple tailnets under one organization exist for OEM-style setups, and webhooks are listed. We found no public information on a self-hosted or on-premises edition documented for production, which is what holds this below the top level. 2 4 7 8 19 20
The MSP Technician
Rollout is genuinely fast: a central console, a REST API on all plans, Jamf deployment documented down to bundle IDs and profile scope, central auto-updates with stable, release candidate and unstable tracks, four administrator roles, GitOps policy, and support tiers with 24/7 coverage named at Gold and Platinum. Terraform support is only documented for privileged access resources, the multiple-tailnet option that would serve a provider's managed multi-tenancy is "contact sales" and framed for OEM, and we found no public information on a self-hosted edition or billing per tenant. 7 19 20 8 4 2
The Operations Manager
A quickstart gets a first connection in minutes, the API is available on every plan, Jamf and Intune deploy preconfigured clients, and updates can be driven centrally with stable and pre-release tracks — a non-specialist like me can run this without an external provider on speed dial. Admin roles are granular and Terraform and webhooks exist, but we found no public information on a self-hosted edition for production, and managing several organisations through multiple tailnets runs through a contact-sales path. 1 20 19 7 8 4
The Information Security Officer
A documented API available on all plans, MDM deployment with Jamf configuration profiles plus update control via Intune or Jamf, granular admin roles, Terraform, webhooks, multiple tailnets under one organisation, and per-tier support with 24/7 severity-one coverage on the paid tiers make this runnable by a small team. I found no public information on a self-hosted production edition of the control plane. 4 7 8 19 20
The Skeptic
A central console, a REST API available on every plan with scoped tokens and delegated trust credentials, detailed Jamf deployment guidance, centrally and MDM-managed updates across stable and unstable build tracks, four administrator roles, multiple tailnets under one organisation, Terraform for PAM resources, webhooks, and support tiers with 24/7 severity-one coverage at the top. The self-hosted question is where it stops: I found no public information on an on-premises edition, and reseller or per-tenant billing for service providers is likewise not described. 2 4 7 8 19 20
Architecture, reliability & security assurance
Show reasoningHide reasoning
How this is scored
How the product is built and how its claims are proven: a published architecture showing what the coordination servers, relays and gateways see, whether traffic passes through the vendor or end to end between devices, encryption and key management, open-source clients or servers, independent security audits and penetration tests with reports or summaries published, a vulnerability disclosure or bug bounty programme, high availability and failover of the vendor's control plane, what happens to existing connections when the vendor's service is down, the vendor's own public status page and incident history, and an SLA.
0 — Nothing is published about how the product works or is secured.
3 — Encryption is mentioned in marketing terms; architecture, audits, availability and the vendor's status page are basic or not described.
5 — An architecture overview of clients, gateways and the control plane, the encryption protocol and key handling named, an independent security audit or penetration test stated, a vulnerability disclosure contact, the vendor's public status page, and an availability SLA on the business plans.
8 — A security whitepaper with the data flow and what the vendor can see, open-source clients or core components, audit or pentest reports or summaries published by the auditor, a bug bounty, high availability of the control plane documented, existing connections kept alive when the control plane is down, and the incident history public with post-mortems.
10 — Assurance a regulated buyer can verify: fully open-source and reproducible components, recurring independent audits published in full, the control plane self-hostable with no call home, a documented failure mode for every vendor component, and several years of availability published.
The IT Lead
The how-it-works page says plainly what the coordination server sees — public keys and connection metadata, never private keys or traffic — and the crypto is documented down to Noise IK with X25519, WireGuard on the data plane and a TLS 1.2 minimum, with node and relay code open source, DERP regions failing over independently, and existing connections surviving a coordination-server outage. SOC 2 Type II and Latacora audits are stated, but the reports come on request rather than published, the security page states there is no bounty program, and I found no public information on a status page, an availability SLA or an incident history. 11 12 21 22
The DevOps Engineer
The how-it-works page is exactly what I ask vendors for: the coordination server is described as a shared drop box for public keys only, private keys never leave the node, and DERP relays blindly forward already-encrypted WireGuard packets and do not log — with the relay code open source so I can check. Encryption is documented down to Noise IK with X25519, TLS 1.2 minimum, AEAD cipher selection and Tailnet Lock signatures, the network stays reachable when the coordination server is down, and DERP regions fail over independently. Independent Latacora audits are stated but available only on request, the vendor states it has no bug bounty program, and we found no public information on a status page, incident history or an availability SLA. 4 11 12 21 22
The MSP Technician
The architecture is published in unusual depth: a coordination server that only exchanges public keys, end-to-end encrypted peer-to-peer traffic the vendor states it cannot read, open-source node and relay code, named ciphers with forward secrecy, SOC 2 Type II, and the network staying reachable when the coordination server is down. Independent Latacora audits exist but only on request rather than published, the vendor states plainly that it has no bounty program, and we found no public information on a status page, an availability SLA or incident post-mortems. 21 22 12 11 10
The Operations Manager
The how-it-works and encryption pages show precisely what the coordination server and relays can see — nothing, for traffic, since private keys never leave the devices — and the network stays up if the coordination server goes down, with relays failing over between regions and client and relay code open source. Independent audits by a named security firm and SOC 2 Type II are stated, but the reports are available on request rather than published, the vendor states plainly there is no bounty program, and we found no public information on a status page or an availability SLA. 21 22 12 11
The Information Security Officer
The architecture is published in detail — the coordination server holds only public keys, private keys never leave the node, relays cannot decrypt traffic, existing connections survive a coordination-server outage and relay regions fail over — and independent audits by Latacora, SOC 2 Type II and periodic third-party penetration tests are all stated. The audit reports themselves are available only on request rather than published, there is no bug bounty, and I found no public information on a status page with incident history. 11 12 21 22
The Skeptic
The vendor publishes what the coordination server and relays actually see — public keys and connection metadata, not traffic — names its protocols and ciphers, keeps private keys on the nodes, open-sources the node and relay code, and states that existing connections survive a coordination-server outage while relay regions fail over independently; SOC 2 Type II and third-party penetration tests are stated. But the Latacora audits are available on request rather than published, the vendor itself states it runs no bug bounty programme, and I found no public information on a status page, incident history or availability SLA. 11 12 21 22
European sovereignty
panel opinion
Show reasoningHide reasoning
How this is scored
Who the contracting entity and the parent company are, where account data, user and device identities, connection logs and configuration are stored and processed, which party runs the coordination servers, relays and gateways the traffic passes through, and who the subprocessors are (hosting, identity, email, support and payment tools). Independently sourced by the sovereignty pipeline. Gateway and exit locations outside Europe are part of what the product does and are not counted against it; where the logs and identities are stored and who processes them is. A self-hosted or open-source edition the customer runs on its own European servers counts as the customer's chain, whatever the vendor's seat.
0 — Non-EU vendor and contracting entity, hosting of the control plane and logs unstated, subprocessors unnamed, and no data processing agreement offered.
3 — A privacy policy and a data processing agreement exist, but the location of the control plane and logs is unstated or non-EU and the subprocessors are not listed.
5 — EU hosting of logs and account data available and an EU contracting entity or EU representative, but parts of the chain (relays, support, identity, payment) run through non-EU providers without a stated safeguard.
8 — EU hosting on named infrastructure for the control plane and logs, EU contracting entity, subprocessors listed with their locations, a data processing agreement published, and security certifications (ISO 27001, SOC 2) stated — or a self-hosted edition documented that keeps every record and connection on the customer's own servers.
10 — Sovereign end to end and evidenced: European ownership, entity, hosting and every subprocessor, or a self-hosted open-source edition with no call home, data export and deletion documented, and certifications published with their scope rather than implied.
The IT Lead
The contracting entity for new accounts is Tailscale US Inc., a Delaware corporation, the terms set exclusive venue in New York County, and processing is stated to occur in Canada, Germany, the United States and the United Kingdom — a mixed chain, even though an Article 27 GDPR representative, EDPO, is appointed and a published DPA relies on standard contractual clauses. A subprocessor page with ten days' change notice is referenced and personal data is returned or destroyed within thirty days of termination, but the captured pages do not show which subprocessors are used or where, and no EU hosting option is proven here. 9 10 11
The DevOps Engineer
The contracting entity is a US corporation with exclusive venue in New York County, while the DPA is published with standard contractual clauses, an Article 27 GDPR representative (EDPO) appointed, and subprocessors listed with ten days' notice of changes. Information is stated to be maintained and processed in Canada, Germany, the United States and the United Kingdom — a mixed footprint rather than a documented EU-hosting option for the control plane and logs — and we found no public information on a self-hosted production edition that would keep records on our own servers. 9 10 11 12
The MSP Technician
This is an American chain: contracting with Tailscale US Inc., a Delaware corporation, exclusive venue for business customers in New York County, and processing locations named as Canada, Germany, the United States and the United Kingdom, and we found no public information on a European hosting option for the control plane and logs. The paperwork is solid for client contracts — a published data processing agreement with standard contractual clauses, EDPO as EU and UK GDPR representative, a subprocessor page with ten days' change notice, return or destruction within thirty days, SOC 2 Type II — but my Hamburg clients will ask where identities and logs sit, and the answer includes the United States. 9 10 11 12 1
The Operations Manager
The contracting entity is a US corporation with New York venue and USD invoices; a data processing agreement exists with standard contractual clauses, an EU representative is appointed, and processing happens in Canada, Germany, the United States and the United Kingdom. We found no public information on EU hosting of the control plane and logs or on subprocessors named with their locations, so this is a mostly non-EU chain with stated safeguards rather than a European one. 9 10 11
The Information Security Officer
The contracting entity is a US corporation in Delaware, transfers from the EU rely on standard contractual clauses, and information is processed in Canada, Germany, the United States and the United Kingdom with no statement that identities and logs stay in Europe — this is the dimension that fails my requirement. A data processing agreement exists, the European Data Protection Office acts as the EU GDPR representative and a subprocessor page is referenced with ten days' notice of changes, but the captured pages do not name the subprocessors or their locations. 9 10 11
The Skeptic
The contracting chain is a Delaware corporation, processing is stated to occur in Canada, Germany, the United States and the United Kingdom with no statement of where the coordination plane or logs specifically live, while standard contractual clauses, an Article 27 EU representative and a published DPA with a subprocessor list and ten-day change notice provide safeguards. The captured pages give neither EU hosting on named infrastructure nor an EU contracting entity, subprocessor locations are not given, and I found no documented self-hosted edition that would keep every record on the customer's own servers. 9 10 11 12
Pricing transparency
Show reasoningHide reasoning
How this is scored
Whether a buyer can compute the real annual cost from public pages alone: price per user or per device and tier, minimum seats, what dedicated gateways, static IPs, extra networks or sites cost, which features (SSO, SCIM, device posture, log streaming, longer retention, site-to-site) need a higher tier, the free tier and its limits, the price of a self-hosted or on-premises licence, monthly versus annual billing, minimum term and VAT.
0 — No public prices at all; every customer is a sales call or a partner quote.
3 — A starting price or a free tier exists, but how cost scales with users, devices, gateways or features is unclear.
5 — Tiers are public with a price per user and their main inclusions, but at least one commonly needed piece (dedicated gateways or IPs, extra sites, SSO or SCIM, log retention, the self-hosted licence) is unpriced or "on request".
8 — Every tier priced publicly with its scaling rule (users, devices, gateways, networks), dedicated IPs and gateways priced, add-ons priced, minimum seats, minimum term and VAT treatment stated.
10 — Complete price computability: annual cost derivable for a given team size, number of sites, gateways and devices, with every add-on, overage and support fee and the cancellation and data-return terms published.
The IT Lead
Standard is $8 per user, per month, Premium is $18 per user, per month, the Personal plan is $0, and tagged resources such as exit nodes cost $1 per month beyond the first fifty included — with plan-change proration, overage timing, excluded taxes and USD invoices all stated, so the per-user basis survives a budget round. Enterprise is custom-priced through sales, extra ephemeral minutes are sales-priced, minimum seats and minimum term are not stated, the terms say the fees are specified at checkout, and log streaming and network flow logs need Premium or Enterprise. 3 8 9 15 18
The DevOps Engineer
Published tiers are Personal at $0 forever, Standard at $8 per user, per month and Premium at $18 per user, per month, with tagged resources at $1 per month each beyond fifty included, per-plan ephemeral-minute allotments, taxes explicitly excluded, USD invoicing at thirty days, and plan gating documented for posture attributes and log streaming. Enterprise and additional ephemeral minutes are contact sales. Minimum seats, minimum term and an annual-versus-monthly price difference are the pieces we found no public information on. 3 6 8 9 15 18
The MSP Technician
I can quote most of a client bill straight from the public pages: $0 for the Personal plan free forever, $8 per user per month on Standard, $18 on Premium, 50 tagged resources included with more at $1 per month each, monthly or annual billing set at checkout, taxes excluded, the API on all plans, and network flow logs plus log streaming gated to Premium and Enterprise. Enterprise is custom pricing, extra ephemeral minutes and multiple tailnets are "contact sales", and we found no public information on support-tier prices, minimum seats or minimum term. 3 8 9 18
The Operations Manager
Personal is $0 free forever, Standard is $8 per user, per month, Premium is $18 per user, per month, and tagged resources beyond the fifty included cost $1 per month each, with taxes excluded and monthly or annual billing stated — enough to sketch what fifty people plus a pile of freelancers would cost. But the Enterprise tier, extra ephemeral minutes and multiple tailnets are contact-sales, and the fee for a chosen payment period is set at checkout, so I cannot compute the real annual bill from public pages alone. 3 8 9
The Information Security Officer
Three tiers are public — $0 free forever, $8 per user, per month and $18 per user, per month — with tagged resources beyond the 50 included at $1 per month for every tagged resource, ephemeral-minute allowances, SSH host limits and the plan requirements for log streaming and posture attributes all stated, and taxes expressly excluded from the fees. The Enterprise tier is custom-priced through sales, the ephemeral add-on is contact sales, and I found no public information on minimum seats or a minimum term. 3 6 8 9 18
The Skeptic
Tiers are public — a free Personal plan, Standard at $8 per user per month, Premium at $18 per user per month — with the tagged-resource add-on at $1 per month for every tagged resource beyond 50 included, per-plan ephemeral minutes, and plan gating stated for features like log streaming and posture attributes; taxes excluded and USD invoicing are stated in the terms. Enterprise and the ephemeral add-on are contact sales, and I found no public information on minimum seats or a minimum term, so the annual cost of a larger deployment is not computable from the captured pages alone. 3 8 9 15 18
European sovereignty — proven facts
0 of 6 dimensions provenBuilt only from facts shown on the vendor's own pages. A dimension we could not prove is left open, not scored as zero.
| Legal entity | Not determined | — | uncited Report an error |
|---|---|---|---|
| Hosting location | Not determined | — | uncited Report an error |
| Hosting options | Not determined | — | uncited Report an error |
| Open source | Not determined ⚠ unverified | — | uncited Report an error |
| Data processing agreement | Not determined ⚠ unverified | — | uncited Report an error |
| Transfer impact assessment | Not determined | — | uncited Report an error |
Questions about Tailscale
Is Tailscale European?
No. whats-best.ai classifies Tailscale as Rest of world.
Where does Tailscale store data?
Not stated on the vendor’s pages as of 5 Nov 2026.
Does Tailscale have a free plan?
Yes. Tailscale has a free plan, per the vendor’s page captured 5 Nov 2026.
What are the best alternatives to Tailscale?
As of 6 Nov 2026, the panel rates Defguard (3.5/5), Firezone (3.5/5) and Cloudflare Zero Trust (3.5/5) highest among the other 12 Business VPN & Zero Trust Access products evaluated. Ratings that look equal are rounded to half stars; the order uses the unrounded rating, then the name. The highest-rated European alternative is Defguard (EU-Made). Ratings are the AI panel’s opinion, formed from public evidence: how scores are made. The full list, with European products first: Tailscale alternatives.
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 5 Nov 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- Weak sourcing — Open source, Data processing agreement. Not confirmed on the vendor’s own pages as captured.
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- 16 product facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 5 compliance facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 4 integrations facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 2 legal facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 2 support facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 2 sovereignty dimensions could not be confirmed on the vendor’s own pages and are shown as unknown. Know more? Tell us
Sources (22)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Vendor homepage tailscale.com Checked 5 Nov 2026 Details →
- 2 Features page tailscale.com Checked 5 Nov 2026 Details →
- 3 Features page (zero trust networking) tailscale.com Checked 5 Nov 2026 Details →
- 4 Documentation tailscale.com Checked 5 Nov 2026 Details →
- 5 Documentation (access control) tailscale.com Checked 5 Nov 2026 Details →
- 6 Documentation (logging) tailscale.com Checked 5 Nov 2026 Details →
- 7 API documentation tailscale.com Checked 5 Nov 2026 Details →
- 8 Pricing page tailscale.com Checked 5 Nov 2026 Details →
- 9 Terms of service (names the contracting entity) tailscale.com Checked 5 Nov 2026 Details →
- 10 Privacy policy tailscale.com Checked 5 Nov 2026 Details →
- 11 Data processing agreement (dpa) tailscale.com Checked 5 Nov 2026 Details →
- 12 Security / trust page tailscale.com Checked 5 Nov 2026 Details →
- 13 Access model & connectivity — found from sitemap tailscale.com Checked 5 Nov 2026 Details →
- 14 Access model & connectivity — found from sitemap tailscale.com Checked 5 Nov 2026 Details →
- 15 Identity, access policy & device posture — found from sitemap tailscale.com Checked 5 Nov 2026 Details →
- 16 Identity, access policy & device posture — found from sitemap tailscale.com Checked 5 Nov 2026 Details →
- 17 Logs, audit trail & incident response — found from sitemap tailscale.com Checked 5 Nov 2026 Details →
- 18 Logs, audit trail & incident response — found from sitemap tailscale.com Checked 5 Nov 2026 Details →
- 19 Deployment, API & administration — found from sitemap tailscale.com Checked 5 Nov 2026 Details →
- 20 Deployment, API & administration — found from sitemap tailscale.com Checked 5 Nov 2026 Details →
- 21 Architecture, reliability & security assurance — found from sitemap tailscale.com Checked 5 Nov 2026 Details →
- 22 Architecture, reliability & security assurance — found from sitemap tailscale.com Checked 5 Nov 2026 Details →