Business and ownership
I am an IT leader
Assess the business outcome, division of responsibilities, commercial model and a controlled path forward.
Tailscale guide for business
Tailscale provides the connectivity and policy layer. We make the access path production-ready.
At its core, Tailscale provides identity-based, WireGuard-encrypted connectivity and distributed access-policy enforcement. Defense First defines, tests and maintains who or what may connect to each resource — and with which network or supported application capability.
Choose your perspective
Start with the decisions you own.
The same access path looks different from business, security and implementation perspectives. These routes take you directly to the content that supports your decision.
Controls and evidence
I am a security lead
Review scope, positive and negative tests, log evidence and the controls that remain outside Tailscale.
Architecture and lifecycle
I am an infrastructure/platform engineer
Go directly to the technical decisions around policy, routing and an automated lifecycle.
Customer outcome
A working connection also needs scope, evidence and an owner.
The platform provides connectivity and policy enforcement. A production-ready access model emerges only when resources, identities, conditions, tests and changes form a manageable whole.
Private connection
The selected service does not need to be exposed through a public ingress port.
Traffic is protected with WireGuard and, whenever possible, travels directly between devices.
Explicit policy
Every allowed access path has a named source, destination and network or supported application capability.
Grants policy replaces broad default connectivity with customer-approved rules.
Ongoing manageability
A change can be justified, tested, approved and rolled back when needed.
Policy, test results, ownership and maintenance instructions remain together.
Public use cases
Four public examples of how organisations use Tailscale.
The examples cover different starting points: a global VPN migration, Zero Trust access, a public AI-company customer reference and secure cloud development.
Source boundary
The summaries below are based on customer stories or customer references published by Tailscale or its customers. These organisations are not Defense First reference customers, and the examples do not describe Defense First deliveries. The reported outcomes have not been independently audited by Defense First.
Tailscale customer story
trivago — global VPN migration
trivago gradually moved from an unstable OpenVPN setup that routed international traffic through Europe to Tailscale. Connectivity across three cloud regions, ACL-scoped GitHub Actions traffic and Tailscale SSH reduced maintenance; users reported lower latency and fewer dropped connections.
Read the Tailscale customer storyTailscale customer story
Hugging Face — Zero Trust and multi-cloud
Hugging Face standardised fragmented remote and multi-cloud access with Tailscale. Okta SSO/MFA, SCIM, role-based ACLs and ephemeral GitHub Actions credentials automate the user lifecycle; the company estimates this saves tens of hours of manual work each month.
Read the Tailscale customer storyPublic Tailscale customer reference
Mistral AI — confirmed adoption
Tailscale names Mistral AI among the AI companies using Tailscale. Public sources do not describe Mistral AI's implementation or a measured outcome, so we do not infer architecture or benefit claims from them.
Read Tailscale's customer referenceCustomer technical account
Duolingo — private resources from Codespaces
Duolingo connected GitHub Codespaces development environments to private AWS resources with Tailscale. A relay node in its VPC, an automatically started Tailscale client and Google SSO make opening the secure remote-development connection repeatable.
Read Duolingo's technical accountSources checked 13 August 2026.
How implementation works
Identify. Model. Enforce. Demonstrate.
Technology and environments vary, but every delivery follows the same decision logic.
-
1
Identify
Name the user or workload, source device, critical resource, purpose and approver.
-
2
Model
Translate the business decision into groups, tags, tagOwners responsibilities, destinations and, when required, source-device posture conditions.
-
3
Enforce
Distribute Grants policy to Tailscale devices or to the subnet router representing the resource and enforcing allowed network access.
-
4
Demonstrate
Test the agreed allowed connection, named denied connections, rollback method and owner approval.
Installation alone does not mean restricted access.
The Grants model is deny by default, but the pre-created default policy in a new tailnet initially allows broad device-to-device traffic. A least-privilege policy must be designed and tested separately.
Clear division of responsibilities
Tailscale provides the connectivity and enforcement layer. Defense First turns it into an operating model.
Tailscale
Private connectivity and distributed policy enforcement
- WireGuard-encrypted connections
- node identities, user-identity association and tags
- Grants policies and selected posture conditions
- direct connectivity and encrypted relaying when required
- subscription-specific administrative, logging and SSH capabilities
Defense First
Architecture, acceptance and ongoing ownership
- resource, identity, group and responsibility model
- explicit Grants rules and policy tests
- alignment of IdP, MDM, EDR and SIEM responsibility boundaries
- implementation, rollback and documentation
- maintenance of changes, permissions and decisions within the agreed scope
Customer
Business permissions and supporting controls
- resource owners and access approvers
- user lifecycle, IdP and MFA
- endpoint maintenance and security
- application permissions and information protection
- monitoring and response unless agreed separately
Technical evidence
Policy must be readable, testable and recoverable.
The excerpt below is illustrative. Production policy selectors, posture conditions and other rules are defined for the customer's environment.
Grant
Restricted source, destination and port
{
"grants": [{
"src": ["group:ops"],
"dst": ["tag:prod-web"],
"ip": ["tcp:22"],
"srcPosture": ["posture:managed"]
}]
}
The Grant's ip capability allows a connection to the destination and port. A Grant can contain ip and/or app capabilities; an application capability has an effect only when the destination application reads and enforces it. Other read, write and administrative permissions remain controlled by the application.
Acceptance tests
Both intended and invalid connections are tested
- Allowed managed ops device → prod-web:22
- Denied device failing the posture condition → prod-web:22
- Denied ops user → prod-db:5432
Grants rules are additive. Tests are therefore evaluated against the entire policy, not by reading only one rule.
Connection type
Direct connection, configured peer relay, then DERP
Tailscale attempts to upgrade the initial relayed connection to a direct connection. If direct connectivity is not possible, it can use a configured peer relay before falling back to DERP. Relayed traffic remains end-to-end WireGuard encrypted; the relay does not decrypt its content.
Connection type, firewall requirements and performance are verified during acceptance testing.
Governed change
Git, approval and rollback version
Policy can be maintained in Git, where each change shows the diff, rationale, automated tests and approval. Reapplying a previously validated policy version provides controlled policy rollback; it does not automatically reverse changes already made in other systems.
Access-path lab
Explore what a single access decision is made of.
Choose a predefined source, device posture, destination and capability. The lab compares the request with one visible example rule and produces an acceptance test, evidence, owner and service recommendation.
Illustrative demo onlyThe result does not validate a Tailscale policy, the full Grants rule set or a production environment. Do not use the example excerpt in production as-is.
Identity → device → Grant → resource
- IdentityOps group member
- Device postureManaged device
- Grant capabilitytcp:22
- Resourcetag:prod-web
The request matches the example policy's only allowed path.
The source, device posture, destination and capability all match the illustrative Grant.
Example excerpt · not for production as-is
The Grant used for comparison
{
"grants": [{
"src": ["group:ops"],
"dst": ["tag:prod-web"],
"ip": ["tcp:22"],
"srcPosture": ["posture:managed"]
}]
}Acceptance tests
Test the intended path and its opposite.
- Positive test · expected: allowedOps group member + managed device → tag:prod-web / tcp:22
- Negative test · expected: deniedOps group member + unmanaged device → tag:prod-web / tcp:22
The test describes the expected result for this single example. The complete Grants policy is additive and must always be validated as a whole.
Evidence and accountability
A decision needs evidence and an owner.
- Evidence
- A versioned policy excerpt and the results of repeatable positive and negative acceptance tests.
- Owner
- The resource owner approves the need; the policy owner approves and maintains the rule.
Recommended service stage
Manage — maintain the approved access path, evidence and changes.
Explore the recommended service stage →Portable starting point
Copy the illustrative summary as input for an assessment.
Capabilities and boundaries
Capabilities are selected based on the use case, risk and subscription.
Open a technical detail to see both the capability and its key responsibility boundary.
Connectivity, control plane and data plane
Tailscale's control plane coordinates device discovery and distributes public keys, policies, DNS and route information. Each node enforces the cached policy in its own data plane. Actual data traffic moves between nodes with WireGuard encryption and does not pass through the Tailscale control plane.
User identities, node identities and tags
The customer's IdP authenticates the user and handles MFA. Tailscale binds the user identity to the user's node. Servers, containers and other workloads can use tags rather than a person's identity. tagOwners delegates who may assign a tag, while Owners, Admins and Network admins can apply any tag; tag-assignment rights are therefore privileged.
Grants and source-device posture conditions
Grants are the primary model for new policies. A Grant defines a source, destination and ip and/or app capability. Rules are additive, so access must be evaluated against the complete policy. Posture conditions apply to the initiating source device and can use operating-system, Tailscale-version, MDM or EDR attributes. MDM or EDR provides security state and is responsible for device remediation.
Subnet routers and legacy resources
A subnet router can provide connectivity to devices where Tailscale is not installed. A resource behind it does not receive its own Tailscale node identity or posture state. Policy is then enforced by the router representing the resource, and local-network boundaries are designed separately.
Tailscale SSH and reauthentication
Tailscale SSH can control authentication and authorisation for a Tailscale SSH connection. Check mode can require the user to reauthenticate with the IdP at defined intervals. This does not apply to standard SSH or other TCP connections over Tailscale.
Device approval, keys and Tailnet Lock
Device approval, available on all plans, prevents a device awaiting approval from sending or receiving tailnet traffic but does not demonstrate security state. Auth-key, OAuth and node-key lifecycles are designed for the use case. Tailnet Lock is an optional Personal- and Enterprise-plan protection for node-key distribution, not a default capability, and cannot be used at the same time as device approval.
Tailscale product context
Our current core focus sits within a wider Tailscale portfolio.
Defense First's standard services currently focus on Business VPN and identity-based infrastructure access: Grants, device controls, routing and connectors, Tailscale SSH, Kubernetes, automation and logging. Tailscale also offers product extensions for other use cases.
Border0 / PAM
Tailscale's beta privileged-access product adds application-aware access, approvals and session controls beyond core Tailscale SSH.
Aperture
Tailscale's beta AI gateway governs model access, credentials, policy and telemetry; Aperture Connectors are currently public alpha.
CI/CD, workloads and Edge & IoT
Tailscale packages connectivity for build pipelines, ephemeral workloads and fleets as additional product areas.
Portfolio context, not a service promise.
Border0, Aperture, CI/CD Connectivity, Workload Connectivity and Edge & IoT are not current standard Defense First deliverables. Scope, release stage, plan and support model must be assessed separately. Last verified: 29 July 2026.
Shared responsibility
A secure connection does not replace identity, endpoint, application, data or monitoring controls.
| Layer | Tailscale | Defense First | Customer and the rest of the control stack |
|---|---|---|---|
| Identity and MFA | Uses the user identity authenticated by the customer's IdP | Maps groups to policy and tests the offboarding path | Maintains users, MFA, approvals and lifecycle |
| Endpoint security | Can use defined posture attributes as a source condition | Designs conditions and tests their effect on connectivity | MDM/UEM and EDR/XDR provide the data and remediate the device |
| Connectivity and network policy | Encrypts traffic and enforces distributed policy | Models topology, tags, Grants rules and tests | Approves business permissions and maintains other network restrictions |
| Application permissions | Restricts network connectivity; application capabilities only in applications that support them | Documents the responsibility boundary between network access and application authorisation | The application owner manages roles, data and actions |
| Monitoring and response | Provides subscription- and configuration-dependent log sources | Defines export, review and reporting within the agreed scope | SIEM, SOC and threat response unless agreed separately |
| Information protection | Protects traffic on the Tailscale connection with WireGuard | Scopes and documents the access path | Classification, encryption at rest, DLP and application controls |
Logs without overpromising
Availability, retention and export depend on the log source, settings and subscription.
| Log source | What it shows | Availability and retention | Key boundary |
|---|---|---|---|
| Configuration auditing | Who changed the tailnet configuration, what changed and when; full diff for policy changes | All subscriptions, always enabled, 90-day history | No read operations or network-connection events |
| Network flow logs | Metadata for successful connections between nodes | Premium and Enterprise, enabled separately, 30-day history | No traffic content or complete record of denied attempts; the endpoint must send telemetry |
| Log streaming | Export of configuration and flow logs to a SIEM or storage service | Premium and Enterprise; external retention is defined in the customer's system | Export alone does not include monitoring, alerting or response |
| Tailscale SSH recording | Terminal output from separately configured Tailscale SSH sessions | Beta; Personal and Enterprise; requires a recorder node and SSH policy | No keystrokes or standard SSH; by default sessions fail open when recorders are unreachable unless enforceRecorder is enabled |
Technical expertise hub
Eight guides to support production decisions.
Each guide explains the mechanism, plan dependencies, responsibility boundaries and how the topic appears in Advice, Integrate or Manage.
Grants and access control
Source, posture, destination, ip/app capabilities, tags, ownership and whole-policy tests.
Device posture and device approval
Default posture, MDM/EDR signals, approval and device lifecycle.
Open guide →Routing and connectors
Subnet routers, site-to-site, exit nodes, app connectors, high availability and DNS.
Open guide →Tailscale SSH and JIT
SSH policy, check mode, reauthentication and session recording.
Open guide →Kubernetes Operator
Kubernetes API, ingress/egress, workload identities and connector models.
Open guide →GitOps, API and webhooks
Policy validation, OAuth scopes, auth keys and lifecycle automation.
Open guide →Logging and evidence
Audit, network-flow and SSH logs, export, retention and constraints.
Open guide →Subscriptions and licensing
Plan selection based on the use case, posture signals, logging and automation.
Open guide →Due diligence
Technical sources
- Control and data planes
- Direct, peer-relay and DERP connection types
- Tailscale Grants
- Device visibility and default policy
- Device posture management
- Shared responsibility model
- Tailscale SSH
- Configuration audit logging
- Network flow logs
- Tailnet Lock
- Border0 privileged access
- Aperture AI gateway
- Aperture Connectors
- Plans and platform extensions
Frequently asked questions
Technical boundaries before a production decision.
Does installing Tailscale automatically restrict traffic?
No. Grants rules are deny by default, but a new tailnet's pre-created default policy initially allows broad device-to-device traffic. Explicit policy and its tests are separate work.
Is the user reauthenticated for every connection?
Not generally. Tailscale devices enforce the policy distributed to and cached on them. Tailscale SSH check mode can require IdP reauthentication at defined intervals.
Does a Grant control read and write permissions within an application?
A Grant's ip capability controls connectivity to a destination, protocol and port. A Grant can also carry an app capability, but the destination application must interpret and enforce it. Other authorisation within the application remains with the application.
How does Tailscale work with devices where the client cannot be installed?
A subnet router can represent resources in a subnet. Devices behind it do not have their own Tailscale node identity or posture state, so routing and other controls are scoped separately.
Is Tailscale alone a complete Zero Trust solution?
No. Tailscale provides strongly encrypted connectivity, node identity and network-policy enforcement. The customer still needs identity, endpoint, application, data, monitoring and governance controls.
