>Secure node state storage can help protect against a malicious actor copying node state from one device to another, effectively cloning the node. By using platform-specific capabilities, Tailscale ensures node state encrypts at rest, making theft from disk and node cloning more difficult.

Marketing blogpost - https://tailscale.com/blog/encrypting-data-at-rest:

>What we really care about here are those private keys stored in the state file, since those are used to identify your node to the coordination server and to other nodes. We need to protect them from exfiltration.

>If the Tailscale state file is unencrypted, an attacker with that kind of root access could use the file’s contents from a different machine and impersonate your node. From the perspective of the Tailscale coordination server, it’s as if your device switched to a different network and got a new IP address. We call this attack “node cloning”.

TL;DR If you care about the stuff mentioned in that blog post (which most sensible sysadmins would) then the implication is that you are no longer protected against those threat scenarios UNLESS you manually apply the flag at install time.

Which means for people using deployment scripts/tools you now need to update those to put the flag in during installation. Because previously you could rely on the feature being "on by default", which is no longer the case.

[1]https://tailscale.com/blog/encrypting-data-at-rest

Could you elaborate ? Firmware/OS should not affect TPM contents ? Otherwise e.g. TPM-reliant Windows installs would break ?

In addition there are cloud scenarios where your VM has a TPM and you want to e.g .stop a malicious actor poaching your VM and running it elsewhere.

Having the tailscale TPM tied to your cloud hypervisor prevents the "lift and shift" attack.

Nobody says "disable disk encryption right away incase the tom forgets the keys". The vast majority of TPM's manage to not forget the keys.

Yes, just like >= 1.86, you set a flag during install.

But that's not the point.

The point is that >= 1.90.2 it became enabled by default.

The point is that most people would expect that "by default" to be a permanent fixture, i.e. a sane secure-by-default config.

This means that people with automated deployments based on >= 1.90.2 can no longer rely on the "by default" and this now needs to be flagged.

I would say it is because they made a big marketing blog post about it at the time[1] (August 2025). So clearly they considered it a significant new feature.

The blog post ended with the words "If we don’t spot any major regressions with 1.86, the next stable release will likely turn on state encryption by default for all new nodes". It was then enabled by default 1.90.2 onwards (October 2025).

That is why I would consider it a significant u-turn.

[1]https://tailscale.com/blog/encrypting-data-at-rest

¹: and very few of those can explain that it doesn’t actually clear the TPM. Instead it causes a different state to be measured by the TPM, and in that new state the TPM cannot unlock the keys that were previously stored in it. This is a great way to protect the computer against someone who can pull the hard drive out of the computer and try to read the data off of it, or who can substitute a different BIOS chip to get around a BIOS password, but not so great for ordinary users who want the occasional upgrade to go smoothly.

And when you do it should be rare and lead to a password reset.

You can still use crypto without a TPM, including with full disk encryption, and for LUKS specifically you can use multiple passwords and mechanisms to unlock the system. Different solutions will give different benefits and drawbacks. Me and a friend wrote a remote password provider for Debian called Mandos which uses machines on the local network as a way for unattended boots. It does not address the issue of tampering with the bios/boot loader, but for the primary purpose of protecting against someone stealing the server/disks it serves the purpose of allowing us to use encrypted disk without drawbacks of typing in passwords, and the backup server, itself with encrypted disks, handles the risk of needing recovery passwords. At most one needs to have an additional backup key installed for the backup server.

For that purpose they’re pretty good, though there are advantages to a more signature-oriented boot security option like Apple’s Secure Enclave. But that only works so well because Apple simply doesn’t permit altering parts of the macOS boot process. For Windows/Linux, you have a variety of hardware, firmware, and OS vendors all in the mix and agreeing on escrow of keys for all of them is hard.

The private key is safe from any exfiltration, and usage only requires a short PIN instead of a long passphrase. The TPM ensures you're physically typing that PIN at the machine not a remote desktop window or other redirection that could be hacked.

Obviously, this is problematic/annoying for scripts and things that can't share the SSH session, because you need to PIN with every authentication. Also, for encryption, you want to use something where you can backup the private key before stashing it in the TPM. Windows allows you to do this with certificates that are exported for backup prior to encrypting the private key with an unexportable TPM key in Hello.

For the same reason that most folks don't use bank vault doors on their house.

Ex - even reasonably technical people hit this footgun in lots of edge cases... like updating their bios, changing the host of a vm running the tool, or having a k8s pod get scheduled on a different node.

I'm surprised this was "default on" at all.

Apart from Windows, there are many setups that fail in fun ways: Kubernetes pods that migrate from one VM with a TPM to another one, hypervisors that mount a virtual TPM to VMs, containers or VM images that do Tailscale registration on one machine and then get replicated to others, etc.

Tailscale already did some attempts at cleverness when deciding whether to enable features using a TPM (e.g. probing for TPM health/version on startup, disabling node state encryption on Kubernetes pods), but there was still a long tail of edge cases.

If the bitlocker stuff goes wrong, big problem, hopefully you printed and kept your recovery key.

If the microsoft account stuff goes wrong, mostly the microsoft store and microsoft store apps break in subtle ways... but that's also how that ecosystem normally works, so how are you supposed to know it's the TPM problem?

Hardware key attestation is a yet-unfinished feature that we're building. The idea is to generate a signing key inside of the TPM and use it to send signatures to our control plane and other nodes, proving that it's the same node still. (The difference from node state encryption is that an attacker can still steal the node credentials from memory while they are decrypted at runtime).

We started by always generating hardware attestation keys on first start or loading them from the TPM if they were already generated (which seemed safe enough to do by default). That loading part was causing startup failures in some cases.

To be honest, I didn't get to the bottom of all the reports in that github issue, but this is likely why for some users setting `--encrypt-state=false` didn't help.

At least it was fixed in the 5900x (and _different_ gigabyte motherboard, but from the same lineup) that replaced it.

VMs typically do not use TPMs, so it is not surprising that the feature was not being used there. One common exception is VMware, which can provide the host's TPM to the VM for a better Windows 11 experience. One caveat is this doesn't work on most Ryzen systems because they implement a CPU-based fTPM that VMware does not accept.

As part of setting up a device in our org we enroll our device in Intune (Microsoft's cloud-based device management tool aka UEM / RMM / MDM / etc). To enroll your device you take a "hardware hash" which's basically TPM attestation and some additional spices and upload it to their admin portal.

After the system board replacement we got errors that the device is in another orgs tenant. This is not unusual (you open a ticket with MS and they typically fix it for you), and really isn't to blame on Dell per se. Why ewaste equipment you can refurbish?

Just adding 5c to the anecdata out there re: TPM as an imperfect solution.

Overseeing IT admins for corp fleets is part of my gig, and from my experience, we get malfunctioning TPMs on anything consumer - Lenovo, Dell, HP, whatever. I think the incidence is some fraction of a percent, but get a few thousand devices and the chance of eventually experiencing it is high, very high. I can't imagine a vTPM being perfect either, since there isn't a hypervisor out there someone hasn't screwed up a VM on.

Yeah, that was a feature and the exact reason why we use TPMs. I guess it should have been better advertised.

If someone had messed with your BIOS maliciously, that's desirable. Unfortunately you messing with your BIOS intentionally also makes the original key pretty much unrecoverable.

A TPM’s primary function works by hashing things during the boot process, and then telling the TPM to only allow a certain operation if hashes X & Z don’t change. Depending on how the OS/software uses it, a whole host of things that go into that hash can change: BIOS updates being a common one. A hostile BIOS update can compromise the boot process, so some systems will not permit automatic decryption of the boot drive (or similar things) until the user can confirm that they have the key.

The third one is just the open-source tailscaled binary that you have to compile yourself, and it doesn't talk to the Keychain. It stores a plaintext file on disk like the Linux variant without state encryption. Unlike the GUI variants, this one is not a Swift program that can easily talk to the Keychain API.