Prepare signing-node and disablement recovery before enabling Tailnet Lock

Tailnet Lock moves admission authority onto trusted nodes and creates a separate recovery dependency.

Source facts

Tailnet Lock requires new node public keys to be signed by trusted signing nodes before peers accept connections. Tailscale’s setup procedure asks administrators to select at least two signing nodes. Initialization creates disablement secrets that are displayed only at that time; a secret authorizes disabling Tailnet Lock. The documentation warns that losing those secrets without supplying a support disablement option can prevent recovery of the tailnet. Nodes use an initial trust-on-first-use state, and administrators can compare their reported trusted signing keys.

Source: Tailscale — Tailnet Lock.

Applicability

This is a planning guide for Tailnet Lock, not a command sequence to enable it on a production network. Check current plan eligibility and supported client versions before scheduling a change.

DSE recommendation

DSE recommends assigning separate custodians to signing nodes and recovery material. Avoid placing every signing node behind the same operational dependency. Store disablement secrets in approved protected storage with a documented access process, and decide deliberately whether to provide the optional support recovery secret. Record the expected trusted public keys independently of the setup screen. Review how a new node is admitted, how a lost signer is replaced, and how emergency disablement would be authorized before enabling enforcement.

Verification

Pilot with disposable nodes first. Compare the trusted-key list on participating nodes, admit one intended node through the documented signing flow, and verify that an unsigned node remains excluded. Check that authorized custodians can locate recovery instructions without exposing disablement secrets in ordinary tickets.

Official reference

Tailscale — Tailnet Lock. Reviewed October 15, 2026.