Platform Baselines
Theory is over. Here are the KRAB baselines for the five major cloud TEE platforms as of 2026. These score only the layers controlled by the platform provider — firmware, hypervisor, paravisor, attestation path. Your application's R, B, and K scores sit on top of these foundations.
No platform achieves the theoretical maximum. Every one requires a trust decision.
GCP TDX
| Dimension | Baseline | Notes |
|---|---|---|
| Attestation | A2 | Silicon-Rooted, Mediated. The guest accesses configfs-tsm directly and the quote is signed by Intel's PCK chain — no software vTPM intermediates quote delivery. However, Google's closed KVM-based hypervisor manages TD launch and controls what is measured into the MRTD. CSP-controlled software participates in the initial measurement setup, placing GCP TDX at A2. Use A2[GCP TDX] when declaring this trust anchor explicitly. |
| Firmware R | R0 | Opaque. GCP uses a custom closed-source OVMF. It is hardware-measured via TDX MRTD and signed by Intel's certificate chain, but you cannot audit the source or reproduce the binary. |
What it means: GCP TDX occupies a distinctive position between Azure TDX and bare-metal. The quote delivery path is direct (no paravisor intercept), and Intel's silicon anchors the trust chain — but Google's hypervisor controls the TD launch, so the attestation ceiling is A2, not A3. You get silicon-rooted proof with fewer intermediaries than Azure, but not the full control of bare-metal.
Azure TDX
| Dimension | Baseline | Notes |
|---|---|---|
| Attestation | A2 | Silicon-Rooted, Mediated. Intel TDX hardware, but the OpenHCL paravisor mediates all attestation. The guest has no direct quoting access. |
| Firmware R | R1 | Source Available. OpenHCL is open-source — you can read the code and audit it. But the production build pipeline is closed. You cannot reproduce the binary Microsoft deploys. |
What it means: You get silicon-rooted attestation with a source-auditable paravisor — but the paravisor is always in your TCB, and you cannot verify the deployed binary matches the published source. Azure's approach trades attestation directness for code auditability: you can read what should be running, but you can't prove it is.
Azure SEV-SNP
| Dimension | Baseline | Notes |
|---|---|---|
| Attestation | A2 | Silicon-Rooted, Mediated. AMD SEV-SNP hardware, but a proprietary closed-source HCL paravisor intercepts all SNP APIs. /dev/sev-guest is hidden from the guest. |
| Firmware R | R0 | Opaque. Proprietary closed-source paravisor with no published source or build artifacts. |
What it means: The weakest Azure offering from a transparency perspective. Silicon-rooted via AMD, but the paravisor is a complete black box — no source, no reproducibility, no auditability. The mediation layer is both opaque and mandatory. You trust Microsoft entirely for both the attestation path and the firmware integrity.
AWS SEV-SNP
| Dimension | Baseline | Notes |
|---|---|---|
| Attestation | A3 | Silicon-Rooted, Direct. The guest has raw access to /dev/sev-guest, signed by AMD VLEK. No paravisor in the quote path. |
| Firmware R | R4 | Deterministic / Reproducible. Nix-reproducible OVMF. Anyone can rebuild and verify the firmware binary. |
What it means: On paper, the strongest baseline in the industry — A3 attestation with R4 firmware. In practice, there's a catch that changes everything.
Measurement Chain Fracture
AWS uses closed-source tooling to modify the guest OS after firmware but before the OS boots — and this modification is not measured into any hardware register. The firmware is measured. The OS modification is not. The measurement chain fractures at the OS layer.
The platform's attestation ceiling is A3 and the firmware is R4, but the effective runtime attestation of a typical workload collapses to A0 unless you apply custom in-guest mitigations to detect or prevent the unmeasured modification.
This is the most important lesson in platform baselines: a strong foundation means nothing if the chain breaks above it.
AWS Nitro Enclaves
| Dimension | Baseline | Notes |
|---|---|---|
| Attestation | A1 | Provider-Rooted. The Nitro Security Module (NSM) computes measurements and ensures real process isolation. But the root of trust is the AWS Nitro PKI, not a silicon vendor. |
| Firmware R | R0 | Opaque. No source, no build artifacts. The Nitro hypervisor and NSM firmware are AWS proprietary. |
What it means: Nitro Enclaves provide genuine hardware isolation and a measurement-based attestation model — but the entire trust chain roots in AWS. A compromised AWS could forge attestation documents without hardware alarms. Third-party verification without trusting AWS infrastructure is structurally impossible. This is a conscious trust delegation, not a flaw — but it's the deepest CSP dependency of any platform listed here.
The comparison
| Platform | A | Firmware R | Key trade-off |
|---|---|---|---|
| GCP TDX | A2 | R0 | Direct quote delivery, closed hypervisor in TD launch TCB |
| Azure TDX | A2 | R1 | Auditable paravisor code, explicit mediated attestation |
| Azure SEV-SNP | A2 | R0 | Mediated and fully opaque |
| AWS SEV-SNP | A3* | R4 | Best on paper — but measurement chain fracture at OS layer |
| AWS Nitro | A1 | R0 | Provider-rooted — deepest CSP trust dependency |
| Bare-metal TDX / SEV-SNP | A3 | R0–R4 | Full stack control, true silicon-direct attestation |
*A3 is the platform ceiling. Effective workload attestation may be A0 due to the OS measurement gap.
What this means for your CoCo Vector
These baselines set the floor for your system's vector. Your application inherits the attestation ceiling and firmware R-grade. Everything above — your OS, your app, your binding, your key release — builds on this foundation.
A system on GCP TDX with a reproducible app, strong binding, and strict key release scores:
A2[GCP TDX] | R[f0/o0/l4/a4] | B2 | K4
The same system on Azure TDX:
A2[Azure TDX] | R[f1/o0/l4/a4] | B2 | K4
The same system on AWS Nitro:
A1[AWS Nitro] | R[f0/o0/l4/a4] | B2 | K4
The application engineering is identical. The platform changes the vector. Choose accordingly — and make the trust decision explicit.
No public cloud platform as of 2026 achieves A3 with an intact measurement chain from firmware to application. A3 currently requires bare-metal. Every cloud platform requires at least one trust decision — the baselines above tell you exactly where that decision lives for each provider.
GCP TDX sits between Azure TDX and bare-metal: direct quote delivery (no vTPM proxy) but closed hypervisor in TD launch TCB. If your threat model requires A3, bare-metal is the only option on any public cloud today.