RFC-0009 §1, verbatim: "A signed artifact from a host is also a proof that the host's measured boot state matched declared expectations at the moment of signing."
01The thesis
The signed-artifact chain gives each fleet member a cryptographic identity in software today. Hardware binding anchors that identity in the silicon, gates every secret on boot-state attestation, and makes lying about identity a path to automatic expulsion from the fleet. A stolen disk yields no readable filesystem, a tampered host cannot speak in the evidence chain, and a host that lies persistently stops being part of the fleet.
02Five properties of a cryptographic citizen
| Property | Mechanism |
|---|---|
| Identified by a key that cannot leave the silicon | TPM2-generated signing key, sealed against the host's declared PCR set. Exportable only as a public half. |
| Authorised by a hardware-bound enrollment | Bootstrap token claims include the host's TPM Endorsement Key (EK) fingerprint. CP refuses enrollment if the EK quote doesn't match. |
| Trusted to speak only when boot state matches declaration | Every probe signature simultaneously attests "kernel + initrd + cmdline at signing time matched the closure-derived expectation". |
| Permitted to decrypt only when boot state matches declaration | agenix secrets AND LUKS volume keys sealed against the same PCR policy. Tampered kernel = TPM authorization failure before plaintext is reachable. |
| Auto-expelled if it lies persistently | Host-attestation quarantine state machine. CP stops issuing fresh mTLS certs after N consecutive AttestationDrift/Invalid outcomes. Host falls out of active fleet within one renewal cycle (~30 days), observably and reversibly. |
03Four RFCs - design-stage, falsifiable criteria
TPM-bound host signing key, PCR-bound secrets (agenix + LUKS sealed against boot-state policy), boot-evidence wire protocol additions, escrowed recovery flow.
EK-bound bootstrap tokens, three documented operator roles (release / org-root / infrastructure), threshold-signed channels (N-of-M hardware-token signers), host-attestation quarantine, tested rotation runbooks.
Bounded staleness for channel artifacts (particularly relevant to air-gap).
Signed bundle transport, transport-only sovereign binary cache, verification-host workflow.
Each RFC ships with a falsifiable done-criteria section. Total ~1000 lines across RFC-0009, RFC-0010, RFC-0011, RFC-0012. This is not aspirational language - these are specifications waiting for implementation effort.
04What's already shipping toward this
The trajectory is not greenfield. The foundation already ships:
- TPM keyslot abstraction (
impls/keyslots/tpm/): primary-key generation, persistent-handle eviction,tpm-sign-<name>wrappers, PCR policy support, idempotent across impermanence wipes. RFC-0009 explicitly does not reimplement this - it extends with host-identity binding. - Signed-artifact verification machinery: the same
verify-artifactlibrary that today verifies CI release signatures will tomorrow verify TPM-quoted boot evidence on the same chain. - Trust-root rotation slots (
current/previous/successor/retireAt) on every declared trust root. - Bootstrap-token allowlist: single-use enforcement, hostname + pubkey scoping. EK-fingerprint binding is an additive field.
05Why this matters for regulation
NIS2 Article 21(d) - supply-chain security. Asks how you know the software running on your host is what you intended. The signed-artifact chain answers with closure-hash + cryptographic signing today. Hardware binding extends to: the boot chain that loaded the closure is also measured into every signature the host produces.
NIS2 Article 21(i) - access control + privileged access evidence. Asks how you know who is in your fleet and that they have not been replaced. mTLS certs signed by your fleet CA answer today. Hardware binding extends with: the host's signing key cannot leave the TPM, enrollment is bound to the hardware EK recorded at unboxing, and a host that lies about its boot state is automatically removed.
ANSSI BP-028 v2.0 (R7-R14, R33). Largely kernel + boot + audit hardening. Today's chain ships the static gates. The trajectory ties them to a hardware-attested measurement chain.
DORA Articles 9 + 17. Access + authentication, plus incident management. Both benefit from the visible-failure, reversible-quarantine model: a misbehaving host is not silently kept in the fleet, and its expulsion is auditable end-to-end.
SecNumCloud / ANSSI qualification trajectories require the kind of hardware-bound trust chain the RFCs specify. This is the work that takes NixFleet from "credible NIS2-aligned tooling" to "qualifiable for sovereign deployments."
06What this is NOT - honest scoping
- No calendar commitment. This work is design-stage. Pilot operators are direct input to the priorities. We ship when the spec is right, not when a deck promised.
- Not confidential computing. The trajectory does not defend against runtime tampering after a successful unsealed boot. That requires AMD SEV / Intel TDX - a separate future RFC.
- Not bus-level attacks. Sustained physical access with TPM-bus interception is out of scope (same future RFC).
- Not auto-magic. PCR drift from a legitimate firmware update requires the operator to test on staging, bump
firmwareGenerationinfleet.nix, and let CI re-sign. The framework refuses silent acceptance of boot-chain changes - the cost is also the value. - Per-host opt-in. No fleet-wide flag day. A host migrates to TPM-bound identity by declaring it in
fleet.nix.
07For a pilot operator
A pilot signed in 2026 directly informs the trust trajectory. The pilot validates the signed-artifact-chain model on your hardware and against your auditor's evidence requirements. Future work prioritises the integrations your operators need - PCR set defaults, EK capture tooling, recovery flow ergonomics, threshold-signing UX - the right defaults emerge from real deployments, not greenfield design.
This is the trade pilot operators accept: a framework that ships today and iterates with their feedback, in exchange for direct influence on the design that determines what hardware-rooted trust looks like in EU regulated infrastructure for the next decade.
If your trajectory needs this in 18–36 months, talk to us now →