Multiple tailnets are separate network instances within one organisation. They let teams isolate development, testing, production, or customer connectivity while keeping a shared identity provider. Each tailnet can maintain its own policy, tags, devices, and settings, which reduces operational coupling and limits accidental impact across environments.
Expanded Definition
Multiple tailnets are a segmentation pattern in which one organisation runs separate network instances for different trust zones while retaining a common identity foundation. In practice, this lets a team isolate development, staging, production, or customer-specific connectivity without duplicating identity lifecycle processes. The term is used most often in environments that rely on identity-aware networking, where policy follows the NHI or device rather than the subnet. That makes multiple tailnets less about routing alone and more about reducing blast radius through distinct policy boundaries.
Definitions vary across vendors, because some products describe this as tenant separation, environment segmentation, or distributed private networking. The key distinction is that a multiple-tailnet model creates operational separation while still allowing shared administration and governance controls. It is closely related to Zero Trust Architecture principles in the NIST Cybersecurity Framework 2.0, but it is not the same as a general VLAN strategy. The most common misapplication is treating separate environments as if they were one tailnet with broad policy exceptions, which occurs when teams prioritise convenience over explicit trust boundaries.
Examples and Use Cases
Implementing multiple tailnets rigorously often introduces more policy design and lifecycle overhead, requiring organisations to weigh stronger isolation against higher administrative complexity.
- A software company uses one tailnet for engineering laptops and another for production workloads so that debug access cannot spill into live systems.
- A platform team creates customer-dedicated tailnets for regulated clients, aligning access paths with contract boundaries and support processes.
- A security team separates test automation from internal admin services, then assigns distinct tags and ACLs to prevent accidental cross-environment access.
- An organisation maps the model to guidance discussed in The State of Secrets in AppSec because environment separation also helps reduce secret reuse and exposure.
- Teams evaluating AI-connected tooling compare the pattern with identity and access guidance in NIST Cybersecurity Framework 2.0 when deciding how much connectivity a given agent or service should receive.
Why It Matters in NHI Security
Multiple tailnets matter because they turn network segmentation into an identity governance control. When every environment shares one broad mesh, a compromised credential, mis-tagged device, or overly permissive service account can move laterally into systems that were supposed to remain separate. This is especially important for secrets handling, where one exposed token can become a path into multiple operational domains. NHIMG research shows that only 44% of developers are reported to follow security best practices for secrets management, which means policy boundaries have to compensate for real-world human inconsistency, not ideal behaviour. The DeepSeek breach illustrates how exposed credentials and overshared systems can cascade into much larger access problems when boundaries are too loose.
For NHI governance, the practical question is not whether a tailnet exists, but whether each one has its own access rules, logging, and recovery assumptions. A shared identity provider can be safe only if policy stays environment-specific and secrets are not repurposed across zones. Organisations typically encounter the cost of weak separation only after a credential leak, misconfiguration, or lateral movement event, at which point multiple tailnets become operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 | Covers segmentation and isolation patterns that reduce NHI blast radius across environments. |
| NIST CSF 2.0 | PR.AC-3 | Addresses access enforcement and segmentation needed for environment-specific network boundaries. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust emphasizes resource isolation and controlled communications between trust zones. |
| NIST SP 800-63 | Identity assurance underpins shared identity providers used across separate tailnets. | |
| OWASP Agentic AI Top 10 | AG-04 | Agentic systems need constrained network reach so tool access does not exceed intended scope. |
Separate environments and service paths so one compromised identity cannot traverse every tailnet.
Related resources from NHI Mgmt Group
- How do organisations govern multiple tailnets without creating identity sprawl?
- How should enterprises govern AI agents across multiple clouds and SaaS platforms?
- How should security teams audit privileged access across multiple clouds?
- How should organisations govern machine identities across multiple regions?
