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 | A3 | Silicon-Rooted, Direct. The guest has direct configfs-tsm access. No paravisor intercepts the quote path. Intel's PCK chain roots the trust. |
| 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: The strongest attestation ceiling on any public cloud, paired with the least transparent firmware. You get direct silicon proof that something is running — but that something includes firmware you cannot inspect. GCP compensates with signed endorsements proving the firmware's provenance, but this is a trust-in-Google claim, not independent verification.
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 | A3 | R0 | Direct proof, opaque firmware |
| Azure TDX | A2 | R1 | Auditable code, mediated attestation |
| Azure SEV-SNP | A2 | R0 | Mediated and 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 |
*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:
A3 | 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 + R4 with an intact measurement chain from firmware to application. Every platform requires at least one trust decision. The baselines above tell you exactly where that decision lives for each provider.
When choosing a platform, decide which matters more for your threat model: attestation directness (A3 on GCP/AWS) or firmware auditability (R1 on Azure). They don't currently coexist on any single cloud platform.