Hardware Roots of Trust: What 'Hardware-Backed' Actually Means

“Hardware-backed” is among the most widely used and least interrogated phrases in security. At its best it names a specific and valuable protection: a small, deliberately limited piece of hardware that holds cryptographic keys and will not surrender them, even to software that has otherwise taken over the machine. At its worst it is an adjective applied to make a product sound safer than it is. The distance between those two is the subject of this piece.

The problem it addresses is an old one. Software must keep its secrets somewhere, and for most of the history of the discipline that somewhere was memory and disk – territory an attacker with sufficient privilege can read at leisure. Every software protection for a key ultimately rested on other software, and the regress had no natural floor. A hardware root of trust is the industry’s answer: a hardware boundary whose only job is to protect keys and perform cryptographic operations without ever releasing the usable key material to the software that asked. The design now appears across modern phones, managed laptops, servers, and cloud key-management platforms, though the implementations and their assurance levels differ a great deal – which is precisely where the adjective starts to be applied with varying honesty.

The Core Idea: Keys That Cannot Leave

A hardware key store inverts the usual relationship between software and secrets. Applications do not fetch keys in order to use them; they send requests across a boundary – sign this, decrypt this – and the hardware returns the result. The key itself is generated inside the boundary, lives inside it, and is engineered never to cross it. Compromise the operating system completely and, whilst the device is in your hands, you can still ask the hardware to use the key – a real and important caveat – but you cannot extract it, copy it, or carry it away for an offline attack.

That one property changes the economics of a breach. Software-stored keys turn a temporary foothold into a permanent, portable cache of credentials: steal them once and they are yours to use anywhere, indefinitely. A non-exportable hardware-held key can be misused whilst the attacker’s access lasts, but it cannot be copied out and kept. The distinction is containment, not immunity. The point is the removal of a promise: nothing merely asserts that the keys will not be exfiltrated; the boundary is built without an export path in the first place.

A Field Guide To The Acronyms

The implementations differ in ways that matter the moment you are deciding what to trust.

A Trusted Execution Environment (TEE) is a protected mode of the main application processor – ARM TrustZone is the canonical example – running a small trusted operating system alongside the ordinary one. The logical isolation is strong, but the trusted and untrusted worlds share the same physical silicon, which makes for a larger attack surface than dedicated hardware would present. Most Android hardware-backed keys live here.

Dedicated secure subsystems and secure elements go a step further. Apple’s Secure Enclave is a dedicated subsystem built into the system-on-chip; Android’s StrongBox requires dedicated secure hardware with its own CPU, secure storage, and random-number generator; Google’s Titan chips and conventional smartcards follow related secure-element designs. These isolate execution and key handling from the main processor, talk to it over deliberately narrow interfaces, and may add resistance to physical and side-channel attack. The Android Keystore draws an explicit line between TEE-backed and StrongBox-backed keys, and the distinction is substantive: they are different claims, and should be read as such.

A Trusted Platform Module (TPM) is the standardised component found in PCs and servers, used to hold keys and, distinctively, measurements of what booted – the foundation for secure boot, for releasing disk-encryption keys only to a known-good system, and for device-health attestation. A TPM may be a discrete chip or a firmware implementation running on the main processor, and those two forms carry materially different isolation and physical-attack assumptions.

A Hardware Security Module (HSM) is the data-centre tier: a physical device built to safeguard keys and perform cryptographic operations, usually with tamper evidence or active tamper response and validation against a standard such as FIPS 140-3. HSMs protect certificate-authority roots, payment infrastructure, and the backends of cloud key-management services. When a cloud provider tells you the keys sit in an HSM, the question that matters is not whether they do, but who can instruct the HSM.

Attestation: Proving State, Not Just Holding Keys

Holding keys is only half the value. The other half, and the less discussed, is attestation: the hardware’s ability to prove to a remote party, cryptographically, what it is and what state it is in.

Depending on the platform and certificate chain, key attestation can let a server verify a key’s reported security level and certificate chain, rather than merely trust an API response from the client. Device and platform attestation carry the same idea up to whole systems: that this laptop booted measured firmware, that this server is running the image it claims to be running. The effect is to convert “the client says it is secure,” which any piece of malware can say, into evidence anchored in hardware. That is the difference between a machine telling you it is trustworthy and a machine proving it, and it is increasingly the basis of any serious zero-trust device policy.

The Limits That Remain

A hardware root of trust narrows the attack surface. It does not abolish it, and four limits deserve stating plainly.

The most immediate is authorisation. The hardware faithfully serves whoever the operating system says is authorised, so malware running with the user’s privileges on an unlocked device can request a signature exactly as the legitimate application can. Hardware storage defeats extraction, not misuse-in-place – which is why, in high-value designs, it matters that individual sensitive operations are gated behind a biometric or PIN rather than the device unlock alone.

Then there is implementation. Enclaves and TEEs are engineered products, and products have flaws: there have been key-extraction attacks against TEE-held keys, side-channel results against secure processors, and the long run of speculative-execution findings that began with Spectre and Meltdown. Dedicated hardware reduces what is shared with the main processor, but neither dedicated silicon nor a certification removes implementation and side-channel risk entirely.

A third limit is the supply chain. A root of trust is only as trustworthy as its manufacture and provisioning, which is the whole reason attestation chains terminate in manufacturer certificates – and the reason that anchoring deserves hard scrutiny in high-assurance procurement rather than polite assumption.

And, once again, vocabulary. “Hardware-backed” is stretched to cover everything from a FIPS-certified secure element down to ordinary software keys that are merely encrypted by a hardware key whilst they do their actual work in ordinary memory. Those are not equivalent claims, and a vendor ought to be able to tell you which one they are making. We are convinced enough of the difference that our Signet authenticator reports it for each account – StrongBox, TEE, or Secure Enclave – rather than rounding the lot up to a single reassuring adjective.

In Practice

The practical guidance is short. Prefer keys that are generated in hardware, non-exportable, and attestable. Distinguish dedicated secure elements from shared-processor TEEs when you weigh a claim. And treat “hardware-backed” as the start of a question rather than the answer to one. For anything that matters, verify the attestation rather than admiring the fact that it exists – an unverified attestation is a decorative one.

Underneath the advice sits a simpler idea. A hardware root of trust is a small machine for turning a promise into a property: we will protect your keys becomes the keys cannot leave. The conversion is never total – authorisation, implementation, and manufacture all remain matters of judgement – but it moves the irreducible trust down to a layer that is smaller, harder, and far better scrutinised than the sprawling software above it. Security rarely offers absolutes; it offers that kind of narrowing, and taken for what it is, that is a real gain.