FR: Auto-Renewal (Key Rotation) + Admin Revocation for Headless Node Keys

[PaulCharlton]

What are you trying to do?

Problem:
Tailscale node keys currently expire by default (typically every 90 days), even on headless systems, with no built-in mechanism to:
• Auto-renew keys prior to expiration
• Re-authenticate a locked-out node remotely
• Revoke or rotate a node key via the admin panel or API

This creates critical operational risk for production systems (IoT, remote VMs, servers, etc.) that are not regularly logged into. Once a key expires, access is fully lost unless physical or alternative network access is available — which defeats the purpose of a zero-config overlay network.

How should we solve this?

We propose two core features to make Tailscale production-safe and ops-friendly:

1. Auto-Renewal / Key Rotation for Headless Nodes
   • Enable node key rotation via a local agent or background process
   • Configurable via tailscale up or ACL tags (e.g., "autorenew": true)
   • Ensures keys are refreshed securely without human interaction
   • Minimizes downtime and service interruption for unattended nodes

2. Manual and Automated Revocation
   • Allow admins to revoke node keys from the Tailscale admin console or API
   • Support scheduled or conditional revocation (e.g., “expire after 7 days” or “if node goes offline for X hours”)
   • Audit log for revocation actions, including reasons and actor
   • Optional: auto-generate new auth key and notify admins for fast recovery

What is the impact of not solving this?

Without these capabilities, Tailscale risks being brittle and unusable for production environments that rely on headless systems, especially at scale. These are foundational lifecycle controls that should be native to any identity-based access solution.

Anything else?

No response

[stevetrease]

Why not just disable key expiry on the nodes you are worried about?

[PaulCharlton]

Why not just disable key expiry on the nodes you are worried about?

Hi Steve, great question — and yes, disabling key expiry can help in some cases, but it’s not a real solution at scale or in dynamic environments. Here’s why:

1. Disabling expiry is not a safe default

It’s a manual workaround that:
• Requires preemptive action on every node
• Introduces security risk by leaving long-lived credentials untouched
• Breaks down entirely in dynamic or ephemeral deployments (e.g., autoscaling VMs, CI runners, remote field devices)

2. No path to recover a locked-out node

Once a key expires, there’s no built-in way to re-auth the node remotely — even if you later disable expiry. At that point, you’re locked out unless you have out-of-band access (which many don’t, by design).

3. Tailscale markets itself as zero-config, production-safe, ops-friendly

But this behavior is brittle and fails silently. An unattended prod server going offline due to a key expiration it can’t self-renew breaks that promise.

⸻

So this isn’t just about avoiding expiry — it’s about robust lifecycle management:
• Secure, automated key rotation
• Admin visibility and revocation
• Preventing dead-end lockouts in unattended systems

We believe these are table-stakes for any identity-based overlay network, and would love to see them considered as first-class features.

Thanks for engaging — happy to expand further if helpful.

—Paul

PS: Rendering a remote, lights-out server inoperable due to TS key expiry — where the only recovery is physical access — is a non-starter at scale.

Perhaps a workable middle ground: expired nodes could be quarantined into an “admin-only” control plane — removed from normal mesh traffic, but still reachable by authorized admins (e.g., via SSH proxy or audit access) to review, recover, and re-federate the node securely without requiring someone to physically touch the box.

This would massively reduce risk and improve confidence in using TS for real infrastructure.

Thanks again for engaging. Happy to help scope this further.