# Prepare signing-node and disablement recovery before enabling Tailnet Lock

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

- Canonical URL: https://update.dsesecurity.com/updates/tailscale-tailnet-lock-signing-disablement-recovery/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-15T13:33:17+00:00
- Modified: 2026-10-15T13:36:16+00:00
- Last reviewed by DSE: 2026-10-15
- Resource type: Guide
- DSE priority: Information
- Topics: Business Continuity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

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

## Potentially affected

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.

## Article

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](https://tailscale.com/docs/features/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](https://tailscale.com/docs/features/tailnet-lock). Reviewed October 15, 2026.

## Primary reference

- Name: Tailscale — Tailnet Lock
- Authority: tailscale.com
- URL: https://tailscale.com/docs/features/tailnet-lock
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Prepare signing-node and disablement recovery before enabling Tailnet Lock,” DSE Security, https://update.dsesecurity.com/updates/tailscale-tailnet-lock-signing-disablement-recovery/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.