How do organisations implement roots of trust?

What a root of trust actually anchors

A root of trust is the lowest hardware or firmware basis that the organisation trusts first. Everything above it, boot code, measured state, update verification, and policy enforcement, depends on that initial anchor being hard to bypass. That is why roots of trust are usually implemented in firmware, secure elements, TPMs, or platform features designed to establish an immutable starting point.

The practical question is not whether the device has a root of trust in name only, but whether the platform can prove what it is before it is allowed to operate. If the first trusted measurement is weak, the rest of the control stack can be correct and still inherit a bad starting state.

Hardware-backed boot trust is also where firmware security becomes operational, not theoretical, as described in Firmware and Boot Security Guide. The implementation details matter because secure boot keys, measured boot, and attestation only help when the organisation can actually verify the platform state it receives.

How organisations implement the trust chain

Most implementations begin with secure key storage so the first trust anchor cannot be copied or tampered with easily. The next layer is verified or measured boot, where firmware, bootloaders, and operating system components are checked against expected signatures or measurements before normal execution continues.

After boot, attestation extends that trust to a verifier, often a management service, cloud control plane, or security platform. The verifier compares the device's claimed state with the expected baseline and decides whether to grant access, allow workload registration, or permit sensitive operations. That is the point at which trust becomes a policy decision rather than a hardware assumption.

For embedded and edge environments, this often overlaps with secure update paths, rollback resistance, and debug-port control. Those environments are especially exposed because the root of trust is only useful if update channels, recovery paths, and physical interfaces do not let an attacker replace the trusted code after deployment. Embedded Device Security Guide is useful here because it ties hardware trust to firmware update security, rollback protection, and interface hardening.

Some organisations also map this to workload identity and attestation when the trusted platform is a server or node that must prove itself before joining a cluster. In that context, the root of trust is not just about hardware integrity, it is about proving that the platform presenting credentials is the same platform the policy engine expects.

Where roots of trust fail in practice

The common failure mode is treating the root of trust as a product feature instead of an enforced trust chain. A device can ship with secure hardware and still fail if keys are unmanaged, firmware is not measured, attestation is not checked, or policy is applied before the attestation result is validated.

Another weak point is update trust. If the organisation trusts boot but not update provenance, an attacker can preserve the original root while replacing the software above it. If the organisation trusts attestation but not revocation, compromised or outdated devices may continue to be accepted long after their trust anchor should have been withdrawn.

That is why firmware trust and device trust are tightly connected to secure update handling, as also reflected in NIST SP 800-207 Zero Trust Architecture. zero trust principles reinforce the idea that the verifier should not assume a device is trustworthy just because it has historically been present in the environment.

Practitioner Guidance

What to verify: Confirm that the device can prove three things independently: the authenticity of the boot path, the integrity of the measured state, and the freshness of the attestation. If any of those are missing, the root of trust is incomplete even if the hardware component exists.

Decision rule: If the platform cannot support attestation to a trusted verifier, restrict it to low-trust functions or isolate it until the trust chain is complete. If the platform can attest but cannot enforce policy on the result, treat the attestation as visibility only, not as a control.

What good looks like: Keys are hardware-protected, boot measurements are checked against an authoritative baseline, failed attestation blocks sensitive access, and firmware updates are signed, verified, and revocable. In mature environments, the trust anchor is tied to operational policy, not just device engineering.

Practitioner takeaway: A root of trust is only valuable when it is part of an end-to-end trust decision, from secure key storage through attestation to policy enforcement. If the verifier does not act on the proof, the organisation has telemetry, not trust.

Related resources from NHI Mgmt Group

• Why do non-human identities complicate zero trust architecture?
• Why do non-human identities increase zero trust risk?
• When should organisations prioritise Zero Standing Privilege for non-human identities?
• Why do NHIs complicate zero trust and least privilege efforts?