A Compromised Node Will Attest That It's Healthy

Zero-trust has a clean promise: verify every node before it joins the network. The promise hides an assumption, that you can ask a node whether it is trustworthy and get an honest answer. A compromised node answers too, and its answer is yes. Attestation only carries information when the thing producing it is not the thing you are trying to verify. Get that wrong and you have built an elaborate way for a hollowed-out machine to wave itself through the door.

The failure is not the impostor

Most zero-trust diagrams show a node presenting a credential and a gate checking it. The credential proves identity: this node holds the right key. It says nothing about integrity: that the software holding the key is the software you shipped, unmodified, doing what you think it does. Those are different claims, and the gap between them is where the interesting attacks live.

The impostor, a machine with no valid key, is the easy case. Mutual TLS handles it. The hard case is the legitimate node that has been rooted: it has a real key, in the right place, with a valid chain. It passes authentication perfectly, because authentication was never asking the question that matters.

Authentication proves the node holds the key. It does not prove the node is still the node you shipped.

Software cannot vouch for itself

Ask the operating system whether it has been compromised and the answer arrives from the one component with both the motive and the means to lie. An agent reporting its own health reports the health its attacker permits. A log forwarder reports the events its rootkit leaves visible. This is the same root failure as monitoring is not understanding: the compromised system is the narrator of its own compromise, and a narrator under the attacker's control is not a witness.

Self-attestation, where a process signs a statement that it is fine using a key the same process can read, is the purest form of the mistake. Whatever owns the process owns the key and owns the statement. The signature is valid and the claim is worthless.

Push the root of trust below the attacker

The only escape is to produce the attestation somewhere the attacker on the OS cannot reach. That is what measured boot and a TPM are for, and the mechanism is worth stating plainly because it is usually hand-waved:

• Each stage measures the next before handing control: firmware measures the bootloader, the bootloader measures the kernel, and so on, hashing each into a TPM Platform Configuration Register (PCR).
• PCRs are extend-only. You can fold a new measurement in; you cannot rewrite one. Later code physically cannot erase the record of the code that loaded it.
• The TPM signs a quote over the PCR values with an attestation key that never leaves the chip.
• A separate verifier checks the quote and compares the measurements against known-good values.

Now the statement "this node booted in a known state" is produced by hardware the compromised OS does not control, signed by a key it cannot extract, and checked by someone else. That is the entire difference between attestation and a process insisting it is fine.

It is also why hardware keys and mTLS are necessary but not sufficient. They prove a key is present and live. They do not prove the software around the key booted clean. People conflate "the connection is cryptographically verified" with "the endpoint is trustworthy," and those are not the same sentence.

mTLS proves the tunnel. It says nothing about what is standing at the other end of it.

In the cloud, the hypervisor is in your trust base

Everything above assumed you own the hardware. On bare metal the TPM is a physical chip on the board, and trusting it is trusting silicon you can hold. In a cloud VM there is no chip you control. The TPM is a virtual one, emulated by the hypervisor, and the hypervisor can read your memory, pause your CPU, and forge whatever the vTPM reports. Measured boot into a vTPM attests to a state the hypervisor curates. If your threat model includes the platform operator, or a hypervisor compromised through another tenant, the cloud's default attestation is vouching for the very thing you cannot trust.

This is the gap confidential computing exists to close. Azure Confidential VMs, and the AMD SEV-SNP and Intel TDX hardware they run on, move the root of trust back into the physical CPU:

• Memory is encrypted and integrity-protected in hardware, with keys held by the CPU's secure processor. The hypervisor can schedule the VM but cannot read its RAM or silently remap and replay its pages.
• The attestation report is signed by the CPU itself, with a key rooted in the silicon vendor's chain rather than by the hypervisor's emulated device. The thing vouching for the boot state is hardware the cloud operator does not control either.
• The hypervisor leaves the trusted computing base for confidentiality and integrity. You verify the hardware report, bind the vTPM and boot measurements to it, and only then hand the node a real role.

The honest accounting is that you have not removed trust, you have moved it, the same move as everywhere else in this piece. You stop trusting the cloud's hypervisor and start trusting the CPU vendor's enclave implementation, its firmware, and its microcode. That is a smaller and more defensible base, but it is not nothing: these designs have had real side-channel and microcode breaks, and "confidential" means the host is out of the trust base, not that the box is unbreakable.

Confidential computing does not make the VM trustworthy. It removes the landlord from the list of people who can tamper with it.

None of which is a reason to skip it. A confidential VM is protected from the host even though it is not protected from itself, and removing the platform operator from the set of people who can silently tamper with you is a real gain, not a cosmetic one. It is the right floor to build on.

It just is not the whole building: the rooted node still attests that it is healthy from inside the encrypted enclave, the boot-clean-is-not-run-clean problem is identical, and the report is still worth nothing unless the control plane consumes it and gates capability on it. Confidential computing restores the hardware root that virtualization took away, which is where this gets to begin, not where it gets to stop.

Boot-time clean is not run-time clean

Measured boot has a hard limit that vendors are quiet about: it measures the boot. The PCRs capture firmware, bootloader, kernel, maybe the initramfs. Everything after the system pivots to its real root filesystem, the running userspace, the long-lived agent, the config that drifts over a deployment's life, is back in ordinary mutable-software territory, where the attacker lives. A clean TPM quote tells you the node booted clean. It does not tell you the node is clean now.

This is exactly why immutable infrastructure and attestation are a pair rather than competing options. A read-only root, of the kind that makes the snapshot the audit trail, shrinks the mutable surface that exists after boot, which keeps the boot-time measurement meaningful for longer. Without it, the measured state goes stale the moment userspace starts writing. Runtime measurement, Linux IMA hashing files as they are opened, periodic re-quoting, stretches the window further, but nothing closes it. Integrity is a claim with a half-life.

The binary that never touches disk

On-disk measurement still assumes the thing you run lives on a disk a rootkit could rewrite between the measurement and the next exec. There is a more aggressive way to shrink the surface: do not keep the binary on disk at all.

The model inverts the usual flow. The binary is delivered fresh over the authenticated channel, its signature verified against the exact bytes about to run, placed in an anonymous in-memory file (a Linux memfd) that never touches the filesystem, sealed against further writes, and executed from there. Nothing is ever written to disk. Each run is a signed payload that exists only for the life of the process.

This is the same fileless-execution primitive that malware uses to dodge disk forensics, turned around. The property that makes it evasive for an attacker, leaving no artifact behind, makes it tamper-resistant for a trusted loader. There is no persistent binary to backdoor, no file for a disk-resident rootkit to alter, no path to swap. The integrity question moves from "is the file on disk the one we shipped" to "are these exact bytes signed, and are they frozen once loaded," and both are answerable at the instant of execution rather than inferred from a measurement taken earlier.

Static and dependency-free is what makes this clean. A single self-contained blob has nothing to resolve at load: no shared library to pull from the very disk you were trying to avoid trusting, no dynamic loader to subvert, no transitive package that changed under you. The thing you verify and seal is the whole program, in one hash, in one mapping.

The same fileless trick malware uses to leave no evidence, a trusted loader uses to leave nothing to tamper with.

The honest limits, moved up a level

Same shape as the others, just relocated:

• The loader becomes the trusted component. You have not removed the root of trust, you have relocated it to whatever pulls, verifies, and seals the fresh binary. That loader is now the thing that must be measured, and because it is small, static, and present at boot, it is exactly what the TPM chain can cover. The recursion bottoms out at a boot-measured loader instead of a sprawling disk image, which is a far smaller thing to trust.
• Sealing freezes the code, not the process. Read-only executable pages stop an attacker rewriting your code in place, which closes the in-memory-modification vector directly. They do not stop control-flow hijacking that reuses existing code, or data-only attacks. "Cannot be changed" means the code is frozen, not that the process cannot be subverted.
• The kernel still enforces all of it. The seal, the page protections, the in-memory file itself are the kernel's guarantees. A kernel-resident attacker ignores them. This still sits on measured boot for the kernel underneath, the same as everything else.

What is left is the strongest version of shrinking the measurable surface: the surface is not on disk at all. It is a single signed blob, verified at the moment it runs and frozen the instant after, and the only persistent thing left to attest is the small static loader at the bottom of the chain.

The question nobody answers

Every attestation design eventually meets the node that fails the check, and this is where most of them quietly fall apart. There are two obvious responses, and both are wrong.

Fail closed: no valid quote, no join. Correct in theory, an availability incident generator in practice. Bare-metal bootstrap has no prior state to attest. Hardware without a TPM cannot play at all. A firmware update legitimately changes a PCR, and now every node in the fleet fails until the known-good baseline is rebuilt. A node recovering from a real incident is locked out exactly when you need it back. The operational pressure to add "just allow this one" is immense, and the exception added under pressure is a permanent hole nobody revisits.

Fail open: the node joins, the failed attestation is logged for someone to review later. Congratulations: you have rebuilt the reactive dashboard this entire approach was supposed to replace. The red mark arrives after the node is already inside.

Fail closed and attestation becomes an outage generator. Fail open and it becomes a dashboard. Neither is the point.

Integrity gates capability, not connectivity

The useful design grades trust into capability instead of admitting or rejecting at a gate. A node that cannot attest is not turned away. It joins in a quarantined role with a minimal capability set: it can pull its own configuration and report basic liveness, and little else. It cannot receive secrets, cannot act as a control-plane peer, cannot accept lateral connections, cannot be handed work that touches anything sensitive. As it proves more about its state, it earns more capability.

This is the egress-allowlist instinct turned inward onto membership. Default-deny is not a wall around the network; it is the resting state of every node, and capability is the thing a node earns by proving its integrity, continuously, rather than the thing it is granted once at the door.

What this means for an agent-based admin mesh

Concretely, for a system where many agents act on many nodes at once, the design has four properties it cannot skip:

• Identity and integrity are separate credentials. Authorization for any action is their intersection. A valid key on an unattested node yields the quarantined capability set and nothing more, no matter how good the key is.
• Attestation is continuous, not at-join. Re-quote on an interval and before any privilege escalation, because "clean at join" decays the instant userspace runs. A stale or failed re-quote is an automatic capability downgrade, not an alert for a human to read.
• The verifier is independent of the verified. The remote-attestation architecture splits the roles on purpose, attester, verifier, relying party, and it only works if the verifier does not run on the machines it judges. The classic failure is hosting the attestation service as a workload inside the very cluster it attests, so that rooting the cluster also owns its judge.
• Revocation moves at the speed of the concurrency. If two hundred agents can act in the time a human takes to read an alert, a downgrade that propagates at human speed is decorative. The control plane has to strip a node's capability fleet-wide in the same loop that detected the problem.

Security is a practice, not an end

Attestation does not remove trust from the system. It relocates it. Trust moves off the OS, which the attacker owns the moment they get root, down into hardware, which they mostly cannot reach, and outward to a verifier, which only helps if it is genuinely independent. What you are building is a bootstrapping discipline: each layer measured by the one beneath it, anchored in silicon at the bottom, graded into capability at the top, and re-checked on a clock because the measurement decays.

The version that fails closed at the door is an outage waiting for a firmware update. The version that warns and admits is the reactive dashboard we were trying to leave behind. The version that works is the one in the middle, where integrity is a continuous, graded input to what a node is allowed to do. Almost nobody builds it, because the middle is the most work.

The node that reports it is healthy is not the one to trust. It is the one to check, against something it cannot lie to.

And you have to decide, before the incident, what happens when it cannot.

Step back, and every move in this piece did the same thing. Measured boot pushed trust into hardware. Confidential computing pushed it to the CPU vendor. The memory-resident loader pushed it onto whatever verifies and seals. Continuous attestation pushed it onto a clock. Not one of them produced a node you can finally call secure, because there is no such state to reach. Security is not a property a system has. It is something you keep doing: you attest, you re-attest, you grade capability by what a node can prove right now, and you decide ahead of time what a failed check costs. Each round you actually run moves the odds. None of them moves you to certainty.

You do not get to claim a system is secure. You get to practice security, and the more of it you practice, the better your chances.

A node is never trustworthy in the end. It is only better checked than it was, by whoever is still doing the work.