Reading the CoCo Vector

You now know the four dimensions: Attestation (A), Reproducibility (R), Binding (B), and Key Release (K). Time to put them together.

The equation

K x R x A x B = V

A system's Verifiability (V) depends on all four dimensions being present. This is not a single numeric score and should never be collapsed into one. It expresses a structural truth: if any dimension is zero, verifiability is zero.

• A = 0 → no measurement possible. The workload has no hardware proof.
• R = 0 → irreproducible build. No one can verify what the binary is.
• B = 0 → flawed architecture. The quote proves nothing about the current session.
• K = 0 → secrets released without enforcement. The TEE is decoration.

Each zero kills the system in a different way. The equation makes that unavoidable.

The notation

The CoCo Vector is written as a linear sequence:

A | R | B | K

Here's what a real one looks like:

A2[Azure TDX] | R[f1/o0/l4/a4] | B2 | K4

Let's read it:

• A2[Azure TDX] — Silicon-rooted but mediated. Azure's paravisor sits in the attestation path. The trust anchor (Azure TDX) is declared explicitly in brackets.
• R[f1/o0/l4/a4] — Read left to right: firmware is source-available but not reproducible (f1), OS is fully opaque (o0), libraries and application are deterministically reproducible (l4/a4). Each slot immediately locates the verification gap.
• B2 — Dynamically bound. Fresh session data in reportdata, strictly enforced.
• K4 — Full enforcement. The KBS verifies measurements and session binding before releasing secrets.

This vector tells a complete story: strong software engineering on a mediated platform, with a known firmware verification gap and solid session security. The trust delegation to Azure is explicit, not hidden.

How to read any vector

Explicit Trust Anchors

When A is below A3, the platform's identity should appear in brackets: A2[Azure TDX], A1[AWS Nitro]. This makes the trust delegation visible. It's the difference between "mediated attestation" (which could mean anything) and "mediated by Azure's OpenHCL paravisor" (which is specific and reviewable).

Per-Layer R Notation

R is scored per-layer using R[fX/oX/lX/aX] notation — where f = Firmware, o = OS, l = Libraries, a = Application. This makes verification gaps impossible to miss.

Common patterns:

R profile	What it means
R[f4/o4/l4/a4]	Full-stack reproducibility. Every layer verifiable. Achievable on bare-metal with significant engineering investment.
R[f0/o0/l4/a4]	Reproducible application and libraries, opaque OS and firmware. Most common public cloud profile (GCP TDX, AWS Nitro).
R[f1/o0/l4/a4]	Reproducible application and libraries, source-available but non-reproducible firmware, opaque OS. Typical on Azure TDX (OpenHCL).
R[f1/o0/l3/a3]	Source-available firmware, SLSA-provenance app/libs, opaque OS. Strong provenance without full determinism.
R[f4/o0/l4/a4]	Reproducible firmware and app (AWS SEV-SNP OVMF baseline), opaque or unmeasured OS layer.

The strongest profile

A3 | R[f4/o4/l4/a4] | B2 | K4

Direct silicon-rooted attestation, fully reproducible at every layer, dynamic binding, and full key-release enforcement. This is the theoretical maximum — achievable on bare-metal with significant engineering investment. No public cloud currently supports this profile end-to-end.

CSP trust vs. architectural flaws

This is the most important interpretive principle. Not all non-maximum scores are equal:

A1 or A2 is a conscious trust delegation. You are deliberately trusting the CSP as part of the attestation path. If that dependency is explicit in the threat model, the architecture remains coherent and production-worthy.

R0, B0, or weak K levels are architectural weaknesses. These create blind spots — in supply-chain verification, session identity, or secret-release enforcement — that leave the system structurally exposed regardless of intent.

The practical comparison:

A1[AWS Nitro] | R[f0/o4/l4/a4] | B2 | K4 is often stronger in practice than A3 | R[f0/o0/l0/a0] | B0 | K3.

The first system explicitly trusts AWS but verifies everything else rigorously. The second runs on superior hardware but is opaque, unbound, and loosely enforced. Good hardware cannot compensate for broken software verification.

The Scorecard

The final deliverable of a Practical CoCo evaluation is the Scorecard — a table that pairs each dimension's score with a justification explaining why.

Target: Confidential Signing Service v1.2 Deployment Context: Azure TDX CVM

Dimension	Score	Justification
A: Attestation	A2[Azure TDX]	Silicon-Rooted, Mediated. Intel TDX hardware, but Azure's OpenHCL paravisor mediates the attestation path. The platform is silicon-rooted, but Azure's mediation layer is inside the TCB.
R: Reproducibility	R[f1/o0/l4/a4]	Significant Verification Gap. Application and libraries are deterministically reproducible (a4/l4). The firmware is source-available but not reproducible (f1). The guest OS is fully opaque (o0). Strong at the top, blind at the foundation.
B: Binding	B2	Dynamically Bound & Enforced. Fresh session identity hashed into reportdata. Verifiers tie the live session to the attested workload.
K: Key Release	K4	Dynamically-Bound / Full Enforcement. The KBS verifies measurements and enforces bound reportdata before releasing the signing seed.

The Vector

A2[Azure TDX] | R[f1/o0/l4/a4] | B2 | K4

Executive Summary: Strong dynamic security alignment (B2 + K4). Explicit Azure trust delegation (A2). Application and libraries are fully reproducible, but the system carries a significant verification gap — the firmware is source-available but not reproducible (f1) and the guest OS is fully opaque (o0). The trust assumptions are declared, not hidden.

Composability: Mixed Workloads

A single CoCo Vector covers one trust boundary. When a workload spans multiple TEEs — for example, a CPU TEE passing data to a GPU TEE — each component gets its own independent KRAB vector scored separately:

[CPU: A3 | R[f0/o0/l4/a4] | B2 | K4] + [GPU: A1[NVIDIA] | R[f0/o0/l0/a0] | B0 | K0]

The + means two independently scored components. By default, an external verifier who validates the CPU quote has no evidence about which GPU — or whether any authentic GPU — is actually receiving the sensitive data. The compound vector makes the weakest link explicit even when no binding exists.

Establishing cryptographic trust between components

A CPU TEE and a GPU TEE are separate attestation domains. Simply running code in both does not establish a verifiable trust relationship between them. To create a verifiable end-to-end trust claim, the CPU TEE must complete a 3-step binding protocol:

1. Request the GPU's attestation report — via SPDM (Security Protocol and Data Model) over PCIe, retrieving the GPU's hardware attestation report
2. Verify the GPU's attestation report — confirm the GPU's identity and integrity against the expected hardware certificate chain
3. Bind the GPU report into the CPU TEE's own quote — hash the verified GPU report into the CPU TEE's reportdata field before generating its own quote

Without step 3, no cryptographic link exists between the two attestation domains — the vectors remain two separate, unlinked claims.

When step 3 is completed, record the binding in the CPU component's B dimension justification in the scorecard: note that the GPU attestation report is included in reportdata. The + notation stays the same; the binding claim lives in the scorecard text, not in a separate symbol.

[CPU: A3 | R[f0/o0/l4/a4] | B2* | K4] + [GPU: A1[NVIDIA] | R[f0/o0/l0/a0] | B2 | K0] (B2 on CPU: GPU attestation report bound into reportdata — see scorecard)*

Advisory Dimensions

Two properties don't change your CoCo Vector but are worth calling out in any evaluation:

TCB size — Two A3 systems with identical vectors can have very different attack surfaces. A bare TEE running a single static binary versus a full Linux kernel, container runtime, and application, all measured into the same MRTD, present different lateral attack exposure. Smaller TCB is harder to compromise even if the vector is identical.

Tooling maturity — A system can score A3 | R[f4/o4/l4/a4] | B2 | K4 in theory but be unverifiable in practice if the tooling to independently verify it is undocumented or immature. When producing a scorecard, note whether independent verification is actually achievable with current ecosystem tools (go-tdx-guest, go-sev-guest, RATS frameworks, etc.).

You can now read CoCo Vectors

Every system in the confidential computing ecosystem can be mapped to a vector. The next article — Platform Baselines — applies KRAB to the five major cloud TEE platforms, producing a concrete baseline score for each.

When you encounter a new confidential computing deployment, you now have four questions:

1. What is the attestation ceiling, and is the chain intact?
2. Can every layer be rebuilt and verified — and where does the gap start?
3. Is the session dynamically bound to the attested workload?
4. Does the key-release path enforce all of the above?

The CoCo Vector is the answer compressed into a single line.

Practical tip

When writing a scorecard for your own system, the justification column is the most important part. A score without reasoning is just a letter. The justification forces you to articulate exactly where trust lives and why.