Amutable has opened signups for the private preview of Amutable Foundations, a Linux system in which every machine sends a signed report of the software and configuration it is running, according to Help Net Security. The reports draw on local hardware so they are easier to verify. The company says its engineers write and maintain code in the kernel, in systemd and in the image-building tools.
The announcement was reported on Tuesday. Amutable is pitching Foundations at organizations that run fleets of Linux machines and need a stronger way to confirm each host is in the state it claims.
Why it matters
Fleet operators today have few reliable ways to prove that a machine matches its declared configuration. Under Amutable's design, a host that cannot demonstrate that match can be denied secrets and kept out of the cluster. That shifts the decision from trust in credentials to evidence from the hardware itself.
Amutable also argues that machine identity is currently something a host holds — a host key, a client certificate, an API token or a cloud instance identity. Any of those four can be copied, leaked or presented by a tampered machine. Foundations instead ties identity to a signed statement of measured state, so a host's standing depends on what it can prove about itself.
How a machine is built and verified
In Amutable's model, the intended state of each machine is kept in version control. A build system converts that state into signed images, and configuration is compiled into those images rather than applied afterward.
At boot, a machine checks its firmware, boot loader, kernel and operating system. It then records measurements in a TPM, the chip that logs what a machine booted, or in CPU attestation measurements when the machine runs as a confidential VM — a virtual machine whose processor can vouch for what runs inside it.
Machines in the system carry no package manager and no SSH or interactive shell. The only way to change one is to hand it a new signed image. At regular intervals and at stages such as boot, each machine sends a signed report. A control plane checks that report against the hardware root of trust and compares it with the declared state. When the two diverge, the system flags the specific machine that drifted, and rollouts move forward only as machines prove a good state.
Amutable offers two concrete examples of how this plays out: new database credentials are refused to a machine running an outdated configuration, and a machine whose measurements no longer match is kept out of the cluster when it reboots.
Two gaps Amutable says it closes
The company points to two weaknesses in common practice. Configuration usually sits outside signed image data, which places it beyond what hardware-backed trust can measure. Amutable also describes shared join tokens as the weak norm for setting up clusters.
The company cites the EU Cyber Resilience Act in making its case. Vulnerability reporting obligations under the law have been enforced since September 2026, with the remaining provisions due to follow in December 2027, Help Net Security reports.
For teams weighing the private preview, the practical question is how the control plane handles a flagged machine and how much of an existing fleet's configuration can be expressed in version control before images are built. Amutable has not said when the preview will widen beyond signups.
