Operate the tailnet safely

A private network accumulates old devices and permissions unless someone deliberately removes them.

Nothing rots loudly. The old intern’s laptop stays enrolled, a test route stays approved, a forgotten reusable key stays valid. Each is harmless until one becomes the way in. Operating a tailnet is mostly scheduled subtraction.

The monthly review

Review device ownership and last-seen times, delete retired nodes, revoke unused auth and OAuth credentials, inspect advertised routes, update clients, and test important policy paths.

Concretely: walk the admin console machines list sorted by last seen, and question anything silent for a month. Check the keys page for auth keys and OAuth clients you cannot explain. Look at every approved subnet route and exit node and ask whether it is still needed. Routes are easy to approve and easier to forget.

Client versions matter too:

tailscale version
# 1.86.2

Old clients miss security fixes and path-negotiation improvements. After updating, re-run your policy tests and one real check of the critical path:

tailscale ping lab-server
ssh ubuntu@lab-server 'echo ok'

Keep a recovery path outside Tailscale

Keep a recovery method outside Tailscale for critical routers and servers. If Tailscale SSH is your only access and a bad policy edit locks you out, you cannot fix the policy that locked you out. A cloud console, a physical keyboard, or classic SSH on a tightly firewalled public port: something that does not depend on the system you are administering.

The lost-device runbook

Respond to device loss by revoking access first. Not “look for the laptop”, not “ask around”. Revoke, then investigate. A revoked device can be re-enrolled in minutes if it turns up in a jacket pocket. The reverse mistake has no undo.

Write a monthly checklist and a lost-device runbook. Include who can approve devices, edit policy, advertise routes, and recover a locked-out server. Names, not roles. A runbook that says “an admin” helps nobody at 2am.