Tailscale state encryption narrows node-cloning risk on disk

At a glance

What this is: Tailscale is encrypting client state at rest to make copied node credentials harder to reuse elsewhere.

Why it matters: This matters because endpoint compromise often turns into non-human identity abuse when private keys, settings, and device trust material sit unprotected on disk.

👉 Read Tailscale's post on encrypting client state at rest

Context

Non-human identity risk is not only about token theft in transit. It also shows up when long-lived device state, private keys, and client settings are stored on disk in a form that can be copied, replayed, or used to impersonate a node after the original system is no longer under control.

In Tailscale’s case, the issue is node cloning, where an attacker with root-level filesystem access can copy the state file and reuse the credentials on another machine. The article’s core point is that protecting the stored state narrows the abuse window, but it does not change the trust assumptions that exist once an attacker can execute as root or read memory.

Key questions

Q: How should teams handle machine identity after a host compromise?

A: Treat the identity as potentially reusable by the attacker, even if the filesystem was encrypted. Revoke the node, rotate the underlying credentials, and require fresh registration before the device returns to production. The goal is to eliminate trust in copied state, not just protect the file after the fact.

Q: Why does encryption at rest not fully solve NHI risk?

A: Because the decisive failure often happens after the attacker reaches privileged execution. If they can read memory or run code as root, they can still use the identity while it is live. Encryption helps against disk theft and low-effort copying, but it does not protect a compromised runtime.

Q: What breaks when machine identity state can be copied between hosts?

A: The assumption that one device equals one identity breaks down. A copied state file can let an attacker impersonate the original node from a different machine, which means your access control and audit trail no longer map cleanly to a single endpoint. That creates containment and attribution problems.

Q: How do security teams know whether node cloning is still possible?

A: Check whether the identity state is still recoverable from disk, whether hardware-backed protection is enabled, and whether the node can be registered on another host using copied files. If any of those are true, clone resistance is weak. Validation should include restore, reimage, and post-incident scenarios, not only steady-state configuration checks.

Technical breakdown

Node state files and identity material

Tailscale’s state file stores the machine private key, WireGuard node keys, Tailnet Lock private keys, and per-tailnet client settings. Those are not just preferences. They are identity material that binds a node to the coordination plane and to peers in the mesh. If an attacker can copy that file after gaining read access as root, they may be able to rehydrate the node’s identity on another machine. Encryption at rest reduces the value of that copy, but it does not remove the operational dependency on how the OS stores and protects the underlying secrets.

Practical implication: Treat node state as identity-bearing secret material and classify it with the same rigor you apply to credentials and certificates.

TPM, Keychain, and hardware-backed key protection

The implementation relies on OS-specific mechanisms to protect the encryption key rather than keeping the state file plaintext. On Windows and Linux, Tailscale uses a symmetric key sealed with the TPM. On Apple platforms, it uses Keychain-backed storage, and on Android it uses encrypted shared preferences with hardware support. The architectural pattern is the same: encrypt the file with a local symmetric key, then place the key behind platform controls that are harder to export. That improves resilience against simple disk theft and low-effort infostealers, but it still depends on OS integrity and runtime protection.

Practical implication: Map platform-specific storage mechanisms to your device trust model, especially where root access or local privilege escalation is plausible.

Why encryption at rest is not the same as runtime protection

The article is explicit that encryption at rest does not help once the attacker can read process memory or execute code as root. At that point, the decrypted keys exist in runtime and the attacker can act as the node regardless of the state-file format. That distinction matters because many identity programmes assume file protection equals identity protection. It does not. The real boundary is whether the attacker can cross from filesystem access into live process state or privileged execution.

Practical implication: Separate disk exposure controls from runtime compromise controls when assessing whether an NHI is actually contained.

Threat narrative

Attacker objective: The attacker wants to reuse a stolen node identity to impersonate the compromised device from a different machine.

1. entry: an attacker gains read access to the host filesystem as root through local compromise or a path traversal style flaw, allowing them to locate the Tailscale state file.
2. escalation: the attacker copies the unencrypted state file or extracts its contents while the node remains locked down, preserving the private keys and client settings needed for reuse.
3. impact: the attacker reuses the copied node identity on another machine and impersonates the node, creating a node-cloning event that survives after the original compromise is remediated.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Node cloning is an identity abuse problem, not just a storage problem. The article is really about what happens when a machine identity can be copied after local compromise. Encrypting the state file lowers the chance that an attacker can reuse disk-resident credentials, but the underlying governance issue is that the node identity still exists as portable trust material. Practitioners should treat copied state as a reissuance and revocation problem, not merely a file-security issue.

Standing node trust creates a reusable blast radius. Tailscale’s design shows how one compromised host can carry durable identity state that remains valuable even after the original compromise is contained. That is a classic NHI control challenge: secrets and keys persist longer than the incident lifecycle that exposed them. The implication is that offboarding, revalidation, and trust reset must be part of endpoint recovery for machine identities.

Runtime protection matters more than encryption labels. The article makes clear that if an attacker can read memory or execute code as root, state-file encryption stops being a meaningful boundary. That is the broken premise many teams miss: protecting data at rest does not equal protecting live identity. Practitioners need to evaluate where the trust boundary actually sits, and whether a local privileged process can still act as the identity even when storage is encrypted.

Platform-specific identity storage is now a governance decision. TPMs, Keychain, and Android Keystore are not interchangeable implementation details. They shape how recoverable, portable, and auditable a machine identity becomes after compromise. The broader lesson for NHI governance is that storage architecture directly affects revocation speed, clone resistance, and incident containment. Teams should decide whether their machine identities are meant to be recoverable artifacts or tightly bound to one runtime instance.

Encrypted state reduces casual abuse, but not privileged abuse. This is the important line in the design: the feature blocks low-effort copying, not a determined actor with root-level execution. That distinction mirrors the rest of NHI governance, where control strength often collapses once the attacker reaches the same privilege tier as the identity itself. Practitioners should focus on the privilege conditions under which identity can still be reconstructed or reused.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a broader breach pattern view, the 52 NHI breaches Report shows how exposed non-human credentials can persist into later stages of compromise.

What this signals

Identity blast radius: once a node’s state can be copied, the practical blast radius is no longer limited to the original host. That matters for recovery planning because clone resistance, revocation, and re-registration become part of the same control problem, especially where root access on the endpoint is in scope.

With 43% of security professionals concerned about AI systems learning and reproducing sensitive information patterns from codebases, per The State of Secrets in AppSec, the governance lesson is broader than Tailscale itself. Teams need to assume that identity material may be re-exposed in places they did not intend, then design detection and containment around that assumption.

For practitioners

• Inventory node identities as reusable trust assets Identify where machine identity state, private keys, and client settings are stored on disk and classify them as NHI assets rather than ordinary configuration. Prioritise systems where root access or local privilege escalation would let an attacker copy the state file and reuse it elsewhere. A useful starting point is to map those assets against the controls in the 52 NHI Breaches Analysis.
• Bind state protection to device trust policy Use platform controls such as TPM, Keychain, or equivalent hardware-backed storage where available, and make the encryption state policy part of your device posture baseline. Validate how the node behaves during reimage, migration, and restore so that identity does not silently survive in an unintended form. Where the platform offers it, check for attributes such as node:tsStateEncrypted during compliance review.
• Test clone resistance after local compromise Run a recovery exercise that assumes the attacker has already read the filesystem as root and copied the identity state. Verify whether the node can be reconstituted on another machine, whether revocation is immediate, and whether device approval or posture gates can block reuse. This is the practical test of whether encryption at rest actually changes the trust outcome.
• Revoke and reissue machine identity after containment When a host compromise is confirmed, treat the state file as burned even if it was encrypted. Rotate the machine keys, revoke the node identity, and force re-registration before the device is allowed back into production access paths. Recovery should assume that a copied NHI state file can outlive the incident unless explicitly invalidated.

Key takeaways

• Encrypted state files reduce casual node cloning, but they do not eliminate the risk once an attacker reaches privileged execution.
• The most relevant failure mode is copied machine identity state that survives after the original compromise has been contained.
• Teams should treat node revocation, key rotation, and re-registration as part of incident response for machine identities, not optional cleanup.

Key terms

• Node cloning: Node cloning is the reuse of a copied machine identity on another host so it appears to be the original device. In NHI terms, this is a trust failure, not just a file-copy problem, because the attacker inherits keys, settings, and identity continuity after compromise.
• State file encryption: State file encryption is the practice of protecting persisted client identity data with a symmetric key so the raw file is not directly usable if copied from disk. For machine identities, it reduces low-effort theft, but it still depends on the runtime and the platform that protects the key.
• Hardware-backed key protection: Hardware-backed key protection stores or seals encryption material in a TPM, secure enclave, or equivalent system so the application never needs to keep the key in plaintext on disk. It improves resistance to casual extraction, but it does not stop abuse when an attacker already controls the runtime.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

What's in the full article

Tailscale's full blog post covers the implementation detail this post intentionally leaves for the source:

• The TPM and Keychain storage choices behind state-file encryption on Windows, Linux, macOS, and Android.
• The migration behaviour for existing nodes when encryption is enabled or rolled back.
• The Linux and macOS-specific policy and command-line settings used to turn the feature on.
• The failure cases Tailscale observed during 1.86.0 and how 1.86.2 corrected them.

👉 Tailscale's full blog post covers the OS-specific implementation, migration behaviour, and rollout caveats.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.