Standards Alignment
An educational mapping of TSLink to NIST SP 800-207 Zero Trust concepts. TSLink is not certified and this is not a compliance determination.
Scope and disclaimer
This page is an educational mapping between TSLink's shipped behavior and the concepts in NIST SP 800-207. TSLink is not certified against NIST SP 800-207 or any other standard, and nothing here is a compliance determination. Read it as "which zero-trust ideas TSLink borrows, and where its boundaries are," not as a conformance claim. The authoritative description of what TSLink actually does is the CLI README and the exported capability manifest.
Zero-trust concepts TSLink borrows
TSLink applies several zero-trust ideas to local services: services are private to your tailnet by default, the tailnet transport is WireGuard-encrypted, and HTTP proxy/file services can enforce a per-service allow-list. It brings these ideas to individuals and small teams in a single open-source binary. It is a single-operator gateway, not a Policy Decision Point, and it does not implement device posture, risk scoring, behavioral analysis, or compliance-certification controls.
NIST SP 800-207: Seven-Tenet Mapping
The table maps each of the seven tenets from Section 2 of NIST SP 800-207 to what TSLink actually does. "Coverage" describes how much of the tenet TSLink touches; it is never a certification.
| # | NIST SP 800-207 Tenet | TSLink behavior (bounded) | Coverage |
|---|---|---|---|
| 1 | All data sources and computing services are considered resources. | Every service registered with tslink add gets its own embedded tsnet node with its own tailnet identity; HTTP services have a tailnet TLS listener, while raw TCP does not terminate TLS. This is per-service network identity / microsegmentation, not process or host isolation: TSLink does not sandbox the local process and does not prevent a compromised local service from reaching host or peer resources by other means. host_isolation is not_provided. | Partial (network identity only) |
| 2 | All communication is secured regardless of network location. | The leg between an accessing tailnet device and the TSLink node is WireGuard-encrypted (including when relayed through Tailscale DERP). The backend hop from the TSLink node to your local service is plain HTTP/HTTPS or plain TCP as you configure it, and may be plaintext. Raw TCP services have no TSLink TLS termination. Communication is not end-to-end encrypted across the whole path. | Partial (tailnet leg only) |
| 3 | Access to individual enterprise resources is granted on a per-session basis. | Private HTTP/file people policy reads local grants and checks WhoIs and deadlines on each request. Legacy-only --allow authorization and best-effort proxy identity headers retain their 60s source-IP cache. Configured identity gates fail closed; ordinary services without either policy can pass permitted tailnet callers. Accepted streams can finish after revocation. | Partial (HTTP request gates; no universal session revocation) |
| 4 | Access to resources is determined by dynamic policy... | TSLink enforces private HTTP/file people grants, absolute deadlines, deny records and legacy allow rules, with registry updates. It does not implement device posture, behavioral analysis or risk scoring. | Partial |
| 5 | The enterprise monitors and measures the integrity and security posture of all owned and associated assets. | Bounded local access history carries typed HTTP/TCP/guest events and WhoIs-attested identity when available; mutation intent/completion and lifecycle receipts are independently bounded. Identity may be absent; drops and crash gaps remain. No Prometheus endpoint, flow analysis or host-wide posture inventory is shipped. See access history. | Partial |
| 6 | All resource authentication and authorization are dynamic and strictly enforced before access is allowed. | Inbound Tailscale identity headers are stripped on proxy requests. Applicable people policy or configured --allow can deny before the backend/file content. Raw TCP and public Funnel do not use these HTTP caller identity gates; backend authentication remains required where the app needs it. | Partial (bounded HTTP enforcement) |
| 7 | The enterprise collects as much information as possible... | Bounded local access history carries typed HTTP/TCP/guest events and WhoIs-attested identity when available; mutation intent/completion and lifecycle receipts are independently bounded. Identity may be absent; drops and crash gaps remain. No Prometheus endpoint, flow analysis or host-wide posture inventory is shipped. See access history. | Partial |
TCP Services: Scope Note
TSLink supports HTTP reverse proxy, file server, and TCP forwarder services. The tenet mapping's application-layer parts apply only to HTTP proxy and file services.
TCP forwarding operates at the transport layer. TCP traffic is forwarded byte-for-byte with no HTTP processing: TSLink does not inject identity headers, does not perform application-layer access control, and does not terminate TLS on raw TCP. The backend hop to your TCP target is plain TCP.
TCP services still inherit network-layer properties:
- WireGuard-encrypted tailnet transport on the tailnet leg to the TSLink node (the backend hop to your target is plain TCP)
- Tailscale ACL policies controlling which tailnet members can reach the service (network-level access control, configured in Tailscale, not TSLink
--allow) - Per-service tailnet identity (a network identity, not process/host isolation)
- No public internet exposure by default
HTTP services can receive network-layer transport plus TSLink's optional --allow application-layer check. TCP services receive network-layer transport only.
For Non-Technical Readers
Zero-trust networking is based on one idea: do not assume a connection is safe just because it comes from inside your network. TSLink applies parts of this to your local services.
Two honest caveats. First, "encrypted" here means the connection from a tailnet device to the TSLink node is WireGuard-encrypted; the short hop from the TSLink node to your actual local service is whatever you configured (often plain HTTP or plain TCP). Second, giving each service its own tailnet identity is a network boundary, not a sandbox: if one local service is compromised, TSLink does not by itself stop it from reaching other things on the same machine.
Use this mapping to understand the shipped controls and their limits. TSLink is not certified, and this page is not a compliance determination. Deployment security also depends on tailnet policy, host isolation, and backend authorization.