The device loses the files that hold its machine key and related configuration, so it is no longer recognised as part of the tailnet. The endpoint must be reset and then re-authenticated through user login. This can affect ordinary laptops as well as servers, especially where key expiration is disabled and the machine is expected to remain continuously trusted.
Why the device stops being trusted after Windows wipes Tailscale’s local state
When the local state is removed, Tailscale loses the endpoint’s locally stored machine key and the configuration that ties that install to the tailnet. From the network’s point of view, it is no longer the same trusted node, even if the hardware has not changed. The practical result is a fresh identity establishment step rather than a seamless reconnect.
The key point is that this is not a normal session refresh. The endpoint’s prior trust relationship has been erased at the client side, so the service cannot simply resume the old device identity. That is why the machine must be reset and then re-authenticated through user login before it can rejoin with a new trusted state.
This behaviour is especially noticeable on long-lived systems such as servers, where the endpoint may be expected to stay continuously enrolled. When key expiration is disabled, operators can overlook how much the local state itself becomes part of the trust boundary, because a disk cleanup, profile reset, or OS action can have the same effect as an intentional re-provisioning event.
What changes operationally for laptops and servers
On an ordinary laptop, wiping the local state usually looks like a lost device registration followed by a normal user re-login. The endpoint comes back, but it comes back as a newly trusted client rather than as the old one continuing its prior membership.
On a server, the operational impact is higher because the machine may host stable services that depend on uninterrupted connectivity. If the server is expected to remain present in the tailnet, a wiped local state can break inbound management paths, automation hooks, and any assumption that the node’s identity will survive routine OS maintenance.
That distinction matters because the failure is about trust continuity, not just connectivity. A server that silently re-enrolls under a fresh identity may need additional review, especially if the old identity was used in firewall rules, access lists, or operational runbooks that assume the endpoint keeps the same membership.
Why reset and re-authentication are the correct recovery path
The safest recovery is to treat the endpoint as untrusted until it has been reset and re-established through the normal login flow. That ensures the new installation state is issued under current policy, current approvals, and current access conditions rather than inheriting stale trust from an erased client record.
For administrators, the useful mental model is that local identity material is part of the device’s security state. Once it is gone, the old trust anchor is gone with it. Re-authentication is therefore not a workaround, it is the mechanism that recreates a valid device relationship.
In environments where device continuity matters, this also creates an inventory and lifecycle issue: the team needs to know which endpoints can be re-enrolled automatically, which require manual approval, and which must be treated as replacement devices after local state loss.
Risk and Threat Considerations
Loss of local state can create more than inconvenience, because it can also break the continuity of a trusted endpoint and force an operational reset at the exact moment teams expect the device to stay available. If the device was meant to remain permanently enrolled, the wipe can expose a gap in access control, recovery planning, or endpoint governance.
Failure mechanism: The local machine key and associated state are deleted, so the service can no longer bind the endpoint to its previous trusted identity and the old membership is invalidated.
Impact: The node drops out of the tailnet, automation or remote administration paths may fail, and the endpoint must be deliberately re-provisioned before it is safe to trust again.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Local machine keys and re-authentication depend on credential lifecycle control. |
| IA-9 — Service Identification and Authentication | Tailscale endpoints authenticate as non-human nodes using stored machine identity material. | |
| Recommendation — Track machine-key lifecycle and require re-enrollment after local state loss. Treat each endpoint reset as a new service authentication event. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Endpoint trust depends on maintaining and re-establishing device identity records. |
| Recommendation — Maintain authoritative records for device re-registration and trust revocation. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Wiped local state effectively offboards the device until it is re-established. |
| NHI-07 — Long-Lived Secrets | Continuously trusted endpoints rely on durable local secrets and keys. | |
| Recommendation — Require deliberate offboarding and re-onboarding handling for lost endpoint state. Review whether long-lived machine keys should be replaced or time-bound. | ||
Practitioner Guidance
What to verify: Confirm whether the endpoint is supposed to survive state loss as the same trusted device or whether it should be treated as a fresh enrollment every time. That decision changes how you handle servers, build images, profile resets, and OS reinstalls.
What to prioritise: For any endpoint that carries operational dependencies, check the recovery path before you need it. The important question is not whether the device can reconnect, but whether it can reconnect without breaking policy, ownership, or downstream access assumptions.
Common mistake: Treating a wiped install as a minor connectivity issue. In practice, it is a trust-reset event, so the right response is to re-establish the device intentionally rather than assume the old state still exists.
Practitioner takeaway: If local state is the thing that anchors endpoint trust, losing it should be handled like losing the device identity itself, not like a temporary network outage.
Related resources from NHI Mgmt Group
- What happens when ransomware deletes shadow copies and system state backups on a Windows endpoint?
- What happens when BlackCat ransomware is executed on a Windows endpoint without recovery controls?
- What happens when a self-signed certificate is used on Windows without importing the root CA certificate on client machines?
- What happens when a malicious Follina document is opened on a Windows endpoint?
