The question comes up in almost every architecture review for cloud infrastructure security: do we handle key custody in a Trusted Execution Environment running on the host SoC, or do we attach a discrete HSM die? Both options provide some form of hardware isolation. Both can produce attestation evidence. The costs differ by roughly an order of magnitude. The attack surfaces differ in ways that are not obvious until you work through the threat model carefully. This article goes through the tradeoffs without pretending there is a universal answer.
What a TEE Actually Guarantees
A Trusted Execution Environment — whether Arm TrustZone on mobile and embedded SoCs, Intel SGX on server-class x86, or AMD SEV-SNP protecting full VMs — provides a software-defined isolation boundary enforced by hardware memory access controls. TrustZone partitions the SoC into Secure World and Normal World; the memory management unit enforces that Normal World code cannot read Secure World memory. SGX goes further, encrypting enclave memory with a key generated in the processor and never exposed to ring-0 software.
The key word throughout is software-defined. The isolation logic runs in the SoC's general-purpose processor, sharing silicon with the operating system and hypervisor. The root of trust is the processor firmware — in SGX's case, the microcode and provisioning keys fused at Intel's manufacturing facility. If that microcode contains a vulnerability (and historically, SGX has seen a significant number of speculative-execution side-channel disclosures requiring microcode updates), the TEE isolation can be weakened without any physical access to the device.
This is not a knock on TEEs. For the threat model they address — protecting tenant workloads from a malicious or compromised hypervisor — they provide a genuine and hardware-enforced boundary. The question is whether that boundary is sufficient for key custody specifically.
What a Discrete HSM Actually Guarantees
A discrete HSM die is a dedicated security processor whose only job is key management and cryptographic operations. Its security boundary is physical: the die package, and whatever tamper-evident or tamper-responsive measures are in the design. Key material lives inside this boundary — in registers or RAM that are not accessible via any external bus — and cryptographic operations are performed inside it. The host SoC sends commands over SPI or PCIe and receives results; it never touches key material directly.
The root of trust for a discrete HSM is the HSM's own firmware, ideally loaded from a dedicated masked ROM that cannot be updated in the field, plus a PUF-derived or fuse-injected device identity. Critically, the HSM's security posture does not depend on the correctness of the host SoC's microcode, the host OS, or the hypervisor. A host that is fully compromised — up to and including the hypervisor — cannot extract keys from a correctly-designed discrete HSM without physical access to the die.
This independence from host software correctness is the core architectural difference. A TEE's isolation is conditioned on the correctness of the processor's microcode and secure firmware. A discrete HSM's isolation is conditioned on the physical integrity of the die package and the correctness of the HSM firmware alone — a much smaller and more auditable trusted computing base.
Attack Surface Comparison
Walking through specific attack classes makes the tradeoff concrete:
Speculative execution side channels: TEEs in SGX and SEV-SNP have both faced real disclosures here — Foreshadow, CacheOut, CrossTalk, and related attacks can leak enclave memory under specific microarchitectural conditions. Mitigations exist (microcode patches, compiler-level retpoline, disabling hyperthreading), but the attack surface is real and ongoing. A discrete HSM running on its own dedicated processor with no branch predictor shared with tenant workloads has no exposure to this class of attack.
Firmware update attacks: TEE security typically depends on the host platform's secure boot chain — if an attacker can inject a malicious microcode update or UEFI payload, they may be able to reconfigure the TEE boundary before the OS boots. Discrete HSMs with ROM-resident firmware and hardware fuse locks on the update path eliminate this class entirely.
Power analysis on crypto operations: Both TEEs and discrete HSMs are theoretically susceptible to power analysis if the attacker has physical access and the implementation is not hardened. However, a discrete HSM on a dedicated die can implement power-analysis countermeasures (random clock jitter, dual-rail logic, dummy operations) that are hard to achieve on a general-purpose processor running enclave code. Most TEE implementations on server CPUs have not published detailed DPA countermeasures for enclave code.
Physical access: A TEE in a server CPU offers no meaningful physical resistance — the processor package is accessible, the memory interface can be probed, cold-boot attacks are possible. A discrete HSM with an active tamper mesh responds to probing with immediate key zeroization. This matters for FIPS 140-3 Level 3 compliance and for defense-embedded use cases where platform capture is a real threat scenario.
Cost and Practical Constraints
The cost difference is significant and deserves honest treatment. A TEE is already on the SoC you are buying; the marginal cost of using it for key custody is essentially zero, plus engineering time. A discrete HSM die adds silicon cost, PCB area, an additional interface to design and validate, and its own driver stack. For high-volume consumer hardware, this is often a dealbreaker.
For server, financial services, and defense use cases — where the key custody decision is amortized over a system costing hundreds of thousands of dollars — the silicon cost of a discrete HSM is not the deciding variable. The deciding variables are certification (FIPS 140-3 Level 3 or PCI-HSM), physical security posture, and independence from host software correctness. In those contexts, the cost argument for TEE-only key custody is weak.
There is also a middle path that is increasingly common in cloud infrastructure: use a TEE for workload isolation and confidential computing, but anchor the TEE's own attestation key in a discrete HSM. The TEE proves its measurement to the HSM; the HSM releases the sealing key that the TEE needs to access persistent secrets. This architecture gets TEE isolation economics for compute while preserving hardware root-of-trust integrity for key material.
When Each Approach Makes Sense
TEE-only key custody is reasonable when: the threat model does not include physical access; the compliance requirements (SOC 2, ISO 27001) do not mandate hardware-rooted key custody; the deployment is high-volume and cost-sensitive; and the workload isolation benefit (protecting from hypervisor) is the primary goal.
Discrete HSM key custody is necessary when: compliance requires FIPS 140-3 Level 3 or PCI-HSM (most financial services and government programs); physical access is a credible threat (embedded, edge, defense); the trusted computing base must not include host OS or hypervisor correctness; or attestation must survive complete host software compromise.
We're not saying TEEs are insecure — they provide real hardware isolation for real threat models. We're saying that the isolation boundary and the attack surface are meaningfully different from a discrete HSM, and architecture teams that conflate "TEE = hardware security" with "TEE = equivalent to HSM" will discover the gap at the worst possible time, typically during a certification evaluation or an incident investigation.