That sinking feeling when you find a developer’s API key hardcoded in a public GitHub repo. Or the morning after a server compromise, when you realize every certificate in your zero-trust architecture is now a liability. You’ve been playing pretend. Software-based machine identity is a charade.
Here’s the uncomfortable truth: any credential that can be read by software can be stolen by software. The entire industry has built a house of cards, layering encryption on top of secrets that are inherently leakable. We’ve normalized the ritual of rotating keys, revoking certs, and hoping the next breach doesn’t happen on our watch.
But one developer, tired of the endless cycle, built something that changes the game. Instead of storing keys in memory, configuration files, or environment variables, he bound them directly to the Trusted Platform Module (TPM) — a piece of silicon that physically refuses to export its cryptographic material. The key never leaves the chip. Ever.
This isn’t just a clever hack. It’s the logical conclusion of machine identity. Think about it: you want a server to prove who it is without ever having to reveal the proof. That’s the paradox. Software tries to solve it by hiding the password, but that’s like hiding a house key under the doormat. Hardware solves it by making the key unextractable — there’s no doormat to lift.
The only secret you can’t leak is the one that physically cannot be extracted.
The project is go-tpm-tls, and it uses mTLS (mutual TLS) where the client’s private key is locked inside a TPM. The authentication handshake happens entirely within the hardware. The server knows the machine is real because the TPM signs the challenge — but the server never sees the key itself. Even if an attacker gains root on the machine, they can’t steal the credential. It’s not stored anywhere. It’s built into the silicon.
This isn’t theoretical. I’ve seen it work. The author describes it as “machine identity after remote attestation” — once you’ve proven a machine is genuine, you still need it to prove which machine it is to a secret store. That’s where mTLS with TPM-bound keys closes the loop. No more stolen certificates. No more leaked keys in logs. No more ‘whoops, I put the secret in the wrong file.’
Now, skeptics will argue that TPMs aren’t perfect — side-channel attacks exist, supply chain risks are real. But let’s be honest: the alternative is software keys that can be copied with a single command. The threat model is not even close. Hardware-rooted trust is the only way to break the cycle of credential theft.
So here’s my challenge to you: the next time you design a zero-trust system, ask yourself — where is the key? If it’s in a file, a vault, or even a memory buffer, it’s already compromised. Demand silicon. Demand a key that stays put. Because the future of machine identity isn’t in software — it’s in the unextractable heart of the machine itself.
FAQ
Q: Isn't TPM just another hardware dependency that can be attacked?
A: Yes, TPMs have known side-channel attacks and supply chain risks. But the comparison is not between perfect and imperfect; it's between a key that is physically bound to a chip versus a key that can be copied by any software with read access. The latter is orders of magnitude more vulnerable.
Q: What's the practical implication for my cloud infrastructure?
A: You can finally deploy machine identity that doesn't rely on stolen credentials. With TPM-bound mTLS, even if an attacker gains root on a server, they cannot extract the private key. This means secret stores, certificate authorities, and other zero-trust components can trust the machine without trusting the software stack.
Q: Couldn't we just use a hardware security module (HSM) instead of a TPM?
A: HSMs are more expensive and less ubiquitous. TPMs are already built into most modern servers and laptops. The beauty of this approach is that it leverages existing hardware at no extra cost, making hardware-rooted machine identity accessible to everyone, not just enterprises with deep pockets.