Anchoring trust in silicon: How Cofide makes hardware attestation work at enterprise scale

Zero Trust architectures with workload identity are underpinned by strong attestation and cryptographic proof mechanisms to enable the issuance and verification of machine credentials. While software and platform-based methods are scalable, flexible, and highly effective for many of the typical cloud computing use cases, scenarios lacking suitable trust providers in the orchestration and deployment layer might require a more foundational binding to hardware-level trust.

Trusted Platform Modules (TPMs) are a class of security-enabling microcontroller, and can be used to anchor attestable identity directly to silicon. When used in identity, they act as a physical root of trust - enabling systems to identify specific nodes and machines in an immutable and cryptographically secure manner by attesting properties directly from the machine's hardware itself. As these chips have become more ubiquitous, interest in their utility for secretless workload identity systems has naturally risen; especially in scenarios where enhanced security with hardware guarantees is beneficial.

In this blog post, we’ll dive into the world of hardware-enabled machine attestation in workload with TPMs, and share how Cofide makes TPMs in enterprise workload identity systems a turnkey reality for organisations who take their security seriously.

The Bottom Turtle, in Silicon

Those familiar with [SPIFFE (Secure Production Identity Framework for Everyone)](https://spiffe.io) will recognise the "bottom turtle" concept: the challenge of establishing the initial root-of-trust for the identity plane before it can begin issuing credentials to machines, nodes, and software processes.

In a cloud native environment, an infrastructure and service provider's API can act as this root-of-trust, and essentially vouch for a given node or virtual machine when queried. For such scenarios, a vendor platform like AWS can provide cryptographic attestations that a particular process or node exists on its systems and verify any properties of interest. This delegation of trust is very common in public cloud, and with orchestration technologies like Kubernetes.Where this becomes more challenging is bare metal, edge, or private data centre contexts. Reliance on a third-party trust provider might not be appropriate or even possible, and operators need to consider other ways to prove the identity of agents and workloads before issuing short-lived credentials (such as X.509 certificates) for authentication.

How it works

At the heart of every TPM 2.0 module is its Endorsement Key (EK) — a cryptographic keypair deterministically derived from a unique seed provisioned in the chip's hardware. The private portion of the EK never leaves the TPM boundary, while the public key can be shared with external systems for attestation purposes. This keypair provides both a disambiguating identifier and a strong security anchor that can be leveraged in hardware attestation flows.

However, for privacy and security reasons, the EK is rarely used to sign daily operational data or identities directly. Instead, verification of the EK and the secure provisioning of a daily-use key is done via a process called credential activation.

Here is how the flow works in practice:

• Key Generation: The agent generates a temporary Attestation Key (AK) on-demand within the TPM. It passes the public portion of this AK, along with the public EK, to the identity plane.
• Challenge (MakeCredential): The identity plane (acting as the trust provider) verifies the public EK against its allowed list. It then uses the public EK to encrypt a secret challenge (a nonce) and mathematically binds that encrypted secret to the public AK.
• Response (ActivateCredential): The identity plane passes this encrypted package back to the TPM via the node's agent. To read the secret challenge, the TPM must use both its private EK and its private AK to decrypt the package.

If the identity plane receives the correct nonce back, it mathematically guarantees two things: the hardware is genuine (because only the true hardware TPM possesses the private EK), and the temporary AK is safely bound to that specific hardware to be used for secure, daily secretless identity requests.

API-first management of TPM-backed machines with Cofide Connect

While the promise of hardware-backed trust is compelling, the operational reality can be daunting for even the most experienced of engineering teams. Various open source tools (e.g. SPIRE) exist with pluggable TPM support, but these require expertise, significant configuration, and ongoing management to deploy at scale. Furthermore, the default distributed model for such systems often requires home-grown orchestration services to augment the core open source components.

The Cofide Connect platform makes hardware attestation for workload identity dynamic and scalable. We incorporate TPM attestation as a first-class concept, allowing for fleets of TPM-backed machines to be registered, attested, and decommissioned all via our best-in-class workload identity control plane and developer tooling ecosystem.

• Easy enrollment: Fleets of machines can be onboarded via API/SDK/Terraform to join the chain of trust
• Dynamic policy: Flexible and expressive node and workload identity can be issued to suit any enterprise trust topology
• Unified management plane: From onboarding, through attestation, to decommissioning - every stage is managed by the Connect platform

By combining hardware-rooted trust with a managed control plane, Cofide Connect lets teams adopt TPM-backed node attestation without the operational overhead of building and maintaining it themselves.

‍Get in touch today to see how your organisation can start its zero trust journey.