What Are You Protecting?
You're deploying a workload on a Trusted Execution Environment. Before you evaluate any platform, tool, or framework, answer one question: what are you trying to prove, and to whom?
A TEE gives you hardware-enforced isolation and cryptographic measurements. But measurements of what, exactly? The answer depends on understanding the stack you're running on, the deployment context you chose, and where you draw the line between what you verify and what you trust.
The stack
Every confidential computing system runs on five layers. From the bottom up:
| Layer | What it is | Who controls it |
|---|---|---|
| Silicon | CPU, microcode, vendor attestation keys | Hardware vendor (Intel, AMD) |
| Firmware | UEFI/OVMF, hypervisor, or paravisor | CSP on public clouds; you on bare-metal |
| OS | Kernel, initrd, system services | CSP-provided image or your own |
| Libraries | Runtime, language packages, system libs | You (usually) |
| Application | Your binary, container, or workload | You |
Silicon is the root of trust — the one layer everyone accepts on faith. It is never scored. Everything above it is fair game.
The critical insight: you have full control only over the top layers. On a public cloud, the firmware is always controlled by the CSP. The OS might be theirs or yours. The deeper a component sits in the stack, the harder it is to verify and the more damage it can do if compromised.
Deployment contexts
The stack runs in a deployment context. This isn't something you score — it defines the ceiling for what's even possible.
| Context | Characteristic | Typical firmware R-grade |
|---|---|---|
| CSP (AWS, GCP, Azure) | Vendor controls firmware/paravisor. Strong physical and operational security. | R0–R1 |
| Bare-metal provider | You control the full stack above silicon. Provider handles physical security. | R0–R4 (depends on effort) |
| Self-hosted | Full control including physical. | R0–R4 |
CSPs inject closed-source firmware or paravisors into the base of your stack, forcing an R0 or R1 bottleneck that cannot be worked around. In exchange, you get enterprise-grade physical security, 24/7 operations, hardware supply chain oversight, and infrastructure resilience at a scale no bare-metal provider can match today. That is a trade-off, not a flaw.
Bare-metal providers handle physical security and hardware provisioning — but usually at lower operational maturity than a major CSP. You trade CSP-grade hosting and adversarial physical security guarantees for a transparent stack you can verify end-to-end. This is a deliberate trade-off, not a free upgrade.
The Trusted Computing Base
The TCB (Trusted Computing Base) is everything your workload must trust to operate correctly. If any component in the TCB is compromised, your security guarantees collapse — regardless of what the layers above it do.
On a CSP, the TCB always includes their firmware. On bare-metal, you own it. On self-hosted, you own everything down to the building's door locks.
The question isn't whether you have a TCB — you always do. The question is how much of it can you independently verify, and how much must you take on trust.
The KMS/KBS: where it all comes together
A KMS (Key Management Service) or KBS (Key Broker Service) is the external gate where secrets are released or denied. It sits alongside the stack as an enforcement point.
The KBS evaluates attestation evidence — the cryptographic proof that specific code is running on genuine TEE hardware — and decides whether to release secrets. If the evidence doesn't match the expected policy, the secrets stay locked.
This is the payoff of the entire verification chain: the ability to say "release this signing key only if the exact binary I expect is running, on hardware I trust, in a session I can verify." Every dimension of the KRAB model — Attestation, Reproducibility, Binding, and Key Release — feeds into this moment.
What comes next
The rest of this handbook teaches you the four dimensions of the KRAB model, one at a time:
- Attestation — does the hardware prove what's running?
- Reproducibility — can anyone rebuild it and verify the binary?
- Binding — can the outside world tie a session to this specific instance?
- Key Release — does the secret-release path enforce all of the above?
Each dimension gets a score. Together, they form a CoCo Vector — a compact diagnostic that makes your system's trust assumptions visible and its verification gaps impossible to ignore.
Every deployment has a TCB. If you can't name what's in yours, you can't evaluate whether your TEE setup actually protects anything. Start by listing the layers and asking: "who controls this, and can I verify it?"
Before evaluating any TEE platform, write down your threat model in one sentence. "We need to protect signing keys from a compromised operator" is different from "We need to prove to regulators that no one — including us — can access customer data." The right KRAB profile depends entirely on the threat.