Notifications
Clear all
Topic starter
02/08/2026 12:31 pm
TL;DR: Node-cloning risk is reduced when attackers can read disk-backed keys, as Tailscale’s 1.86 release encrypts client state files at rest on Windows, Linux, macOS, and Android, according to Tailscale. The change tightens NHI credential protection, but it also exposes how much identity trust still depends on OS-specific storage and migration behaviour.
NHIMG editorial — based on content published by Tailscale: Encrypting data at rest, one OS at a time
Questions worth separating out
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.
Q: Why does encryption at rest not fully solve NHI risk?
A: Because the decisive failure often happens after the attacker reaches privileged execution.
Q: What breaks when machine identity state can be copied between hosts?
A: The assumption that one device equals one identity breaks down.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Tailscale's post on encrypting client state at rest →
Tailscale state encryption: what it means for node cloning risk?
Explore further
02/08/2026 1:29 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Tailscale state encryption narrows node-cloning risk on disk
