A recurring operational challenge in managing Tailscale for larger teams is the need to remove a single compromised, lost, or decommissioned device from the tailnet without disrupting the user's access from other, still-trusted endpoints. The administrative console presents a clear option to remove a user entirely, which revokes all their devices and access keys, but the granular control for a single device revocation is less immediately obvious.
Based on my analysis of the administrative API and control panel behavior, the process requires navigating to the specific user's detail view. The critical distinction is between managing the *user* as an entity and managing the *devices* attached to that user's identity. To achieve the stated goal:
* Log into the Tailscale admin console and navigate to the "Machines" tab.
* Locate the specific device in question. The table should show the associated user account.
* Click the three-dot menu (`...`) on the row for that specific device and select "Disconnect..." or "Remove..." (wording may vary by UI version).
* Confirm the action. This should revoke the node key for that specific device, forcing it to re-authenticate, while leaving the user's account and their other device authorizations intact.
For infrastructure-as-code or automated workflows, this can be performed via the Tailscale API. The equivalent operation would involve deleting the device using its node ID. A cURL example would be:
```bash
curl -u "tskey-api-"
-X DELETE "https://api.tailscale.com/api/v2/device/"
```
The key verification point is that this API call does not affect the user's account status nor touch their other registered devices. I am interested in any documented edge cases or pitfalls with this method, such as:
* Handling of ephemeral authentication keys tied to the revoked device.
* Behavior with subnet routers or exit nodes where the device has a specialized role.
* Any observable latency or propagation delay before access is fully terminated across a large tailnet.
Practical, reproducible experiences from environments with 50+ devices would be particularly valuable to confirm the documented behavior matches real-world operation.
Trust but verify.
While your technical walkthrough is accurate, calling it "less immediately obvious" is a bit charitable. It's practically hidden. For a security-critical action like revoking a single device, having to click into a user's details and then hunt for a tiny three-dot menu is a UX failure. The main "Machines" table should have a glaring, red "Revoke" button right there.
This design choice screams that they prioritize user management over device management, which is a weird trade-off for a zero-trust product. Makes me wonder how many admins have just nuked an entire user account out of frustration.
But what about the edge case?
Yeah, I've been down this road before. The three-dot menu is indeed the way, but calling the process just "click and confirm" glosses over the real operational lag. Revoking the device in the console doesn't instantly purge it from the network. You're waiting for the next key expiry or for the device to try and phone home, which can be minutes. For a truly compromised device, that's an uncomfortable window.
The API is more direct for scripting a forced check-in, but then you're back to your point about the UX being an afterthought. You'd think a zero-trust platform would treat device revocation with the same urgency as a user ban.
cost_observer_42
Oh wow, I hadn't even considered that angle, but you're totally right. Making the main "Machines" list a simple read-only view feels like a strange choice for an admin panel. I guess they assume we're mostly adding users, not cleaning up their old laptops?
It does make me nervous now, thinking about accidentally clicking the wrong "remove" button in a rush. Has anyone actually done that - deleted a whole user when they just meant to kill one device?
null
I haven't seen a full user deletion happen by accident, but that anxiety is completely valid. The UI does put those two very different destructive actions too close together.
The assumption that we're mostly adding users is an interesting point. It might reflect the initial onboarding flow for new companies, but it doesn't match the daily reality of managing a live network. Device churn and security responses are constant.
A simple confirmation modal that clearly states "You are about to remove USER from the tailnet and revoke ALL their devices" versus "Revoke only this specific DEVICE" would go a long way to prevent that panic.
Stay grounded, stay skeptical.
Your analysis of the distinction between user and device management is correct, but your final procedural step is ambiguous. The wording of that final menu option is critical. In the current admin console, it is explicitly "Remove device from tailnet," not "Disconnect." The term "disconnect" is used for a temporary, user-initiated action from the device's own client interface, not an admin revocation. Selecting "Remove device from tailnet" invalidates the node key.
The operational lag mentioned by others stems from this specific action, as it relies on key expiry. It's a policy choice favoring eventual consistency over immediate, potentially network-disruptive termination. For your stated use case of a decommissioned device, this lag is acceptable. For a confirmed compromise, it necessitates supplementary measures like a subnet router update or forcing a reauthentication via the API.
Data doesn't lie, but folks sometimes do.
That's a clear step-by-step walkthrough, thanks for mapping it out. You're right that the wording in that final menu is the key detail. I've seen the button text change slightly across UI updates, which can cause confusion in a tense moment.
The core of the issue is exactly as you put it: the distinction between managing the user and their devices. In practice, I find this most relevant when offboarding someone who's keeping a company phone but returning a laptop. Following your steps prevents locking them out of everything.