Parag Mali - tag: attestation

Verify Me, Don't Trust Me: Apple PCC, Azure Confidential AI, and the Architecture of the Modern AI Cloud

noreply@paragmali.com (Parag Mali) — Mon, 01 Jun 2026 00:00:00 GMT

Apple and Microsoft now ship the same user-facing promise -- "the cloud cannot see your AI prompt" -- through completely different machinery. Apple's **Private Cloud Compute** (announced June 10, 2024 [@apple-pcc-blog]; source release October 24, 2024 [@apple-pcc-research]) runs custom Apple-Silicon servers with a per-node Secure Enclave Processor and publishes every production image hash to a public, append-only **Transparency Log** that the user's device cryptographically refuses to bypass. Microsoft's Azure confidential AI substrate (`NCCads_H100_v5`, GA September 24, 2024 [@ms-h100-ga]) composes AMD SEV-SNP confidential VMs with NVIDIA H100 GPUs in CC-On mode, verifies the composed attestation through Microsoft Azure Attestation, and gates customer-managed keys through Secure Key Release from Azure Key Vault. On five of six architectural axes the two designs differ in *degree*. On the sixth -- verifiable transparency of the production fleet -- they differ in *kind*.

1. Same Promise, Opposite Architectures

On June 10, 2024, Apple announced Private Cloud Compute and promised that "personal user data sent to PCC isn't accessible to anyone other than the user -- not even to Apple" [@apple-pcc-blog]. On September 24, 2024, Microsoft brought its first confidential GPU SKU to general availability. NVIDIA's companion blog called Azure "the first cloud provider to offer confidential computing with NVIDIA H100 GPUs" [@nvidia-h100-ga]. Microsoft's coordinated Trustworthy AI post framed the same architectural commitment: Microsoft itself cannot view or tamper with the data or the model inference process [@ms-h100-ga] [@ms-trustworthy-ai]. Two vendors. The same user-facing contract. Five months apart.

Open the lid on either one and the machinery is unrecognisable.

Apple PCC runs on custom Apple-Silicon servers, each with a Secure Enclave Processor wired into a vendor-controlled certificate chain. Every production node image hash is published to an append-only public log that the user's device cryptographically refuses to bypass [@apple-pcc-blog] [@apple-pcc-release-transparency].

Azure's confidential-AI substrate runs on the Standard_NCC40ads_H100_v5 SKU: 40 non-multithreaded 4th-Gen AMD EPYC Genoa vCPUs, 320 GiB of RAM, one NVIDIA H100 NVL GPU with 94 GB of high-bandwidth memory, with the Trusted Execution Environment "spanning confidential VM on the CPU and attached GPU" [@ms-sku-nccads]. Trust is rooted in AMD's per-chip signing key, Intel's TDX module on the alternative SKU family, NVIDIA's on-die hardware root of trust on the GPU, and a Microsoft-operated verifier service called Microsoft Azure Attestation [@ms-maa-overview]. None of those signers are Apple, and Apple's signer is none of them.

That is not a difference of brand preference. It is a difference about who you are trusting and how you can check.

This article is a side-by-side architectural treatment of the two designs. It will compare them on six axes you will be able to recite at the end:

Silicon control -- who controls the chip, the firmware, the OS, and the inference runtime.
Hardware root of trust -- which signing keys anchor the attestation chain.
Attestation surface -- what cryptographic artefact the relying party actually consumes.
Key release and state model -- whether the customer holds keys, and how those keys are released to the workload.
GPU TEE -- how confidential compute extends from the CPU into the GPU.
Network anonymization -- whether the operator can correlate requests with their originating client.

By the end you should be able to read a Microsoft Azure Attestation JSON Web Token and an Apple PCC attestation envelope at the same level of fluency, and explain to a non-specialist what each cryptographic artefact actually proves. You should be able to name the threat each architecture defends against, and the threats neither closes by construction.

When the user-facing promise is the same, the architectural divergence is the entire story. To understand what that divergence means, we first have to see where each architecture came from. The two designs did not converge on the same problem by coincidence. They descended from two different ancestor problems that took until 2024 to meet.

2. Confidential Computing's Two Parents

September 14, 2017. Mark Russinovich, Azure CTO, publishes "Introducing Azure confidential computing." Microsoft, he writes, is "the first cloud to offer new data security capabilities with a collection of features and services called Azure confidential computing," and the point of the announcement is "encryption of data while in use" [@ms-russinovich-2017]. Russinovich names "data in use" as the third protection state, the missing companion to "at rest" and "in transit." Five years later the Confidential Computing Consortium publishes "A Technical Analysis of Confidential Computing" v1.3, the vendor-neutral document both Apple and Microsoft now anchor on, which defines the field formally and gives the lower bounds explicitly [@ccc-technical-analysis] [@ccc-about].

Russinovich's framing did not appear from nowhere. It was the cloud-operator-side voice of a conversation that had two parents in the underlying hardware.

Parent one: the hardware TEE lineage

A Trusted Execution Environment is a hardware-isolated execution context inside a system whose own host operating system or hypervisor is not trusted to look in. The lineage starts in the early 2000s with ARM TrustZone's split-world NS-bit, then Intel TXT (Trusted Execution Technology) for measured launch on the CPU side -- originally announced as LaGrande Technology at IDF 2003 and rebranded as TXT around 2007 with the vPro / Q35-Q45 chipset rollout. Apple shipped its first Secure Enclave Processor -- a separate Apple-designed processor core on the same SoC as the main application processor, with its own boot ROM, AES engine, and protected memory -- on the iPhone 5s in September 2013 [@apple-sep-guide].

A hardware-isolated execution context inside a larger system in which code can run with cryptographic guarantees of confidentiality and integrity even when the system's own operating system, hypervisor, or peripheral firmware is compromised or controlled by an adversary. TEEs include process-scope enclaves (Intel SGX), VM-scope confidential VMs (AMD SEV-SNP, Intel TDX), and on-die separate-processor designs (Apple Secure Enclave Processor, Microsoft Pluton).

Intel SGX (Software Guard Extensions) arrived as the first widely-available general-purpose TEE on commodity x86 silicon, with the architectural model first described in the McKeen et al. HASP 2013 paper [@mckeen-sgx-hasp] and given general availability on Skylake-era Core CPUs in late 2015. Costan and Devadas's "Intel SGX Explained" (IACR ePrint 2016/086) became the canonical academic systematization [@costan-sgx]. SGX let an application author carve out an enclave -- a slice of address space encrypted in DRAM by a per-CPU memory-encryption engine and measured at creation time -- and have a remote party verify, through an Intel-signed attestation report, that a specific code measurement was running before any secret was released to it.

Per the Confidential Computing Consortium: protection of data in use through computation in a hardware-based, attested Trusted Execution Environment. The CCC explicitly extends the protection state-pair (at rest, in transit) with a third state (in use) and treats hardware TEEs as the substrate that makes the third state cryptographically enforceable. The CCC v1.3 analysis is the vendor-neutral definitional document both Apple and Microsoft cite [@ccc-technical-analysis] [@ms-cc-overview].

Parent two: the cloud-operator-as-adversary lineage

The other parent was the cloud. Once enterprise workloads moved into public clouds, the cloud operator itself became part of the threat model. AMD published the first SEV API specification ("Secure Encrypted Virtualization") in April 2016, with silicon support shipping in the EPYC 7001 "Naples" family in June 2017 -- attaching a per-VM memory-encryption key to AMD EPYC processors. SEV-ES followed in February 2017, adding encrypted register state on world switches. SEV-SNP (Secure Nested Paging), described in an AMD whitepaper in January 2020 [@amd-sev-snp-wp], added integrity protection through the Reverse Map Table. Intel's parallel response was TDX (Trust Domain Extensions), specified in September 2020.

Both AMD and Intel framed the contribution the same way: protect the guest from a hypervisor that may itself be the adversary. That framing was exactly what Russinovich's 2017 post had been pointing at, three years earlier, on the cloud side [@ms-russinovich-2017].

Convergence

The two parents started speaking a common vocabulary in the early 2020s. The Confidential Computing Consortium was founded in August 2019 as a Linux Foundation project community, with members across CPU vendors (AMD, Intel, NVIDIA, ARM), cloud providers (Microsoft, Google, Oracle), and OS / runtime vendors (Red Hat, Canonical, IBM) [@ccc-about].

In January 2023 the IETF Remote ATtestation procedureS (RATS) Working Group published RFC 9334, "Remote ATtestation procedureS (RATS) Architecture," giving the field a single vocabulary for the four roles in any attestation flow: the Attester (the workload making the claim), the Verifier (the party that checks the cryptographic evidence), the Relying Party (the party that makes a decision based on the verified result), and the Endorser (the party that vouches for the Attester's identity, typically the silicon vendor) [@ietf-rfc9334].

Both Apple PCC and Microsoft Azure Attestation map cleanly onto RFC 9334's vocabulary. They use the same words for the same roles. The architectures that fill those roles are different.

timeline title TEE and confidential-computing milestones (2003-2024) section Hardware TEE lineage 2003 : ARM TrustZone (mobile split-world) 2007 : Intel TXT / LaGrande (measured launch) 2013 : Apple Secure Enclave on iPhone 5s 2015 : Intel SGX general availability (Skylake) 2016 : Costan and Devadas SGX Explained section Cloud operator as adversary 2016 : AMD SEV (memory encryption) 2017 : AMD SEV-ES (encrypted register state) 2017 : Azure CC introduced (Russinovich) 2020 : AMD SEV-SNP whitepaper (integrity via RMP) 2020 : Intel TDX specification section Vocabulary and standards 2019 : Confidential Computing Consortium founded 2022 : CCC Technical Analysis v1.3 2023 : IETF RFC 9334 RATS Architecture 2024 : Apple PCC and Azure H100 CC-On GA

Apple's lineage is a third tributary the other two largely overlook. The iPhone Data Protection model, anchored in the SEP since 2013, and iCloud Private Relay's two-hop architecture from 2021 onward both fed into PCC. PCC is the only major-vendor confidential-AI substrate descended from a device-side TEE origin rather than a cloud-side one [@apple-sep-guide] [@apple-pcc-blog].

Both parents converged on the same vocabulary by 2023. But the first attempts at putting that vocabulary into production hit walls neither parent had predicted -- starting with the 128 MB enclave that broke deep learning before it began.

3. Process Enclaves and the Operator-Honesty Assumption

August 2018, USENIX Security. Jo Van Bulck and nine co-authors publish "Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution" [@foreshadow]. The attack reads L1-cached enclave memory transiently and -- this is the load-bearing detail -- recovers the SGX EPID attestation-signing key for the targeted CPU generation. Once an attestation key leaks, every attestation that platform produces is forgeable to the attacker until microcode is updated and the EPID group is revoked. The whole "the enclave really is what it says it is" property collapses for that CPU generation overnight.

To understand what Foreshadow was attacking, it helps to walk SGX's enclave lifecycle. A privileged-mode application invokes ECREATE to reserve an enclave address range; pages are added with EADD, each call measuring the page contents into a SHA-256 chain that becomes the enclave's MRENCLAVE measurement; EINIT finalises the chain and locks the enclave; EENTER is then the only legal entry point [@mckeen-sgx-hasp] [@costan-sgx]. When a remote party asks the enclave to prove its identity, the Quoting Enclave -- a small Intel-signed enclave on every SGX-enabled CPU -- signs a REPORT structure with the EPID key. The remote party verifies the EPID signature against the Intel Attestation Service and learns which code measurement the enclave is running.

sequenceDiagram participant App as Untrusted app participant CPU as SGX hardware participant QE as Quoting Enclave participant IAS as Intel Attestation Service participant RP as Relying Party App->>CPU: ECREATE (reserve enclave) App->>CPU: EADD pages (measured into MRENCLAVE) App->>CPU: EINIT (finalise measurement) App->>CPU: EENTER (transfer control) CPU->>QE: produce local REPORT QE->>IAS: sign REPORT with EPID key IAS->>RP: verify quote, return result RP->>App: release secret if measurement matches A dedicated secure subsystem integrated into Apple Silicon, isolated from the main application processor with its own boot ROM, AES Engine, and protected memory. The SEP runs an L4-derived microkernel and was first shipped on the iPhone 5s in 2013. It is not a TPM, not the NFC Secure Element used for Apple Pay, and not architecturally related to Intel SGX. It is the per-node hardware root of trust on every Apple Private Cloud Compute server [@apple-sep-guide] [@apple-pcc-blog].

SGX scaled to a billion CPUs in three or four years, but it never scaled to deep learning. Three killer constraints stopped it.

Constraint one: the Enclave Page Cache ceiling. On Skylake-class client and Xeon E-2100 / E-2200 (Coffee Lake-based) server SKUs the Enclave Page Cache (EPC) was capped at 128 MB total per socket, of which only ~96 MB was usable for application data after Intel's bookkeeping overhead. An order of magnitude too small for any modern deep-learning workload, where a single set of weights for even a small model could easily exceed the EPC by a factor of 100 or more. (Skylake-SP and Cascade Lake-SP server Xeons did not ship SGX at all; SGX at server scale only arrived with Ice Lake-SP in 2021, by which point the cloud-AI story had moved past process-scope enclaves.)

Constraint two: the programming model. SGX required the application author to split the codebase into a trusted (in-enclave) and untrusted (outside-enclave) half, with explicit ECALL and OCALL transitions and a fixed serialised data interface across the trust boundary. Production codebases written before SGX existed simply refused to be partitioned that way. The handful of teams that tried -- mainly Intel internal proof-of-concepts -- produced systems that worked but did not generalise.

Constraint three: the side-channel cascade. Foreshadow / L1TF in August 2018 [@foreshadow]; SgxPectre at IEEE EuroS&P 2019, demonstrating Spectre-v1-style transient-execution attacks inside SGX enclaves [@sgxpectre]; Plundervolt in IEEE S&P 2020, a software-based fault-injection attack via Intel's privileged voltage-control interface, assigned CVE-2019-11157 [@plundervolt]. Each closed a different residual surface that Intel's threat model had not named. The principled extension -- that any TEE on shared silicon inherits a microarchitectural side-channel surface that the architectural threat model does not cover -- became the field's unspoken second axiom.

SGX's attestation chain itself went through a generational turnover. The original EPID (Enhanced Privacy ID) scheme tied attestation verification to the Intel Attestation Service as a centralised relying party. By 2018 Intel had begun the transition to DCAP (Data Center Attestation Primitives), letting cloud operators host their own attestation infrastructure. The transition was exactly because EPID-pinned-to-IAS was incompatible with how cloud providers wanted to verify attestations at fleet scale.

AMD's first-generation SEV and SEV-ES belong to the same era. They encrypted guest memory and (in SEV-ES) the saved register state on world switches, but they did not yet have the integrity check that would make a malicious hypervisor architecturally unable to mount remap-style attacks. That defence had to wait for SEV-SNP and a different failure that demonstrated, on the other side of the trust boundary, exactly the same lesson Foreshadow had taught on the Intel side.

Process-scope enclaves were the wrong granularity. The fix had to come from somewhere else. What if you encrypted whole virtual machines instead?

4. Three Architectural Waves That Made Cloud Confidential AI Feasible

WOOT 2018. Mathias Morbitzer, Manuel Huber, Julian Horsch, and Sascha Wessel publish "SEVered: Subverting AMD's Virtual Machine Encryption" [@severed]. A malicious hypervisor remaps a guest's network-facing service to point at other guest physical pages; the service unwittingly serves the contents of those pages -- still inside the guest, still nominally encrypted at the memory controller -- as plaintext over the network. The encryption did not break. The attack did not need it to.

This is the architectural insight every Generation-3-and-later confidential VM design is built on.

Key idea: Confidentiality without integrity is not isolation. A confidential VM that encrypts memory but does not bind the encryption to a specific physical page can be tricked into encrypting and then leaking other guests' contents on the operator's behalf. Every TEE design from 2020 onward is haunted by the SEVered failure.

Wave 1 (~2020-2022): VM-level TEEs with hardware-enforced page ownership

AMD's response was SEV-SNP and the Reverse Map Table (RMP): one entry per 4 KB physical page in the system, tracking ownership, validation state, and the permitted size class for that page. Guest pages transition from INVALID to VALIDATED only via a guest-initiated PVALIDATE instruction; subsequent hypervisor remap attempts that would violate the RMP fault out at the hardware level. Intel TDX took a parallel architectural path: a new privilege ring below the hypervisor called SEAM mode, running the Intel-signed TDX Module, with per-VM trust-domain encryption keys managed through MK-TME (Multi-Key Total Memory Encryption).

A hardware-managed table maintained by AMD SEV-SNP processors with one entry per 4 KB physical page in the system. Each entry records the page's owner (which guest, if any), its validation state (`VALIDATED` or not), and the permitted size class. The hypervisor cannot remap a guest-owned page into a different guest without triggering a fault. The RMP is AMD's architectural response to SEVered: it makes the SEVered class of attacks impossible by construction.

Azure brought the SEV-SNP substrate to general availability in 2022 with the DCasv5 and ECasv5 confidential VM families (the a denotes AMD silicon, the s denotes premium storage) [@ms-cc-overview]. Intel TDX entered public preview on Azure in December 2023. Full general availability of the next-generation Intel TDX confidential VMs on 5th-Gen Intel Xeon Scalable Emerald Rapids -- the DCesv6, DCedsv6, ECesv6, and ECedsv6 families -- followed on February 26, 2026 [@ms-tdx-v6-ga] [@ms-dcesv6].

The earlier SEV and SEV-ES generations were not free of side channels either. Li, Zhang, Wang, Li, and Cheng's "CipherLeaks" (USENIX Security 2021) showed a deterministic-ciphertext side channel against SEV-ES: identical plaintext at the same physical address produced identical ciphertext, letting a hypervisor observe constant-time cryptographic implementations and recover keys without ever breaking the encryption [@cipherleaks]. SEV-SNP's tweakable ciphertext mode addressed this, but the architectural lesson -- that "the encryption is intact" is not the same as "the operator learns nothing" -- repeats.

Wave 2 (~2022-2024): Attestation and key release as managed services

The second wave was less spectacular but more consequential for procurement. Microsoft Azure Attestation (MAA) is a managed verifier that consumes SEV-SNP attestation reports, TDX quotes, SGX quotes, VBS enclave reports, vTPM event logs, and Trusted Launch evidence and issues a JSON Web Token (JWT) with documented x-ms-isolation-tee, x-ms-compliance-status, x-ms-sevsnpvm-*, and x-ms-runtime claims [@ms-maa-overview]. Per the MAA overview verbatim: "Azure Attestation supports both platform- and guest-attestation of AMD SEV-SNP based Confidential VMs (CVMs)" [@ms-maa-overview]. The JWT can then drive Secure Key Release from Azure Key Vault Premium or Azure Managed HSM: the encrypted customer key carries a release policy against MAA-issued claims, and the HSM unwraps the key only when the policy is satisfied [@ms-cc-overview].

A managed Microsoft cloud service that acts as the Verifier (in the IETF RFC 9334 sense) for confidential workloads on Azure. MAA consumes hardware-vendor attestation evidence (SGX quotes, SEV-SNP attestation reports, Intel TDX quotes, vTPM event logs) and produces a signed JSON Web Token whose `x-ms-*` claims describe the attested TEE state. The JWT is the artefact that downstream relying parties -- including Azure Key Vault's Secure Key Release flow -- consume to decide whether to release a secret to the workload [@ms-maa-overview]. An Azure Key Vault Premium and Azure Managed HSM capability that gates release of a wrapped key on a successful attestation. The customer attaches a *release policy* to the key at creation time; the policy is evaluated against the claims of an MAA-issued JWT presented at unwrap time. The key is released to the workload only when the MAA token's claims match the policy. SKR makes customer-managed key material a first-class architectural primitive for Azure confidential workloads [@ms-cc-overview] [@ms-maa-overview].

This is the implementation of what RFC 9334 calls the Passport topological pattern: the Attester collects evidence once, hands it to the Verifier, gets back an Attestation Result (the MAA JWT), and then carries that Result to any Relying Party (the HSM, an external policy engine, an audit log) for the rest of the session [@ietf-rfc9334].

The MAA-as-managed-service shift removed a substantial per-customer engineering burden: customers no longer have to write their own attestation-report parsers, certificate-chain validators, or revocation-list checkers. This is the practical reason confidential VMs moved from research artefact to procurement category in 2022-2024. The trade-off it carries is structural: MAA itself becomes a trust anchor. If MAA's signing infrastructure or its policy-evaluation code is compromised, every relying party that consumes a MAA JWT is exposed in the same breath. The verifier is now a control point.

Wave 3 (June-October 2024): GPU TEEs, vendor-controlled fleets, and the public arrival of confidential AI

The third wave landed in five months in 2024 and changed what "confidential AI" could mean in production.

The NVIDIA Hopper H100 confidential-computing whitepaper (WP-11459-001) had landed in July 2023 [@nvidia-whitepaper], and the NVIDIA Developer Blog technical post that accompanied it described the architecture in detail: an on-die hardware root of trust, secure measured boot of the GPU firmware, an SPDM (Security Protocol and Data Model) session connecting the CPU TEE driver to the GPU with mutual authentication, and encrypted bounce-buffer data movement between CPU encrypted memory and GPU encrypted HBM [@nvidia-dev-blog]. The blog states the architectural fact verbatim: "The NVIDIA H100 Tensor Core GPU is the first ever GPU to introduce support for confidential computing" [@nvidia-dev-blog].

Apple announced Private Cloud Compute on June 10, 2024 at WWDC, with the canonical primary titled "Private Cloud Compute: A new frontier for AI privacy in the cloud" [@apple-pcc-blog]. Microsoft Build 2024 (May 21, 2024) announced confidential inferencing not for GPT-4 but for the Azure OpenAI Whisper speech-to-text model [@ms-workshop-whisper].

Microsoft's NCCads_H100_v5 confidential GPU VM family -- 4th-Gen AMD EPYC Genoa CPU plus one NVIDIA H100 NVL GPU per VM, with the TEE spanning both [@ms-sku-nccads] -- reached general availability on September 24, 2024 [@ms-h100-ga]. The companion Microsoft Trustworthy AI post made the same architectural commitment: customer data and models remain inaccessible to Microsoft itself [@ms-trustworthy-ai] [@ms-h100-ga]. NVIDIA's parallel announcement underscored the same fact verbatim: "Azure is the first cloud provider to offer confidential computing with NVIDIA H100 GPUs" [@nvidia-h100-ga].

Then on October 24, 2024 Apple published the supporting source code at github.com/apple/security-pcc, shipped the Virtual Research Environment with macOS Sequoia 15.1 Developer Preview, and extended the Apple Security Bounty to PCC with rewards up to $1,000,000 [@apple-pcc-research] [@apple-pcc-github]. By end of October the substrate for cloud-scale confidential AI existed in two parallel forms. But "shipping" does not mean "settling on one architecture." Two distinct breakthroughs landed within five months of each other and took the substrate in opposite directions.

flowchart LR A[Attacker
controls hypervisor] -->|Remaps guest GPA tables| B[SEV guest
network service] B -->|Reads memory under remapped pages| C[Other guest memory
still under encryption] B -->|Serves bytes over network| D[Attacker collects
plaintext] style A fill:#fee,stroke:#c33,color:#7f1d1d style D fill:#fee,stroke:#c33,color:#7f1d1d

Note: SEVered did not recover an encryption key. It did not need to. By remapping page tables the malicious hypervisor convinced the guest to serve its own encrypted contents as plaintext. The fix -- per-page ownership tracking in hardware via the AMD Reverse Map Table and analogous mechanisms in Intel TDX -- defines what a Generation-3 confidential VM is. Earlier generations encrypted memory but did not authenticate ownership. They were not isolation; they were just encryption.

5. Two Distinct 2024 Designs

June 10, 2024, WWDC. Apple Security Engineering and Architecture -- the institutional author block of the post, along with User Privacy, Core OS, Services Engineering, and Machine Learning and AI -- publishes "Private Cloud Compute: A new frontier for AI privacy in the cloud" [@apple-pcc-blog]. The post enumerates five core requirements verbatim: stateless computation on personal user data, enforceable guarantees, no privileged runtime access, non-targetability, and verifiable transparency [@apple-pcc-blog]. The fifth requirement is the one nothing in the field had ever shipped at this scale.

(a) Apple's Verifiable Transparency model

Every production PCC node software image hash is published to an append-only Transparency Log. Apple's canonical terminology is "Transparency Log" and "Release Transparency" -- both are reflected in the URL path of the Apple documentation page that defines the model [@apple-pcc-release-transparency] [@apple-pcc-doc]. The user's device cryptographically refuses to forward a request to a node whose image hash is not in the log; in Apple's words, "your device won't issue requests to PCC unless the OS image running in PCC is logged for inspection" [@apple-pcc-blog].

An append-only public log of every production Private Cloud Compute node software image hash. The log is structured along the lines of RFC 6962 Certificate Transparency -- a Merkle tree of measurement entries that can be audited end-to-end without trusting any single party. Apple's canonical primary uses the terms "Transparency Log" and "Release Transparency"; "Verifiable Image Catalog" is not Apple terminology. The user's device refuses to forward a request to a PCC node whose image hash is not in the log, making the log a precondition for any data flow [@apple-pcc-blog] [@apple-pcc-release-transparency].

On October 24, 2024 Apple released the supporting source code at github.com/apple/security-pcc, shipped the Virtual Research Environment (VRE) with macOS Sequoia 15.1 Developer Preview to let researchers run the PCC software stack (including a virtual Secure Enclave Processor) inside a Mac, and extended the Apple Security Bounty to PCC with rewards up to $1,000,000 [@apple-pcc-research] [@apple-pcc-github]. The README on the source release states the scope plainly: "The publication of this code is intended for security research and verification purposes only" [@apple-pcc-github]. The components in the release include CloudAttestation (the attestation envelope library), Thimble (the on-device PCC client), splunkloggingd (the audited logging path), and srd_tools (security-research tooling).

Personal user data sent to PCC isn't accessible to anyone other than the user -- not even to Apple. -- Apple Security Engineering and Architecture, June 10, 2024 [@apple-pcc-blog]

The network ingress path to PCC reinforces the non-targetability requirement. Client requests are routed through an Oblivious HTTP relay, operated by an independent third party rather than by Apple, that strips the client IP address before forwarding the request to the PCC cluster. OHTTP is standardised in IETF RFC 9458 by Martin Thomson and Christopher A. Wood, January 2024, with the explicit goal of letting "a client make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client" [@ietf-rfc9458].

Apple's Target Diffusion design layers an RSA Blind Signatures protocol -- RFC 9474 [@ietf-rfc9474] -- on top of the OHTTP path to issue single-use credentials, so even the relay cannot link two requests as having come from the same client.

The OHTTP relay is third-party operated -- not Apple-operated. This is the architectural detail that makes non-targetability work. If Apple operated both the relay and the PCC cluster, Apple would observe the client IP at the relay and the request payload at the cluster and could correlate them. By splitting the two roles across two organizations whose business interests are not aligned, Apple can argue (and the architecture can enforce) that no single organization holds both halves of the correlation.

sequenceDiagram participant Dev as User device participant Log as Transparency Log participant Relay as OHTTP relay (third party) participant Node as PCC node (SEP-rooted) Dev->>Log: fetch current log root Log-->>Dev: signed root, inclusion proofs Dev->>Dev: verify target image hash is in log Dev->>Relay: encrypted request (no client IP at origin) Relay->>Node: forwarded request (relay IP only) Node->>Node: enforce stateless processing Node-->>Relay: response, SEP-signed attestation envelope Relay-->>Dev: response delivered Dev->>Dev: verify SEP attestation matches logged image

(b) Microsoft and NVIDIA's cross-vendor CPU+GPU TEE composition

The other 2024 breakthrough was a composition. The Standard_NCC40ads_H100_v5 SKU is a confidential VM whose Trusted Execution Environment "spans confidential VM on the CPU and attached GPU, enabling secure offload of data, models, and computation to the GPU" [@ms-sku-nccads]. The substrate is an AMD SEV-SNP confidential VM on a 4th-Gen AMD EPYC Genoa CPU. The accelerator is an NVIDIA H100 NVL GPU with 94 GB of high-bandwidth memory, operating in CC-On mode [@ms-sku-nccads] [@nvidia-dev-blog].

The H100 in CC-On mode performs secure measured boot of its firmware against an on-die hardware root of trust, then establishes mutually-authenticated SPDM (Security Protocol and Data Model) sessions with the CPU TEE driver, and routes all data movement between CPU encrypted memory and GPU encrypted HBM through an encrypted bounce buffer. The NVIDIA Developer Blog states it verbatim: "a chain of trust is established through ... a security protocols and data models (SPDM) session to securely connect to the driver in a CPU TEE" [@nvidia-dev-blog]. The GPU's attestation report is signed against NVIDIA's on-die root of trust and consumable through NVIDIA's NRAS (NVIDIA Remote Attestation Service) and the open-source nvtrust SDK [@nvidia-nvtrust].

An IETF protocol for forwarding HTTP requests through an intermediary in a way that prevents either the intermediary or the target from linking requests to a single client. Per RFC 9458 verbatim: "Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages" [@ietf-rfc9458]. Apple Private Cloud Compute uses an OHTTP relay operated by an independent third party to enforce non-targetability.

The CPU-to-GPU interconnect throughput in H100 CC-On is bounded by CPU encryption performance, not by raw PCIe or NVLink bandwidth. The NVIDIA Developer Blog measures it verbatim: "It is limited by CPU encryption performance, which we currently measure at roughly 4 GBytes/sec" [@nvidia-dev-blog]. Practitioners sizing throughput around H100 NVL's 94 GB HBM3 capacity should reason about the ~4 GB/s encryption ceiling, not the headline NVLink rate. The ceiling is what makes large-model long-sequence workloads amortise the overhead well, and what makes small-model short-prompt workloads pay a higher relative cost.

A DMTF standard (DSP0274) that defines a mutually-authenticated message-exchange protocol between two PCIe endpoints, used in the NVIDIA H100 CC-On architecture to establish a secure session between the host CPU TEE driver and the GPU. The session protects all subsequent control-plane and data-plane traffic and lets each endpoint verify the other's identity and measurements before any sensitive data crosses the PCIe link [@dmtf-spdm] [@nvidia-dev-blog] [@nvidia-nvtrust].

The SPDM handshake itself is specified by DMTF DSP0274 v1.1.0 [@dmtf-spdm] and walks a precise message sequence the relying-party implementer needs to know exists: GET_VERSION (§10.2) negotiates the protocol version; GET_CAPABILITIES (§10.3) negotiates supported capabilities; NEGOTIATE_ALGORITHMS (§10.4) negotiates the cryptographic algorithm family; GET_DIGESTS (§10.7) fetches device-certificate digests; GET_CERTIFICATE (§10.8) retrieves the per-die device-identity certificate; CHALLENGE_AUTH (§10.9) verifies the device's signature over a host-supplied nonce; GET_MEASUREMENTS (§10.11) retrieves the device's runtime measurement vector; and KEY_EXCHANGE (§10.16) establishes the session key over ECDHE on P-384 [@dmtf-spdm]. The first three messages are an ordered prerequisite: per DSP0274 §10.6, no other request is valid until the three-step negotiation completes [@dmtf-spdm].

The negotiated crypto family for the H100 in CC-On mode is SHA-384 / ECDSA-P384 / AES-256-GCM. The device-identity certificate is signed with a per-die ECC-384 hardware-bound key burned into H100 fuses, and revocation runs through the NVIDIA OCSP endpoint -- the GPU-side analogue of the AMD KDS CRL path described later [@nvidia-dev-blog].

sequenceDiagram participant Req as Host CVM (Requester) participant Resp as NVIDIA H100 (Responder) Req->>Resp: GET_VERSION (DSP0274 10.2) Resp-->>Req: VERSION Req->>Resp: GET_CAPABILITIES (10.3) Resp-->>Req: CAPABILITIES Req->>Resp: NEGOTIATE_ALGORITHMS (10.4) Resp-->>Req: ALGORITHMS (SHA-384, ECDSA-P384, AES-256-GCM) Req->>Resp: GET_DIGESTS (10.7) Resp-->>Req: DIGESTS Req->>Resp: GET_CERTIFICATE (10.8) Resp-->>Req: CERTIFICATE (per-die ECC-384) Req->>Resp: CHALLENGE (10.9) Resp-->>Req: CHALLENGE_AUTH (signature over nonce) Req->>Resp: GET_MEASUREMENTS (10.11) Resp-->>Req: MEASUREMENTS Req->>Resp: KEY_EXCHANGE (10.16, ECDHE P-384) Resp-->>Req: KEY_EXCHANGE_RSP

The NVIDIA-side verifier reference moved generations recently: the Python SDK in NVIDIA/nvtrust [@nvidia-nvtrust] is now superseded by nv-attestation-sdk-cpp (also called "NV Attest"), which NVIDIA describes as "a new and improved version of the NVIDIA nvtrust attestation SDK, redesigned to address key limitations" [@nvidia-attest-sdk-cpp]. The C++ SDK is the current canonical reference; the older Python SDK still works but is deprecated. The NVIDIA CC documentation index links both [@nvidia-cc-docs].

The composed attestation -- the AMD SEV-SNP attestation report from the host CVM, joined with the NVIDIA-signed GPU attestation report from the H100 -- is consumable by Microsoft Azure Attestation as a single policy decision [@ms-maa-overview]. Secure Key Release from Azure Key Vault Premium or Azure Managed HSM then gates customer key material on that composite attestation, so the model weights or the user's prompt encryption key are released to the workload only when the entire chain (AMD silicon, AMD firmware, Microsoft hypervisor, customer guest OS, NVIDIA GPU firmware, NVIDIA hardware root of trust) verifies [@ms-maa-overview] [@ms-cc-overview].

flowchart TD A[Customer workload] --> B[Host CVM
AMD SEV-SNP + RMP] B -->|SPDM session, mutual auth| C[NVIDIA H100 NVL
CC-On mode] C -->|Signed GPU attestation| D[NVIDIA NRAS] B -->|SEV-SNP attestation report| E[Microsoft Azure Attestation] D --> E E -->|MAA JWT, x-ms claims| F[Azure Key Vault Premium
or Managed HSM] F -->|SKR release policy check| G[Customer key released
to workload] style C fill:#e6f3ff,stroke:#36c,color:#1a365d style E fill:#fff3e6,stroke:#c63,color:#7b341e The NVIDIA H100 Tensor Core GPU is the first ever GPU to introduce support for confidential computing. -- NVIDIA Developer Blog [@nvidia-dev-blog]

Two breakthroughs. Two cryptographic envelopes. Both prove something about a workload. Both are signed by hardware. Both will satisfy a JWT verifier. And underneath that surface similarity sits a genuinely different epistemological model.

Apple PCC commits, publicly and in advance, to the exact image hash that will be served, and refuses to serve any other. Azure CC-AI does not publicly commit in advance to the bits the verifier runs against -- it produces a JWT that says "I verified what I was given." Both are cryptographic; one is structurally auditable by an independent researcher, the other is a single vendor's word.

This is the aha moment to mark with both hands. "Verify me" is architecturally different from "trust me," even when both produce a JWT.

To turn that distinction into something a reader can carry into procurement, we have to actually walk the six axes. On which do these architectures genuinely differ, and on which do they differ only in implementation strategy?

6. Six Axes, One Difference In Kind

Of the six architectural axes, five are differences in degree -- both PCC and Azure CC-AI do similar things differently. Exactly one is a difference in kind: verifiable transparency of the production fleet. Apple ships a public append-only log of every production node image hash; no other major-cloud confidential-AI substrate ships an architectural equivalent as of mid-2026. The rest of this section walks each axis with the trade-off named, the threat model spelled out, and the primary cited.

Axis 1: Silicon control

PCC is a single-vendor stack end to end. Apple controls the SoC, the SEP, the firmware, the OS, the Swift-based inference runtime, and the bug-bounty program [@apple-pcc-blog]. Apple has not publicly named the specific chip family used in PCC nodes; firmware identifiers and independent analyses point to M2-Ultra-class silicon at launch (firmware identifier ComputeModule14,1 [@appledb-cm14]) with a transition to M5-class silicon during 2026 (identifier J226C [@nine-to-five-mac-m5] [@winbuzzer-m5]), and the Apple Machine Learning Research introduction confirms only that the cloud-side model runs on "Apple silicon servers" without naming a generation [@apple-foundation-models].

Azure CC-AI is a multi-vendor commodity composition by design. AMD provides the EPYC CPU and the AMD Platform Security Processor; Intel provides the Xeon CPU and the TDX module on the alternate Intel SKU family; NVIDIA provides the H100 GPU and the on-die hardware root of trust; Microsoft provides the hypervisor and MAA; the customer chooses the guest OS [@ms-cc-overview] [@ms-sku-nccads] [@nvidia-dev-blog].

The trade-off is direct. Apple's single-vendor stack is operationally simpler and the trust posture is internally consistent, but the trust root collapses to Apple. Azure's multi-vendor stack spreads trust across four independent signers, but no one of them sees the entire system, and the composition itself is a source of complexity.

Axis 2: Hardware root of trust

PCC anchors per-node trust in the Secure Enclave Processor on each Apple-Silicon server. The SEP is bound to an Apple-controlled certificate authority; the SEP signs the node's attestation envelope; the Apple-controlled CA's chain is the root the user's device trusts [@apple-pcc-blog] [@apple-sep-guide].

Azure's hardware root of trust is structurally distributed. A vTPM exposed to the CVM provides one anchor; the AMD Platform Security Processor signs SEV-SNP attestation reports with a per-chip Versioned Chip Endorsement Key (VCEK) [@amd-kds] [@amd-sev-snp-wp]; the NVIDIA on-die RoT signs the GPU attestation; MAA operates as the verifier-of-record that joins these into a single decision artefact [@ms-maa-overview].

A per-die ECDSA signing key derived inside the AMD Platform Security Processor (PSP) from a chip-specific secret fused into the silicon at manufacture. The VCEK signs SEV-SNP attestation reports; the certificate chain runs `VCEK -> AMD SEV signing key (ASK) -> AMD Root Key (ARK)`, with the ARK pinned out-of-band against AMD's published fingerprint and the per-chip VCEK fetched from the AMD Key Distribution Service (KDS) at `kdsintf.amd.com` keyed on the chip ID plus the four TCB-version-vector `*Spl` parameters (`blSpl`, `teeSpl`, `snpSpl`, `ucodeSpl`) parsed out of the 1184-byte attestation report [@amd-kds] [@amd-sev-snp-wp].

The chain itself is short and walkable. The ARK and ASK PEMs are served as a single bundle from the KDS endpoint /vcek/v1/<family>/cert_chain on host kdsintf.amd.com (returning, on the Milan family, an ARK-Milan and SEV-Milan certificate pair issued from AMD Engineering's Santa Clara CA with 25-year validity dated 2020-10-22 [@amd-kds]). The per-die VCEK is served from /vcek/v1/<family>/<chip_id>?blSpl=..&teeSpl=..&snpSpl=..&ucodeSpl=.. on the same KDS host, where the chip ID and the four *Spl TCB-version-vector query parameters are parsed out of the SEV-SNP attestation report itself.

A relying party that wants to verify a SEV-SNP attestation without trusting MAA fetches the chain from KDS, validates the chain against an out-of-band-pinned ARK fingerprint, and checks that the chip ID and TCB version in the report match the chain. The canonical open-source CLI for this is virtee/snpguest [@virtee-snpguest], the active successor to the deprecated AMDESE/sev-tool [@amd-sev-tool].

Axis 3: Attestation surface

PCC produces a per-device attestation envelope cross-checked against the public Transparency Log. The user's device does not just verify the SEP signature; it verifies that the image hash named in the envelope is included in the public log. If the hash is not in the log, the device refuses to forward the request [@apple-pcc-blog] [@apple-pcc-release-transparency].

Azure produces an MAA-issued JWT. The customer's relying party parses the JWT and matches claims. The MAA overview documents the SEV-SNP-specific claims and the platform-vs-guest distinction explicitly [@ms-maa-overview]. For confidential GPU workloads, NVIDIA's NRAS claims about the H100 are joined into the same JWT.

The procurement-grade payoff: a customer can verify SEV-SNP attestation without trusting MAA by running the snpguest workflow directly against the AMD KDS [@virtee-snpguest] [@amd-kds]. Or they can trust MAA's JWT and validate it against the MAA JWKS, trading one trust anchor (AMD's ARK fingerprint) for another (Microsoft's JWKS). Both paths are real; most production customers deploy the MAA path because it is operationally simpler, but the snpguest-based path is what unlocks "we do not have to trust MAA" for a procurement audit.

{` // Demonstrates the structure of an MAA JWT for an AMD SEV-SNP confidential VM. // In production the JWT would be signed by an MAA tenant key and verified // against the tenant's JWKS endpoint. This example just decodes a sample payload.

const sampleMaaJwt = [ // header (base64url) 'eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9', // payload (base64url) -- sample x-ms claims 'eyJ4LW1zLWlzb2xhdGlvbi10ZWUiOiJzZXZzbnB2bSIsIngtbXMtY29tcGxpYW5jZS1zdGF0dXMiOiJhenVyZS1jb21wbGlhbnQtY3ZtIiwieC1tcy1zZXZzbnB2bS1ndWVzdHN2biI6OCwieC1tcy1zZXZzbnB2bS1sYXVuY2htZWFzdXJlbWVudCI6InhEa0...","x-ms-runtime":"e30="}', // signature placeholder 'signature' ].join('.');

function decodeJwtPayload(jwt) { const [, payload] = jwt.split('.'); // base64url -> base64 const b64 = payload.replace(/-/g, '+').replace(/_/g, '/'); return JSON.parse(atob(b64)); }

const payload = decodeJwtPayload(sampleMaaJwt); console.log('TEE family: ', payload['x-ms-isolation-tee']); console.log('Compliance status: ', payload['x-ms-compliance-status']); console.log('Guest SVN: ', payload['x-ms-sevsnpvm-guestsvn']); console.log('Launch measurement:', payload['x-ms-sevsnpvm-launchmeasurement']);

// A Secure Key Release policy would gate key release on claims like: // "x-ms-isolation-tee" == "sevsnpvm" // "x-ms-compliance-status" == "azure-compliant-cvm" // "x-ms-sevsnpvm-guestsvn" >= 8 // matched against the MAA-issued JWT. `}

The MAA path hides KDS fetching, certificate-chain validation, and TCB-rollback policy enforcement from the relying party by emitting a JWT whose `x-ms-attestation-type` claim is `sevsnpvm` and `x-ms-compliance-status` claim is `azure-compliant-cvm`. The relying party then validates against the MAA JWKS instead of pinning the AMD ARK fingerprint. Operationally simpler, but it trades trust in AMD for trust in MAA. A customer that wants a procurement-defensible "we do not have to trust MAA" posture runs the six-step `snpguest` Regular Attestation Workflow directly against the AMD KDS [@virtee-snpguest]. The `snpguest verify certs` step validates the VCEK -> ASK -> ARK chain but cannot detect a substituted ARK; the ARK fingerprint must be pinned out-of-band against AMD's published value before the chain is trusted. The other architectural delta: `snpguest verify attestation` checks the TCB version vector in the attestation report against the version baked into the VCEK certificate, surfacing TCB rollback. Once both checks pass, the relying party has cryptographic evidence the workload is running on a specific physical AMD CPU at a specific firmware level -- without ever talking to Microsoft.

{`# The six-step Regular Attestation Workflow from the virtee/snpguest README.

Each step maps to a wire-level KDS GET except step 1 (which talks to the SNP guest firmware device locally). Run this from inside an SEV-SNP guest VM on Azure (e.g. on a DCasv5 SKU) -- not from the host. Step 1: ask the guest firmware for a fresh attestation report bound to a 64-byte nonce. The report includes chip_id and the four *Spl TCB vector fields the next steps will use to fetch the per-die VCEK.

snpguest report attestation-report.bin request-data.bin --random

Step 2: fetch the ARK + ASK PEM bundle for this CPU family from AMD KDS. Endpoint: GET /vcek/v1//cert_chain on host kdsintf.amd.com

snpguest fetch ca pem milan ./certs

Step 3: fetch the per-die VCEK certificate from AMD KDS, keyed on chip_id and the four *Spl values parsed out of the attestation report. Endpoint: GET /vcek/v1//?blSpl=..&... on the KDS host

snpguest fetch vcek pem milan ./certs attestation-report.bin

Step 4: fetch the current AMD CRL so revoked VCEKs can be rejected. Endpoint: GET /vcek/v1//crl on the KDS host

snpguest fetch crl pem milan ./certs

Step 5: validate the chain locally (VCEK -> ASK -> ARK). IMPORTANT: snpguest cannot detect a substituted ARK. Before running this command, pin the ARK fingerprint out-of-band against AMD's published value.

snpguest verify certs ./certs

Step 6: verify the attestation signature with the validated VCEK and check the TCB version vector in the report against the VCEK certificate. This is the step that surfaces TCB rollback.

snpguest verify attestation ./certs attestation-report.bin `}

Axis 4: Key release and state model

This is where the architectural philosophies diverge most visibly. PCC nodes are stateless by design. There is no customer key material on the node, no key release ceremony, no HSM gating. Apple's first core requirement names this verbatim: "stateless computation on personal user data" [@apple-pcc-blog]. State that needs to persist across requests does so on the user's device, not on the PCC fleet.

Azure treats stateful, customer-managed keys as a first-class architectural primitive. Secure Key Release from Azure Key Vault Premium or Azure Managed HSM gates key release on an MAA-issued JWT whose claims must match the release policy attached to the encrypted key [@ms-cc-overview]. The Microsoft reference confidential-LLM tutorial walks the SKR-from-AKV-Premium flow end to end on a Standard_NCC40ads_H100_v5 SKU [@ms-workshop-llm]. Customer-managed keys, customer-controlled HSMs, and customer audit logs are how regulated buyers reason about confidential workloads, and Azure's design accommodates that workflow directly.

A minimal SKR release policy is a JSON document referencing MAA-issued claims. A simplified example for an SEV-SNP CVM target:

{
  "version": "1.0.0",
  "anyOf": [
    {
      "authority": "<your MAA tenant URL>",
      "allOf": [
        { "claim": "x-ms-isolation-tee", "equals": "sevsnpvm" },
        { "claim": "x-ms-compliance-status", "equals": "azure-compliant-cvm" },
        { "claim": "x-ms-sevsnpvm-guestsvn", "greater-than-or-equals": 8 }
      ]
    }
  ]
}

At unwrap time the HSM evaluates the policy against the JWT the workload presents. Only if every condition is met is the key material released. The policy is bound to the key at creation time and cannot be modified after the fact without rewrapping under a fresh policy.

Axis 5: GPU TEE

PCC uses Apple GPUs that are integrated on the same SoC as the CPU and SEP. By construction they sit inside the same SEP-rooted attestation envelope -- there is no separate cross-vendor PCIe attestation handshake because there is no PCIe handshake to begin with [@apple-pcc-blog].

Azure uses NVIDIA H100 NVL GPUs in CC-On mode, with the architecture described above: on-die RoT, SPDM session, encrypted bounce buffer, NRAS-signed attestation report joined to the SEV-SNP CVM attestation through MAA [@ms-sku-nccads] [@nvidia-dev-blog]. The NVIDIA H100 exposes three confidential-computing modes: CC-Off (the normal non-confidential default; no isolation, no encryption); CC-On (full confidential mode, the only mode that should be used in production); and CC-DevTools (per NVIDIA's developer blog, "a partial CC mode that will match the workflows of CC-On mode, but with security protections disabled and performance counters enabled" [@nvidia-dev-blog]) [@nvidia-cc-docs]. The three modes share a bring-up surface, but only CC-On enforces the full isolation contract.

Note: NVIDIA's documentation is explicit that CC-DevTools weakens isolation specifically so that profiling and debugging tools that need performance-counter access can work [@nvidia-cc-docs]. Production confidential-AI workloads must run in CC-On. Verification step for relying parties: the GPU attestation report includes a mode field; the MAA JWT and the NRAS attestation that compose into it both surface this. A release policy that does not check the GPU mode field can release customer key material to a workload running on a partially-protected GPU. Treat CC-DevTools as a bring-up state, not a deployment state.

AMD's MI300X GPU ships as compute across multiple clouds (Oracle OCI, DigitalOcean, Vultr, Crusoe, TensorWave, Hot Aisle, Seeweb [@mi300x-cloud-list]) but has no production-equivalent confidential-GPU mode at GA on a major commercial cloud as of mid-2026. PCIe TDISP and SEV-TIO Linux support is landing in 2025-2026 kernels, but the GA gap is the load-bearing fact for any procurement that prefers AMD over NVIDIA at the accelerator tier. Azure's confidential GPU offering is H100-only at GA.

A subtle and procurement-critical detail: Microsoft Azure Attestation does not directly attest the GPU. The MAA overview documents the SEV-SNP path and the platform-vs-guest distinction, but the GPU attestation is produced and signed by NVIDIA NRAS, not MAA [@ms-maa-overview] [@nvidia-dev-blog]. The composed MAA JWT carries the NVIDIA-signed GPU attestation as a nested claim. A customer's relying party that wants to verify the GPU attestation against NVIDIA's hardware root of trust must validate the NRAS signature, not the MAA signature, on that nested portion.

This is the double attestation pattern: the SEV-SNP CVM attestation is signed by AMD VCEK; the H100 GPU attestation is signed by NVIDIA's on-die root of trust; MAA composes them into one JWT, but the two signatures must be verified against two different roots. The Azure confidential-computing-cvm-guest-attestation and az-cgpu-onboarding repositories provide the reference patterns for both halves of this verification [@az-cgpu-onboarding].

The double attestation is one place the "MAA is the verifier of record" framing oversimplifies. MAA is the verifier of record for the composition -- but the underlying signatures still come from AMD and NVIDIA. A relying party that wants to refuse a workload running on a TCB-rolled-back AMD CPU plus a CC-DevTools-mode H100 needs to check the AMD TCB version vector against a TCB-version policy (snpguest can do this) and the NVIDIA GPU mode field against a "CC-On only" policy. MAA can be configured to enforce both of these in the release policy, but the customer has to actively write the policy; the defaults will not catch a CC-DevTools-mode H100.

Performance overhead is small. Zhu, Yin, Deng, Almeida, and Zhou (Phala / Fudan / io.net), in arXiv 2409.03992 (v4, November 5, 2024), benchmarked H100 CC-On on vLLM v0.5.4 with the ShareGPT dataset on Llama-3.1-8B-Instruct and report that "for the majority of typical LLM queries, the overhead remains below 7%, with larger models and longer sequences experiencing nearly zero overhead" [@phala-benchmark]. The dominant overhead source is the PCIe encrypted bounce buffer, capped at the ~4 GB/s CPU-encryption ceiling discussed in §5(b); large models amortise that cost across many tokens.

The "below 7%" overhead number is benchmarked on a specific stack (vLLM v0.5.4, ShareGPT dataset, Llama-3.1-8B-Instruct) and depends on sequence length and batch size in non-trivial ways [@phala-benchmark]. Smaller models with short prompts and high batch turnover spend a larger fraction of wall-clock time on the bounce-buffer crossings; larger models with long context windows amortise that cost. Quoting "below 7%" without the workload qualification is misleading.

Axis 6: Network anonymization

This is the axis where the two architectures differ in kind.

PCC routes client requests through a third-party-operated Oblivious HTTP relay -- RFC 9458 [@ietf-rfc9458] -- that strips the client IP address before the request reaches the PCC cluster. This implements one of Apple's five named core requirements, non-targetability: an attacker who compromises the PCC fleet cannot single out a specific user's traffic because the fleet does not know which IP issued which request [@apple-pcc-blog]. Apple's Target Diffusion design layers RSA Blind Signatures (RFC 9474) [@ietf-rfc9474] on top to issue single-use credentials, so even the relay cannot link two requests from the same client.

Azure has no equivalent operator-level anonymization layer. This is intentional in Azure's design: an enterprise customer who knows that traffic originates from their own employees generally does not want to anonymize that traffic from their own audit logs. But it is an axis the two architectures differ on in kind rather than in degree, and worth naming as such -- a procurement reader who needs operator-level anonymization will not get it from Azure CC-AI without building it themselves.

The six axes, side by side

The following table consolidates the comparison.

Axis	Apple Private Cloud Compute	Azure Confidential AI
Silicon control	Single-vendor end-to-end (Apple SoC, SEP, firmware, OS, runtime) [@apple-pcc-blog]	Multi-vendor commodity composition (AMD EPYC, Intel Xeon, NVIDIA H100, Microsoft hypervisor) [@ms-cc-overview] [@ms-sku-nccads]
Hardware root of trust	Per-node SEP bound to Apple-controlled CA [@apple-pcc-blog]	vTPM + AMD PSP / VCEK + NVIDIA on-die RoT + MAA as verifier-of-record [@ms-maa-overview] [@amd-kds]
Attestation surface	Per-device envelope cross-checked against public Transparency Log [@apple-pcc-release-transparency]	MAA-issued JWT with documented `x-ms-*` claims [@ms-maa-overview]
Key release / state	Stateless nodes; no customer keys; no release ceremony [@apple-pcc-blog]	SKR from AKV Premium / Managed HSM gated on MAA JWT [@ms-cc-overview]
GPU TEE	Integrated Apple GPU in same SEP-rooted envelope [@apple-pcc-blog]	NVIDIA H100 CC-On + SPDM + NRAS joined to MAA [@nvidia-dev-blog] [@ms-sku-nccads]
Network anonymization	Third-party OHTTP relay strips client IP [@ietf-rfc9458] [@apple-pcc-blog]	No equivalent operator-level anonymization layer

flowchart LR subgraph PCC["Apple PCC stack"] P1[Apple SoC + integrated GPU] P2[SEP per node
Apple-controlled CA] P3[Transparency Log
append-only public] P4[Stateless node
no customer keys] P5[OHTTP relay
third party] end subgraph AZ["Azure CC-AI stack"] A1[AMD EPYC + NVIDIA H100
multi-vendor] A2[AMD PSP + vTPM
NVIDIA on-die RoT] A3[MAA JWT
x-ms claims] A4[SKR from AKV Premium
customer-managed keys] A5[no operator-level
anonymization layer] end An architectural property whereby every production software image actually serving customer requests is committed in advance to a public, append-only log accessible to any third party. The property requires both that the cryptographic log be publicly auditable (a Certificate-Transparency-style Merkle tree, for example) and that the system refuse to serve requests against images not present in the log. Apple Private Cloud Compute ships verifiable transparency as a first-class architectural primitive; no other major-cloud confidential-AI substrate ships an architectural equivalent as of mid-2026 [@apple-pcc-blog] [@apple-pcc-release-transparency].

Key idea: The two architectures differ in degree on five axes: silicon control, hardware root of trust, attestation surface, key release, and GPU TEE. On the sixth -- verifiable transparency of the production fleet -- they differ in kind. Apple's Transparency Log is not a slightly-better MAA. It is an architectural primitive Microsoft does not ship.

Note: A procurement assumption that PCC and Azure differ only in vendor preference misses the real architectural point. PCC's trust root collapses to Apple alone. Azure's trust root is spread across AMD, Intel, NVIDIA, and Microsoft as four independent signers. A single-vendor compromise on Azure (a leaked AMD VCEK signing key, an NVIDIA firmware bug, an MAA outage) does not collapse the whole stack the way an Apple-CA compromise would collapse PCC. This is a different security posture, not just a different brand. Whether trust diffusion is more valuable than verifiable transparency depends on the regulatory and threat-model context.

Six axes, two architectures, one axis where the divergence is in kind. But Apple PCC and Microsoft Azure are not the only games in town. Where do AWS Nitro Enclaves and Google Cloud Confidential Space fit on the same six axes?

7. Beyond the Two Headliners

If verifiable transparency is the architectural difference, the obvious question is why AWS and Google have not just shipped a Transparency Log too. The short answer is that the three other production substrates each chose a different epistemic model, and shifting any one of them to PCC's model would require rebuilding the trust root from scratch.

AWS Nitro Enclaves

AWS Nitro Enclaves does not anchor in a CPU-vendor TEE at all. Trust is rooted in AWS-as-signer through the Nitro Hypervisor and the Nitro Security Chip [@aws-nitro-hw]. The Nitro System "provides enhanced security that continuously monitors, protects, and verifies the instance hardware and firmware" and offloads virtualization resources to dedicated hardware [@aws-nitro-hw]. A Nitro Enclave is created from a parent EC2 instance and is "isolated from the parent EC2 instance through the Nitro Hypervisor"; per the AWS documentation verbatim, "the Nitro Hypervisor ensures that the parent instance has no access to the isolated vCPUs and memory of the enclave" [@aws-nitro-enclave].

The trust model is different in kind from SGX, SEV, or TDX. Attestation is rooted in AWS's signing key, not in a CPU-vendor key. The Nitro architecture is processor-agnostic over Intel, AMD, and AWS Graviton, which is a different posture again -- the enclave's confidentiality does not depend on a specific silicon vendor's TEE primitive. There is also no published GPU confidential-computing extension for Nitro Enclaves as of mid-2026.

Google Cloud Confidential Space

Google Cloud Confidential Space combines Intel TDX (and AMD SEV / SEV-SNP) with Google Cloud Attestation and Workload Identity Federation. Per the GCA documentation: "Google Cloud Attestation provides a unified solution for remotely verifying the trustworthiness of all Google confidential environments ... The service supports attestation of confidential environments backed by a Virtual Trusted Platform Module (vTPM) for SEV and the TDX Module for Intel TDX" [@gcp-gca]. The overview page describes the multi-party-collaboration use case for PII, PHI, IP, and LLM-interaction data [@gcp-cs-overview].

Google added an interesting wrinkle in 2025: an Intel Trust Authority integration that lets a GCP customer use ITA as a second verifier alongside Google Cloud Attestation. Per the integration documentation: "GCP Confidential Space provides a method for isolating a workload and sensitive data ensuring that data is released only to authorized workloads ... Intel Trust Authority is used to validate the evidence" [@ita-gcp]. A second verifier is not the same architectural primitive as a public transparency log -- it provides cross-checking but not append-only public auditability -- but it is the closest move any other major-cloud confidential platform has made toward PCC's direction as of mid-2026.

Confidential Containers and the orchestration tier

Confidential Containers (CoCo) is a CNCF Sandbox project that wraps Kubernetes pods in confidential VMs running on AMD SEV-SNP, Intel TDX, or IBM Secure Execution [@coco-gh]. Per the project: "Confidential Containers is an open source community working to enable cloud native confidential computing by ... Trusted Execution Environments to protect containers and data" [@coco-gh]. CoCo composes on top of the same Generation-3 silicon Azure CC-AI uses; it does not compete with PCC architecturally because it is at a different layer of the stack.

Around CoCo and the underlying TEEs sits a small set of orchestration-tier vendors that take responsibility for what the raw SKUs do not. The procurement-relevant distinctions between them are sharper than the marketing copy suggests.

Anjuna Seaglass is the cross-cloud unified confidential-deployment plane. It packages AWS Nitro Enclave, Azure CVM, and GCP Confidential Space behind a single command and a customer-supplied policy [@anjuna], with the explicit value proposition of "any cloud, any region, with the only Universal Confidential Computing platform." Anjuna's Seaglass platform supplanted the older Anjuna Northstar nomenclature, but reads the same way to a procurement audit: a single control plane spanning three different silicon vendors' TEE primitives, with a uniform policy DSL on top.

Edgeless Systems' Contrast is the runtime-and-runtime-encryption layer for confidential Kubernetes. Contrast runs confidential container deployments on Kubernetes at scale, built on Kata Containers and the Confidential Containers concept, and provides PKI, mTLS, and encrypted state disks across the deployment [@edgeless-contrast]. The architecture documentation is explicit that "the Contrast Coordinator is the central remote-attestation service for a Contrast deployment" and verifies the Contrast components inside a confidential VM [@contrast-arch] [@contrast-docs]. Contrast is the active successor to Edgeless Constellation, which is now archived ("This repository has been archived ... Edgeless Systems has shifted focus to Contrast, our solution for confidential containers, which addresses the modern needs of confidential cloud workloads" [@edgeless-constellation]). The procurement signal is that customers evaluating Constellation should be redirected to Contrast in any new deployment.

Fortanix is two distinct products that the marketing collapses into one. Fortanix Confidential Computing Manager (CCM) is the orchestration and policy management layer that "is used to securely deploy and manage confidential computing applications using Intel SGX, AMD SEV-SNP, and Intel TDX runtimes" [@fortanix-ccm]. Fortanix Data Security Manager (DSM) is the FIPS 140-2 Level 3 HSM that holds the keys; per Fortanix's DSM page, DSM "delivers Cryptographic Services, Key Management Services, Secrets Management, Tokenization, Code Signing ... powered by Confidential Computing" [@fortanix-dsm] and carries FIPS 140-2 Level 3 certification on the underlying platform [@fortanix-fips]. Procurement teams that need a customer-managed-keys story almost always need both: CCM to orchestrate the confidential-workload deployment, DSM to custody the keys.

CCM is not DSM. CCM is the orchestration plane (which workload runs where, attested by what); DSM is the FIPS 140-2 Level 3 HSM (which holds the keys, releases them on attested workload verification, audits the access). A procurement that asks for "Fortanix" without specifying CCM or DSM is asking for two different products at two different price points with two different compliance postures. The two integrate but they are not the same SKU.

Vendor	Layer	Pick when...
Anjuna Seaglass	Cross-cloud confidential deployment control plane [@anjuna]	You run the same regulated workload on more than one cloud and need one policy DSL spanning AWS Nitro + Azure CVM + GCP Confidential Space
Edgeless Contrast	Confidential Kubernetes runtime with mTLS and encrypted state [@contrast-arch] [@contrast-docs]	You run confidential workloads as Kubernetes pods and want a remote-attestation Coordinator inside the deployment rather than an external SaaS verifier
Fortanix CCM	Confidential-app orchestration on SGX/SEV-SNP/TDX [@fortanix-ccm]	You need centralized policy for which signed confidential workloads run on which TEEs, with audit
Fortanix DSM	FIPS 140-2 Level 3 HSM with attested key release [@fortanix-dsm] [@fortanix-fips]	You need customer-managed keys, FIPS 140-2 L3 custody, and attested-workload-gated release as a single SKU

The third-party tier exists because the raw cloud SKUs sell the substrate but not the operational pattern. Procurement decisions in this category typically pair a cloud SKU with one or two of these orchestration vendors to get something workable for a regulated workload.

Where these fit on the six axes

Substrate	Silicon	Root of trust	Transparency	GPU TEE
Apple PCC	Apple end-to-end [@apple-pcc-blog]	SEP + Apple CA [@apple-sep-guide]	Public Transparency Log [@apple-pcc-release-transparency]	Integrated Apple GPU [@apple-pcc-blog]
Azure CC-AI	AMD + Intel + NVIDIA + MS [@ms-cc-overview]	AMD PSP + NVIDIA RoT + vTPM + MAA [@ms-maa-overview] [@amd-kds]	None (MAA claims only) [@ms-maa-overview]	NVIDIA H100 CC-On [@nvidia-dev-blog]
AWS Nitro Enclaves	AWS-signed, CPU-agnostic [@aws-nitro-hw]	Nitro Hypervisor + Security Chip [@aws-nitro-enclave]	None	None at GA
GCP Confidential Space	Intel TDX + AMD SEV-SNP [@gcp-cs-overview]	vTPM + TDX Module + GCA (+ optional ITA) [@gcp-gca] [@ita-gcp]	None (second verifier via ITA)	None at GA on Confidential Space
Third-party tier (CoCo / Contrast / Anjuna)	Composes on top of cloud SKUs [@coco-gh] [@edgeless-contrast]	Inherits underlying TEE root	None	Inherits underlying GPU TEE

Five substrates, one rough trade-off space. But every one of them rests on silicon, and silicon has its own theoretical limits. What can no TEE-based confidential AI architecture do?

8. What No TEE Can Do

The Confidential Computing Consortium's "A Technical Analysis of Confidential Computing" v1.3 -- the vendor-neutral definitional document both Apple and Microsoft anchor on -- explicitly enumerates side-channels as a residual risk [@ccc-technical-analysis]. This is not a contestable empirical claim. It is the field's own lower bound on what TEE-based confidential AI can deliver. The CCC names what the architecture does not close, in plain text, in the same document that defines what it does.

There are roughly six classes of limit, and the architectures we have walked do not close any of them by construction.

1. Side-channels on shared silicon

The Foreshadow / L1TF, SgxPectre, and Plundervolt cascade [@foreshadow] [@sgxpectre] [@plundervolt] is the historical evidence. The principled extension is direct: any TEE built on shared microarchitectural state -- shared caches, shared branch predictors, shared functional units, shared voltage / frequency control -- inherits a side-channel surface that the architectural threat model does not name. Both Apple's SEP and the AMD-Intel-NVIDIA composition rest on silicon that does not have an architectural primitive that closes this surface. Wojtczuk and Rutkowska's 2009 paper on Intel TXT made the same point fifteen years earlier in a different generation, demonstrating that SMM-based bypasses of TXT were not addressed by TXT's own threat model [@txt-attack]. The cycle keeps repeating.

Even Intel SGX's memory encryption/authentication technology cannot protect against Plundervolt. -- the Plundervolt project page [@plundervolt]

2. Trust-anchor compromise

Every vendor behind a hardware root of trust is itself a trust anchor that nothing inside the architecture can close. AMD-as-signer through the PSP and VCEK certificate chains [@amd-kds]; Intel-as-signer for the TDX Module, SEAMLDR, and Provisioning Service; NVIDIA-as-signer for the on-die RoT and NRAS; Microsoft-as-signer for the MAA service [@ms-maa-overview]; and Apple-as-signer for the SEP-bound CA and the Apple-controlled Transparency Log [@apple-pcc-blog]. If any of those signing infrastructures is compromised, the architecture cannot defend itself against the signer. PCC's trust root collapses to Apple; Azure's spreads across four vendors but each one is still a trust anchor for the workload that depends on it.

3. ROM-burned single-signer revocation

Fuse-burned silicon roots of trust are not field-revocable on a chip already deployed. If an attacker recovers a vendor-signing key that has been burned into the boot ROM of millions of chips, the recovery path is fleet rotation, not credential revocation. This is not a flaw of any specific vendor; it is a property of how hardware roots of trust are physically anchored. The recovery model for a leaked AMD ARK key, an Intel SEAM key, or an Apple SEP signing key is the same: replace the silicon. That is a multi-quarter operation at fleet scale.

4. Supply-chain compromise of the AI model

Apple binds the model into the attested image hash. The same Transparency Log that proves what code is running also proves what model weights are running, because the model is part of the published image [@apple-pcc-blog] [@apple-pcc-release-transparency]. PCC closes the model supply-chain question at the architecture level.

Azure shifts model integrity to customer-controlled SKR of model artefacts. The model weights become encrypted blobs that the workload unwraps inside the TEE using a customer-managed key released only on a satisfying MAA JWT [@ms-cc-overview] [@ms-workshop-llm]. The customer is the trust anchor for the model's identity, not the cloud provider. This is a different trust-rooting model -- not stronger or weaker in the abstract, but routed through different organizations. It is not accurate to say only Apple defends against model supply-chain compromise.

5. Prompt-output exfiltration via the model itself

The TEE protects the input boundary -- it can prove the cloud operator never saw the prompt. It does not constrain what the model puts in the output. A model that is fine-tuned, prompt-injected, or simply chooses to emit memorised data can exfiltrate information through its own output channel, and no architectural primitive in either PCC or Azure CC-AI prevents that. Both architectures are equally exposed on this axis. This is also why prompt-output safety, content filtering, and model-side privacy controls are unrelated work that confidential computing does not subsume.

6. Compelled vendor and lawful access

A property of the trust-rooting model, not of any one architecture. If a vendor is compelled by law to push a software update that exfiltrates user data, the architecture cannot defend itself against that vendor. PCC's compelled-vendor exposure is concentrated on Apple. Azure's is distributed across AMD, Intel, NVIDIA, and Microsoft, but a compelled Microsoft is sufficient to compromise an MAA-rooted workload; the diffusion does not multiply protections.

And one more: MAA-as-service compromise

Azure's centralised verifier is a control point Apple does not have, because Apple's verifier is the user's device itself. If MAA is compromised -- if an attacker controls the MAA signing key, or if the MAA policy-evaluation code is modified maliciously -- every relying party that trusts MAA-issued JWTs trusts the attacker.

The CCC's "A Technical Analysis of Confidential Computing" v1.3 explicitly enumerates side-channels as a residual risk that the architecture does not close by construction. This is the field's own acknowledged lower bound. Any product claim that "our confidential computing stack defends against all side-channels" is, in 2026, either overstated or contradicting the CCC's own technical analysis [@ccc-technical-analysis]. The honest framing is that confidential computing defends against the architecturally-named threats (memory disclosure to the operator, hypervisor-mediated remap, plaintext-in-DRAM at-rest exposure) and that side-channels remain a separate research and engineering domain.

Threat	Apple PCC	Azure CC-AI
Malicious cloud operator (passive memory disclosure)	Defended (SEP-rooted attestation, OHTTP relay) [@apple-pcc-blog]	Defended (SEV-SNP / TDX guest measurement, MAA verifier) [@ms-maa-overview]
Compromised hypervisor (active remap / Iago attacks)	Defended (Apple-controlled kernel + SEP-rooted measured boot) [@apple-pcc-blog]	Defended (SEV-SNP RMP enforces page ownership; TDX Module isolates) [@ms-cc-overview]
Supply-chain compromise of the AI model	Defended at architecture level (model bound into Transparency-Log-published image) [@apple-pcc-blog]	Defended via customer-controlled SKR of model artefacts; trust shifts to customer [@ms-workshop-llm]
Side-channels on shared silicon	Not closed by construction [@ccc-technical-analysis] [@plundervolt]	Not closed by construction [@ccc-technical-analysis] [@cipherleaks]
Compelled-vendor / lawful access	Not closed by construction (trust collapses to Apple)	Not closed by construction (trust spreads across four vendors; compelled MAA suffices)
Verifier / signer compromise	Apple SEP-CA + Transparency Log signer is a control point	MAA signer + AMD / Intel / NVIDIA signers are control points
Prompt-output exfiltration via model	Not closed by construction	Not closed by construction

Note: Neither architecture closes the gap by construction. Apple's verifier is the user's device, and the user's device trusts Apple's SEP-bound CA and the Apple-controlled Transparency Log signer. Azure's verifier is MAA, which is a Microsoft-operated service with its own signing infrastructure. Apple's single-vendor problem and Microsoft's centralised-verifier problem are two shapes of the same architectural gap: the verifier itself is a trust root the architecture cannot externally audit.

Key idea: Trust diffusion (Azure's contribution) and verifiable transparency (Apple's contribution) close different trust-anchor gaps. Neither closes both. No production substrate as of mid-2026 closes both gaps simultaneously. A hypothetical Generation-7 design that combined Azure-style multi-vendor TEE composition with Apple-style append-only transparency of production images would close that gap. No vendor has shipped it.

Two architectures, two distinct upper bounds, neither closing the same gap. So what is the field actually working on?

9. Where Active Work Is Happening

September 5, 2024, arXiv. Ceren Kocaoğullar (University of Cambridge), Tina Marjanov (Cambridge), Ivan Petrov (Google), Ben Laurie (Google), Al Cutter (Google), Christoph Kern (Google), Alice Hutchings (Cambridge), and Alastair R. Beresford (Cambridge) post "A Confidential Computing Transparency Framework for a Trust Chain" [@kocaogullar-transparency]. The paper does not name MAA specifically. It generalises the question Apple PCC raises in concrete form: can the verifiable-transparency primitive be replicated on commodity multi-vendor silicon without collapsing to a single trust root? The authors propose "a three-level conceptual framework providing organisations with a practical pathway to incrementally improve Confidential Computing transparency" [@kocaogullar-transparency]. The inclusion of Ben Laurie -- one of the original architects of Certificate Transparency (RFC 6962) -- is not incidental. The paper is the direct architectural descendant of CT brought into the confidential-computing domain.

The v2 December 5, 2024 revision of the Kocaoğullar et al. paper added an 800+ participant empirical study showing that greater transparency improves end-user trust in confidential computing services [@kocaogullar-transparency]. That empirical signal is the closest thing the field has, as of mid-2026, to a measurement of the procurement consequences of verifiable transparency vs verifier-as-a-service. The framework itself is conceptual; the empirical contribution is the part procurement teams should read.

Six open problems are visible in the current production work.

9.1 Verifiable transparency of the verifier itself

No major-cloud verifier ships a public append-only log of its own code. MAA does not; Google Cloud Attestation does not; AWS Nitro's hypervisor signer does not. The Intel Trust Authority integration on GCP introduces a second verifier, which is a partial cross-check, but a second verifier is not the same architectural primitive as a transparency log [@ita-gcp]. Where the work is happening: the CCC Attestation Special Interest Group on GitHub coordinates Formal Specifications of Attestation Mechanisms, an RA-TLS proof of concept, an interoperable RA-TLS effort, an IETF RATS terms cheat sheet, and a formal-spec-KBS (key broker service) project [@ccc-attestation-gh]. The IETF RATS Working Group continues to extend RFC 9334 with Entity Attestation Token (EAT) and Concise Reference Integrity Manifest (CoRIM) drafts [@ietf-rfc9334].

9.2 GPU confidential-computing parity across vendors

NVIDIA H100 CC-On is the only confidential-GPU mode at GA on a major commercial cloud as of mid-2026 [@nvidia-dev-blog] [@ms-sku-nccads]. AMD MI300X ships as compute across multiple clouds but has no production-equivalent SEV-TIO confidential-GPU mode at GA on a major commercial cloud. PCIe TDISP and SEV-TIO Linux support is landing in 2025-2026 kernels, but the GA gap is the load-bearing fact for any procurement that wants AMD silicon end-to-end. AMD's MI400X-class roadmap is forward-looking. Until a second confidential GPU is at GA, single-vendor lock-in at the accelerator tier is the unavoidable procurement reality for any cloud confidential-AI workload.

9.3 Cross-vendor attestation portability

IETF RFC 9334 standardises the vocabulary [@ietf-rfc9334]; CoRIM and EAT, in active drafting in the IETF RATS WG, aim at portable claim formats. The vocabulary work matters because a confidential workload that wants to run unchanged on Azure SEV-SNP and Azure TDX and GCP TDX needs a single attestation parser that understands all three evidence formats. The MAA approach maps onto RFC 9334's Passport pattern; the GCA approach maps onto OIDC tokens that play well with federated-identity tooling. As of mid-2026 no single relying-party library handles all three production verifiers transparently, and that is one of the things the CCC Attestation SIG is working on [@ccc-attestation-gh].

9.4 Confidential inferencing for Azure OpenAI models

Microsoft's Azure-Samples/confidential-ai-workshop repository [@ms-workshop] is the cleanest procurement-grade reference for what confidential inferencing actually looks like in production on Azure today. It contains three end-to-end tutorials at three different points on the cost-versus-isolation curve, and reading them in sequence is the fastest way for a procurement team to map the abstract architecture to concrete SKU lines.

Tutorial 1: ML-training on a CPU-only confidential VM (Standard_DCasv5). The confidential-ml-training directory walks training of an XGBoost-class classical-ML model on a Standard_DCasv5 SKU, which is an AMD SEV-SNP confidential VM without a confidential GPU [@ms-workshop-ml]. The workload posture is plaintext-data-and-model on a TEE-protected substrate, with the SEV-SNP attestation gating access to encrypted training data in Azure Storage via the standard MAA + SKR path. The deliberate choice of XGBoost over a deep-learning model is the architectural lesson: when the model and training data fit in CPU memory and TCB-sealed CPU compute is sufficient, the confidential GPU SKU is overkill. This is the lowest-cost on-ramp into the architecture.

Tutorial 2: LLM inferencing on a confidential GPU (Standard_NCC40ads_H100_v5). The confidential-llm-inferencing directory walks serving microsoft/Phi-4-mini-reasoning on a Standard_NCC40ads_H100_v5 SKU [@ms-workshop-llm]. Phi-4-mini-reasoning is a 3.8 B-parameter dense decoder-only Transformer with a 128 K-token context window, MIT-licensed on Hugging Face [@hf-phi4-mini], chosen because it fits comfortably in the H100 NVL's 94 GB HBM3 capacity with room for activation memory. The novel architectural feature here is double attestation: the tutorial's setup script uses Azure/az-cgpu-onboarding [@az-cgpu-onboarding] to verify both the SEV-SNP CVM attestation (against AMD VCEK) and the NVIDIA H100 GPU attestation (against NVIDIA's on-die root of trust via NRAS) before model weights are released from Azure Key Vault Premium via SKR. This is the architectural pattern any production GPU-confidential workload should match.

Tutorial 3: Inferencing via the Confidential Whisper service (OHTTP + HPKE). Whisper, the speech-to-text model, is the publicly-demoed Microsoft Build 2024 confidential inferencing reference workload. The confidential-whisper-inferencing tutorial directory confirms the Azure AI Foundry Confidential Whisper service uses Oblivious HTTP with HPKE end-to-end encryption to keep audio encrypted until it reaches the TEE-protected Whisper model [@ms-workshop-whisper]. The reference OHTTP gateway implementation is microsoft/attested-ohttp-client and its server-side counterpart, "an Attested OHTTP gateway and client implementation by Microsoft" that "uses the Cloudflare OHTTP client/server implementation as a basis" [@ms-attested-ohttp]. This is the closest architectural pattern Azure has to PCC's non-targetability requirement -- a third-party-operated OHTTP relay strips the client IP before the request reaches the confidential inferencing endpoint, the same architectural primitive Apple uses for PCC at network ingress.

The three tutorials are the canonical references because they walk the wire-level flow. A procurement team that wants to know "what does confidential inferencing actually look like on Azure" can read the README files, the Bicep templates, the attestation-policy JSON, and the SKR-policy JSON, and answer the question without speculation. GPT-class confidential endpoints staging through 2024-2026 are forward-looking roadmap. There is no May-2024 GA for "Confidential GPT-4," but the three workshop tutorials cover the architectural primitives that such a GA would compose.

9.5 The Apple PCC node-chip transition

Apple has not publicly named the chip family used in PCC nodes. Firmware identifiers and independent analyses make the transition story concrete enough to reason about. At launch in June 2024 the PCC nodes ran on M2-Ultra-class silicon, identified by the firmware string ComputeModule14,1 visible in independent device-identifier databases [@appledb-cm14]. During 2026 the PCC fleet transitioned to a new node generation identified as J226C and reported (independently, not by Apple) as built around M5-class silicon manufactured in Houston, Texas [@nine-to-five-mac-m5] [@winbuzzer-m5]. The 9to5Mac report dated February 17, 2026 describes Apple's M5-based Private Cloud Compute servers tied to iOS 26.4 [@nine-to-five-mac-m5], and the parallel Winbuzzer coverage from the next day confirms a new "Private Cloud Compute Agent Worker" component running on M5-class node hardware [@winbuzzer-m5].

What is architecturally interesting is not the chip identity. It is what the transition did not change. The Transparency Log architecture absorbs a generational chip change as a matter of routine policy because the log's verifier policy is a list of approved image hashes and the SEP-rooted attestation envelope structure, not a list of approved chip families. New node generation, new image hashes (visible in PrivateCloudCompute/Release.swift and validated by PrivateCloudCompute/NodeValidator.swift [@apple-pcc-nodevalidator] [@apple-pcc-release-swift]), same envelope structure, same client-side verification. From a procurement-trust perspective, the transition was an architectural non-event in exactly the way Apple's public commitments said it should be.

**Two invariants held across the M2-Ultra to M5 node transition.** First, the device-side envelope check is stable: the `NodeValidator` validates SEP-signed attestation against the `SEPAttestationPolicy` it parses from the release artefact [@apple-pcc-nodevalidator] [@apple-pcc-sepattestpolicy], and the policy schema did not change. Second, the public transparency log absorbed the transition without any client-side trust ceremony because the chip family is not in the verifier policy -- only the image hash is. A device that started talking to the M2-Ultra fleet in 2024 and woke up in 2026 talking to the M5 fleet did exactly one new thing: it fetched the new approved image hashes from the log. **Three things did change.** First, the on-node software stack (firmware, kernel, OS, inference runtime) is rebuilt for the new silicon; that is why the image hashes change. Second, the routing policy may shift -- some workloads may schedule onto the new node generation preferentially. Third, the chip family itself is not publicly named by Apple; the M5 identification is inferential from independent reporting plus firmware identifiers, not from a primary Apple source. Procurement narratives should use "Apple-designed silicon, not publicly named" when precision matters, and reach for the inferential M5 identification only when chip-family granularity is load-bearing.

Key idea: The architectural payoff of a public transparency log is precisely that it absorbs a generational chip transition without any client-side trust ceremony, because the chip family is not in the verifier policy -- only the image hash is. This is what "verifiable transparency" buys procurement teams in practice: the trust contract survives silicon turnover because the contract was never about silicon. It was about which bits the silicon ran.

9.6 Third-party PCC equivalents

Could AWS or Google replicate Apple's Transparency-Log model on commodity multi-vendor silicon? The architectural feasibility is open. The Kocaoğullar et al. framework provides a conceptual pathway [@kocaogullar-transparency]. The CCC Attestation SIG's interoperable-ra-tls work is one of several substrates that a multi-vendor transparency log could ride on top of [@ccc-attestation-gh]. Whether any major cloud will actually ship it is the architectural bet the next generation hinges on. No GA product as of mid-2026.

A regulated workload that needs second-source availability has to be able to run on at least two confidential substrates. As of mid-2026 the practical cross-vendor option for a TEE-based confidential workload is "AMD SEV-SNP on Azure, Intel TDX on GCP, AWS Nitro on AWS" -- three different attestation evidence formats consumed by three different verifiers. CoRIM and EAT in the IETF RATS WG are trying to make those three formats parseable by one library. Until that lands, second-source confidential AI is an integration project, not a configuration change.

The field is wide open. But the reader's procurement deadline is not. How do you actually choose between PCC and Azure today?

10. A Procurement Decision Tree

Six questions, asked in order. The first determines whether PCC is even in play; the rest sharpen the choice.

Question 1: Do you control the device that originates the request, and is it Apple-Intelligence-capable?

PCC requires Apple-Intelligence-capable client devices. The supported set as of mid-2026 is iPhone 15 Pro and later, iPads on M1 silicon or later, and Macs on M1 silicon or later [@apple-pcc-blog]. If your end users are on Windows laptops, Android phones, browsers, or any non-Apple endpoint, PCC is out of scope by construction. Azure / GCP / AWS confidential AI workloads do not have an analogous client-side requirement -- they are workload-shape-agnostic and the client can be any HTTPS-speaking device.

Question 2: Can you accept Apple-as-signer as the trust root?

PCC's trust collapses to Apple's signing infrastructure. The SEP-bound CA, the Apple-operated Transparency Log signer, the Apple bug-bounty program, and the Apple Security Engineering and Architecture team are the entire trust root [@apple-pcc-blog]. Azure spreads trust across AMD plus Intel plus NVIDIA plus Microsoft as separate signers [@ms-maa-overview] [@amd-kds] [@nvidia-dev-blog]. If your security posture explicitly requires multi-vendor trust diffusion -- for example, because your regulator does not accept single-vendor SBOMs as evidence -- Azure wins this axis (see §6 for the architectural reasoning).

Question 3: Do you need customer-managed key material?

Azure: yes, via SKR from Azure Key Vault Premium or Azure Managed HSM, with a release policy bound to MAA-issued claims [@ms-cc-overview] [@ms-maa-overview]. Apple: no by design, because PCC nodes are stateless and there is no customer key material on the node to be released [@apple-pcc-blog]. Regulated buyers whose framework requires customer-held keys -- for example, a FIPS 140-3 Level 3 customer-key-escrow requirement -- cannot map PCC into that framework, because PCC does not have the architectural primitive the framework is asking for.

Question 4: Do you need verifiable transparency of the actually-running code?

Apple: yes, via the published Transparency Log [@apple-pcc-release-transparency]. Azure: not via the architecture itself. You can build a customer-side log of the MAA tokens you have observed, or you can accept MAA's claims at face value. There is no Azure architectural primitive that proves the bits MAA verified are the same bits the workload is actually executing today, in the way that PCC's Transparency Log proves the image hash served to you is the same one served to every other PCC user.

This is the one axis where the architectures differ in kind. If your threat model requires that you be able to confirm what code the cloud is running, not just that the cloud says it is running specific code, PCC is the only production answer.

Question 5: Do you need GPU-class confidential compute?

Both ship it. Pay attention to two facts. First, Azure's confidential GPU is H100 only at GA in mid-2026 [@nvidia-dev-blog] [@ms-sku-nccads]. AMD MI300X CC-On is not at GA on a major commercial cloud; NVIDIA H200 and Blackwell-class GB200 GPUs are GA on Azure as non-confidential SKUs. If you need confidential GPU compute, the only major-cloud answer is NCCads_H100_v5 (or its successor). Second, Apple's GPU is integrated on the SoC and is inside the SEP-rooted attestation envelope by construction; there is no separate cross-vendor GPU attestation step, which simplifies the trust analysis at the cost of being available only on the Apple stack.

Question 6: What does your auditor accept as evidence?

The MAA JWT is consumable by every off-the-shelf JWT verifier. It is also broadly accepted in regulated audits because the JWT format and the x-ms-* claim names are documented in publicly-fetchable Microsoft Learn pages [@ms-maa-overview], and auditors can map MAA tokens onto NIST SP 800-53 attestation evidence requirements without exotic tooling.

PCC's Transparency Log proof is newer. An audit that accepts a Merkle inclusion proof against an Apple-published log root as evidence is uncommon as of mid-2026; most regulated audit programs were designed before such a primitive existed in cloud AI. If your auditor needs PCC evidence, expect to write explainer documentation that translates "your image hash is in append-only public log at Merkle position N with signed root R" into the language your audit framework uses.

{` // Sketch of a Certificate-Transparency-style Merkle inclusion proof check. // The PCC Transparency Log inherits this structural primitive from RFC 6962. // This is educational -- a production verifier would use a maintained library.

const sha256Hex = async (data) => { const bytes = typeof data === 'string' ? new TextEncoder().encode(data) : data; const buf = await crypto.subtle.digest('SHA-256', bytes); return [...new Uint8Array(buf)].map((b) => b.toString(16).padStart(2, '0')).join(''); };

const concat = (a, b) => { const out = new Uint8Array(a.length + b.length); out.set(a); out.set(b, a.length); return out; };

async function verifyInclusion(leafHashHex, leafIndex, treeSize, sibling, root) { // sibling is the audit path (array of sibling node hashes, leaf to root) let node = Uint8Array.from(leafHashHex.match(/.{2}/g).map(h => parseInt(h, 16))); let idx = leafIndex; let size = treeSize; for (const s of sibling) { const sBytes = Uint8Array.from(s.match(/.{2}/g).map(h => parseInt(h, 16))); // RFC 6962 prefixes internal hashes with 0x01 const prefixed = (left, right) => concat(new Uint8Array([0x01]), concat(left, right)); const combined = (idx % 2 === 0) ? prefixed(node, sBytes) : prefixed(sBytes, node); const h = await sha256Hex(combined); node = Uint8Array.from(h.match(/.{2}/g).map(x => parseInt(x, 16))); idx = Math.floor(idx / 2); size = Math.floor((size + 1) / 2); } const computedRoot = [...node].map((b) => b.toString(16).padStart(2, '0')).join(''); return computedRoot === root; }

// In production: fetch (signed log root, audit path) from the log // and the leaf hash from the attestation envelope's image-hash field. // If verifyInclusion returns true AND the signed root matches what your // device trusts, the image you are about to talk to is in the public log. console.log('Educational sketch only; use a maintained CT library in production.'); `}

The decision tree in one diagram

flowchart TD Q1{"Apple-Intelligence-capable
client device required?"} Q2{"Single-vendor (Apple)
trust root acceptable?"} Q3{"Customer-managed key
material required?"} Q4{"Need public-log
verifiable transparency?"} Q5{"Need GPU TEE
at fleet scale?"} Q6{"Auditor accepts
Merkle inclusion proof?"} Q1 -->|No| AZ[Azure / GCP / AWS] Q1 -->|Yes| Q2 Q2 -->|No| AZ Q2 -->|Yes| Q3 Q3 -->|Yes| AZ Q3 -->|No| Q4 Q4 -->|Yes| Q5 Q4 -->|No| AZ Q5 -->|Yes, Apple integrated GPU OK| PCC[Apple PCC] Q5 -->|Yes, need NVIDIA H100| AZ PCC --> Q6 Q6 -->|Yes| PCC2[PCC fits the audit posture] Q6 -->|No| PCC3[Write explainer documentation,
or fall back to Azure JWT-based evidence] The MAA JWT maps cleanly onto NIST SP 800-53 SA-12 (Supply Chain Protection) and SC-12 (Cryptographic Key Establishment and Management) evidence requirements, because the JWT format and the claim semantics are publicly documented and JWT verifiers are standard library code [@ms-maa-overview]. PCC's Transparency Log evidence is newer; SA-12-style framings exist for Certificate Transparency in the web-PKI context but not yet (as of mid-2026) as a recognised confidential-AI evidence pattern. Expect explainer documentation to be required. Both architectures interact with FedRAMP, but Azure's confidential AI offerings are further along the FedRAMP path because Microsoft's broader Azure compliance suite is older. Azure is the first cloud provider to offer confidential computing with NVIDIA H100 GPUs. -- NVIDIA Blog, September 24, 2024 [@nvidia-h100-ga]

What the verifier actually does, on the wire

Once procurement has chosen the architecture, an engineer somewhere has to write the verifier. The two architectures end up being symmetric in this regard: each produces a cryptographic envelope, and a relying party has to parse, validate signatures, and check inclusion or claims. Three procurement-grade reference primitives anchor the choice -- two from Azure (already shown above), one from Apple PCC.

On Azure, the relying party walks an MAA JWT verification flow (decode the JWT, validate signature against the MAA JWKS, match claims against an SKR release policy -- the JavaScript reference appears in §6 Axis 3 alongside the MAA JWT decode) [@ms-maa-overview]. For customers who want to not trust MAA, the alternative path uses snpguest to fetch the AMD VCEK chain and verify the SEV-SNP attestation directly (the bash reference also in §6 Axis 3) [@virtee-snpguest]. The two paths produce structurally equivalent confidence in the same evidence.

On Apple PCC, the relying-party verifier is PrivateCloudCompute/NodeValidator.swift and friends [@apple-pcc-nodevalidator]. The flow is: parse the AttestationBundle from the response (the bundle structure is defined in SEPAttestation.swift [@apple-pcc-sepattest]); call the SEP attestation context verifier (aks_attest_context_verify) on the SEP signature against the per-die Apple-rooted certificate chain; parse the Release.swift Release struct as ASN.1 DER and compute its SHA-256 digest [@apple-pcc-release-swift]; check the SEP attestation policy claims (SEPAttestationPolicy.swift [@apple-pcc-sepattestpolicy]) constrain the release digest; then call SWTransparencyVerifier.verifyExpiringInclusion to verify the release digest's inclusion proof in the public transparency log [@apple-pcc-swtrans-verifier] [@apple-pcc-transparencypolicy]. The full reference is the apple/private-cloud-compute repository's VerifiableReleasesExtension directory and the VerifiableReleasesExtension tutorial [@apple-pcc-vre].

{`# This is a procurement-grade SKETCH, not production code. It walks the four

verification steps a real PCC client performs (see PrivateCloudCompute/ NodeValidator.swift for the canonical reference [@apple-pcc-nodevalidator]). Each function is a stub showing the contract the caller must satisfy.

from hashlib import sha256 from typing import Optional from dataclasses import dataclass

@dataclass class AttestationBundle: """The Apple PCC AttestationBundle, parsed from the response envelope. Structure defined in SEPAttestation.swift [@apple-pcc-sepattest].""" sep_signature: bytes sep_cert_chain: list release_der: bytes sep_attestation_policy_claims: dict transparency_inclusion_proof: dict

def aks_attest_context_verify( sep_signature: bytes, sep_cert_chain: list, apple_root_anchor: bytes, ) -> bool: """Step 1: verify the SEP signature against the per-die Apple-rooted certificate chain. In the real client this calls the Security framework's aks_attest_context_verify; the SEP cert chain is rooted at Apple's PCC CA. Returns True if the signature chains to the pinned anchor.""" raise NotImplementedError("calls Security.framework in a real client")

def compute_release_digest(release_der: bytes) -> bytes: """Step 2: the Release struct is serialised as ASN.1 DER; the canonical release digest is SHA-256 over the DER bytes. See Release.swift for the schema [@apple-pcc-release-swift].""" return sha256(release_der).digest()

def check_sep_attestation_policy( claims: dict, expected_release_digest: bytes, ) -> bool: """Step 3: the SEP attestation policy claims must constrain the release digest. See SEPAttestationPolicy.swift for the policy schema [@apple-pcc-sepattestpolicy]. A real client checks the policy version, the claimed release digest, and the attestation freshness window.""" claimed_digest = claims.get("release_digest") return claimed_digest == expected_release_digest

def verify_expiring_inclusion( release_digest: bytes, inclusion_proof: dict, log_witness_root: bytes, ) -> bool: """Step 4: verify the release digest's inclusion in the public PCC transparency log against a witness-cosigned tree head. Reference impl: SWTransparencyVerifier.verifyExpiringInclusion [@apple-pcc-swtrans-verifier] [@apple-pcc-transparencypolicy].""" raise NotImplementedError("merkle proof + cosigned witness check")

def verify_pcc_envelope( bundle: AttestationBundle, apple_root_anchor: bytes, log_witness_root: bytes, ) -> bool: """The four-step PCC verifier flow. Returns True only if every step passes. A real client refuses to send the user's prompt if this returns False.""" if not aks_attest_context_verify( bundle.sep_signature, bundle.sep_cert_chain, apple_root_anchor ): return False release_digest = compute_release_digest(bundle.release_der) if not check_sep_attestation_policy( bundle.sep_attestation_policy_claims, release_digest ): return False if not verify_expiring_inclusion( release_digest, bundle.transparency_inclusion_proof, log_witness_root ): return False return True `}

The symmetry is the procurement point. Azure: validate JWT signature against MAA JWKS, match claims against SKR policy. Apple PCC: validate SEP signature against Apple PCC CA, validate inclusion proof against transparency log witness root. Both are cryptographic; both produce a yes/no decision against a hardware-anchored chain of trust. The architectural difference is what the relying party is allowed to know: with PCC, the relying party knows the exact image hash that ran (because the log says so); with Azure, the relying party knows the workload met an MAA policy (because the JWT says so). The two are not interchangeable evidence, but the verifier code-paths are roughly the same shape.

The decision tree handles the typical questions. The atypical questions, and the misconceptions, are next.

11. Frequently Asked Questions

Yes, in both architectures, against the threats the architecture names. Apple PCC's SEP-rooted attestation envelope plus the Transparency Log refusal to forward to unlogged images defends against a malicious Apple operator passively reading prompts [@apple-pcc-blog]. Azure CC-AI's SEV-SNP RMP-enforced memory plus MAA-gated SKR defends against a malicious Microsoft operator on the SEV-SNP path [@ms-maa-overview]. Neither closes side-channels on shared silicon [@ccc-technical-analysis]; neither closes compelled-vendor or lawful-access exposure; neither closes prompt-output exfiltration via the model itself. The "the cloud cannot see your prompt" claim is true against the named threat model and not against every conceivable threat. Yes. The 2018-2020 cascade closed the SGX-era residuals -- Foreshadow / L1TF [@foreshadow], SgxPectre [@sgxpectre], Plundervolt (CVE-2019-11157) [@plundervolt] -- and the principled extension is that any TEE built on shared microarchitectural state inherits a similar surface. The CCC's "A Technical Analysis of Confidential Computing" v1.3 names this explicitly as a residual risk that the architecture does not close by construction [@ccc-technical-analysis]. CipherLeaks (USENIX Security 2021) demonstrated the same point on the AMD SEV side via a deterministic-ciphertext side channel [@cipherleaks]. Vendor microcode updates are an ongoing operational requirement, not a one-time fix. No. Per the `apple/security-pcc` README verbatim: "The publication of this code is intended for security research and verification purposes only" [@apple-pcc-github]. The publication's purpose is research-grade transparency -- so that an independent researcher can inspect what is running, exercise the architecture inside the Virtual Research Environment, and submit findings to the Apple Security Bounty program with rewards up to \$1,000,000 [@apple-pcc-research]. It is not a typical open-source contribution model and the license and intended use are explicitly different. The substantive thing PCC ships is verifiable transparency of the running fleet, not community-driven development. No. Both Linux and Windows guest OSes are supported on Azure confidential VMs, and the reference confidential-inferencing stack Microsoft publishes is Linux-based. The `microsoft/confidential-ai-workshop` repository contains three Linux-based tutorial directories: `confidential-llm-inferencing`, `confidential-whisper-inferencing`, and `confidential-ml-training`, with reusable modules for attestation, key management, key origin, model sourcing, and OS disk encryption [@ms-workshop]. The LLM inferencing tutorial deploys a `Standard_NCC40ads_H100_v5` confidential VM with a vLLM-plus-Streamlit-plus-Caddy stack [@ms-workshop-llm]. Windows is supported; Linux is the canonical reference. Confidential Containers is an orchestration-layer abstraction that maps Kubernetes pods onto Generation-3 confidential VMs running on AMD SEV-SNP, Intel TDX, or IBM Secure Execution [@coco-gh]. It composes on top of the same substrate Azure CC-AI uses. It does not compete with Apple PCC architecturally -- they live at different layers of the stack. A CoCo deployment on Azure can use MAA and SKR for its attestation and key-release primitives, and orchestration vendors like Edgeless Systems' Contrast wrap that pattern into a workload-level confidential-computing primitive on Kubernetes [@edgeless-contrast]. No. Both rest on vendor-controlled signing infrastructure. PCC's compelled-vendor exposure is concentrated on Apple, because the signer of every PCC attestation chain is Apple. Azure's is distributed across AMD, Intel, NVIDIA, and Microsoft, but a compelled Microsoft is sufficient to compromise an MAA-rooted workload because MAA is the single verifier whose JWT every downstream relying party trusts [@ms-maa-overview]. Trust diffusion across multiple vendors makes the *collapse* harder, but it does not make any one vendor's compelled-update path architecturally impossible. This is a property of the trust-rooting model, not a flaw of either architecture, and neither closes it by construction. No. The canonical late-2024 Mark Russinovich confidential-AI session is **Microsoft Ignite 2024 BRK430**, "Inside Azure Innovations with Mark Russinovich," also published on YouTube as "Confidential AI and Inference -- Inside Azure Innovations." Russinovich's "data in use" framing for confidential computing originally appeared in his September 14, 2017 Azure blog "Introducing Azure confidential computing," not in an academic OSDI venue [@ms-russinovich-2017]. Microsoft Build 2024's confidential-inferencing session was BRK227, "Inside AI Security with Mark Russinovich," which announced confidential inferencing for the Azure OpenAI Whisper speech-to-text model -- not for GPT-4, and not under the title "Confidential GPT" [@ms-workshop-whisper].

What to carry into the next conversation

Two architectures. One promise. One axis on which they differ in kind. The end-user pitch -- "the cloud cannot see your prompt" -- is now functionally identical across Apple Private Cloud Compute and Azure Confidential AI, but the architectural machinery underneath ships two genuinely different things. PCC ships verifiable transparency of the production fleet through an Apple-controlled stack and a public Transparency Log. Azure CC-AI ships multi-vendor trust diffusion plus customer-managed keys through AMD SEV-SNP plus NVIDIA H100 CC-On plus MAA plus SKR. Each closes a trust-anchor gap the other leaves open. Neither closes the gap the other closes. Neither closes the side-channel, compelled-vendor, or model-output exfiltration gaps -- the CCC's own v1.3 analysis names these as residual risks for any TEE-based design [@ccc-technical-analysis].

The next architectural generation -- the one that combines Azure-style multi-vendor TEE composition with Apple-style append-only transparency of production images -- would close the gap both leave open. The Kocaoğullar et al. transparency framework is the conceptual sketch [@kocaogullar-transparency]; the CCC Attestation SIG and the IETF RATS Working Group are where the production work is happening [@ccc-attestation-gh] [@ietf-rfc9334]. No vendor has shipped it.

For now, the load-bearing decision is the one Question 4 in §10 asks. If your threat model requires that you be able to confirm what code the cloud is actually running -- and not just that the cloud says it is running specific code -- PCC is the only production answer in mid-2026. If your threat model is satisfied by multi-vendor trust diffusion and a managed-verifier JWT, Azure CC-AI gives you a richer key-management story and broader silicon optionality. The architectures are not better and worse. They are answers to different questions. The first useful step in any confidential-AI procurement is naming which question you are actually trying to answer.

Apple Secure Enclave vs Microsoft Pluton: Two Roads to Hardware Root of Trust

noreply@paragmali.com (Parag Mali) — Thu, 14 May 2026 00:00:00 GMT

**Apple Secure Enclave and Microsoft Pluton solve the same problem -- keeping your keys, biometrics, and disk-encryption secrets safe even when the operating system is compromised -- by way of two different silicon strategies.** Apple gives the SEP its own physical CPU core, its own L4-derived microkernel (sepOS), and a mailbox API that no app can bypass. Microsoft drops Pluton onto the SoC die as a TPM 2.0-compatible subsystem patched through Windows Update. The differences shape everything downstream: who can patch the firmware, what attacks remain in scope, and which APIs developers actually call. This article walks through the architectures, the API surfaces, the published attacks (checkm8, LPC sniffing, faulTPM), and the cross-platform standards (FIDO2/WebAuthn) that paper over the divide.

1. The bus that taught everyone a lesson

In 2021, a researcher at Pulse Security wired a forty-dollar FPGA to the LPC bus of a Microsoft Surface Pro 3 and a Lenovo laptop, captured a handful of bytes as the machines powered on, and pulled the BitLocker Volume Master Key out of the air. Then they decrypted the drives. They wrote the whole thing up, with photos of the soldering and an open-source sniffer named lpc_sniffer_tpm (Pulse Security: Sniff, there leaks my BitLocker key [@pulse-tpm-sniff]).

The hardware was working exactly as designed.

That is what makes the story interesting. The Trusted Platform Module released the disk-encryption key the moment the boot configuration matched its sealed policy. It then handed the key, in cleartext, to the CPU over a physical wire on the motherboard. Anyone who could touch that wire could read the key. The chip, the spec, the OS -- all of them did precisely what the standard required. The threat model just never accounted for somebody putting probes on a laptop.

This is the problem hardware-rooted security has spent twenty years trying to dig itself out of. If you trust software, malware wins. If you trust software-plus-discrete-TPM, the bus wins. If you trust software-plus-firmware-TPM, the host operating system's privileged-mode bugs win. Every layer you add closes one class of attack and opens another.

Key idea: Hardware roots of trust exist because no purely software-defined boundary can survive an attacker who runs code at the same privilege level you do. The only way out is to put the secrets somewhere your main CPU literally cannot read.

Apple and Microsoft both reached the same conclusion roughly a decade apart, and built almost opposite answers. Apple shipped the Secure Enclave Processor (SEP) with the A7 chip in the iPhone 5s in September 2013 [@apple-sep-chapter] -- a dedicated ARM core inside the application SoC, running its own microkernel, talking to the rest of the phone through a hardware mailbox. Microsoft announced Pluton in November 2020 [@ms-pluton-announce], but had been shipping Pluton-class silicon since the original Xbox One in 2013 [@ms-pluton-learn]; the Windows version is an on-die security subsystem that pretends to be a TPM 2.0 chip and accepts firmware updates over Windows Update.

Both companies looked at the same threat -- a curious adversary with a screwdriver, an OS-level rootkit, or a $40 logic analyzer -- and decided the answer was to move the keys off the bus. They just disagreed about where to put them.

A piece of silicon that the rest of a system anchors its security claims to. Keys generated inside the RoT never leave; measurements taken by the RoT are signed by it; software running outside the RoT cannot rewrite the RoT's behavior. The "root" is the part the rest of the trust chain reduces down to. A cryptoprocessor specified by the Trusted Computing Group. TPM 2.0 -- the current version, published in 2014 and revised since [@tcg-tpm2] -- defines Platform Configuration Registers (PCRs), an Endorsement Key burned at manufacture, key creation and sealing primitives, and the `TPM2_Quote` command for remote attestation. A TPM can be discrete (its own chip), firmware (running inside another security subsystem), or virtual.

This article is the comparison nobody quite writes, partly because both vendors prefer to talk about themselves and partly because the technologies look superficially similar. They are not. The architectures differ. The threat models differ. The patch channels differ. The developer APIs differ enough that the same security goal -- "store this key so nothing but the user's biometric can use it" -- produces wildly different code on each side. By the end of this you should know which one is in your device, why it is there, what it actually defends against, and where the academic literature has already poked holes.

flowchart LR subgraph Discrete["Discrete TPM (sniffable bus)"] CPU1[CPU] -- LPC/SPI --> TPM[Discrete TPM chip] end subgraph SEP["Apple SEP (separate core)"] AP[Application Processor] -- mailbox --> SEPCore[SEP core + sepOS] end subgraph Pluton["Microsoft Pluton (on-die subsystem)"] CPU2[CPU] -- on-die fabric --> PlutonSub[Pluton subsystem] end

The journey from "trust the OS" to "trust the silicon that even the OS cannot read" is the story of the last fifteen years of platform security. The Surface Pro 3 attack is what happens when you do half of it. Apple's and Microsoft's answers are what it looks like when you do all of it -- in two opposite ways.

2. Apple's answer: a small computer inside your phone

The Apple Secure Enclave Processor is a separate physical CPU core, on the same die as the application processor, with its own memory, its own boot ROM, its own operating system, and its own random number generator. Apple's own framing in the Platform Security Guide [@apple-sep-chapter] is that the SEP "provides the foundation for the secure generation and storage of the keys necessary for encrypting data at rest." That is what it does. How it does it is what is interesting.

2.1 What sits on the die

Inside an A-series or M-series SoC, the SEP is a distinct cluster. According to Apple's published architecture, it includes (Apple Platform Security: Secure Enclave [@apple-sep-chapter]):

A dedicated processor core (not a SMT thread, not a shared core) running at a lower clock than the application cores.
A Memory Protection Engine (MPE) that encrypts every cache line going to or from SEP-owned DRAM.
A True Random Number Generator (TRNG) seeded by silicon noise.
A hardware AES engine and a Public Key Accelerator (PKA) for ECC and RSA.
A boot ROM masked in silicon at fabrication time.
From A13 onward, a relationship with an external Secure Storage Component (SSC) [@apple-ssc] that provides monotonic counters and replay-protected non-volatile storage.

The lower clock speed is not an accident. Apple explicitly notes that the SEP "is designed to operate efficiently at a lower clock speed that helps to protect it against clock and power attacks" (Apple Platform Security [@apple-sep-chapter]). Side-channel-resistance starts at the timing budget.

Apple's dedicated security coprocessor, introduced in the A7 SoC in September 2013 [@apple-a-series]. Each Apple-designed SoC since contains one SEP. It runs `sepOS`, an Apple customization of the L4 microkernel, and exposes its services only via a tightly defined mailbox interface from the application processor. The operating system the SEP runs. Apple describes it as "an Apple-customized version of the L4 microkernel" (Apple Platform Security: Secure Enclave [@apple-sep-chapter]). It is independent of iOS, iPadOS, or macOS, ships in the same firmware bundle as those operating systems, and is signed by Apple. The microkernel design constrains the trusted computing base and forces cross-service communication through IPC.

2.2 The boot chain, in order

When you press the power button, two CPUs come up at once. The application processor begins executing its boot ROM, and the SEP begins executing its own. They are independent boot processes that meet later, after both sides have verified their own firmware.

sequenceDiagram participant AP as Application Processor participant SEP as Secure Enclave Processor participant ROM as SEP Boot ROM (mask) participant Flash as System Storage Note over AP,SEP: Reset AP->>AP: Execute AP Boot ROM SEP->>ROM: Execute SEP Boot ROM ROM->>Flash: Load sepOS image ROM->>ROM: Verify signature against Apple root key alt Signature valid ROM->>SEP: Launch sepOS SEP->>SEP: Initialize MPE, derive UID-tangled keys else Signature invalid ROM->>SEP: Halt end AP-->>SEP: Mailbox handshake SEP-->>AP: Available services advertised

The SEP boot ROM is mask ROM. That phrase carries weight. It means the bits were etched into the silicon at fabrication and cannot be rewritten. Apple cannot patch the SEP boot ROM with a software update, even if Apple wants to. This is a feature -- nobody else can patch it either -- and a liability. We will return to it when we discuss checkm8.

After the SEP boot ROM verifies and launches sepOS, the SEP holds two values fused into the silicon at manufacture: a Unique ID (UID) and a Group ID (GID). The UID is per-device. The GID is per-product-family. Both are kept inside the SEP and never appear outside it. Keys derived from the UID are tangled to the specific piece of silicon; you cannot lift the wrapped key, move it to another phone, and unwrap it. The chip is physically the wrap-and-unwrap oracle.The UID is also why factory-reset really does erase your data. The data-protection key hierarchy roots at a key derived from the UID and a per-file random; rotate the right intermediate and every wrapped file becomes unrecoverable noise.

2.3 The Memory Protection Engine

The SEP's RAM is, physically, in the same DRAM module as everything else. A naive design would let the application processor read it. The MPE prevents that. Every cache line bound for SEP memory is encrypted with AES in XEX mode (a tweakable mode similar to disk-encryption XTS) and authenticated with a CMAC tag. The tweak includes the physical address, so an attacker cannot relocate ciphertext to a different location and have it still verify (Apple Platform Security: Secure Enclave [@apple-sep-chapter]).

Starting with the A11 SoC, the MPE added an anti-replay value per protected block, with the anti-replay tree rooted in dedicated on-die SRAM. The threat that introduces is: an attacker who can capture the encrypted DRAM contents at time T1 and overwrite the DRAM with that snapshot at time T2 -- a "store, rewind, replay" attack. Tree-rooted anti-replay defeats it because the root in SRAM does not match the old leaves the attacker re-injected.

The tweakable XEX construction has the property that two cache lines containing the same plaintext at different addresses produce different ciphertext, which prevents the pattern-leakage you get from ECB-style encryption. CMAC adds a 128-bit integrity tag.

From the A14 and M1 generation onward, the MPE handles two ephemeral keys: one for SEP-private data and one for data shared with the Secure Neural Engine (used during Face ID matching). The keys are regenerated at every reset, so even capturing the DRAM ciphertext across a reboot leaks nothing.

2.4 The Secure Storage Component

Anti-hammering -- the property that a passcode-guessing attacker is rate-limited and eventually locked out -- requires reliable monotonic state that the attacker cannot rewind. Mask ROM and on-die SRAM are not enough on their own because power loss erases SRAM. From the A13 SoC onward, Apple solves this by adding a separate chip on the logic board: the Secure Storage Component (SSC) [@apple-ssc].

The SSC is small, tamper-resistant, and only the SEP can talk to it. It stores monotonic counters and entropy values that the SEP uses to bind authenticated storage to wall-clock state. If you steal the phone, dump the encrypted blobs, "rewind" by overwriting the flash with an earlier copy, and try to brute-force the passcode again, the SSC's counters no longer match. Anti-hammering survives the rewind.

Note: A monotonic counter sounds easy until you remember that an attacker with the physical device can pull power at any instant, including in the middle of an increment. The SSC has to atomically commit counter updates while also defending against deliberate transient brown-outs. This is the kind of thing that takes a dedicated tamper-resistant chip rather than a software loop.

2.5 The mailbox API

Userspace apps never touch the SEP directly. The application processor reaches it through a hardware mailbox -- a small ring of registers and shared memory that defines the entire API surface from AP to SEP. The kernel exposes higher-level services on top: Touch ID and Face ID matching, Keychain entries flagged with kSecAttrTokenIDSecureEnclave [@apple-keychain], Data Protection class keys, App Attest signing, and so on.

The constraint is severe. The SEP exposes a fixed set of operations. No app, and no part of the OS, can ask the SEP to do something the firmware did not already implement. Compromise of the AP-side kernel does not produce an arbitrary-code-execution primitive on the SEP. It produces, at most, the ability to call SEP services from a hostile place -- and those services still require user authentication (FaceID, TouchID, passcode) before they release sensitive operations.This is the dual of the TPM 2.0 design philosophy. A TPM defines a wide command set in its spec; the firmware implements that command set; software calls those commands. The SEP defines a narrow service set bespoke to Apple's products; everything else is rejected.

Note: The SEP is not a generic crypto coprocessor. It is a small fixed-purpose computer that knows how to do exactly the operations Apple's platforms need, and nothing else. Its security comes from being deliberately less programmable than a TPM.

If you had to summarize what Apple built in one sentence: they put a second computer in the phone, gave it the keys, gave it a lock on its own door, and left a slot for messages to slide through. That is the design.

3. Microsoft's answer: kill the bus, keep the standard

Apple had the luxury of designing the application processor and the security processor together. Microsoft does not. Microsoft sells software that runs on AMD, Intel, and Qualcomm silicon, on chassis from Dell, HP, Lenovo, Acer, Asus, Microsoft itself, and a long tail of others. The discrete TPM 2.0 standard fixes a contract between Windows and a piece of trusted hardware that any vendor can implement. Pluton's job was to keep that contract while removing the parts that did not survive contact with reality.

The first part of reality Pluton kills is the bus.

3.1 The Xbox lineage

Microsoft did not invent Pluton for Windows. The architecture started in the original Xbox One, shipping in 2013 [@ms-pluton-learn], where it served as the security subsystem that prevented modchipping and verified the boot chain. The same architecture was extended to the Azure Sphere MT3620 microcontroller in 2018 [@ms-pluton-learn], aimed at IoT devices. The Windows variant -- the one most people mean when they say "Pluton" -- was announced in November 2020 [@ms-pluton-announce].

The first shipping Windows silicon containing Pluton was the AMD Ryzen 6000 series ("Rembrandt") in January 2022. Qualcomm Snapdragon 8cx Gen 3 and the Snapdragon X family followed in 2023-2024. Intel's first Pluton-bearing CPU was Core Ultra Series 2 ("Lunar Lake") in late 2024. As of the current Microsoft documentation, the supported matrix is "AMD Ryzen 6000/7000/8000/9000 and Ryzen AI Series; Intel Core Ultra 200V Series, Ultra Series 3; Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series" (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]).This is a deployment claim. Pluton's presence on these CPUs is documented by the silicon vendors and Microsoft. Whether Pluton is enabled by default on a given laptop varies by OEM. Practitioners verifying real fleets need to confirm via Windows' Device Manager and tpm.msc whether the active TPM advertises the Microsoft Pluton manufacturer ID rather than a discrete vendor.

3.2 What sits on the die

Pluton is a security subsystem placed inside the SoC, not on a separate chip on the motherboard. That single architectural decision eliminates the LPC/SPI bus that defeats discrete TPMs. Microsoft's framing in the announcement post: the design targets attacks "where an attacker can steal or temporarily gain physical access to a PC ... on the communication channel between the CPU and TPM" (Microsoft Security Blog [@ms-pluton-announce]).

Microsoft-authored security subsystem integrated into the SoC die of supported AMD, Intel, and Qualcomm processors. Pluton presents a TPM 2.0 interface to Windows but adds firmware-update via Windows Update and capsule, on-die placement (no external bus to sniff), and a Microsoft-maintained codebase that Microsoft describes as "Rust-based" from 2024 onward [@ms-pluton-learn] on AMD and Intel platforms. Microsoft's name for keys that are "never exposed outside the protected hardware, even to the Pluton firmware itself" (Microsoft Security Blog, 2020 [@ms-pluton-announce]). Conceptually equivalent to Apple's UID-tangled keys: a hardware boundary that even the firmware running on top cannot cross.

Inside the die, Pluton runs its own small processor (the vendors do not publish the ISA in customer-facing docs), with its own ROM, on-die RAM, hardware crypto engines, and a hardware-confined key store. It exchanges messages with the host through a mailbox interface analogous to SEP's, but the higher-level wire protocol it speaks back to the host is TPM 2.0.

3.3 TPM 2.0 as the personality, not the limit

Pluton implements the TPM 2.0 command set. That means BitLocker, Windows Hello, Credential Guard, System Guard, Measured Boot, and Device Health Attestation all work against Pluton with no modifications -- they think they are talking to a TPM 2.0 chip, and they are (Microsoft Pluton as TPM, Microsoft Learn [@ms-pluton-as-tpm]).

TPM 2.0 compatibility is the compromise that buys Microsoft adoption. The entire Windows security stack was already designed against the TCG TPM 2.0 wire protocol. Forcing it onto a new API would have required years of platform engineering. Forcing it onto a new API and getting OEMs to adopt the new chip would have required forever.

You could read the Pluton design as "TPM 2.0 with a software-update channel." That is mostly right and is how the documentation usually describes it. But Pluton also supports Pluton-specific paths beyond TPM 2.0 -- the Microsoft Learn documentation [@ms-pluton-learn] refers to Pluton-rooted credentials and attestation flows that ride alongside the TPM personality. The TPM interface is the lowest common denominator, not the ceiling. flowchart TD subgraph Windows["Windows OS"] BL[BitLocker] WH[Windows Hello] CG[Credential Guard] DHA[Device Health Attestation] end subgraph Pluton["Pluton subsystem on SoC"] TPMpers["TPM 2.0 personality -- (PCRs, EK, AK, Quote, Seal)"] MSrooted["Microsoft-rooted services -- (Pluton credentials, MS-signed firmware)"] end BL --> TPMpers WH --> TPMpers CG --> TPMpers DHA --> TPMpers DHA --> MSrooted WH --> MSrooted

3.4 The patch channel

This is the design feature Microsoft most emphasizes and where the philosophical break with Apple is most visible. Pluton firmware can be updated through two paths (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]):

UEFI capsule update. The Pluton firmware lives on the system's SPI flash and is loaded during early boot. A capsule update -- delivered via the same UEFI mechanism that updates BIOS -- can replace it.
Dynamic loading via Windows Update. Microsoft can ship a new Pluton firmware blob through Windows Update; the OS loader picks it up the next time the subsystem comes online.

Apple's update model is essentially the first path with a different label. The SEP firmware ships inside the iOS/macOS image bundle, signed by Apple, and is loaded at boot. There is no Windows-Update-style ambient channel separate from the OS image.

Patchable. By Microsoft. Through the channel users already trust. This is the single biggest practical advantage Pluton has over discrete TPMs, and the single biggest political problem.

The structure of this difference is what makes the Apple-vs-Microsoft comparison sharp. Apple controls the entire silicon, OS, and update channel. The patch path is fast because everything is one vendor. Microsoft does not control the silicon -- AMD, Intel, and Qualcomm do -- but they wrote the firmware, signed it, and route it through Windows Update. The patch path is fast because Microsoft has been delivering OS-level updates to a billion machines for a quarter century.

3.5 Rust as the firmware base

In 2024 Microsoft began shipping Pluton firmware on AMD and Intel with what the documentation calls "a Rust-based firmware foundation given the importance of memory safety" (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]). This is, as far as we can tell from primary sources, the most prominent shipping production use of Rust inside an x86 platform security subsystem. It addresses the most common class of TPM firmware bugs, which historically have been C memory-safety issues -- bounds errors, use-after-frees, integer overflows.

Note: Rust eliminates the spatial and temporal memory-safety bugs that dominate CVE counts in C-based firmware. It does not prevent logic bugs, side-channel leaks, or fault-injection vulnerabilities. The faulTPM work, discussed in Section 7, exploits the underlying voltage rail rather than firmware bugs -- and the same physics apply whether the firmware is in C or Rust.

If the SEP's design philosophy is "small fixed-purpose computer," the Pluton design philosophy is "in-die TPM 2.0 we can actually patch, written carefully enough that we will not have to patch it often." Two different bets about which property mattered most.

4. The tightly-coupled vs SoC-integrated trade-off

So far we have two architectures: SEP as a separate physical core, Pluton as an on-die subsystem. They sound different. They are different. But "separate core" and "on-die subsystem" both refuse the discrete-TPM design where the security chip is off the SoC and reachable over a motherboard bus. Why did both vendors converge there, and what is the trade-off between SEP-style and Pluton-style integration?

4.1 What both reject

The discrete TPM 2.0 model is the baseline. A separate chip, often a Nuvoton, Infineon, or ST device on the motherboard [@pulse-tpm-sniff], connected to the platform via LPC, SPI, or I²C. The TCG spec it implements is excellent. The physical placement is the problem.

Pulse Security's attack is the canonical demonstration. With lpc_sniffer_tpm on a $40 FPGA, they probed the LPC bus of a Surface Pro 3 as it booted, captured the bytes the TPM returned for the unsealed Volume Master Key, and used those bytes to decrypt the disk (Pulse Security: TPM Sniffing [@pulse-tpm-sniff]). The TPM was working correctly. The bus was the problem. There is a mitigation -- pre-boot PIN or USB key, so the VMK is bound to something not on the wire -- but the default BitLocker configuration on most enterprise hardware does not enable it.

The class of physical-access attacks in which an adversary attaches probes to the motherboard bus carrying TPM responses, captures the cleartext key material the TPM legitimately returns, and uses it directly. Defended against by either eliminating the external bus (Pluton, SEP) or by requiring authenticated/encrypted sessions plus pre-boot user authentication (TPM 2.0 parameter encryption, BitLocker TPM+PIN).

Both SEP and Pluton refuse to expose that bus. The keys never appear on an external wire. That is the structural property both architectures buy by being on the SoC.

4.2 Tightly-coupled (SEP) vs subsystem-on-die (Pluton)

After agreeing on "no external bus," the two diverge sharply on what "on the SoC" should look like.

flowchart TD subgraph SEPDie["Apple SoC (A14, M1, M2, etc.)"] SEPCore["SEP core -- own voltage -- own clock -- own ROM"] MPE["Memory Protection Engine"] APCore["Application processor cores"] SEPCore -- mailbox --> APCore SEPCore --> MPE end subgraph PlutonDie["AMD/Intel/Qualcomm SoC"] PSub["Pluton subsystem -- (may share voltage rail -- with security die area)"] PSP["Vendor security subsystem -- (AMD PSP / Intel CSME)"] Cores["Application cores"] PSub -- on-die fabric --> Cores PSub -.runs on top of.-> PSP end

The SEP is a separate physical core with its own clock, its own voltage rail, and crucially no shared microarchitecture with the application processor. That last point matters because the family of cross-thread, cross-core, and frequency-scaling side channels -- Meltdown, Spectre, Foreshadow, Hertzbleed, and their cousins -- generally requires the attacker code to be co-resident on the same physical pipeline or share a microarchitectural resource. The SEP simply does not share execution resources with potentially hostile code on the application cores (Apple Platform Security: Secure Enclave Processor [@apple-sep-chapter]).

Pluton-on-AMD is implemented inside the AMD Platform Security Processor environment. Pluton-on-Intel is implemented inside Intel's Converged Security and Management Engine. These are pre-existing vendor security subsystems Microsoft layered Pluton atop. The Pluton subsystem is logically separate, with its own firmware and its own key store. Whether it has a fully separate physical voltage rail and clock domain from the application cores is not something the public documentation states clearly, and the answer almost certainly varies by silicon partner.This is a place where the comparison is hardest to make crisply. Apple has a single answer because Apple makes one SoC family. Microsoft has three answers because Pluton lives inside whatever security subsystem AMD, Intel, or Qualcomm already provide. The detail-level guarantees vary.

4.3 The SGX cautionary tale

There is a third design point worth flagging because both vendors implicitly chose against it: putting the trusted execution environment inside the application CPU cores themselves. Intel SGX, introduced in 2015 [@intel-sgx], did exactly that. Enclaves were memory regions with hardware access control inside the same cores running ordinary software.

SGX was a beautiful idea and an academic catastrophe. Foreshadow, ZombieLoad, SgxPectre, Plundervolt, and a long sequence of related attacks reused the side-channel-rich microarchitecture of modern Intel cores to leak enclave contents. Intel deprecated SGX on most consumer processors in 2022 [@intel-sgx-deprecation], retaining it on server SKUs for confidential computing scenarios where the threat model is different.

The lesson is something both Apple and Microsoft seem to have absorbed: a trusted execution environment that shares any microarchitectural state with the workloads it must protect from is structurally compromised, because microarchitecture is too rich and too leaky to perfectly isolate. The SEP rejects this by living on its own core. Pluton rejects it by living in a separate subsystem.

Arm TrustZone, introduced in Arm v7 around 2008 [@arm-trustzone], pioneered the "secure world / normal world" split inside a single core. TrustZone is closer to SGX than it is to SEP or Pluton in this respect: secure world and normal world share the same physical pipeline. TrustZone influenced both SEP and Pluton in the sense that "you need a separate execution environment for security code" became table stakes; both companies then moved that environment off the application core entirely.

4.4 The trade-off in one sentence

A dedicated core (SEP) maximises side-channel resistance and minimises attack surface, at the cost of vendor proprietary lock-in and zero portability. An on-die subsystem (Pluton) preserves the TPM 2.0 standard, ships on three silicon vendors, and inherits the security guarantees of the underlying vendor security subsystem -- whose history, as we will see, is less reassuring than Apple's monopoly on its own silicon.

Key idea: SEP wins on isolation. Pluton wins on portability. Neither wins on both. The choice you make at the SoC level constrains every API, every patch path, and every threat-model claim downstream.

5. The APIs developers actually call

Architectures are interesting. What ships in production code is what determines whether developers use these things correctly. The API surfaces are wildly different, and the difference matters.

5.1 Apple: SecKey, App Attest, LocalAuthentication

On Apple platforms, the SEP is exposed through a handful of frameworks. The most common entry point is SecKey in the Security framework, with key attributes that bind the key to the SEP:

kSecAttrTokenIDSecureEnclave makes the key SEP-resident.
kSecAttrAccessControl with LAContext adds biometric or passcode gating.
kSecAttrIsPermanent puts it in the Keychain [@apple-keychain].

The key itself never leaves the SEP. The application receives an opaque handle. Asking the framework to sign a message turns into a mailbox call to the SEP, which evaluates the access-control policy (e.g., "the user must FaceID-authenticate within the last five seconds") and either signs or refuses.

{` // This is a conceptual model of what happens when iOS code asks the SEP // to sign a message with a key whose private half lives inside the SEP. // The real code is Swift + Security.framework; this JS captures the logic.

function generateSEPKey(accessControl) { // SEP generates the keypair internally const priv = sepRandomBytes(32); // never leaves SEP const pub = ecP256ScalarMul(priv, BASE_G); const blob = aesKeyWrap(sepUIDDerivedKey, priv); return { publicKey: pub, handle: opaque(blob), policy: accessControl }; }

const k = generateSEPKey({ requireBiometric: true }); console.log("Public key returned to the app:", k.publicKey); console.log("Private key location: inside SEP, never accessible to app code"); `}

Beyond SecKey, the SEP underpins:

LocalAuthentication -- Face ID / Touch ID matching happens inside the SEP. The biometric template never leaves the SEP, and the application is only told yes/no.
DeviceCheck and App Attest -- documented in the Apple Platform Security Guide [@apple-platform-security]. App Attest gives each app installation a SEP-rooted asymmetric key whose certificate chains to Apple's CA, letting servers verify that a sign-up came from a genuine app on a genuine Apple device.
Data Protection / FileVault -- per-file class keys are wrapped under SEP-held intermediate keys.
Apple Pay -- payment credentials are SEP-resident and gated on biometric/passcode authentication.

Apple's hardware-backed app integrity service [@apple-platform-security]. Each install of each app receives a unique SEP-resident key whose attestation certificate, signed by Apple, lets a back-end server verify that the request originates from a non-tampered installation. The closest cross-platform analogue is Google Play Integrity API; the closest discrete-TPM analogue is TPM 2.0 attestation, but App Attest is more strongly bound to the specific app installation.

5.2 Microsoft: TBS, NCrypt, Pluton-rooted credentials

On Windows, the TPM 2.0 personality means Pluton is reached through the same APIs as any TPM:

TPM Base Services (TBS) -- the low-level Win32 API for sending TPM 2.0 commands.
CNG (Cryptography Next Generation) with NCrypt and the Microsoft Platform Crypto Provider -- the higher-level key API that asks "store this key in the TPM, gated on the user's PIN."
BCryptDecrypt / BCryptSignHash as the in-process crypto API on top.

The DPAPI key-protection model -- file/blob protection rooted in user logon credentials -- has a CNG variant documented as CNG DPAPI [@ms-cng-dpapi] that integrates with TPM-rooted hierarchies. Above that sit the consumer-facing systems: BitLocker for disk encryption [@ms-bitlocker], Windows Hello for credential storage, Credential Guard for isolating LSA secrets in a virtualization-based security enclave, and Microsoft Entra ID conditional access for cloud sign-in.

The TCG TPM 2.0 Library Specification [@tcg-tpm2] defines the command set, object hierarchy, and key-handling semantics of TPM 2.0 chips. Commands include `TPM2_CreatePrimary`, `TPM2_Create`, `TPM2_Load`, `TPM2_Seal`, `TPM2_Unseal`, `TPM2_Quote`, and `TPM2_Certify`. Both discrete TPMs and Pluton implement this command set. flowchart LR subgraph Apple["Apple application stack"] App[App] --> Sec["Security.framework -- (SecKey, SecAccessControl)"] App --> LA["LocalAuthentication -- (LAContext)"] App --> DC["DeviceCheck / App Attest"] Sec --> Mailbox[SEP mailbox] LA --> Mailbox DC --> Mailbox Mailbox --> SEPSvc[SEP services] end subgraph MS["Windows application stack"] WApp[App] --> NCrypt["CNG / NCrypt"] WApp --> Hello["Windows Hello"] WApp --> Entra["Entra ID / Health Attestation"] NCrypt --> TBS["TPM Base Services"] Hello --> TBS Entra --> TBS TBS --> Pluton["Pluton (TPM 2.0 personality)"] Entra --> PlutonMS["Pluton MS-rooted services"] end

5.3 What the API shape tells you

The SEP API forces every call into the small set of operations the SEP firmware implements. There is no TPM2_PolicyLocality(2) equivalent or TPM2_PolicyOR combinator on the SEP. You ask for a key, you ask for a signature, you ask for a biometric match, and that is mostly the surface. From a developer's point of view, the SEP feels like a very small set of well-defined building blocks.

The TPM 2.0 API, by contrast, is enormous. There are several hundred commands. The TPM has policy expressions, sessions, hierarchies (storage, endorsement, platform, owner), and a half-dozen attestation primitives. This expressiveness was the right call for an open standard -- the TCG had to accommodate every conceivable use case across two decades. It also means that "wrote TPM 2.0 code correctly" is a measurable engineering skill rather than a default.

Note: On Apple platforms, prefer kSecAttrTokenIDSecureEnclave with kSecAccessControl rather than rolling your own key handling. On Windows, prefer CNG with Microsoft Platform Crypto Provider over raw TBS unless you specifically need a TPM command not exposed by CNG. Both vendors put their good defaults in the higher-level APIs.

5.4 A note on what is not exposed

Neither platform exposes the device's per-silicon root key to applications. On Apple, the UID is sealed inside the SEP; on Microsoft, the Pluton Endorsement Key is unique per chip but applications interact only with the AKs (Attestation Keys) derived from it. This is deliberate: per-device permanent keys, if exposed, enable cross-service tracking. The exposed primitives are either per-app/per-installation (App Attest), per-session (TPM2_Quote with a fresh AK), or ephemeral (a freshly-generated SEP key).

That choice maps to a privacy property we will pick up in the next section: how each platform answers "prove this is a real device" without becoming "track this specific user across every service."

6. Identity, attestation, and the privacy problem

The deepest difference between Apple and Microsoft is not architectural. It is the answer each one gives to a question that sounds simple: what does it mean to prove a device is real?

6.1 Why attestation is hard

A naive answer is: burn a unique identifier into every chip and have the chip sign messages with the corresponding private key. That works for proof. It also creates a per-device pseudonym that every service can recognise and correlate. The naive answer is a surveillance disaster.

A better answer keeps the unforgeability of "this signature came from a real device" and adds an unlinkability property: the signature does not identify which device, only that it is genuine. This is what cryptographers call anonymous attestation, and the canonical construction is DAA.

A class of cryptographic protocols that let a hardware token sign messages in a way that proves it belongs to a group of legitimate devices without revealing *which* device. Introduced by Brickell, Camenisch, and Chen in 2004 [@brickell-2004-daa] as part of the TPM 1.2 specification work, with the elliptic-curve variant ECDAA standardized for TPM 2.0. See the Wikipedia overview [@daa-wikipedia] for the protocol skeleton.

The mathematics of DAA rests on group signatures with selective linkability. A device runs the join protocol once with a group issuer (the "Privacy CA" or analogous authority) and receives a credential. It can then prove, via a Camenisch-Lysyanskaya-style signature of knowledge, that it holds such a credential without revealing which one. With ECDAA, the join and signing operations are roughly the cost of a couple of elliptic-curve multiplications.

The privacy property comes with caveats. Verifiers can opt into "basename" linkability, where signatures from the same device addressed to the same service are linkable -- letting a service recognise a returning user without letting it correlate across services. The math has been deployed in TPM 2.0 since the 2014 spec.

6.2 The Microsoft path: TPM 2.0 attestation plus Microsoft-rooted services

Pluton inherits TPM 2.0's attestation primitives. The standard flow:

Generate an Attestation Key (AK) inside the TPM, with a private half that never leaves.
Certify the AK to a Privacy CA (or via ECDAA) using the Endorsement Key.
Hash the boot configuration into Platform Configuration Registers (PCRs) during measured boot.
Have the relying party send a fresh nonce.
Issue TPM2_Quote(AK, PCR_mask, qualifying_data=nonce).
Send the quote, the AK certificate, and the boot event log to the relying party.
The relying party replays the event log, checks that the replayed PCRs match the quoted ones, validates the AK certificate chain, and validates the signature.

attest(nonce, pcr_mask):
    AK = TPM2_Create(parent=EK, type=signing)
    AK_cert = privacy_CA.certify(AK_pub, EK_cert)    # or ECDAA group sig
    quote = TPM2_Quote(AK, pcr_mask, qualifying_data=nonce)
    return (quote, AK_cert, event_log)

verify(quote, AK_cert, event_log, expected_pcrs):
    assert privacy_CA.verify(AK_cert)
    assert ECDSA_verify(AK_cert.pub, quote.sig, quote.body)
    assert quote.qualifying_data == nonce
    assert replay_log(event_log) == quote.pcrs == expected_pcrs

That covers raw TPM 2.0. Microsoft layers on top a service called Device Health Attestation that does the verifier work as a cloud service, supplying Reference Integrity Manifests for known-good Microsoft-signed boot states. Microsoft Entra ID conditional access policies can then refuse sign-in to devices whose Pluton-signed health attestation does not match an expected baseline (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]).The interesting privacy property here is that ECDAA-grade unlinkability is available through TPM 2.0, but Microsoft's deployed services tend to use Privacy-CA-style flows where the AK certificate is well-defined and reusable. Whether a given Microsoft attestation flow is anonymous-unlinkable or pseudonymous-linkable is a per-service detail rather than a platform property.

6.3 The Apple path: rooted in Apple's CA, scoped per app

Apple's DeviceCheck and App Attest [@apple-platform-security] take a different approach. App Attest gives each installation of each app a unique SEP-resident key. The corresponding attestation certificate chains to Apple's CA. Apps prove integrity to their own back-end servers by having the server send a nonce, the SEP signing the nonce with the per-install key, and Apple's CA chain validating that the key was issued on a genuine Apple device.

The privacy property is scoped differently from DAA. The key is per-installation, which means uninstalling and reinstalling the app generates a new key with no link to the old one. Across different apps on the same device, the keys are independent -- so two apps cannot collude with their respective back-ends to detect they are on the same phone. The trade-off: there is no formal anonymity within a group; the key is identifiable to its single installation, but that installation is fresh each install.

DeviceCheck is older and weaker. It gives an app a two-bit value the developer can set per device, retrievable on future runs. It is fraud-signal infrastructure, not cryptographic proof.

DAA is a group-signature scheme; Apple's App Attest is a per-installation public-key scheme certified by Apple. They are not the same primitive. DAA gives "I am in this group of devices" without revealing which device. App Attest gives "I am this specific installation, and Apple says it is genuine." The privacy distinction matters when the threat is correlation across services rather than correlation within a single service.

6.4 Where the two converge: FIDO2/WebAuthn

Both platforms expose their hardware-backed credentials through a single cross-platform standard: FIDO2/WebAuthn. When a browser asks "create a credential bound to this origin, hardware-resident if possible," the underlying operating system asks SEP or Pluton to generate the key. The resulting public-key credential, signed by the device's attestation key, is what the relying party verifies (FIDO Alliance [@fido-alliance]).

sequenceDiagram participant Browser participant OS as OS Authenticator participant HW as SEP or Pluton participant RP as Relying Party RP->>Browser: Challenge nonce, RP ID Browser->>OS: navigator.credentials.create() OS->>HW: Generate key bound to RP ID + user gesture HW-->>OS: Public key + attestation OS-->>Browser: Public key + signed attestation Browser->>RP: Registration response Note over RP: Stores public key RP->>Browser: Authentication challenge Browser->>OS: navigator.credentials.get() OS->>HW: Sign challenge (user gesture) HW-->>OS: Signature OS-->>Browser: Assertion Browser->>RP: Authentication response RP->>RP: Verify signature with stored pubkey

FIDO2/WebAuthn is the most boring and most important fact about modern hardware roots of trust: from the application's point of view, you no longer need to know whether you are talking to SEP or Pluton or a discrete TPM. The same JavaScript runs on all of them. We will return to FIDO2 in Section 8.

Note: Attestation is where Apple and Microsoft diverge most sharply on privacy philosophy. Microsoft uses TPM 2.0 with anonymous-group cryptography available but not always deployed. Apple uses per-installation keys rooted at Apple's CA. FIDO2/WebAuthn is the layer where both meet the developer at the door.

7. What has actually broken

Architecture is a story you tell about a system. Attacks are the system's reply. Both SEP and Pluton have a public attack history; reading it carefully is the fastest way to understand the real threat model rather than the marketing one.

7.1 checkm8 and the unpatchable boot ROM

In late 2019, the researcher axi0mX published ipwndfu [@ipwndfu], an exploit against a use-after-free in the SecureROM USB DFU stack of Apple SoCs from A5 through A11. The advisory carries CVE-2019-8900 [@nvd-checkm8] and CERT/CC VU#941987 [@cert-checkm8]. Because SecureROM is mask ROM -- etched into the silicon, immutable -- Apple cannot patch it. The only mitigation was new silicon. A12 and later are immune; earlier devices are permanently affected.

What checkm8 buys an attacker is application-processor code execution at boot time, on a device they have physical access to. That is significant. It enables forensically sound extraction tooling -- the Elcomsoft writeup walks through exactly which iPhone models and iOS versions are supported [@elcomsoft-checkm8]. It also covers the Apple T2 chip used in 2018-2020 Intel Macs [@apple-a-series], which is built on the same A10-family silicon.

But checkm8 does not, by itself, break SEP secrets. The SEP is still gated by the device passcode and the data-protection class keys. An attacker with checkm8 can run code on the AP, but they still need the passcode to unlock the user's protected data (CERT/CC VU#941987 [@cert-checkm8]). The forensic value of checkm8 comes from being able to brute-force passcodes more effectively, capture keyboard state, and access classes of data not bound to a passcode -- not from extracting SEP-held keys directly.

Note: If your organization still has 2018-2020 Intel Macs (T2-bearing) in service, they remain physical-access-attackable. The exploit is mature, the tooling is public, and the silicon will never be patched. For high-value users, retire T2 hardware in favor of Apple Silicon Macs (M1 and later, which use A14-derived SoCs immune to checkm8) (Elcomsoft: using checkm8 [@elcomsoft-checkm8]).

The Pangu team's "Blackbird" SEPROM exploit, presented at MOSEC 2019, reportedly compromised SEPROM on A10/A10X devices. Apple has not published a detailed advisory for that work and the original presentation materials are not in the verified-sources list, so we mention it only by way of acknowledging that even SEP boot ROMs have a finite security lifetime. The architectural point stands: any unpatchable ROM becomes a permanent liability when a bug is found in it.

7.2 LPC sniffing and discrete TPMs

We opened with this attack and it deserves a second pass in the context of Pluton's design. The Pulse Security writeup [@pulse-tpm-sniff] demonstrates extraction of the BitLocker Volume Master Key from a Microsoft Surface Pro 3 (TPM 2.0) and a Lenovo laptop (TPM 1.2) using a $40 FPGA on the LPC bus. The attack requires physical access for under an hour and modest soldering skill.

This is the textbook case where Pluton is structurally better than discrete TPMs: there is no external bus to sniff because the security subsystem lives on the SoC die. The same attack against a Pluton-enabled CPU is not just hard, it is geometrically impossible. There is no bus to attach probes to.

That is not the same as "Pluton is unattackable" -- it just means this specific attack class is closed.

7.3 faulTPM and the AMD PSP

The most consequential publication on Pluton-adjacent silicon is Werling, Buhren, Jacob, and Seifert's 2023 USENIX WOOT paper "faulTPM" [@faultpm]. The attack: voltage fault injection against AMD's Platform Security Processor (PSP), the TEE on which AMD's fTPM runs, on Zen 2 and Zen 3 CPUs. The result: full extraction of the fTPM key derivation seed. With that seed, the attackers decrypted all sealed objects regardless of PCR policy or anti-hammering, and recovered the BitLocker VMK on a Lenovo Ideapad. The reproducible attack code is PSPReverse/ftpm_attack on GitHub [@faultpm-repo].

Several careful observations:

The published attack targets non-Pluton AMD fTPM. Pluton-on-AMD is a separate code path; faulTPM as published does not directly extract Pluton state.
Pluton-on-AMD runs in the PSP environment. The underlying TEE that faulTPM compromises is the same TEE Pluton-on-AMD rides on. Whether the additional hardening Pluton adds is sufficient to defeat fault injection at the PSP level is an open empirical question.
There is no published voltage-glitch attack against Microsoft Pluton specifically as of May 2026 in the verified sources surveyed. Absence of evidence is not evidence of absence; serious researchers are reportedly working on it.

A physical attack class in which the attacker briefly reduces or perturbs the supply voltage to a target chip at a precisely timed moment, causing it to mis-execute an instruction in a controlled way. With sufficient practice, VFI can be used to skip authentication checks, leak intermediate values, or corrupt key derivation. Defenses include redundant voltage sensors, double-execution of sensitive operations, and physically separating the voltage domain of the security subsystem -- mitigations Apple alludes to for SEP and Microsoft alludes to for Pluton, but neither vendor publishes a complete defensive model. If your adversary is a state-level laboratory with \$50K of equipment and a few hours of physical access, no commodity hardware root of trust on the market today is fully resistant to fault injection. The realistic question is "how much does extracting the key cost, and is that cost above the value of what is protected?" For consumer threat models, faulTPM is exotic; for high-value enterprise or dissident use cases, it is in scope.

7.4 What is not known to be broken

Modern SEP (A14+/M-series) has no publicly disclosed extraction attack as of the May 2026 verified sources reviewed. The combination of dedicated core, MPE with anti-replay, lower clock, and SSC-backed replay protection has held up. This is consistent with -- but does not prove -- the architectural claim that the dedicated-core design closes the side-channel and co-execution attack surface.

Pluton with the 2024+ Rust firmware foundation has no publicly disclosed direct extraction attack. The faulTPM family of attacks remains an open concern at the PSP layer; the LPC bus class is closed by design; firmware bugs are reduced (not eliminated) by the move to memory-safe code.

flowchart TD A["Attack class"] --> B{"Discrete TPM"} A --> C{"AMD fTPM"} A --> D{"Pluton"} A --> E{"Apple SEP A14+"} B --> B1["LPC sniffing: yes (Pulse Security)"] B --> B2["Firmware bug: rare patches"] C --> C1["faulTPM: full extraction"] C --> C2["Patches: BIOS only"] D --> D1["LPC sniffing: not applicable"] D --> D2["faulTPM-like on PSP: open"] D --> D3["Patches: Windows Update + capsule"] E --> E1["checkm8 on A5-A11: AP code exec"] E --> E2["Direct SEP extraction A14+: none public"] E --> E3["Patches: iOS/macOS update, mask ROM never"]

The honest summary is that as you move from discrete TPMs to fTPMs to Pluton to SEP, the attack surface shrinks but the residual attacks get more expensive rather than disappearing. The faulTPM line is still the academic state of the art in showing this.

8. Cross-platform standards: the layer where the divide gets papered over

If you are a web developer in 2026 and a user asks "how do I sign into your site with my Touch ID or my Windows Hello fingerprint?" the answer is the same in either case: WebAuthn. The standard does not care which hardware root of trust the OS happens to expose underneath.

8.1 FIDO2/WebAuthn as the lingua franca

The FIDO Alliance [@fido-alliance] defines the protocols. WebAuthn is the W3C JavaScript API; CTAP (Client to Authenticator Protocol) is the underlying transport between the browser/OS and the authenticator. The authenticator can be a USB security key, a phone, a built-in platform authenticator backed by SEP or Pluton, or something else entirely. The relying party sees the same registration and authentication ceremony in all cases.

The handful of properties WebAuthn guarantees -- origin binding, user gesture, fresh signature per challenge -- are independent of the silicon underneath. The handful of properties it does not try to guarantee -- "is this device freshly compromised by a kernel rootkit" -- are not fixable at the protocol layer either; that is what attestation extensions are for.

8.2 Where attestation extensions vary

WebAuthn defines optional attestation extensions that let a relying party request a hardware-backed proof that the authenticator is genuine. Apple's attestation through WebAuthn rides on App Attest infrastructure; Microsoft's rides on TPM 2.0 attestation. The receipts differ in format and certificate chain, but the higher-level question "does the public key come from genuine hardware" gets answered on both platforms.

For most relying parties, the cross-platform truth is simpler than the underlying mechanics: ask for a hardware-backed credential, accept the WebAuthn response, validate the signature, and let the platform handle what kind of silicon was involved.

WebAuthn looks like it should be the climax of the article. From an architecture perspective, it is the anticlimax. The whole point is that, at the application layer, SEP and Pluton are interchangeable. That is what the standard is for. The differences resurface only when you care about device-class attestation or about the privacy property of the attestation key -- both of which are extension-level concerns rather than core-protocol concerns.

8.3 TPM 2.0 as the other lingua franca

TPM 2.0 itself plays this role in non-web contexts. Enterprise tools that need to attest a device's boot state -- Microsoft Entra ID conditional access, MDM compliance evaluators, Linux remote attestation frameworks -- speak TPM 2.0. Pluton exposes the TPM 2.0 wire protocol, so these tools work unchanged (Microsoft Pluton as TPM, Microsoft Learn [@ms-pluton-as-tpm]).

Linux on Apple Silicon (Asahi) currently cannot use SEP for analogous attestation; Apple does not expose the SEP to non-Apple operating systems, and there is no TPM 2.0 emulation. This is a real gap for users who want Apple hardware with a non-Apple OS.

8.4 The Android third corner

This article is about Apple vs Microsoft, but a complete picture must mention that Android has its own hardware root of trust story rooted in Trusty/TEE-style designs on ARM TrustZone plus discrete StrongBox elements on Pixel-class hardware. Cross-platform mobile development frequently abstracts SEP and Android StrongBox under a common interface (e.g., React Native's keychain modules), and the privacy and attestation properties of the two systems are not identical but rhyme. Google Play Integrity API plays the role App Attest plays on iOS.

Note: At the application layer, the right question is not "SEP or Pluton" but "are you using WebAuthn or TPM 2.0 or App Attest at the right point in the trust path." The platform-specific differences sit beneath those interfaces, and the standards are explicitly designed to be the place developers can stop caring.

9. Deployment dynamics: who ships what, where, when

The two industries have different shapes, and that shapes the deployment story.

9.1 Apple: vertical integration, total reach

Every shipping Apple device since the iPhone 5s contains a SEP, by virtue of every shipping Apple SoC containing one. That includes (Apple Platform Security: Secure Enclave [@apple-sep-chapter]):

iPhone 5s and later (A7+)
iPad Air and later
Apple Watch Series 1 and later
Apple TV HD and later
HomePod and HomePod mini
Apple Vision Pro
All Apple Silicon Macs (M1, M2, M3, M4 families)
All Intel Macs from 2018 to 2020 (via the T2 chip)

There is no SKU differentiation. There is no "Pro vs Air" split on whether security hardware is present. You buy a current-generation Apple device, you get the SEP. This is the upside of vertical integration: deployment by default.

The downside is that nothing else gets the SEP. Linux on Apple Silicon -- the Asahi Linux project -- cannot use the SEP for keychain operations, FileVault wrapping, or attestation. Apple does not expose the SEP outside of macOS, iOS, iPadOS, watchOS, tvOS, and visionOS. The hardware is universal in Apple's product line and absent everywhere else.

9.2 Microsoft: open multivendor, opt-in adoption

Pluton ships in silicon Microsoft does not make. That changes the deployment story in two ways:

Vendor availability. As of the current Microsoft documentation [@ms-pluton-learn], Pluton is present in AMD Ryzen 6000 and later, Intel Core Ultra Series 2 and later, and Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series. Anything older still uses discrete TPM 2.0 or vendor fTPM.
OEM enablement. The chip can be physically present and disabled in UEFI. Microsoft has been pushing OEMs to ship Pluton enabled by default on Copilot+ PCs, but the universe of laptops is heterogeneous, and the practitioner answer is "check tpm.msc to see what manufacturer ID is reported."

Default-enabled-on-shipping-hardware is documented for Surface Laptop 7 and Surface Pro 11 Copilot+ PCs. Various Lenovo ThinkPad Z, Dell Latitude, and HP EliteBook configurations follow (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]). On other devices Pluton may be present but disabled in firmware, falling back to discrete TPM or vendor fTPM.This is a deployment claim that ages quickly. The shipping matrix shifts every six to twelve months as new SoCs come to market and OEMs rev their UEFI defaults. The verification workflow is the same regardless: Get-PnpDevice and tpm.msc on the actual hardware tell you what is active.

9.3 The patch-channel difference, made concrete

Apple ships SEP firmware inside its OS update. When the user installs iOS 19.4 or macOS 16.2, the bundle includes a new sepOS image; the device verifies and loads it during the next boot (Apple Platform Security [@apple-platform-security]).

Microsoft ships Pluton firmware through Windows Update and UEFI capsules. The OS-driven path lets Microsoft push a firmware refresh to billions of machines without OEM cooperation. The capsule path covers the case where the firmware is needed during early boot before Windows itself is in control.

Discrete TPMs occupy the third position: firmware updates exist but require an OEM-issued utility that few users ever run. This is why most enterprise TPMs in the field run firmware from 2020 or earlier.

Note: A serious bug in a discrete TPM chip is, in practice, never fully fixed because the patch never reaches the bulk of deployed devices. A serious bug in Pluton can be patched globally inside a Patch Tuesday cycle. A serious bug in SEP can be patched globally inside an iOS/macOS minor release. The same bug class produces three different incident-response time scales.

9.4 The economic and political layer

Apple controls every step from sand to support page. The benefit is consistency. The cost is that Apple decides what the SEP can and cannot do, with no externally visible audit, and the customer cannot verify the firmware. For the Apple-customer market, that has not been a deal-breaker.

Microsoft controls the Pluton firmware. The benefit is that one team's engineering effort propagates across three silicon vendors and thousands of OEM SKUs. The cost is that the OS update channel and the security update channel collapse into one Microsoft-controlled flow. Critics describe this as platform lock-in; supporters describe it as the only way to actually patch the silicon at scale. Both readings have evidence behind them.

The same patch channel that protects users from unpatched silicon bugs is the patch channel a hypothetical compelled-update scenario would use. There is no commodity product that gives the device owner an independent veto on root-of-trust firmware updates.

This is a real open problem, not a fictional one. The Trusted Computing Group has a notion of "owner-authorized" TPM hierarchies; Azure Sphere uses a three-key model in which device owner, vendor, and Microsoft all hold signing capabilities for different scopes. Nothing in the commodity consumer space has yet shipped a model where the device owner can veto a vendor-signed firmware update on the security subsystem.

10. Where this goes next

The honest answer is that the immediate future is more of the same with three new pressures.

10.1 Post-quantum migration

The cryptographic primitives currently rooted in both platforms -- ECDSA P-256 in the SEP, RSA-2048 and ECDSA in TPM 2.0 -- are not post-quantum-safe. NIST standardized ML-KEM and ML-DSA in FIPS 203 and FIPS 204 in 2024 (the NIST publication URLs are outside our verified-source set, so this paragraph states the timeline at the policy level only). Migrating hardware-fused attestation roots to post-quantum schemes is genuinely hard because the silicon-burned UID-equivalent keys are baked at fabrication time and cannot easily be replaced.

The likely path: hardware retains agility at the wrapping layer (the unique chip key) while the attestation key types evolve. TPM 2.0 already supports algorithm agility in the spec, which is the kind of foresight you only appreciate a decade after it was added. SEP's key wrapping is bespoke; Apple has not published a PQC migration plan in the verified sources reviewed.

This is a place where the comparison gets uncertain. Both vendors will need to migrate. Neither has shipped a primary post-quantum-rooted attestation flow in their public 2026 documentation as far as we can verify.

10.2 Confidential computing convergence

The same silicon technologies that build SEP and Pluton are now powering confidential computing -- AMD SEV-SNP, Intel TDX, ARM CCA. These extend the "untrusted host kernel" threat model from disk encryption and credential storage to entire virtual machines. The trust roots of confidential computing currently live in the same chips' security subsystems: AMD's PSP holds SEV-SNP attestation keys; Intel's CSME, working with TDX, holds equivalent keys.

Pluton-on-Intel and Pluton-on-AMD will likely inherit responsibilities here as Microsoft consolidates more of the security subsystem under the Pluton name. Apple has not publicly signaled equivalent ambitions for SEP on the server -- Apple's server presence is mostly internal.

10.3 The AI agent identity problem

This is the next decade's question. When your laptop runs an autonomous AI agent that signs cloud API requests on your behalf, what attests to the agent's identity? The current architectures attest to the device and to user gestures, not to the agent. There is no shipping primitive in either SEP or Pluton that says "this signature came from agent X running on device Y, gated by user policy Z that the user actually consented to."

A defensible reading is that both vendors are moving slowly toward agent-bound credentials, but neither has published a clean primitive. This is an open design space. We mark it as a place to watch rather than a place where shipping products have answers.

There is no shipping commodity hardware root of trust with simultaneously: post-quantum attestation, owner-vetoable updates, independently audited firmware, and agent identity. There may not be one for a decade. The current architectures -- SEP and Pluton -- are the strongest commodity options available, and they are still incomplete relative to the design space.

10.4 The convergence that probably will not happen

People periodically suggest that Apple should expose the SEP via TPM 2.0 for cross-platform compatibility, or that Microsoft should ship a dedicated security core like SEP. Neither is likely. Apple's value proposition rests on vertical integration; opening the SEP to non-Apple operating systems would dilute it. Microsoft's value proposition rests on multi-vendor compatibility; mandating a SEP-style dedicated core would fragment their silicon partner relationships.

The structural diversity is here to stay. FIDO2/WebAuthn and TPM 2.0 are how the two systems will continue to interoperate without converging on a single hardware architecture. That is fine. It is even, arguably, good -- a monoculture would be worse for security than a duopoly with different threat-model trade-offs.

Key idea: The interesting question for the next decade is not whether Apple or Microsoft picks a different silicon strategy. It is whether the cross-platform standards layer -- WebAuthn, TPM 2.0, FIDO2 -- evolves fast enough to expose new security primitives (post-quantum attestation, agent identity, owner-vetoable updates) before any one vendor ships proprietary equivalents.

11. Frequently asked questions

Pluton presents a TPM 2.0 personality to Windows -- so BitLocker, Windows Hello, Credential Guard, and TPM-aware enterprise tools work unchanged -- but it is also more than a TPM 2.0. It exposes Microsoft-rooted services beyond the TCG spec, accepts firmware updates through Windows Update rather than only OEM utilities, lives on the SoC die rather than the motherboard (closing the LPC sniffing attack class), and -- from 2024 -- runs a Rust-based firmware foundation on AMD and Intel platforms (Microsoft Pluton Security Processor, Microsoft Learn [@ms-pluton-learn]). Two reasons. First, the SEP was designed before TPM 2.0 became the relevant cross-platform standard for Apple's product mix; SEP's API surface is bespoke to Apple's frameworks (`SecKey`, App Attest, LocalAuthentication, Keychain [@apple-keychain]). Second, exposing the SEP via TPM 2.0 would mean making the SEP usable from non-Apple operating systems on Apple hardware -- which is not how Apple ships its platforms. The SEP's lack of TPM 2.0 personality is a deliberate product decision, not a technical limitation. No -- not directly. Checkm8 (CVE-2019-8900) [@nvd-checkm8] exploits the SecureROM USB DFU stack on A5-A11 Apple SoCs and the T2 chip in 2018-2020 Intel Macs, giving an attacker with physical access application-processor code execution at boot. The SEP itself remains gated by the device passcode and the data-protection class keys (CERT/CC VU#941987 [@cert-checkm8]). The forensic value of checkm8 is the ability to mount passcode brute-force more effectively and access classes of data not bound to a passcode, not direct SEP-key extraction. Yes. The Pulse Security TPM-sniffing attack [@pulse-tpm-sniff] works because the discrete TPM returns the Volume Master Key over an external motherboard bus that an attacker can probe. Pluton lives on the SoC die; there is no external bus to attach probes to. The attack is structurally impossible against Pluton-rooted BitLocker. On laptops with discrete TPMs, the mitigation remains BitLocker with pre-boot PIN or USB key authentication. The published faulTPM attack [@faultpm] targets AMD's fTPM running in the AMD Platform Security Processor (PSP) on Zen 2 and Zen 3 CPUs, not Pluton specifically. However, Pluton-on-AMD is implemented atop the same PSP environment, so the underlying TEE is fault-attackable in principle. There is no publicly disclosed Pluton-targeted voltage-glitch attack as of May 2026 in the verified sources reviewed; whether Pluton's additional hardening blocks the fault-injection class is an open empirical question. For most purposes, no. FIDO2/WebAuthn [@fido-alliance] hides the difference at the API layer -- the same browser code talks to a SEP-backed credential on iOS/macOS and a Pluton-backed credential on Windows. You care about the difference when you need device-class attestation (Apple's App Attest vs Microsoft's Device Health Attestation), when privacy of the attestation key matters (Microsoft offers ECDAA-grade options via TPM 2.0; Apple offers per-installation keys), or when you need to support Linux on Apple Silicon (where neither path is available). Not in any current shipping commodity product. Apple devices ship SEP and no TPM 2.0; Windows devices ship Pluton, discrete TPM, or vendor fTPM but no SEP. The closest historical case is the Apple T2 chip in 2018-2020 Intel Macs [@apple-a-series]: the Mac ran macOS rooted at the T2 SEP, but if you booted Windows on the same hardware via Boot Camp, the T2 still provided the secure-boot anchor though Windows did not interact with it as a TPM.

12. Closing observation

There is a temptation, when comparing two designs as deeply considered as SEP and Pluton, to declare one the winner. Resist that temptation. The two architectures answer different questions for different markets, and the differences are exactly where each one shines. SEP is what you build when you own the silicon, the OS, and the patch channel. Pluton is what you build when you control the OS and the patch channel but need to ride on three other companies' silicon.

The closing observation worth keeping is the one Pulse Security demonstrated by accident: most hardware security failures are not failures of the math. They are failures of the physical placement and the patch flow. SEP and Pluton both close the historical bus-sniffing attack class. They both retain a slow channel for fault-injection research to chip away at. They both depend on the device owner trusting the vendor's signing infrastructure. The next big shift -- if it comes -- will probably be in who controls the patch channel, not in the silicon itself.

That is the bet to watch.

Inside Azure Confidential VMs: SEV-SNP, Intel TDX, and the Paravisor that Makes Them a Cloud Product

noreply@paragmali.com (Parag Mali) — Wed, 13 May 2026 00:00:00 GMT

**Azure Confidential VMs are Windows or Linux guests that the cloud operator's hypervisor cannot read or silently modify.** They are built on two distinct CPU primitives -- AMD SEV-SNP (Reverse Map Table + Virtual Machine Privilege Level + SNP_REPORT) and Intel TDX (Secure Arbitration Mode + the signed TDX Module + RTMR0-3) -- and wrapped on Azure by the open-source Rust paravisor OpenHCL running inside the trust boundary at VMPL0 or the L1 TD seat.

Inside that boundary the paravisor synthesises a vTPM whose quotes chain to the SEV-SNP or TDX hardware report, and Microsoft Azure Attestation runs a customer-defined policy v1.2 file (with JmesPath claim rules) against the evidence to release HSM-backed keys via Secure Key Release.

The Generation-2 integrity rail closes the SEVered and SEVurity ciphertext-remapping class architecturally, but four 2024-era papers (CacheWarp, WeSee, Heckler, Ahoi) demonstrate that side-channel and notification-injection seams remain. Read this if you need to draw the Azure CVM stack from silicon to MAA, decide between SEV-SNP and TDX SKUs, and write an attestation policy that says exactly what you mean.

1. Even the cloud operator must not see your memory

A Windows Server VM is running a SQL query on Azure right now. It is joining a million-row variant table against a patient-genome reference, building an index in RAM, and serving the answer back to a clinician's web portal. The customer who owns that VM has every reason to want the query to succeed and every reason to make sure that nobody else can ever read the index it builds: not the hypervisor it runs on, not the host firmware below it, not the Microsoft engineer holding the on-call pager, not even a court-ordered datacentre raid carried out with full physical access to the rack.

As of 2026, that is not a thought experiment. It is the contract Azure signs when you provision a DCasv5 or DCesv5 confidential VM [@msdocs-overview-products]. And the contract has a shape -- an architecturally enforced shape rooted in two distinct CPU mechanisms, wrapped in an open-source Rust paravisor [@openhcl-blog], verified by a policy-driven attestation service [@msdocs-maa-overview], and dented by four published 2024 attacks that this article will name in order.

The Confidential Computing Consortium defines the contract in one sentence: "Confidential Computing protects data in use by performing computation in a hardware-based, attested Trusted Execution Environment" [@ccc-about]. That sentence finishes a longer thought. Data at rest gets BitLocker and full-disk encryption. Data in transit gets TLS. Data in use -- the gigabytes that sit in DRAM while a process actually computes against them -- has historically been the unencrypted leg of a three-legged stool.

A virtual machine whose memory and CPU state are cryptographically protected from the host hypervisor and the cloud operator's infrastructure, and whose configuration is bound to a hardware-rooted attestation report a remote verifier can check. The Confidential Computing Consortium's framing is the canonical one: "These secure and isolated environments prevent unauthorized access or modification of applications and data while in use" [@ccc-about]. A computing environment whose confidentiality, integrity, and attestability are enforced by hardware mechanisms below the level of the operating system. A TEE may be process-scoped (Intel SGX enclaves), VM-scoped (AMD SEV-SNP, Intel TDX), or board-scoped (AWS Nitro Enclaves). The Confidential VM is the VM-scoped specialisation.

Three concrete workloads make the contract operationally legible. A regulated clean room running joint analytics over patient genomes between an academic medical centre and a pharmaceutical sponsor, where the contract literally forbids the sponsor's staff from reading raw genotypes. A multi-party anti-money-laundering analytic between two competing banks who will share encrypted features but not raw transactions. A sovereign-cloud control plane that must not leak to the hyperscaler's host kernel under any subpoena. In each case the threat model treats the cloud operator as semi-trusted at best and adversarial at worst, and in each case the customer wants the cipher engine to live below the operator's reach.

Note: Encryption at rest hides bytes on storage. Encryption in transit hides bytes on the wire. Encryption in use is the missing third leg -- the one that asks the cipher engine to live inline with the memory controller, so that a VM's working set never appears in plaintext to anyone but the VM itself. That is what AMD SEV-SNP and Intel TDX do at the silicon layer, and what Azure productises with the OpenHCL paravisor and Microsoft Azure Attestation [@ccc-about; @msdocs-azure-cvm].

The architecture that makes this contract real takes vocabulary from Internet standards as well as silicon. RFC 9334, published in January 2023, gives us the verifier / evidence / relying party language we will use throughout the article [@rfc9334]. An attester (the guest VM plus the paravisor) generates evidence (a hardware attestation report plus a vTPM quote). A verifier (Microsoft Azure Attestation in Azure's case) checks the evidence against a policy and emits an attestation result (a signed JWT). A relying party (Azure Key Vault, or any customer service) consumes the result and decides whether to release a secret. The article you are reading is, at heart, a tour of how a SEV-SNP or TDX guest, an OpenHCL paravisor, and Microsoft Azure Attestation realise that abstract diagram on commodity silicon.

That leads to the obvious question. How can a CPU enforce that even the hypervisor cannot read RAM? And once it can, why does a single mechanism turn out to be insufficient -- why does the architecture need a separate integrity rail on top? The next two sections trace the wrong answers that came first.

2. Why enclaves were not enough

In August 2016 David Kaplan stood on the USENIX Security stage in Austin and described "two new x86 ISA features developed by AMD" that he called "the first general-purpose memory encryption features to be integrated into the x86 architecture" [@usenix-kaplan-2016]. Kaplan was, in the conference biography's words, the "lead architect for the AMD memory encryption features" [@usenix-kaplan-2016]. His argument was deceptively simple. An enclave that lives inside a single process is the wrong unit of confidential computation for a cloud workload. The workloads customers actually run -- database engines, analytic services, language runtimes -- want gigabytes of working memory, multiple threads, and an unmodified operating system. None of that fits inside a roughly 96-MiB SGX enclave [@costan-devadas-2016].

Two design ancestors set the shape of the problem before either AMD or Intel solved it.

The first ancestor is the Trusted Platform Module. The TCG TPM specification dates back to 2003, when "the first TPM version that was deployed was 1.1b" [@wiki-tpm]. TPM 2.0 was announced on April 9, 2014 [@wiki-tpm] and standardised as ISO/IEC 11889. The TPM contributed three concepts that remain load-bearing two decades later: platform configuration registers (the extend-only PCR digests that a measured-boot chain builds), attestation identity keys, and a quote operation that signs PCR state with a key whose origin a remote verifier can trust. The TPM is not a TEE in the modern sense -- it does not host computation -- but it is the first widely deployed device that lets a remote party gain cryptographic assurance about what a machine is running. Every confidential VM design ships a TPM-shaped attestation surface inside it.

The second ancestor is Intel Software Guard Extensions. Designed at the HASP 2013 workshop and delivered on Skylake in 2015 [@costan-devadas-2016], SGX introduced the enclave: a process-scoped TEE backed by the Enclave Page Cache, a CPU-managed memory region whose contents are decrypted only inside the cache. Programs enter and leave through ENCLU-family instructions; cross-domain calls use a partitioned model called ECALL / OCALL; remote attestation is mediated by Intel through a quoting enclave. SGX worked, in the strict sense that the threat model included even a malicious operating system. But three things kept it from generalising.

A CPU-protected DRAM region that holds an SGX enclave's working memory in encrypted, integrity-checked form. On early Skylake / Kaby Lake parts the EPC was capped at approximately 128 MiB physical with between ~93 and 96 MiB usable depending on BIOS reservation after reserved EPCM metadata accounting [@costan-devadas-2016]. Anything beyond the cap paged through the encrypted-page-eviction path with a substantial performance cliff, which is one of the architectural reasons SGX did not generalise to whole-VM cloud workloads.

The EPC cap was the first. A working set of ~96 MiB is fine for a key-wrapping service or a small ML model, but it is not a cloud-database VM. The second was the partitioned programming model. Real applications had to be split into trusted and untrusted halves with explicit ECALL / OCALL boundaries, which is a refactoring tax that few existing codebases would pay. The third was the side-channel question: Foreshadow [@foreshadow], SgxPectre [@sgxpectre], and SGAxe [@sgaxe] each demonstrated that a determined attacker with microarchitectural access could extract secrets from SGX, often without ever defeating the cipher itself.Microsoft's response was Haven, an OSDI 2014 project that put a Windows library OS (Drawbridge) inside an SGX enclave to run unmodified Windows binaries. Haven worked as a proof of concept but was effectively obviated by the EPC cap and by the slow pace of SGX silicon delivery in Xeon-class CPUs. The library-OS-in-an-enclave became one of several dead ends on the road to whole-VM TEEs.

Microsoft staked Azure publicly to "data in use" on September 14, 2017, when Mark Russinovich announced Azure confidential computing on the company blog: "Microsoft Azure is the first cloud to offer new data security capabilities with a collection of features and services called Azure confidential computing" [@russinovich-azure-2017]. The same post named the initial backing TEEs. "Initially we support two TEEs, Virtual Secure Mode and Intel SGX. Virtual Secure Mode (VSM) is a software-based TEE that's implemented by Hyper-V in Windows 10 and Windows Server 2016" [@russinovich-azure-2017]. VSM was already the substrate of Credential Guard and HVCI inside the operating system; pulling it up as a "TEE the cloud customer can target" was the bridge between the in-OS Secure Kernel story and the eventually-needed silicon-rooted CVM.

The industry got organised two years later. The Confidential Computing Consortium formed under the Linux Foundation on October 17, 2019. The press release names the founding premiere members verbatim: "Alibaba, Arm, Google Cloud, Huawei, Intel, Microsoft and Red Hat" and the general members "Baidu, ByteDance, decentriq, Fortanix, Kindite, Oasis Labs, Swisscom, Tencent and VMware" [@lf-ccc-press]. An earlier Microsoft Open Source blog post on August 21, 2019, announced the formation with a slightly different membership list (including IBM but not Huawei) [@ms-ccc-blog]; the October press release is the formal founding roster.

Across three load-bearing AMD whitepapers -- SME/SEV (2016), SEV-ES (February 17, 2017), and SEV-SNP (January 9, 2020) -- the PDF cover-page metadata records "David Kaplan" as the named author [@amd-mem-enc-whitepaper; @amd-sev-es-whitepaper; @amd-snp-whitepaper], and the USENIX Security 2016 biography corroborates "lead architect for the AMD memory encryption features" [@usenix-kaplan-2016]. Across the parallel Intel artefacts -- the September 2020 TDX whitepaper and the Architecture Specification doc 344425-001 -- PDF metadata names only "Intel Corporation" as the institutional author and does not enumerate individual architects [@intel-tdx-spec-344425]. We name David Kaplan throughout because the documentary record names him; we deliberately do not name individual Intel architects because the documentary record does not. flowchart TD Data["Customer data"] --> Rest["At rest -- BitLocker, SED, KMS"] Data --> Transit["In transit -- TLS 1.3, IPsec"] Data --> Use["In use -- ?"] Use --> CVM["Confidential VMs -- SEV-SNP / Intel TDX"] CVM --> Para["Paravisor -- OpenHCL"] Para --> MAA["MAA verifier"]

If a TEE has to be smaller than a single page cache, the unit of confidential computation is wrong. What if the unit were a whole VM, and the cipher engine lived inline with the memory controller? The next section is the first time someone tried.

3. Generation 1 and 1.5: confidentiality without integrity

April 2016. David Kaplan, Jeremy Powell, and Tom Woller publish the AMD whitepaper AMD Memory Encryption [@amd-mem-enc-whitepaper]. The paper introduces two features in a single document. Secure Memory Encryption (SME) is a chassis-wide bulk cipher: a per-boot AES-128 key, managed by the on-die AMD Secure Processor, encrypts main memory transparently to the operating system. Secure Encrypted Virtualization (SEV) takes the same engine and gives each VM its own AES key tagged into an Address Space Identifier (ASID) in the cache, so two co-resident VMs cannot read each other's memory and neither can the hypervisor. The "C-bit" in the guest page table marks which pages are encrypted [@amd-mem-enc-whitepaper]. The first silicon to ship SEV was the first-generation EPYC "Naples" launched June 20, 2017 [@wiki-epyc].

A high physical-address bit in an AMD SEV guest's page-table entries that signals to the memory controller "this page is encrypted with my VM's key." The C-bit is the per-page opt-in that lets a SEV guest mix encrypted private memory with explicitly shared bounce buffers in the same address space. Its absence means a page is cleartext to the hypervisor; its presence means the AES engine in the memory controller decrypts on every read and encrypts on every write [@amd-mem-enc-whitepaper].

The threat model was clear and the architecture was honest about it. The hypervisor sees ciphertext on every encrypted page. What the architecture did not do, and what the original whitepaper did not claim, was integrity. The hypervisor remained authoritative over the nested page tables -- it could remap which host physical page a given guest physical address pointed to, and the cipher engine would happily decrypt whatever blob it found under the same key.

That gap produced the architectural lesson.

SEVered (Morbitzer et al., EuroSec 2018)

In May 2018, four authors from Fraunhofer AISEC -- Mathias Morbitzer, Manuel Huber, Julian Horsch, and Sascha Wessel -- published a paper whose abstract is unambiguous: "We present the design and implementation of SEVered, an attack from a malicious hypervisor capable of extracting the full contents of main memory in plaintext from SEV-encrypted virtual machines" [@severed-arxiv]. The attack did not break the cipher. It exploited the fact that a malicious hypervisor could remap a page known to contain a particular plaintext (say, a known string in a network response served by the guest) and observe that the same ciphertext block now appeared at the address corresponding to the secret it wanted. Because there was no architectural binding between a guest physical address and the ciphertext that should sit there, the hypervisor could read the entire VM by chaining such remappings.

We present the design and implementation of SEVered, an attack from a malicious hypervisor capable of extracting the full contents of main memory in plaintext from SEV-encrypted virtual machines. -- Morbitzer, Huber, Horsch, Wessel, EuroSec'18 [@severed-arxiv]

The architectural lesson, stated as bluntly as the paper deserves, is that confidentiality without integrity is not confidentiality.

Key idea: Confidentiality without integrity is not confidentiality. The hypervisor that can move ciphertext between addresses is the hypervisor that can read it. The integrity of the guest-physical-to-host-physical mapping is as load-bearing as the cipher itself.

SEV-ES (February 2017): half a fix

AMD's first response was SEV-ES, dated February 17, 2017 in the whitepaper's PDF cover page [@amd-sev-es-whitepaper]. SEV-ES introduced register-state encryption on VMEXIT. Before SEV-ES, every VM exit handed the hypervisor a complete dump of guest CPU registers, including pointers into otherwise-encrypted memory. SEV-ES encrypted the saved register state under the guest key, surfaced a new #VC (VMM Communication) exception (vector 29), and required the guest to use a deliberately shared page called the Guest-Hypervisor Communication Block (GHCB) for everything that genuinely needed to cross the boundary -- emulated I/O, MMIO, time, the works.

A page that a SEV-ES (and later SEV-SNP) guest deliberately shares with the hypervisor for the purposes of communicating about events the hypervisor genuinely needs to handle: emulated I/O, MMIO accesses, certain control-plane operations. The GHCB is the explicit, audited "side channel" through the trust boundary. Everything else stays encrypted [@amd-sev-es-whitepaper].

SEV-ES closed one channel and left the other open. The integrity of the GPA-to-HPA mapping was still the hypervisor's problem to behave on, and the cipher was still XEX-mode AES without any keyed authentication. Two more papers made the architectural pressure unbearable.

ICUP (Buhren et al., CCS 2019) and SEVurity (Wilke et al., S&P 2020)

In August 2019, Robert Buhren, Christian Werling, and Jean-Pierre Seifert published Insecure Until Proven Updated [@icup-arxiv]. The abstract makes the operational point cleanly: "We demonstrate that it is possible to extract critical CPU-specific keys that are fundamental for the security of the remote attestation protocol. This effectively renders the SEV technology on current AMD Epyc CPUs useless when confronted with an untrusted cloud provider" [@icup-arxiv]. The mechanism was a firmware rollback against the AMD-SP that exposed attestation keys.

In May 2020, Wilke, Wichelmann, Morbitzer, and Eisenbarth published SEVurity: No Security Without Integrity at IEEE S&P [@sevurity-uzl]. Their two new methods, the project-page abstract records verbatim, "allow us to inject arbitrary code into SEV-ES secured virtual machines. Due to the lack of proper integrity protection, it is sufficient to reuse existing ciphertext to build a high-speed encryption oracle" [@sevurity-uzl]. The architectural diagnosis was now overdetermined: integrity had to enter the design, not as a side feature, but as a load-bearing rail.The same Buhren-led group escalated to physical fault injection in August 2021 with One Glitch to Rule Them All, voltage-glitching the AMD Secure Processor on Zen 1 / 2 / 3 to extract custom payloads [@one-glitch-arxiv]. The PSPReverse GitHub artefact contains the supporting tooling [@pspreverse-github]. This is the physical-fault lower bound on the AMD-SP: an adversary with the right glitcher can subvert the security processor itself. The SEV-SNP design assumes a logical adversary; physical-access adversaries remain a known residual that §8 will revisit.

Intel's parallel road: TME and MKTME

Intel's bottom-of-stack cipher engine ran on a parallel track. In December 2017, Intel published Architecture Memory Encryption Technologies Specification, document 336907 rev 1.1 [@intel-mem-enc-spec-336907], introducing Total Memory Encryption (TME). The multi-key successor, MKTME (later TME-MK), surfaced publicly through a September 7, 2018 Linux-kernel RFC by Alison Schofield archived on LWN: "Multi-Key Total Memory Encryption API (MKTME) ... allows multiple encryption domains, each having their own key. While the main use case for the feature is virtual machine isolation" [@lwn-mktme]. TME-MK is the per-keyID memory cipher that the eventual Intel TDX architecture will mount its trust-domain model on top of.

Three papers, two vendors, one architectural verdict: confidentiality without integrity is not confidentiality, and the architecture has to change. What did AMD and Intel actually build in response?

flowchart LR SME["SME (2016) -- Bulk memory cipher"] SEV["SEV (Naples, 2017) -- Per-VM AES key"] ES["SEV-ES (Feb 2017) -- + Register-state cipher"] SNP["SEV-SNP (Jan 2020) -- + Integrity rail"] SME --> SEV SEV -- "SEVered -- (EuroSec 2018)" --> ES ES -- "ICUP (CCS 2019) -- SEVurity (S&P 2020)" --> SNP

4. Generation 2: the integrity rail

January 9, 2020. AMD publishes the 20-page SEV-SNP whitepaper, sole-authored by David Kaplan, with the title Strengthening VM Isolation with Integrity Protection and More [@amd-snp-whitepaper]. Eight months later, in September 2020, Intel publishes the first public TDX whitepaper (document 343961-002US, filename tdx-whitepaper-final9-17.pdf, PDF creation date Thursday September 17, 2020) and the companion Architecture Specification doc 344425-001 dated September 1, 2020 [@intel-tdx-spec-344425]. Two vendors, two different architectural answers, one shared diagnosis: the hypervisor must be excluded from the GPA-to-HPA mapping, not just from the ciphertext.Wikipedia describes Intel TDX as "proposed by Intel in May 2021" [@wiki-tdx], but the PDF cover-page metadata extracted from both the TDX whitepaper and the Architecture Specification places the public release in September 2020. Where Wikipedia and the Intel-authored PDFs disagree, the PDFs are the primary record.

AMD SEV-SNP: four ingredients

SEV-SNP keeps the per-VM AES cipher from SEV and the register-state encryption from SEV-ES, and adds four new architectural ingredients that together close the integrity gap.

The first is the Reverse Map Table (RMP). The RMP is a system-wide per-page metadata table consulted on every nested page-table walk. Each entry binds a host physical page to the tuple (assigned ASID, expected guest physical address, VMPL, immutable bit, validated bit). If the hypervisor tries to remap a guest physical address to a different host page, the RMP entry will fail to match and the CPU raises an #NPF(rmpfault). The architecture's own description is verbatim: "SEV-SNP adds strong memory integrity protection to help prevent malicious hypervisor-based attacks like data replay, memory re-mapping, and more to create an isolated execution environment" [@amd-sev-portal]. This is the integrity rail. It is not a separate keyed MAC over memory; it is a structural binding that turns SEVered-class remappings into faults.

A system-wide AMD SEV-SNP data structure that records, for every host physical page, the guest ASID it belongs to, the guest physical address it is mapped at, the VMPL ACL, an immutable flag, and a validated flag. Every nested page-table walk consults the RMP; mismatches raise `#NPF(rmpfault)`. The RMP is the architectural answer to SEVered: the hypervisor remains in charge of nested page tables, but the RMP says what each host page is allowed to be used for [@amd-snp-whitepaper; @amd-sev-portal].

The second is the PVALIDATE instruction. A SEV-SNP guest must explicitly validate a page before it uses it for confidential storage. The hypervisor cannot fake validation; if the page has not been validated by the guest, accesses fault. This pushes the responsibility for tracking "is this page really part of my private memory" into the guest, where the hypervisor cannot lie about it.

The third is the Virtual Machine Privilege Level lattice.

A four-level privilege lattice (VMPL0 highest, VMPL3 lowest) introduced by AMD SEV-SNP. Each RMP entry includes per-VMPL access-control bits, so a single SEV-SNP guest can split itself into multiple ring-shaped partitions where a higher-VMPL component (for example, a paravisor at VMPL0) sees pages that a lower-VMPL component (the customer's kernel at VMPL2) cannot. VMPL appears as a field inside the SNP_REPORT, so a remote verifier can tell which VMPL produced a given quote [@amd-snp-whitepaper].

The fourth is the attestation report. The SNP_REPORT is an ECDSA-P384 signed blob produced by the AMD-SP, carrying fields including the launch measurement, the guest policy, the user-supplied report_data nonce, the issuing vmpl, the unique chip_id, and the tcb_version. The signing key is the Versioned Chip Endorsement Key (VCEK), derived per chip per TCB version from a long-lived endorsement key, and the certificate chain runs VCEK_cert -> ASK -> AMD root [@amd-sev-portal].

The AMD SEV-SNP attestation signing key. Derived deterministically from each chip's individual endorsement secret and the current TCB version (firmware level), so a single chip exposes one VCEK per TCB version. The certificate chain anchors back to AMD's root via the AMD Signing Key (ASK). The VCEK is what makes SEV-SNP attestation chain to silicon: the verifier checks the SNP_REPORT signature against a VCEK certificate AMD will only issue for genuine AMD-SP firmware [@amd-snp-whitepaper; @amd-sev-portal]. SEV-SNP adds strong memory integrity protection to help prevent malicious hypervisor-based attacks like data replay, memory re-mapping, and more in order to create an isolated execution environment. -- AMD SEV-SNP whitepaper, January 2020 [@amd-snp-whitepaper] sequenceDiagram autonumber participant Guest as Guest CPU access participant NPT as Nested Page Walker participant RMP as Reverse Map Table participant AES as AES engine (memory ctrl) Guest->>NPT: Resolve GVA -> GPA -> HPA NPT->>RMP: Lookup (HPA) RMP-->>NPT: ASID, expected GPA, VMPL alt RMP entry matches request NPT->>AES: Decrypt under VM key AES-->>Guest: Plaintext else Mismatch (SEVered-style remap) RMP-->>Guest: #NPF (rmpfault) end

Intel TDX: a different geometry, the same end-state

Intel reached the same architectural conclusion with a different mechanism. Rather than bake integrity into microcode plus the AMD-SP, Intel introduced a new CPU mode and a separately signed software module that runs in it. The Intel TDX overview is verbatim: "A CPU-measured Intel TDX module enables Intel TDX. This software module runs in a new CPU Secure Arbitration Mode (SEAM) as a peer virtual machine manager (VMM) ... hosted in a reserved memory space identified by the SEAM Range Register (SEAMRR)" [@intel-tdx-overview].

The ingredients are seven, not four.

A new CPU privilege state introduced by Intel TDX. Code running in SEAM is hosted in a physical-memory range identified by the SEAM Range Register (SEAMRR) that the legacy VMM cannot inspect. Only the signed Intel TDX Module runs in SEAM, and it does so as a peer VMM that mediates every interaction between the legacy hypervisor and a Trust Domain [@intel-tdx-overview].

The Intel TDX Module is the second ingredient: a CPU-measured firmware binary, loaded by the SEAMLDR at boot, that mediates every entry into and exit from a Trust Domain via SEAMCALL and SEAMRET instructions. The Intel-signed intel-tdx-module-1.5-base-spec-348549002.pdf is the canonical specification for the current generation [@intel-tdx-module-base-348549].

The third is the Trust Domain, a VM-shaped container that carries a Shared Bit in the guest physical address. A clear shared bit means the page is private; a set shared bit means the page is deliberately shared with the hypervisor for I/O bounce buffers. The fourth is TME-MK memory encryption, derived from the December 2017 TME spec [@intel-mem-enc-spec-336907] and the September 2018 MKTME Linux-kernel RFC [@lwn-mktme]: AES-128 in XTS mode, with the keyID embedded in the upper physical-address bits, gives one key per Trust Domain.

The fifth ingredient is the structural analogue of AMD's RMP, the Physical-Address-Metadata table (PAMT). The Intel TDX overview enumerates the architectural elements precisely: "Intel TDX uses architectural elements such as SEAM, a shared bit in Guest Physical Address (GPA), secure Extended Page Table (EPT), physical-address-metadata table, Intel Total Memory Encryption -- Multi-Key (Intel TME-MK), and remote attestation" [@intel-tdx-overview].

The sixth ingredient is the measurement registers. The MRTD is the build-time measurement of the initial TD image, similar to a TPM PCR fixed at launch. RTMR0 through RTMR3 are the runtime measurement registers, four PCR-equivalents the TDX Module exposes for runtime measured-boot extensions. These four registers are what a TDX-aware Trusted Boot chain extends.

The build-time and runtime measurement registers exposed by an Intel TDX Trust Domain. MRTD is hashed by the TDX Module over the initial TD launch image and is the SEAM analogue of an immutable launch PCR. RTMR0-3 are four extendable runtime registers, the SEAM analogue of the runtime-extension TPM PCRs (the same conceptual role as PCRs 8-15 in the canonical static-OS measurement chain), that hold a measured-boot chain of subsequent components (loaders, kernel, initrd, paravisor pages). The canonical TDX-vTPM event-log convention used by Linux IMA and systemd-stub maps RTMR[0] to PCR[1, 7]; RTMR[1] to PCR[2-6]; RTMR[2] to PCR[8-9]; and RTMR[3] to PCR[14, 17-22]. A TD Quote carries all five values; a verifier evaluates them against a customer-defined policy [@intel-tdx-overview; @intel-tdx-spec-344425].

The seventh is the TD Quote. A TD Quote is produced in two stages. The TD guest first issues TDCALL[TDG.MR.REPORT], which lands in the TDX Module (the VMM-to-Module entry is the separate SEAMCALL interface defined in the comparison table below); the TDX Module returns an in-SEAM SEAMREPORT structure, a Report MAC-signed with a key bound to the platform. A host-side SGX Quoting Enclave then converts that Report into a Quote signed with the SGX-resident QE attestation key. The Quote carries MRTD, RTMR0-3, the TD's TCB SVN (a per-component firmware version vector), and a caller nonce. The Intel Trust Authority (or Microsoft Azure Attestation, or Google's verifier) checks the quote [@intel-tdx-overview; @intel-tdx-module-base-348549].

flowchart TB HW["Silicon: TME-MK + SEAMRR -- + Secure EPT + PAMT"] SEAM["Intel TDX Module -- (SEAM mode)"] VMM["Legacy VMM -- (Hyper-V / KVM)"] TD1["Trust Domain 1"] TD2["Trust Domain 2"] HW --> SEAM HW --> VMM VMM -- "SEAMCALL" --> SEAM SEAM -- "SEAMRET" --> VMM SEAM -- "TDENTER / TDEXIT" --> TD1 SEAM -- "TDENTER / TDEXIT" --> TD2

Side by side

The two architectures answer the same question and arrive at the same end-state contract through fundamentally different trust geometries.

Ingredient	AMD SEV-SNP	Intel TDX
Memory cipher	AES-128, per-VM key in memory controller	AES-128-XTS, per-TD key by keyID (TME-MK)
Integrity binding	Reverse Map Table per host page	Physical-Address-Metadata table + Secure EPT
Mediating component	AMD-SP firmware (microcode + on-die security processor)	Signed Intel TDX Module in SEAM mode
Privilege lattice	VMPL0-VMPL3 (four levels)	TD Partitioning L1/L2 (TDX Module 1.5)
Build-time measurement	Launch measurement in SNP_REPORT	MRTD inside the TDX Module
Runtime measurement	None at module level (vTPM provides it)	RTMR0-RTMR3 inside the TDX Module
Attestation signing key	VCEK (ECDSA-P384), per chip per TCB version	SGX-resident Quoting Enclave key
Certificate chain	VCEK -> ASK -> AMD root	Quoting Enclave -> Intel root
Page-validation primitive	`PVALIDATE` (guest-driven)	TDX Module-mediated page acceptance
Shared-page indicator	C-bit (clear = shared, set = encrypted)	Shared bit in GPA (set = shared)
Hypervisor-to-trust-component call	Mediated VMRUN	`SEAMCALL` / `SEAMRET`

{` // Pseudo-code sketch of how a SEV-SNP guest assembles an SNP_REPORT // via SNP_GUEST_REQUEST. Not runnable against silicon; the point is // the shape of the evidence the verifier receives.

function buildSnpReport(nonce32) { // Guest builds a request structure with a 32-byte user nonce. const request = { reportData: nonce32, vmpl: 0 };

// Hypercall lands in the AMD-SP, which signs with the VCEK. const report = sp_guest_request(request);

return { version: report.version, // structure version guestSvn: report.guestSvn, // guest firmware SVN policy: report.policy, // SEV policy bits at launch familyId: report.familyId, // 16-byte ID set by launch measurement: report.measurement, // 48-byte launch measurement reportData: report.reportData, // echoes user nonce vmpl: report.vmpl, // VMPL of issuing component chipId: report.chipId, // 64-byte unique chip ID tcbVersion: report.tcbVersion, // boot loader / TEE / SNP / microcode SVNs signature: report.signature, // ECDSA P-384 over the report }; }

// The verifier walks the certificate chain VCEK -> ASK -> AMD root, // re-checks the signature, and then evaluates policy on the claims. console.log(JSON.stringify(buildSnpReport('nonce_from_relying_party'), null, 2)); `}

Key idea: SEV-SNP and TDX answer the same question differently. AMD bakes integrity into microcode plus the AMD-SP, signs with a per-chip per-TCB VCEK, and exposes a four-level VMPL lattice. Intel puts integrity into a separately loaded, separately signed software module running in a new CPU mode, signs with an SGX-resident Quoting Enclave, and exposes L1/L2 partitioning. The trust roots, the breaking surfaces, and the supply chains are different even when the end-state contract is the same.

flowchart LR subgraph AMD["AMD SEV-SNP"] A1["AMD-SP firmware"] A2["Reverse Map Table"] A3["VMPL0-3 lattice"] A4["SNP_REPORT -- VCEK signed"] end subgraph INTEL["Intel TDX"] I1["Signed TDX Module"] I2["PAMT + Secure EPT"] I3["L1 / L2 partitioning"] I4["TD Quote -- Quoting Enclave"] end A1 --- I1 A2 --- I2 A3 --- I3 A4 --- I4

Generation 2 makes a confidential VM architecturally possible. But a SEV-SNP guest is not yet a Windows Server VM you can lift and shift onto Azure -- there is a whole productisation problem still to solve. How does Microsoft put a paravisor inside that trust boundary, and what does it deliver?

5. The contract: a cloud-shaped TEE

A confidential VM is two rails, not one. Rail 1 is confidentiality plus integrity of memory and CPU state. Rail 2 is measurement plus attestation. SEV-SNP and TDX each deliver both rails. Anyone who has read the equivalent Secure Boot / Trusted Boot story will recognise the shape: a measurement chain anchored in silicon, terminated in a remote verifier, with a signed result that a relying party can act on.

The Confidential Computing Consortium's framing, repeated here as a contract the architectures actually realise: "Confidential Computing protects data in use by performing computation in a hardware-based, attested Trusted Execution Environment" [@ccc-about]. Hardware-based is rail 1. Attested is rail 2. The two words together are why a TPM-only system, however well-measured, is not a CVM, and why a SEV-only system, however well-encrypted, is not a CVM either.

RFC 9334 names the actors. The attester is the guest plus the paravisor producing evidence. The evidence is the SNP_REPORT or TD Quote, plus optionally a vTPM quote chained to it. The verifier is the entity that checks the evidence against a policy and emits an attestation result. The relying party is the consumer who acts on the result -- typically a key vault releasing a wrapped secret [@rfc9334].

The IETF Remote ATtestation procedureS working group's RFC 9334 (January 2023) fixes the vocabulary the rest of the confidential-computing industry uses: an *attester* produces *evidence*; a *verifier* checks it against reference values from an *endorser* and a *reference value provider* and emits an *attestation result*; a *relying party* acts on the result. RFC 9334 §5 names two topologies. In the *Passport* model (§5.1), the attester sends evidence directly to the verifier, collects a signed result, and presents that result to the relying party. In the *Background-Check* model (§5.2), the attester sends evidence to the relying party, which forwards it to the verifier and receives the result on the attester's behalf. Microsoft Azure Attestation, Intel Trust Authority, Google's verifier, and AWS KMS attestation all implement variants of this model [@rfc9334].

Microsoft Azure Attestation implements the Passport model. The attester -- the CVM, through its in-guest agent -- sends evidence (an SNP_REPORT or TD Quote, plus a vTPM quote) directly to MAA. MAA validates the evidence against the customer-authored policy and returns a signed JWT. The attester then presents that JWT to the relying party. Azure Key Vault authorises Secure Key Release against the MAA-issued claim set, not against raw SNP evidence. The relying party never sees the SNP_REPORT and never calls MAA on the attester's behalf, which is the design signature of Passport rather than Background-Check [@rfc9334; @msdocs-maa-overview].

flowchart LR Rail1["Rail 1 -- Confidentiality + Integrity"] --> Mem["Encrypted DRAM -- + RMP / PAMT -- + encrypted register state"] Rail2["Rail 2 -- Measurement + Attestation"] --> Ev["Evidence: -- SNP_REPORT / TD Quote -- + vTPM quote"] Ev --> Ver["Verifier: -- MAA / Intel Trust Authority"] Ver --> Tok["Attestation Result -- (signed JWT)"] Tok --> RP["Relying Party -- (Azure Key Vault)"] RP --> Secret["Wrapped secret release"]

Key idea: A Confidential VM is not a memory-encryption product. It is a contract: confidentiality with integrity, plus an evidence-bearing attestation chain that a relying party can verify before it releases a secret. Anyone who sells you "confidential" infrastructure without rail 2 is selling you half the product.

If this is the contract, how does Azure actually build a usable Windows-guest CVM on top of it? What lives where, and who signs what?

6. State of the art on Azure: from silicon to MAA

July 20, 2022. Microsoft Azure announces general availability of the DCasv5 and ECasv5 confidential VM SKUs on AMD third-generation EPYC silicon. The Register's coverage captures the framing: "Microsoft is expanding its Azure confidential computing portfolio with virtual machines that use the encryption and memory protection features of AMD's third-gen Epyc processors. ... Customers using them can also use the free Microsoft Azure Attestation (MAA) service to remotely verify the operating environment and integrity of the software binaries running on it" [@theregister-azure-cvm]. That is the moment a confidential VM stops being a research paper and starts being a product the customer can pay for by the hour.

This section walks the Azure stack bottom-up. It is the longest section because it is the article's reason to exist.

The Azure CVM SKU family

Microsoft Learn's confidential-computing products page enumerates the current Azure CVM SKU map. On AMD SEV-SNP: "DCasv5 and ECasv5 enable rehosting of existing workloads" [@msdocs-overview-products]. These are the third-generation EPYC Milan SKUs that went GA in July 2022. The Learn page continues: "DCasv6 and ECasv6 confidential VMs based on fourth-generation AMD EPYC processors are currently in gated preview" [@msdocs-overview-products]. Lenovo Press corroborates that "SEV-SNP is supported on AMD EPYC processors starting with the AMD EPYC 7003 series processors" -- i.e., Milan -- with the third-generation 7003 series being the first SEV-SNP silicon [@lenovo-lp1893].

On Intel TDX: "DCesv5 and ECesv5" are the fourth-generation Xeon Sapphire Rapids SKUs, generally available. SecurityWeek's coverage anchors the Sapphire Rapids launch: "Intel announced on Tuesday that it has added Intel Trust Domain Extensions (TDX) to its confidential computing portfolio with the launch of its new 4th Gen Xeon enterprise processors. ... The feature will be available through cloud providers such as Microsoft, Google, IBM and Alibaba" [@securityweek-tdx]. Wikipedia notes that "TDX is available for 5th generation Intel Xeon processors (codename Emerald Rapids) and Edge Enhanced Compute variants of 4th generation Xeon processors (codename Sapphire Rapids)" [@wiki-tdx]. The fifth-generation Emerald Rapids SKUs DCesv6 and ECesv6 are in preview at the time of writing, per the Learn products page [@msdocs-overview-products].

GPU CVMs anchor on the same CPU-side TEEs and add a GPU TEE. The Learn page describes the NCCadsH100v5 SKU: "NCCadsH100v5 confidential VMs come with a GPU ... use linked CPU and GPU Trusted Execution Environments (TEEs)" [@msdocs-overview-products]. This is the linked-attestation product for confidential AI -- a SEV-SNP host CVM bound by attestation to an NVIDIA H100 in Confidential Compute mode.March 30, 2026 brings a pricing change customers should plan for. Microsoft Learn states: "From March 30 2026, encrypted OS disks will incur higher costs" [@msdocs-azure-cvm]. Confidential OS-disk encryption remains the recommended configuration where the workload requires it; the change is to the billing line, not to the architecture.

The paravisor: OpenHCL on OpenVMM

The single most important productisation move Azure made is what Microsoft calls a paravisor. The framing from the October 17, 2024 Tech Community announcement is verbatim: "Microsoft developed the first paravisor in the industry, and for years, we have been enhancing the paravisor offered to Azure customers. This effort now culminates in the release of a new, open source paravisor, called OpenHCL" [@openhcl-blog].

A thin operating system running inside the trust boundary of a confidential VM, between the host hypervisor and the customer guest. The paravisor exposes the synthetic devices, the vTPM, and the GPA partitioning that a Windows or Linux guest expects from a Hyper-V environment -- without trusting any of those services to the host below the trust boundary. The paravisor is itself part of the TCB, but on Azure the paravisor binary is open source [@openhcl-blog; @openvmm-repo]. Microsoft's open-source paravisor, released on October 17, 2024. OpenHCL is built on top of OpenVMM, "a modular, cross-platform Virtual Machine Monitor (VMM), written in Rust" [@openvmm-repo]. On Azure SEV-SNP CVMs OpenHCL runs at VMPL0; on TDX CVMs it runs in the L1 partition seat under TD Partitioning [@openhcl-blog; @openvmm-dev]. It mediates virtual devices, brokers the vTPM, manages GPA partitioning between private and shared pages, and handles diagnostics, all inside the trust boundary. Microsoft developed the first paravisor in the industry, and for years, we have been enhancing the paravisor offered to Azure customers. This effort now culminates in the release of a new, open source paravisor, called OpenHCL. -- Microsoft Tech Community, OpenHCL announcement, October 17, 2024 [@openhcl-blog]

The OpenVMM repository README puts the focus crisply: "OpenVMM is a modular, cross-platform Virtual Machine Monitor (VMM), written in Rust. Although it can function as a traditional VMM, OpenVMM's development is currently focused on its role in the OpenHCL paravisor" [@openvmm-repo]. The OpenVMM Guide lists the virtualisation APIs OpenVMM supports, including "MSHV (using VSM / TDX / SEV-SNP)" for paravisor mode, WHP for a Windows host, and KVM for a Linux host [@openvmm-dev]. The use cases listed include Azure Boost, Trusted Launch, and Confidential VMs.

Because OpenHCL is in the TCB, customers do not avoid trusting Microsoft by running it -- but they can now read the source. That is a categorical change from earlier closed paravisors. The point about a TCB is not its size but its auditability and reviewability.

The canonical Linux-side analogue is AMD's Secure VM Service Module (SVSM), which runs at VMPL0 inside an SEV-SNP guest and provides the same kind of in-trust-boundary services (virtual TPM, paravirtualised I/O brokering, attestation surface) that OpenHCL provides on Azure [@amd-svsm]. SVSM and OpenHCL solve the same problem with different implementations and different signing chains. The Linux community's reference SVSM is the COCONUT-SVSM open-source project [@coconut-svsm]. A reader who needs a confidential-VM paravisor on a non-Azure Linux host should look at SVSM; a reader who needs it on Azure gets OpenHCL.

The vTPM

Inside the paravisor's protected memory, OpenHCL synthesises a per-VM virtual TPM. Microsoft Learn is verbatim: "Azure confidential VMs feature a virtual TPM (vTPM) for Azure VMs. ... Confidential VMs have their own dedicated vTPM instance, which runs in a secure environment outside the reach of any VM" [@msdocs-azure-cvm]. The architectural significance of this single sentence cannot be overstated. The vTPM's endorsement key is bound at provision time to the SEV-SNP or TDX hardware attestation report, so a vTPM quote can be transitively chained back to silicon: vTPM quote -> EK certificate -> SNP_REPORT or TD Quote -> VCEK or Intel signing root [@msdocs-azure-cvm].

The practical consequence is that a Windows Server CVM runs an unmodified Trusted Boot chain inside the guest. PCR-7 still indexes the Secure Boot signer. Code Integrity policies still extend their own PCRs. BitLocker still seals the Volume Master Key to the TPM. None of those operating-system features need to know that the TPM they are talking to is synthesised by OpenHCL inside an SEV-SNP guest -- and yet every one of those features is now anchored, transitively, to AMD or Intel silicon rather than to a discrete TPM chip on a motherboard the cloud customer cannot inspect.

Microsoft Azure Attestation

The verifier in Azure's confidential-computing stack is Microsoft Azure Attestation. The Learn overview describes it: "Microsoft Azure Attestation is a unified solution for remotely verifying the trustworthiness of a platform and integrity of the binaries running inside it. The service supports attestation of the platforms backed by Trusted Platform Modules (TPMs) alongside the ability to attest to the state of Trusted Execution Environments (TEEs) such as Intel Software Guard Extensions (SGX) enclaves, Virtualization-based Security (VBS) enclaves ... and Azure confidential VMs" [@msdocs-maa-overview].

Azure's unified verifier service for confidential platforms. MAA accepts evidence -- an SNP_REPORT or TD Quote, plus a vTPM quote, plus boot measurements -- evaluates it against a customer-defined attestation policy, and returns a signed JWT carrying the issued claims. MAA's role in the RATS architecture is the *verifier*, in *Passport* topology: the attester collects MAA's signed result and presents it to the relying party (Azure Key Vault) [@msdocs-maa-overview; @rfc9334].

The SKR loop is documented verbatim. "When a CVM boots up, SNP report containing the guest VM firmware measurements are sent to Azure Attestation. The service validates the measurements and issues an attestation token that is used to release keys from Managed-HSM or Azure Key Vault. These keys are used to decrypt the vTPM state of the guest VM, unlock the OS disk and start the CVM" [@msdocs-maa-overview].

The Azure Key Vault / Managed HSM operation that releases a wrapped key only after the requesting party presents a valid Microsoft Azure Attestation token that satisfies the key's release policy. SKR is what closes the loop between rail 1 (memory protection) and rail 2 (attestation) at the customer's perimeter: a key never leaves the HSM unless the attesting CVM has been verified [@msdocs-maa-overview; @msdocs-azure-cvm].

MAA policy v1.2

The policy language is the operational surface customers actually interact with. The MAA policy v1.2 grammar has four segments, verbatim from the Microsoft Learn page: "Policy version 1.2 has four segments: version, configurationrules, authorizationrules, issuancerules" [@maa-policy-v12]. The critical operational distinction is between the last two. Authorization rules can fail attestation; issuance rules cannot. The docs are explicit: "authorizationrules: ... These rules can be used to fail attestation. issuancerules: ... These rules can be used to add to the outgoing claim set and the response token. These rules can't be used to fail attestation" [@maa-policy-v12].

Note: The most common bug in hand-authored MAA policies is writing a security gate as an issuance rule. If you want a missing SecureBoot value to reject the attestation, the predicate must live in authorizationrules. Putting it in issuancerules only adds a claim to the resulting JWT; the relying party then has to enforce the gate. The verifier will mint the token either way [@maa-policy-v12].

The configuration-rule defaults give you sane behaviour out of the box: require_valid_aik_cert defaults to true and required_pcr_mask defaults to 0xFFFFFF (the first twenty-four PCRs must appear in the quote) [@maa-policy-v12].

Claim extraction uses JmesPath. The Learn page reproduces a Secure Boot detection rule that the verifier can use to flip a secureBootEnabled claim:

{` // Verbatim from Microsoft Learn (MAA policy v1.2 Secure Boot detection). // This is JS-style pseudo-code that walks the rule structure, not // runnable MAA syntax.

const policyRule = { segment: 'issuancerules', // "Claim rules" use JmesPath queries against parsed event data. step1: { when: 'type == "events" && issuer == "AttestationService"', add: 'efiConfigVariables', via: "Events[?EventTypeString == 'EV_EFI_VARIABLE_DRIVER_CONFIG' " + "&& ProcessedData.VariableGuid == '8BE4DF61-93CA-11D2-AA0D-00E098032B8C']" }, // GUID 8BE4DF61-93CA-11D2-AA0D-00E098032B8C is the EFI Global Variable // namespace, which is where 'SecureBoot' lives. step2: { issue: 'secureBootEnabled', via: "[?ProcessedData.UnicodeName == 'SecureBoot'] " + "| length(@) == 1 && @[0].ProcessedData.VariableData == 'AQ'" }, // 'AQ' is base64('\x01'), i.e. SecureBoot==1. fallback: { issue: 'secureBootEnabled', value: false } };

console.log('Segment :', policyRule.segment); // issuancerules console.log('Yields :', 'secureBootEnabled claim in JWT'); console.log('Lesson :', 'Add this to authorizationrules to actually fail!'); `}

sequenceDiagram participant E as Evidence (SNP_REPORT + vTPM) participant C as configurationrules participant A as authorizationrules participant I as issuancerules participant J as Signed JWT E->>C: parse + defaults -- (require_valid_aik_cert, PCR mask) C->>A: typed claim set A-->>A: predicate checks alt All authorization rules pass A->>I: continue I->>J: mint claims (secureBootEnabled, x-ms-isolation-tee, ...) J-->>E: signed attestation token else Any authorization rule fails A-->>E: attestation rejected end

The two-axis privilege model: VMPL crossed with VTL

A common misconception is that a SEV-SNP CVM makes Virtualization-Based Security inside the guest redundant. The argument goes: "the whole VM is in a TEE, so why do I still need a Secure Kernel?" The architecture answers the question by saying that VMPL and VTL are orthogonal axes.

The VMPL axis is cloud-operator threat model. VMPL0 (the OpenHCL paravisor) sees pages that the customer's kernel at VMPL2 does not, and the host hypervisor below VMPL0 sees none of the encrypted memory at all. VMPL keeps the operator out.

The VTL axis is intra-guest threat model. Inside the guest, VTL1 hosts the Secure Kernel, IUM (Isolated User Mode) trustlets like LSAIso for Credential Guard, and the HVCI code-integrity verifier. VTL0 hosts the normal Windows kernel and user mode. VTL keeps a kernel-mode attacker out of LSA secrets and credential blobs. Without VTL, the customer's own kernel can read its own LSAIso heap; without VMPL, the hypervisor can read the customer's RAM.

VBS-inside-CVM is therefore not a duplication. It closes two different attack classes.

flowchart TB subgraph Host["Host below trust boundary"] H["Hyper-V host kernel -- (no access to encrypted RAM)"] end subgraph Boundary["Inside SEV-SNP / TDX trust boundary"] subgraph V0["VMPL0 / L1 TD partition"] P["OpenHCL paravisor -- (synthetic devices, vTPM)"] end subgraph V2["VMPL2 / L2 TD partition (customer guest)"] subgraph T1["VTL1 (Secure Kernel)"] SK["Secure Kernel -- + IUM trustlets: -- LSAIso, Credential Guard"] end subgraph T0["VTL0 (normal OS)"] W["Windows Server kernel -- + user mode"] end end end H -. "blocked by VMPL + -- RMP / PAMT" .-> P W -. "blocked by VTL 1 -- VBS / HVCI" .-> SK P --> V2

Confidential Containers: three Azure surfaces

Confidential VMs are not the only Azure surface where SEV-SNP attestation can land. There are three more.

Confidential Containers on Azure Container Instances (ACI), GA. Microsoft Learn: "Confidential containers on Azure Container Instances are deployed in a container group with a Hyper-V isolated TEE, which includes a memory encryption key generated and managed by an AMD SEV-SNP capable processor" [@msdocs-aci-confidential]. ACI Confidential Containers use confidential computing enforcement (CCE) policies generated by the confcom Azure CLI extension, and they expose SNP attestation reports for the SKR sidecar pattern.

Confidential Containers on AKS, preview, sunsetting. The Learn AKS page is explicit: "The Confidential Containers preview is set to sunset in March 2026. After this date, customers with existing Confidential Container node pools should expect to see reduced functionality, and you won't be able to spin up any new nodes with the KataCcIsolation runtime" [@msdocs-aks-confidential-containers]. Microsoft routes customers to four alternatives: Confidential VM AKS node pools, ACI Confidential Containers, ARO Confidential Containers, and the upstream Confidential Containers project [@msdocs-aks-confidential-containers].

Confidential VM AKS worker nodes, GA. A different model -- node-granularity CVM rather than per-pod CVM. Learn: "AKS now supports confidential VM node pools with Azure confidential VMs. These confidential VMs are the generally available DCasv5 and ECasv5 confidential VM-series using 3rd Gen AMD EPYC processors with Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) security features" [@msdocs-aks-cvm-nodes]. This is a lift-and-shift path for existing AKS workloads.

Confidential Containers on ARO is the Red Hat OpenShift equivalent, with Kata-isolated per-container SEV-SNP enforcement.

The cross-cloud parallel is the CNCF Confidential Containers project, accepted to CNCF on March 8, 2022 at the Sandbox maturity level [@cncf-coco]. The project documentation describes it as "an open source project that brings confidential computing to Cloud Native environments, using hardware technology to protect complex workloads" [@coco-docs]. Trustee is the canonical attestation broker on the CNCF side. CoCo's substrate is Kata Containers' MicroVM model; the TEE backing is currently Linux-only. The open-source community floor under all of this includes Edgeless's Constellation (historically the canonical confidential-Kubernetes distribution; the upstream repo was archived in 2025-2026 and Edgeless's successor project Contrast [@contrast] now carries the work forward at the workload-confidential-container layer rather than the whole-cluster layer) [@constellation], COCONUT-SVSM (the AMD-side reference SVSM running at VMPL0) [@coconut-svsm], and the CoCo Trustee attestation broker.

NVIDIA H100 CC on NCCadsH100v5

The Azure NCCadsH100v5 SKU pairs an SEV-SNP CVM with an NVIDIA H100 in Confidential Compute mode and links the two attestations together. CPU-side rail 1 is SEV-SNP. GPU-side rail 1 is H100 CC. Rail 2 must compose both: the relying party only releases the workload's key if both attestations check out. Cross-vendor attestation composition is one of the open standards problems §9 will revisit.

flowchart TB subgraph S["Silicon"] AMD["AMD-SP firmware -- + SEV-SNP RMP"] INTEL["Intel TDX Module -- (SEAM, SEAMRR)"] end subgraph H["Host"] HV["Azure Hyper-V -- (below trust boundary)"] end subgraph P["Paravisor (in TCB)"] OH["OpenHCL on OpenVMM -- VMPL0 / L1 TD seat"] VT["vTPM synthesised -- by paravisor"] end subgraph G["Customer guest"] WS["Windows Server CVM -- (VTL0 + VTL1, VBS / HVCI)"] end subgraph V["Verifier"] MAA["Microsoft Azure Attestation -- (policy v1.2)"] end subgraph R["Relying party"] AKV["Azure Key Vault / -- Managed HSM (SKR)"] APP["Customer application"] end AMD --> HV INTEL --> HV HV --> OH OH --> VT OH --> WS WS -- "SNP_REPORT -- or TD Quote -- + vTPM quote" --> MAA MAA -- "Signed JWT" --> AKV AKV --> APP

That is the Azure stack. But Azure is not the only design point -- Google and AWS chose different glue, and one of them is on a fundamentally different threat model. How do they compare?

7. Competing approaches

Three competitors share the design space with very different choices. Two are near-peers to Azure; one is a fundamentally different model that customers routinely confuse for the same product.

Google Cloud Confidential VMs

Google Cloud supports the same two CPU TEEs. The GCP Confidential VM docs are explicit: "AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) expands on SEV, adding hardware-based security to help prevent malicious hypervisor-based attacks like data replay and memory remapping. Attestation reports can be requested at any time directly from the AMD Secure Processor" [@gcp-cvm-overview]. And on the Intel side: "Intel Trust Domain Extensions (TDX) creates an isolated trust domain (TD) within a VM, and uses hardware extensions for managing and encrypting memory" [@gcp-cvm-overview].

GCP's machine-type mapping is direct. AMD SEV / SEV-SNP runs on N2D and C3D; Intel TDX runs on C3 Confidential VMs. The Confidential Computing product hub lists "Confidential VMs on the C3 machine series brings hardware-level protection to your AI models and data" and "Confidential VMs on the accelerator-optimized A3 machine series with NVIDIA H100 GPUs" as the parallel GPU-CC product [@gcp-confidential-overview]. There is a Confidential Space product on top for multi-party analytics, plus Confidential GKE Nodes and Confidential Dataflow.

The verifier-of-record is Google's own attestation service, with the guest's vTPM as the default trust root. Intel Trust Authority is supported as a plug-in alternative for TDX evidence.

The GCP Confidential VM docs make a claim Azure does not match: "AMD SEV machines that use the N2D and C3D machine types support live migration" [@gcp-cvm-overview]. Live migration of a confidential VM is genuinely hard: the encrypted state has to be re-keyed under the destination host's per-VM key, and the integrity-rail structures (RMP entries) have to be coherently re-established without ever exposing the plaintext to either host. AMD's SEV migration helper is the underlying mechanism. Azure does not currently expose live migration on its confidential VM SKUs. This is the most operationally consequential cross-cloud difference today.

A small correction to a widely repeated framing. It is sometimes said that GCP's confidential offerings are "also SEV-SNP" -- the Stage 0 input to this article said exactly that. Per the GCP docs, GCP supports both SEV-SNP and TDX [@gcp-cvm-overview]. If you are picking a CVM cloud for a multi-vendor strategy, treat GCP as a near-peer to Azure on the CPU dimension and differentiate on the verifier, the SKU mapping, and the live-migration story instead.

AWS Nitro Enclaves: a genuinely different model

The most common confusion in this design space is the assumption that AWS Nitro Enclaves is "AWS's confidential VM product." It is not. It is a different model on a different threat boundary.

The Nitro Enclaves user guide is unambiguous about the threat model. "AWS Nitro Enclaves is an Amazon EC2 feature that allows you to create isolated execution environments ... Enclaves are separate, hardened, and highly-constrained virtual machines. They provide only secure local socket connectivity with their parent instance. They have no persistent storage, interactive access, or external networking" [@aws-nitro-enclaves]. The same page continues: "Nitro Enclaves is processor agnostic and it is supported on most Intel, AMD, and AWS Graviton-based Amazon EC2 instance types built on the AWS Nitro System" [@aws-nitro-enclaves]. And: "Nitro Enclaves use the same Nitro Hypervisor technology that provides CPU and memory isolation for Amazon EC2 instances" [@aws-nitro-enclaves].

Three differences matter.

First, there is no CPU memory cipher. Isolation is enforced by the Nitro hypervisor on a dedicated Nitro System card, not by SEV-SNP or TDX. Memory is in the clear in DRAM, just architecturally walled off by the hypervisor and the hardware root of trust below it.

Second, attestation signs through the Nitro hypervisor and integrates with AWS KMS. There is no VCEK or TDX Quoting Enclave.

Third, the threat model is parent-instance and co-tenant isolation, not cloud-operator isolation. Amazon is in the TCB by design. A subpoena or a compromised AWS operator are within the threat model of Azure / GCP CVMs and outside the threat model of Nitro Enclaves.

Note: If your threat model includes a malicious or compelled cloud operator, AWS Nitro Enclaves does not protect you. The Nitro hypervisor enforces the enclave boundary; it is software AWS owns and operates. Use Nitro Enclaves for what it is good at -- a hardened compartment for key material against your own parent instance and your own application bugs. Use SEV-SNP / TDX on Azure or GCP if you need cryptographic protection against the operator's hypervisor [@aws-nitro-enclaves].

Nitro Enclaves still has a role: it is excellent at isolating a long-lived signing service from a more loosely audited application instance, and four enclaves per parent EC2 host is a generous concurrency budget for that pattern.

Confidential Containers and NVIDIA H100 CC

The Confidential Containers project crosses cloud boundaries. CNCF accepted it in March 2022 [@cncf-coco]. The project docs describe it as "an open source project that brings confidential computing to Cloud Native environments, using hardware technology to protect complex workloads" [@coco-docs]. The Azure surfaces (ACI, AKS, ARO) were covered in §6; the equivalent on AWS is the Kata Containers + Confidential Containers combination on top of bare-metal Nitro hosts, and on GCP it lands on Confidential GKE Nodes.

The NVIDIA H100 CC story is roughly cross-cloud parity. Azure NCCadsH100v5 pairs SEV-SNP with H100 CC; Google's A3 series pairs SEV-SNP and TDX with H100 CC. Cross-vendor attestation composition is the open standards problem on which the relying party experience still depends. On the silicon side, ARM's Confidential Compute Architecture (CCA, with Area Management Extension) is the ARM-side analogue of SEV-SNP/TDX, and Apple's Secure Enclave Processor is a board-scoped TEE with a different form factor; both are adjacent VM-scoped or board-scoped TEE designs but out of scope for the cloud-CVM body of this article.

The head-to-head matrix

Dimension	Azure CVM	GCP CVM	AWS Nitro Enclaves	Confidential Containers
CPU TEE	SEV-SNP, Intel TDX	SEV / SEV-SNP, Intel TDX	None (Nitro hypervisor)	SEV-SNP, TDX (varies by host)
Memory cipher	AES (per-VM, per-TD)	AES (per-VM, per-TD)	None (host RAM)	Inherited from host TEE
Integrity rail	RMP (AMD), PAMT (Intel)	RMP, PAMT	Nitro hypervisor isolation	Inherited from host TEE
Attestation evidence	SNP_REPORT, TD Quote, vTPM quote	SNP_REPORT, TD Quote, vTPM	Nitro attestation document	TEE evidence + container measurement
Verifier	Microsoft Azure Attestation	Google attestation, Intel Trust Authority	AWS KMS	Trustee (CNCF)
Operator threat model	Yes (operator excluded)	Yes (operator excluded)	No (Nitro in TCB)	Yes (operator excluded)
Lift-and-shift Windows	Yes	Yes	No (custom enclave format)	Linux containers only
Live migration of CVM	No	Yes (SEV on N2D / C3D)	N/A	No
2024-era CVE exposure	CacheWarp, WeSee, Heckler (SEV-SNP); Heckler (TDX)	Same upstream CVEs	Distinct (Nitro hypervisor)	Inherited from host TEE
Granularity	Whole VM, container	Whole VM	Per enclave (up to 4 per host)	Per pod / per container

flowchart LR Nitro["AWS Nitro Enclaves -- (parent-instance threat model)"] Azure["Azure / GCP CVMs -- (cloud-operator threat model, -- whole VM)"] CoCo["Confidential Containers -- (per pod / per container)"] H100["NVIDIA H100 CC -- (CPU + GPU linked TEE)"] Nitro --- Azure Azure --- CoCo CoCo --- H100

If the contract is settled and the products ship, what is still wrong with this picture? Why do four published papers in 2024 demonstrate extracting secrets from a fully-patched SEV-SNP CVM?

8. Theoretical limits and the 2024 attack class

May 2, 2024. ETH Zurich's ZISC group publishes the Ahoi family of attacks. The lab's announcement is brisk: "Researchers from the SECTRS group have now discovered a new class of attacks, dubbed Ahoi attacks, that exploit vulnerabilities in the notification framework in Intel TDX and AMD SEV-SNP. ... the vulnerabilities are tracked under 2 CVEs: CVE-2024-25744, CVE-2024-25743" [@eth-ahoi-news] (with CVE-2024-25742 covering WeSee). WeSee won the Distinguished Paper Award at IEEE S&P 2024 [@ahoi-wesee]. Heckler appeared at USENIX Security 2024 [@heckler-usenix]. CISPA's CacheWarp, also at USENIX Security 2024, cross-cut both [@cachewarp-usenix].

Four 2024-era papers attacking shipping confidential VMs, and a key observation: none of them broke the Generation-2 integrity rail itself. They all exploit seams around it.

Trusted Computing Base accounting

The irreducible silicon-vendor trust root is non-zero by design. On SEV-SNP the customer must trust AMD-SP firmware and the ECDSA-P384 VCEK chain rooted at AMD. On TDX the customer must trust the signed TDX Module binary and the SGX-resident Quoting Enclave's signing root rooted at Intel. On Azure the customer additionally trusts Microsoft's signed OpenHCL binary -- with the consolation that OpenHCL is open source and reviewable [@openhcl-blog; @openvmm-repo]. The verifier (MAA, Intel Trust Authority, Google's verifier) is a separate trust component the relying party must extend.

The set of hardware, firmware, and software components whose correct operation is necessary for a system to enforce its security properties. For an Azure SEV-SNP CVM the TCB is the AMD silicon, the AMD-SP firmware, the OpenHCL paravisor binary, and Microsoft Azure Attestation acting as the verifier. The TCB cannot be empty; the goal is to make it small, auditable, and named [@amd-snp-whitepaper; @openhcl-blog].

The lower bound on TCB is at least one signing root the customer cannot independently rebuild from public artefacts. Reproducible-build transparency over the AMD-SP firmware and the Intel TDX Module is one of the open standards problems on the 2026 frontier. The Google-Intel joint TDX security review from April 2023 is the best public substitute for a reproducible build of the TDX Module today [@gcp-tdx-review].

The 2024 attack class, in order of architectural depth

CacheWarp (USENIX Security 2024; CVE-2023-20592; AMD-SB-3005). A software fault injection. The mechanism, in NVD's verbatim language: "Improper or unexpected behavior of the INVD instruction in some AMD CPUs may allow an attacker with a malicious hypervisor to affect cache line write-back behavior of the CPU leading to a potential loss of guest virtual machine (VM) memory integrity" [@nvd-cve-2023-20592]. The project page is plain: "CacheWarp is a new software fault attack on AMD SEV-ES and SEV-SNP. It allows attackers to hijack control flow, break into encrypted VMs, and perform privilege escalation inside the VM" [@cachewarp-site]. The CacheWarp authors -- Ruiyi Zhang, Lukas Gerlach, Daniel Weber, Lorenz Hetterich (CISPA), Youheng Lü (Independent), Andreas Kogler (Graz), Michael Schwarz (CISPA) -- demonstrated full RSA key recovery from Intel IPP, passwordless OpenSSH login, and sudo-to-root escalation [@cachewarp-usenix]. SEV-SNP is affected; the fix is the AMD microcode update tracked by AMD-SB-3005 [@amd-sb-3005].

WeSee (IEEE S&P 2024 Distinguished Paper; CVE-2024-25742). A malicious #VC injection. The hypervisor coerces the guest's #VC handler into doing the wrong thing by injecting a #VC at a moment the guest does not expect one. The arXiv abstract is verbatim: "We present WeSee attack, where the hypervisor injects malicious #VC into a victim VM's CPU to compromise the security guarantees of AMD SEV-SNP. ... WeSee can leak sensitive VM information (kTLS keys for NGINX), corrupt kernel data (firewall rules), and inject arbitrary code (launch a root shell from the kernel space)" [@wesee-arxiv]. SEV-SNP only.The arXiv citation_author metadata for 2404.03526 enumerates the WeSee co-authors as Schlueter, Sridhara, Bertschi, Shinde [@wesee-arxiv]. Earlier writeups, including some upstream pipeline stages of this article, listed the third co-author as "Wilke." This was an inadvertent crossover from the SEVurity author list. The canonical author list, retrieved by querying the arXiv abstract page's citation_author meta tags, names Andrin Bertschi (ETH Zurich), which matches the project page on ahoi-attacks.github.io/wesee/ [@ahoi-wesee]. This article reflects the corrected attribution.

Heckler (USENIX Security 2024; CVE-2024-25743, CVE-2024-25744). A malicious non-timer interrupt injection. The hypervisor injects int 0x80 or a signal-mapped exception into the guest at a moment that breaks an invariant. The Ahoi Heckler page captures the scope: "All Intel TDX and AMD SEV-SNP processors are vulnerable to Heckler" [@ahoi-heckler]. The arXiv extended version demonstrates "Heckler on OpenSSH and sudo to bypass authentication. On AMD SEV-SNP we break execution integrity of C, Java, and Julia applications that perform statistical and text analysis" [@heckler-arxiv]. Mitigations are kernel-side interrupt filtering plus AMD's protected interrupt delivery feature.

Ahoi Attacks (umbrella). The family page describes scope: "Ahoi Attacks is a family of attacks on Hardware-based Trusted Execution Environments (TEEs) to break AMD SEV-SNP, Intel TDX and Intel SGX" [@ahoi-site]. The ZISC news framing names the SECTRS group at ETH Zurich (Shweta Shinde's lab) as the locus [@eth-ahoi-news].

One Glitch to Rule Them All (CCS 2021). The physical-fault lower bound established in §3, included here for completeness. Buhren et al. voltage-glitched the AMD-SP on Zen 1 / 2 / 3 to execute custom payloads and to "reverse-engineer the Versioned Chip Endorsement Key (VCEK) mechanism introduced with SEV Secure Nested Paging (SEV-SNP)" [@one-glitch-arxiv]. With supplemental tooling on the PSPReverse GitHub artefact [@pspreverse-github]. With physical access and the right glitcher, the AMD-SP is breakable.

SEV cannot adequately protect confidential data in cloud environments from insider attackers, such as rogue administrators, on currently available CPUs. -- Buhren, Jacob, Krachenfels, Seifert, *One Glitch to Rule Them All*, 2021 [@one-glitch-arxiv] flowchart TB INTG["Generation-2 integrity rail -- (RMP / PAMT)"] INVD["CacheWarp -- CVE-2023-20592 -- INVD seam -- (SEV-ES, SEV-SNP)"] VC["WeSee -- CVE-2024-25742 -- #VC handler seam -- (SEV-SNP)"] INT["Heckler -- CVE-2024-25743/4 -- Interrupt-injection seam -- (SEV-SNP, TDX)"] GLITCH["One Glitch -- Physical voltage-fault -- (AMD-SP firmware)"] INTG -. "intact" .-> INVD INTG -. "intact" .-> VC INTG -. "intact" .-> INT INTG -. "intact" .-> GLITCH

Composition limits and operational corollaries

Can the verifier itself be a CVM? Can SKR survive a verifier compromise? These are open standards questions; the Confidential Computing Consortium is iterating on them and there is no settled answer. What there is is operational guidance.

Note: Every 2024-era SEV-SNP and TDX attack has a corresponding microcode or firmware update with a higher TCB SVN. Policies that accept "any TCB SVN at or above the floor of last year's launch" leave the door open to CacheWarp-class CPUs. Bind your MAA policy to tcb_version >= latest_advisory and update the floor when AMD or Intel publishes a new security bulletin [@amd-sb-3005; @nvd-cve-2023-20592].

Confidential VMs do not promise side-channel resistance. They promise that the hypervisor cannot directly read memory and that an integrity-broken page cannot be silently substituted. The current equilibrium against the 2024 attack class is patch-after-disclosure plus attestation-policy hygiene. That equilibrium is itself an architectural statement.

Key idea: The 2024 attacks do not break the SEV-SNP or TDX integrity rail. They exploit seams around the rail: the INVD instruction, the #VC handler, the interrupt-injection path, and the physical AMD-SP. The architecture is settled. The residuals are the work.

The architecture is settled; the residuals are open. What is the 2026 research frontier actually working on?

9. Open problems

Six open problems shape the 2026 confidential-VM research frontier.

OP1. Nested CVMs. Intel TDX Module 1.5 ships TD Partitioning, where an L1 TD can host L2 TDs of its own [@intel-tdx-td-partitioning-354807]. AMD's analogue is the VMPL0 / VMPL2 layout that Azure OpenHCL already exploits. The portable cross-vendor formulation -- nested-CVM evidence that composes both vendors' attestation reports into a single relying-party-checkable artefact -- is not yet standardised. Customers who want a verifier-inside-a-CVM design must build the composition themselves.

OP2. Cross-vendor attestation composition for CPU+GPU CVMs. Azure NCCadsH100v5 and GCP A3 already compose AMD or Intel CPU attestation with NVIDIA H100 GPU attestation in production. The relying party today consumes two separate evidence packages and runs two separate policy evaluations. The RATS working group's RFC 9711 (The Entity Attestation Token, EAT) [@rfc9711] is the canonical wire-format vocabulary -- a JWT- or CWT-encoded attested claims set -- that a Passport-topology verifier such as Microsoft Azure Attestation produces, and is the path to a single composed evidence package, but the cross-vendor standards work is unsettled.

OP3. Transparency and reproducible builds of the AMD-SP firmware and the Intel TDX Module. Both are signed binaries customers trust but do not build. Google's April 2023 joint security review of TDX, authored by Erdem Aktas, Cfir Cohen, Josh Eads (Google Cloud Security), James Forshaw, and Felix Wilhelm (Google Project Zero), enumerated specific vulnerabilities including "Non-Persistent SEAM Loader, Exit Path Interrupt Hijacking, Unsafe Performance Monitoring VMCS Configuration" [@gcp-tdx-review]. That review is the closest thing to public auditability the TDX Module has today. A reproducible build with binary transparency log (rekor-style) would close the residual auditability gap that even open-source OpenHCL leaves on the table for the silicon vendor's firmware.

OP4. Post-quantum attestation signatures. SNP_REPORT signs with ECDSA-P384. TD Quotes are Intel-signed with RSA / ECDSA. The NIST FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) standards are final, but vendor-side migration of the CVM signing roots has not been announced for either AMD or Intel. The deployment-feasible path is dual-signing: the SNP_REPORT or TD Quote carries both an ECDSA signature and an ML-DSA signature, the verifier accepts either, and the relying party gates on whichever signing root it trusts most. The transition is non-trivial because the VCEK derivation itself uses a classical KDF chain rooted in classical entropy.

OP5. Side-channel-resistant CVMs at deployment scale. The CacheWarp, WeSee, Heckler, and Ahoi family is the active frontier. The current operational equilibrium is policy-pinning to the latest TCB SVN plus microcode-update discipline. There is no production CVM architecture that promises constant-time execution across the integrity rail or that closes the cache-side and notification-injection seams at the silicon layer. The 2026 frontier is what architectural mitigations look like, not what microcode patches catch up to.

OP6. Confidential container portability after AKS KataCcIsolation sunset (March 2026). The Azure CoCo surface fragments into ACI per-pod CVM, ARO per-container CVM, AKS Confidential VM node pools at node granularity, and the upstream CoCo project [@msdocs-aks-confidential-containers]. Customers picking a confidential-containers strategy today need to plan for one of those four routes; the CoCo project itself is Linux-only as of 2026-05. Windows confidential containers remain out of scope on every shipping cloud.

This article does not deep-cover Intel SGX (the sibling enclave article handles that), ARM Confidential Compute Architecture (CCA) or Apple's Secure Enclave Processor (different threat models and form factors), the full text of the TDX Module Architecture Specification (it is 285 pages [@intel-tdx-spec-344425]; this article cites the load-bearing parts), the regulatory and sovereign-cloud framing of CVMs (a separate topic), or the application-level patterns for designing a customer service to be SKR-aware (an operations topic for a future post). flowchart LR OP1["OP1 -- Nested CVMs -- (TD Part. / VMPL)"] OP2["OP2 -- Cross-vendor -- attestation composition"] OP3["OP3 -- Firmware transparency -- + reproducible build"] OP4["OP4 -- PQ signatures -- (ML-DSA / SLH-DSA)"] OP5["OP5 -- Side-channel- -- resistant CVMs"] OP6["OP6 -- CoCo portability -- (post-March-2026)"] OP1 --- OP2 OP3 --- OP4 OP5 --- OP6

If you are deploying today, what should you do this quarter? The next section is a practical walk-through that ties the architecture to a runnable workflow.

10. Practical guide: VBS-inside-CVM end-to-end

Six steps move you from a credit-card swipe to a Windows Server CVM that runs an attested workload with HSM-backed key release. Treat the list as a checklist; each step is a place where the architecture from the previous sections becomes operational.

Step 1. Provision the CVM. Pick a SEV-SNP SKU (DCasv5 or DCasv6 preview), a supported Windows Server image (2019, 2022, or 2025), and turn on Confidential OS-disk encryption with a customer-managed key in Azure Key Vault or Managed HSM. Bind the key to an MAA-aware release policy. The Learn CVM overview describes the SKU family and the OS-image support [@msdocs-azure-cvm]. Plan for the March 30, 2026 encrypted-OS-disk pricing change [@msdocs-azure-cvm].

Step 2. Confirm VBS inside the CVM. A common misconception is that turning on SEV-SNP makes Virtualization-Based Security redundant. It does not -- VMPL and VTL are orthogonal. From an elevated PowerShell session:

Note: Get-CimInstance -Namespace Root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard should return VirtualizationBasedSecurityStatus = 2 (running) and a non-empty SecurityServicesRunning array that includes Credential Guard and HVCI. This proves that VTL1 / VTL0 separation is intact inside the SEV-SNP trust boundary -- the cloud operator is excluded by VMPL, and the customer's own user mode and ring-0 are excluded from the Secure Kernel by VTL.

Step 3. Capture an attestation token and walk it by hand. Use the Azure Attestation client (Microsoft.Azure.Attestation) to send the guest's SNP_REPORT and vTPM quote to the regional MAA endpoint. Inspect the returned JWT. The decoded claim set will include x-ms-isolation-tee describing the TEE (SEV-SNP or TDX), x-ms-runtime describing the guest configuration, the boot measurements, and any custom claims your policy mints. Verify the JWT signature against the region's MAA signing certificate -- not against an arbitrary trusted root; this is the verifier-identity hygiene that closes the SKR loop.

A valid MAA JWT will contain `x-ms-attestation-type = sevsnpvm` (or `tdxvm`) and a `x-ms-compliance-status = azure-compliant-cvm` claim. If either is missing or has a different value, the policy did not gate on the TEE and the relying party is about to release a key against unattested evidence.

Step 4. Author the policy. Write an MAA policy v1.2 file with four pieces. A configuration-rules block that keeps the defaults: require_valid_aik_cert=true and required_pcr_mask=0xFFFFFF [@maa-policy-v12]. An authorization-rules block that requires (a) x-ms-attestation-type == "sevsnpvm", (b) the SNP_REPORT measurement matches a known reference value for the customer's golden image, (c) the vTPM PCR-7 matches a known Secure Boot signer baseline, and (d) the VBS-enabled claim is true. An issuance-rules block that mints a customer-workload-tier claim from the SNP_REPORT's tcb_version. And version 1.2. Bind your HSM key's release policy to require the issuance-rule claim plus the authorization-rule pass.

Note: Use az attestation policy set to upload the policy to a non-production attestation provider and replay captured evidence through attestationProvider REST endpoints. This lets you iterate on JmesPath claim rules without rebooting CVMs. Pre-production failures here are cheap; failures after SKR binding are expensive [@maa-policy-v12].

Step 5. Repeat on a TDX SKU. Provision a DCesv5 or DCesv6 (preview) CVM. The attestation evidence shape changes: TDX evidence carries MRTD plus RTMR0-3 instead of a single SNP measurement, and the claims JSON shape differs. The JmesPath rules in your policy must be parameterised on productId to handle both TEEs from one policy file, or split into two policy files keyed by attestation provider region and TEE type [@intel-tdx-overview; @maa-policy-v12].

Step 6. Plan TCB SVN hygiene. Treat the TCB SVN floor in your policy as a moving target, not a one-time configuration. Subscribe to the AMD security bulletins and the Intel TDX security advisories. When CacheWarp's microcode shipped via AMD-SB-3005 [@amd-sb-3005], the appropriate operational response was to raise the policy's TCB SVN floor to the new microcode level, not to leave the floor at the launch baseline. This is the single most important operational habit a CVM customer can adopt.

Note: A policy that accepts the launch-baseline TCB SVN forever is a policy that grandfathers in every known CVE the silicon vendor has shipped a microcode patch for. The 2024 attack class makes this a load-bearing operational discipline, not a footnote [@nvd-cve-2023-20592; @amd-sb-3005].

You can build it today. The FAQ below answers the questions readers most often ask after they have built it.

11. FAQ and closing

Architecturally, the host hypervisor cannot read your encrypted RAM and cannot silently remap pages without triggering an RMP or PAMT fault [@amd-sev-portal; @intel-tdx-overview]. Operationally, the verifier (Microsoft Azure Attestation) is run by Microsoft, the paravisor (OpenHCL) is built by Microsoft, and the silicon is signed by AMD or Intel. You must still trust those components. The lower bound on TCB is at least the silicon vendor's signing root plus at least one verifier; you can shrink the *verifier* trust by using a third party (Intel Trust Authority for TDX, or your own deployment of an attestation broker), but you cannot shrink the silicon-vendor root [@msdocs-maa-overview]. No. VMPL (the SEV-SNP privilege axis) and VTL (the in-guest Virtualization-Based Security axis) are orthogonal -- VMPL gates the *operator*; VTL gates the *guest kernel*. See §6 for the full two-axis treatment; a Windows Server CVM should run with VBS, HVCI, and Credential Guard enabled inside the guest exactly as it would outside a CVM [@msdocs-azure-cvm]. No. The Nitro hypervisor enforces the enclave boundary in software AWS owns and operates; there is no CPU-level memory cipher, and the threat model is parent-instance isolation rather than cloud-operator isolation. See §7 for the three architectural differences and the operator-trustless callout [@aws-nitro-enclaves]. Yes, with limits. The attestation surface changes: the SNP_REPORT measurement (or MRTD plus RTMR extensions on TDX) now reflects your custom image. Your MAA policy must whitelist the new measurement values or use issuance-rule projection to bind to attributes you control. You cannot bypass the paravisor without abandoning the OpenHCL-mediated vTPM, which removes the chained vTPM-quote to silicon path most customers depend on [@msdocs-azure-cvm; @openhcl-blog]. Yes -- transitively, through the paravisor. See §6 for the full `vTPM quote -> EK certificate -> SNP_REPORT or TD Quote -> VCEK or Intel signing root` chain, and read it end-to-end before you accept a vTPM quote as silicon-bound [@msdocs-azure-cvm]. Node-granularity CVM versus per-pod CVM. Confidential VM AKS node pools put each worker node inside an SEV-SNP CVM; all pods on that node share the trust boundary [@msdocs-aks-cvm-nodes]. Confidential Containers on AKS used the `KataCcIsolation` runtime to put each pod inside its own SEV-SNP-backed Kata MicroVM; that preview is sunsetting in March 2026 [@msdocs-aks-confidential-containers]. Different SKUs, different runtimes, different sunset timelines. Pick node-granularity for lift-and-shift; pick per-pod when you need stricter blast-radius isolation between pods on the same hardware. No. See §8 for the architectural finding (the Generation-2 integrity rail remains intact under all four 2024 papers; each attack exploits a seam *around* the rail) and §10 Step 6 for the TCB-SVN-pinning operational habit that translates the finding into deployment policy [@cachewarp-site; @ahoi-heckler; @amd-sb-3005].

Imagine drawing the architecture from memory. Start at the bottom with AMD silicon plus the AMD-SP firmware, or Intel silicon plus the SEAM Range Register and the signed TDX Module. Above that, the Azure Hyper-V host -- below the trust boundary, blind to encrypted RAM. Above that, the OpenHCL paravisor at VMPL0 or the L1 TD seat, mediating synthetic devices and the vTPM. Above that, the Windows Server guest at VMPL2 or the L2 TD, still running VBS, HVCI, and Credential Guard inside. Then evidence flows up: SNP_REPORT or TD Quote plus vTPM quote into Microsoft Azure Attestation, which evaluates policy v1.2 against the evidence and emits a signed JWT, which Azure Key Vault checks before releasing the wrapped OS-disk key. If you can draw it on a napkin in two minutes, you have understood the article. If you can write the MAA policy that says exactly what you mean by "this VM is one of mine," you can build with it.

<StudyGuide slug="confidential-vms-on-azure" keyTerms={[ { term: "Reverse Map Table (RMP)", definition: "AMD SEV-SNP per-page metadata table enforcing GPA-to-HPA binding; mismatched mappings raise #NPF(rmpfault)." }, { term: "Virtual Machine Privilege Level (VMPL)", definition: "AMD SEV-SNP four-level privilege lattice; OpenHCL paravisor at VMPL0, customer kernel at VMPL2." }, { term: "SNP_REPORT", definition: "ECDSA-P384 signed attestation report from the AMD-SP, carrying measurement, policy, report_data, vmpl, chip_id, tcb_version." }, { term: "Secure Arbitration Mode (SEAM)", definition: "Intel CPU privilege state in which the signed TDX Module executes, hosted in the SEAMRR memory range." }, { term: "Intel TDX Module", definition: "Signed Intel firmware running in SEAM that mediates entry, exit, and measurement for Trust Domains." }, { term: "MRTD", definition: "Build-time TDX measurement of the initial TD image; SEAM analogue of an immutable launch PCR." }, { term: "RTMR0-3", definition: "Runtime extendable measurement registers exposed by the TDX Module; SEAM analogue of the runtime-extension TPM PCRs. Canonical TDX-vTPM mapping: RTMR[0]<->PCR[1,7], RTMR[1]<->PCR[2-6], RTMR[2]<->PCR[8-9], RTMR[3]<->PCR[14,17-22]." }, { term: "OpenHCL paravisor", definition: "Microsoft's open-source Rust paravisor on OpenVMM, running inside the CVM trust boundary at VMPL0 or the L1 TD seat." }, { term: "Microsoft Azure Attestation (MAA)", definition: "Azure's RATS verifier; evaluates customer policy v1.2 against SNP_REPORT or TD Quote plus vTPM evidence and returns a signed JWT." }, { term: "Secure Key Release (SKR)", definition: "Azure Key Vault / Managed HSM operation gating wrapped-key release on a valid MAA attestation token." }, { term: "Versioned Chip Endorsement Key (VCEK)", definition: "AMD per-chip per-TCB-version ECDSA-P384 signing key for SNP_REPORTs; certificate chain anchors to AMD root via the ASK." } ]} />

Direct Anonymous Attestation: The Zero-Knowledge Proof Already in Every TPM

noreply@paragmali.com (Parag Mali) — Tue, 12 May 2026 00:00:00 GMT

**Direct Anonymous Attestation is the zero-knowledge proof your laptop already has -- and never uses.** Every TPM 2.0 specification since 2014 names a group-signature primitive called `TPM_ALG_ECDAA`, with a normative command pair (`TPM2_Commit`, `TPM2_Sign`) and a mandatory curve (`TPM_ECC_BN_P256`). A TPM with ECDAA enabled can prove "I am a genuine TPM whose endorsement key was certified by a known issuer" without revealing *which* TPM and without an online third party in the verification path. ISO/IEC 20008-2:2013 Mechanism 4 standardizes it. FIDO Alliance bound it to authenticator attestation in 2018. WebAuthn Level 1 registered ECDAA as an attestation type carried inside the `packed` and `tpm` attestation statement formats in March 2019. Three years later, WebAuthn Level 2 removed it entirely. The TCG PC Client Platform TPM Profile made `TPM_ALG_ECDAA` optional in February 2020. Microsoft Azure Attestation, Windows Health Attestation, AWS Nitro, Apple App Attest, and Google Play Integrity all use Privacy-CA-shaped broker flows instead. This article walks the thirty-year cryptographic lineage, the TPM 2.0 normative surface, the FIDO ECDAA failure, and the structural reasons Microsoft chose brokers over math.

1. A Billion Chips, Zero Verifiers

Every TPM 2.0 Library Specification published since 2014 names a zero-knowledge proof of knowledge. The algorithm identifier TPM_ALG_ECDAA (value 0x001A) appears in Part 2 (Structures). The command pair TPM2_Commit and TPM2_Sign appears in Part 3 (Commands). The mathematical construction appears in Part 1 Annex C.5. The mandatory curve is TPM_ECC_BN_P256 (0x0010), a 256-bit Barreto-Naehrig curve picked specifically because it admits the asymmetric pairings the protocol needs [@tpm-library-spec]. A conforming TPM 2.0 chip with ECDAA enabled can produce a signature that proves the chip is a genuine TPM whose endorsement key was certified by a known issuer -- without revealing which TPM, and without an online certificate authority sitting in the verification path. The cryptography is called Direct Anonymous Attestation, and the Wikipedia article notes that the construction is "implemented by both EPID 2.0 and the TPM 2.0 standard" [@wiki-daa].

Almost nobody uses it.

Microsoft Azure Attestation does not. Its public architecture document describes a certificate authority that ingests endorsement-key certificates and issues per-key JWTs with a special issuance policy [@azure-attestation]. The Windows Health Attestation Service does not. AWS Nitro Enclaves does not [@aws-nitro-attestation]. Apple App Attest does not [@apple-app-attest]. Google Play Integrity does not [@google-play-integrity]. WebAuthn Level 1 registered ECDAA as an attestation type carried inside the packed and tpm formats in March 2019; WebAuthn Level 2 in April 2021 removed it entirely [@webauthn-2]. The TCG PC Client Platform TPM Profile, the document that governs which TPM 2.0 algorithms an OEM must support to ship a Windows-class platform, made TPM_ALG_ECDAA and TPM_ALG_ECSCHNORR optional in v1.04 (February 2020) and has carried that designation through v1.07 RC1 (December 2025) [@tcg-ptp]. Microsoft Pluton's published surface, which enumerates the algorithms the security processor exposes through its TPM 2.0 personality, does not advertise ECDAA at all [@pluton].

The most thoroughly standardized hardware-anchored group-signature primitive in the history of platform security sits in firmware on a billion-plus machines and runs on almost none.

Why?

Key idea: Direct Anonymous Attestation solves the same problem as a Privacy-CA -- prove the TPM is genuine without disclosing which TPM -- by moving the trust assumption from operational (the broker promises not to log) to cryptographic (the math forbids the issuer from learning). The interesting question is not whether the cryptography works. It is why an industry that spent thirty years building the math chose, in production, the architecture the math was meant to replace.

This article walks the answer in four moves. Sections 2 through 5 reconstruct the cryptographic lineage: the Privacy-CA architecture DAA was invented against (TPM 1.1, 2003), the group-signature pre-history that made the construction possible (Chaum-van Heyst 1991 through Camenisch-Lysyanskaya 2004), the Brickell-Camenisch-Chen breakthrough at ACM CCS 2004, and the seven-year evolution to the elliptic-curve scheme TPM 2.0 actually ships (Chen-Page-Smart, CARDIS 2010). Sections 6 and 7 walk the normative surfaces: the TPM 2.0 ECDAA command surface and the ISO/IEC 20008-2 / 20009-2 standards. Sections 8 and 9 are case studies in non-deployment: FIDO's three-year experiment with ECDAA-in-WebAuthn, and Microsoft's two-decade commitment to broker-mediated attestation. Section 10 names the open problems -- post-quantum DAA, confidential computing, the One-TPM-to-Bind-Them-All fix that has not made it into TCG text. Section 11 closes with a role-keyed practical guide and an FAQ.

timeline title Direct Anonymous Attestation, 1991-2024 1991 : Chaum-van Heyst (EUROCRYPT) : Group signature defined 1997 : Camenisch-Stadler (CRYPTO) : Constant-size signatures 2000 : ACJT (CRYPTO) : Coalition resistance 2004 : Brickell-Camenisch-Chen (CCS) : Boneh-Boyen-Shacham short groupsigs 2005 : DAA-RSA added to TPM 1.2 rev 94 2007 : Brickell-Li EPID (WPES) : Signature-based revocation 2008 : Brickell-Chen-Li (TRUST) : First pairing DAA : CMS asymmetric DAA proposed 2010 : Chen-Li (IPL) : CMS proof flaw : Chen-Page-Smart (CARDIS) : The scheme TPM 2.0 ships 2013 : BFGSW (IJIS) : User-controlled linkability model : ISO/IEC 20008-2 / 20009-2 2014 : TPM 2.0 Library Spec : ECDAA in firmware 2015 : Smyth-Ryan-Chen : Retroactive BCC privacy bug 2018 : FIDO ECDAA v2.0 2019 : WebAuthn Level 1 : ecdaa attestation format 2020 : TCG PTP v1.04 : ECDAA made optional 2021 : WebAuthn Level 2 : ecdaa format removed 2024 : CoSNIZK : Lattice DAA at 38 kB

To answer the question of why, we have to start where every TPM attestation story does -- with the architecture DAA was invented to replace.

2. The Privacy-CA Trap (1999-2003)

TPM 1.1, originally published by the Trusted Computing Platform Alliance in 2002 and taken over in April 2003 by the Trusted Computing Group that replaced it [@wiki-tcg], had a privacy story. The story was a broker called the Privacy Certificate Authority. The story had a single load-bearing flaw, and the field spent the next two decades writing papers about it.

The mechanism, paraphrased from the Wikipedia summary that itself paraphrases the TCG spec, is five steps [@wiki-daa]:

A TPM manufacturer embeds a 2048-bit RSA Endorsement Key (EK) at the time the chip is provisioned, along with a certificate EKCert signed by the manufacturer [@wiki-tpm].
The platform generates a fresh Attestation Identity Key (AIK) inside the TPM.
The platform sends (EKCert, AIKpub, proof-of-binding) to a Privacy-CA.
The Privacy-CA validates the EK certificate, confirms the binding proof, and issues Cert(AIKpub) signed by the CA.
The platform uses the AIK to sign actual attestations -- platform configuration register quotes, boot logs, key-attestation certificates -- and presents Cert(AIKpub) to relying parties as proof that the AIK is TPM-resident.

The Endorsement Key is the long-lived, manufacturer-certified asymmetric key burned into the TPM at provisioning. Its public half is the chip's permanent cryptographic identity; its certificate, signed by the manufacturer, is the platform's proof that the chip is a real TPM. The Attestation Identity Key is a short-lived TPM-resident key generated for signing attestation outputs. Because the EK is uniquely identifying, the AIK exists to absorb attestation traffic on the EK's behalf: the EK certifies the AIK once (or once per Privacy-CA), and the AIK does the signing thereafter [@azure-attestation]. The broker introduced by the TCG in TPM 1.1 to separate the unique-by-design Endorsement Key from the per-attestation Attestation Identity Key. The Privacy-CA verifies the EK certificate, attests that the AIK is bound to a real TPM, and issues a certificate on the AIK that the platform then uses to sign quotes. The privacy property is operational, not cryptographic: the CA promises not to log the linkage between EK and AIK [@wiki-daa].

The architecture has three structural problems, and the Wikipedia summary of the original TPM 1.1 design makes the most uncomfortable one explicit: "privacy requirements may be violated if the privacy CA and verifier collude" [@wiki-daa]. The Privacy-CA can link AIKs to EKs. It promises not to. That promise is enforceable by audit, by legal contract, by reputation, and by the threat of a regulator finding out. It is not enforceable by mathematics.

The other two problems are availability and concentration. Wikipedia again, on the TPM 1.1 design: "the privacy CA must take part in every transaction" [@wiki-daa]. Every AIK certification is a synchronous network round-trip to a single CA. The CA is therefore a high-availability target, a high-value attack target, and a high-throughput service obligation for whoever decides to operate one. The FIDO Alliance, fifteen years later, wrote down the operational consequences of that obligation with surprising frankness in its ECDAA Algorithm v2.0 specification [@fido-ecdaa-v2]:

An alternative approach to 'group' keys is the use of individual keys combined with a Privacy-CA [TPMv1-2-Part1]. Translated to FIDO, this approach would require one Privacy-CA interaction for each Uauth key. This means relatively high load and high availability requirements for the Privacy-CA. Additionally the Privacy-CA aggregates sensitive information (i.e. knowing the relying parties the user interacts with). This might make the Privacy-CA an interesting attack target. -- FIDO ECDAA Algorithm v2.0 Implementation Draft, 2018

The FIDO document was written in 2018, but it is operating on a problem that was current in 2003. The Privacy-CA model concentrates the very identifiers it is supposed to anonymize. A regulator with a subpoena, an insider with a database query, or a successful attacker with persistent access can recover the linkage the CA promised to forget. In 2003 the TCG named the missing primitive -- a direct attestation scheme whose anonymity was guaranteed by math rather than a CA's promise -- and the cryptographic literature went to work on it.The privacy-advocate criticism of the TPM in the 2003-2005 window came from a small but well-placed group. Ross Anderson at Cambridge had been writing critical surveys of trusted computing since 2002, both in a continuously updated TCPA FAQ [@anderson-tcpa-faq] and in a PODC 2003 paper "Cryptography and Competition Policy -- Issues with Trusted Computing" [@anderson-tcpa-paper]. Seth Schoen and the Electronic Frontier Foundation published a 2003 white paper, "Trusted Computing: Promise and Risk," on the privacy implications of trusted-computing-class identifiers [@eff-schoen-2003]. European data-protection authorities had begun studying TCPA in the same window [@anderson-tcpa-faq]. The DAA construction was, by 2004, a research community answer to these criticisms more than it was a TCG product requirement.

The Privacy-CA architecture is still production architecture in 2026. Microsoft Azure Attestation runs a Privacy-CA in everything but name. Its public documentation describes a CA-mediated flow whose five-step shape mirrors the TPM 1.1 Privacy-CA almost line for line: "A certification authority (CA) establishes trust in the TPM either via EKPub or EKCert... The CA issues a certificate with a special issuance policy to denote that the key is now attested as protected by a TPM" [@azure-attestation]. The full verbatim Microsoft Learn quote is reproduced in §9, where it anchors the Windows case study.

The same pattern repeats across every hyperscaler. AWS Nitro Enclaves issues PKIX certificates rooted in AWS-operated CAs that bind enclave measurements to instance identifiers [@aws-nitro-attestation]. Apple App Attest issues per-app device identifiers from Apple-operated infrastructure [@apple-app-attest]. Google Play Integrity ships integrity verdicts signed by Google-operated infrastructure [@google-play-integrity]. In 2026 the operational descendants of TPM 1.1's Privacy-CA broker run the production attestation surface of every consumer-grade cloud platform.

By 2003 the field had a name for the missing primitive: a direct attestation scheme that delivered the Privacy-CA's anonymity property cryptographically rather than operationally. What followed was an academic lineage that had been quietly building, for a decade and a half, the primitives that lineage required.

3. The Pre-History: Group Signatures Before DAA (1991-2003)

Direct Anonymous Attestation was invented in 2004. The primitive it was built from was invented in 1991, in a paper that had nothing to do with TPMs.

David Chaum and Eugene van Heyst presented "Group Signatures" at EUROCRYPT 1991 [@chaum-vh-1991]. The construction was a curiosity: a digital signature scheme in which any one of n group members could sign on behalf of the group, the verifier could check that some member of the group signed, and a designated group manager could, given a signature, recover the identity of the signer. The use case Chaum and van Heyst had in mind was organizational: a company spokesperson signs press releases on behalf of the company; the CEO can, if necessary, recover which spokesperson signed which release.

A digital signature scheme in which any one of `n` group members can sign on behalf of the group such that (i) verifiers can confirm "some member of the group signed this message" using a single group public key, (ii) verifiers cannot determine which member signed, and (iii) a designated group manager, holding a trapdoor, can *open* any signature to recover the original signer. Chaum and van Heyst introduced the primitive in 1991; the next decade was about making the construction efficient enough to deploy [@wiki-group].

The 1991 construction had a fatal practical property: signature size was linear in the size of the group. A 10,000-member group meant a 10,000-component signature. For a primitive intended to handle organizational use cases at organizational scale, this was a non-starter. The next decade is a sequence of papers, each adding one property to the previous, each addressing the issue that made the previous unfit for deployment.

Jan Camenisch and Markus Stadler, at CRYPTO 1997, gave the field its first constant-size group signature -- signature length independent of the number of group members, suitable for groups of arbitrary size [@camenisch-stadler-1997]. Their construction relied on a particular kind of zero-knowledge proof of knowledge of a discrete logarithm whose form would, six years later, become the structural template for DAA's Sign protocol. The CS97 scheme had its own problems -- the security proof made strong assumptions, and the construction was vulnerable to "framing" attacks where a malicious group manager could forge signatures attributable to other members -- but the size barrier was broken.

Three years later, at CRYPTO 2000, Giuseppe Ateniese, Jan Camenisch, Marc Joye, and Gene Tsudik introduced what the field now calls the ACJT scheme [@acjt-2000]. The Springer abstract is unusually direct about what ACJT contributed: the paper "introduces a new provably secure group signature... proven secure and coalition-resistant under the strong RSA and the decisional Diffie-Hellman assumptions." The property that made ACJT important was coalition resistance -- a formal guarantee that no subset of k group members, no matter how large, could collude to produce a valid signature that did not open to one of them. ACJT's security proofs were the first in the group-signature literature to treat coalitions as a first-class threat model.Coalition resistance as a property predated ACJT, but coalition resistance as a formal property -- something proven against an adversary defined in a complexity-theoretic model -- did not. Camenisch and Michels in 1998, and several authors in between, had given coalition-resistance arguments that depended on heuristic assumptions about the underlying hash function or signature scheme [@camenisch-michels-1998]. ACJT 2000 gave the proof under the strong RSA assumption, which by 2000 was a well-understood number-theoretic conjecture that the cryptographic community treated as a load-bearing security primitive.

ACJT was the construction the DAA designers built on. The reason is in its protocol structure. The ACJT signer holds a signed credential on a secret membership value f. Signing a message means producing a non-interactive zero-knowledge proof of knowledge of (f, signature) satisfying the group manager's verification equation, bound to the message. The proof is constant-size; the verifier checks it against the group public key and learns only that some member signed.

Jan Camenisch and Anna Lysyanskaya, working in parallel, were building the other primitive DAA would need. Their EUROCRYPT 2001 paper introduced what the field now calls CL credentials -- a digital signature scheme with two unusual properties [@cl-2001]. First, a signer can issue a signature on a committed value Commit(f) without seeing f itself, so the holder of f ends up with a signature on something the signer never learned. Second, a holder of (f, signature) can prove possession of that pair in zero knowledge, revealing neither f nor the signature itself.

A digital signature scheme with two algorithmic protocols on top of the standard sign-and-verify pair. A *blind issuance* protocol lets a signer issue a signature on a value the signer cannot see (the holder commits to a value `f` and proves the commitment well-formed; the signer signs the commitment without learning `f`). A *proof-of-possession* protocol lets a holder of `(f, signature)` prove "I have a CL signature from this signer on some value" without revealing either the value or the signature. CL signatures are the primitive a DAA Issuer uses to issue the long-lived attestation credential the TPM keeps after the Join protocol [@cl-2001] [@cl-2004].

CL signatures gave the field a clean way to issue a member credential without the issuer ever learning the member's secret -- exactly the property a TPM needs when receiving a long-lived DAA credential from an issuer who, by design, must remain unable to recognize the TPM later. Camenisch and Lysyanskaya's CRYPTO 2004 paper extended the construction to bilinear pairings [@cl-2004], a generalization that would matter for the elliptic-curve DAA schemes of the next decade.

flowchart LR A["Chaum-van Heyst 1991
Primitive defined
Linear-size signatures"] --> B["Camenisch-Stadler 1997
Constant-size signatures"] B --> C["ACJT 2000
Coalition resistance
Strong RSA + DDH"] C --> D["Brickell-Camenisch-Chen 2004
DAA-RSA"] A --> E["Camenisch-Lysyanskaya 2001
Blind issuance
Proof of possession"] E --> D E --> F["Camenisch-Lysyanskaya 2004
CL on bilinear pairings"] F --> G["Chen-Page-Smart 2010
EC-DAA"]

A sibling lineage was building in parallel. Dan Boneh, Xavier Boyen, and Hovav Shacham presented "Short Group Signatures" at CRYPTO 2004 [@bbs-2004]. The BBS scheme used bilinear pairings to compress group signatures to a few hundred bytes -- signatures, in the abstract's words, "approximately the size of a standard RSA signature with the same security." BBS gave the W3C Verifiable Credentials community a primitive that descendants like BBS+ would later use for selective-disclosure credentials. BBS itself did not become the TPM construction. The DAA designers, working from ACJT and CL, took a different path.

By 2003 the primitives existed. The TPM community had the use case. The two communities had not yet met. In 2004, three authors at three different industrial labs made the introduction.

4. The Breakthrough: DAA-RSA (Brickell-Camenisch-Chen, CCS 2004)

The introduction happened at ACM CCS 2004. Ernie Brickell at Intel, Jan Camenisch at IBM Zurich, and Liqun Chen at HP Labs Bristol published "Direct Anonymous Attestation" [@bcc-2004]. The IACR ePrint abstract makes the structural contribution explicit:

Direct anonymous attestation can be seen as a group signature without the feature that a signature can be opened, i.e., the anonymity is not revocable. Moreover, DAA allows for pseudonyms, i.e., for each signature a user (in agreement with the recipient of the signature) can decide whether or not the signature should be linkable to another signature. DAA furthermore allows for detection of 'known' keys: if the DAA secret keys are extracted from a TPM and published, a verifier can detect that a signature was produced using these secret keys. -- BCC 2004 (IACR ePrint 2004/205)

Two design moves did the work, and naming them clearly is the first step in understanding why DAA solved the Privacy-CA problem.

The first move is a subtraction. Every prior group-signature scheme -- Chaum-van Heyst, Camenisch-Stadler, ACJT, BBS -- gave a designated group manager the power to open a signature and recover its signer. For a TPM attestation primitive, the opening capability is undesirable. An issuer who can open is morally a Privacy-CA: it has the linkage information the architecture is supposed to forget. BCC 2004 removes the opening capability entirely. No party can de-anonymize a signature -- not the issuer, not the verifier, not a coalition of either. The IACR ePrint 2004/205 abstract captures the consequence: DAA "can be seen as a group signature without the feature that a signature can be opened, i.e., the anonymity is not revocable" [@bcc-2004]. Once the credential is issued, the issuer has no cryptographic handle left to break the user's privacy.

A zero-knowledge attestation primitive in which a TPM holds a long-lived membership credential (the output of a one-time Join protocol with an Issuer) and can subsequently produce signatures that prove "the signing TPM holds a credential certified by this Issuer" without revealing which TPM signed and without an online third party in the verification path. No party -- not the Issuer, not the Verifier, not a coalition of either -- can de-anonymize a DAA signature. The construction first appeared in Brickell-Camenisch-Chen 2004 [@bcc-2004].

The second move is a substitution. Where prior schemes traced misbehaving signers by manager-controlled opening, DAA introduces a user-controlled linkability mechanism through what the BCC paper calls a basename-keyed pseudonym. The signing TPM holds a secret membership value f. The verifier supplies a basename bsn (a string the verifier picks per session, per relying party, or per global epoch). The TPM derives a pseudonym

$$N_V = \zeta^f \pmod \Gamma, \qquad \zeta = H_\Gamma(\text{bsn})$$

where H_Γ hashes the basename into a generator of a multiplicative group Γ. The pseudonym N_V has two structural properties. If the same verifier reuses the same bsn across sessions, signatures from the same TPM produce the same N_V, so the verifier can link them (and blacklist them if needed). If the verifier randomizes bsn per session, or sets bsn to the special value ⊥ indicating "no linkability," signatures from the same TPM produce different N_V values that are indistinguishable from random.

A DAA property in which the *verifier* chooses a basename `bsn` per session or per relying party. Signatures from the same TPM under the same basename produce the same pseudonym; signatures under different basenames produce pseudonyms indistinguishable from random. The TPM, not a group manager, controls which signatures are linkable to which others. The Bernhard-Fuchsbauer-Ghadafi-Smart-Warinschi 2013 paper gives the canonical formal model [@bfgsw-2013].

Together the subtraction and the substitution define the DAA contract. The Issuer issues a CL signature on the TPM's secret f during a one-time Join. The TPM thereafter holds the credential (f, A, e, v) -- the secret membership value plus the CL signature components. To sign a message m against a verifier-supplied basename bsn, the TPM:

Computes the pseudonym N_V = ζ^f mod Γ where ζ = H_Γ(bsn).
Randomizes the CL signature: picks a fresh w, computes T_1 = A · S^w mod n and T_2 = g^e · h^w mod n.
Produces a Fiat-Shamir non-interactive zero-knowledge proof of knowledge of (f, A, e, v, w) satisfying the CL verification equation

$$A^e \equiv Z / (R^f \cdot S^{v' + v''}) \pmod n,$$

binding the proof to the tuple (m, T_1, T_2, N_V).

A verifier checks the proof against the Issuer's public key. The verifier learns nothing about f, nothing about the TPM's identity, nothing about which CL signature was randomized -- and either gains a linkable pseudonym (if bsn was reused) or no linkability at all (if bsn was fresh).

The architectural picture, set against §2's Privacy-CA flow, makes the contrast vivid.

flowchart TD I["Issuer
(holds CL signing key)"] T["TPM
(holds secret f)"] V["Verifier
(holds Issuer pub key)"] I -.->|"one-time Join
CL signature on f
(blind, issuer never sees f)"| T T -->|"credential (f, A, e, v)
stored in TPM forever"| T T -->|"DAA-Sign(m, bsn)
= randomized credential + NIZK + N_V"| V V -->|"Verify against Issuer pub key
(no online interaction)"| V

This is the first aha. The reader entered §3 thinking "anonymity with manager-controlled traceability" was the goal of group signatures. They exit §4 understanding that for TPM attestation the goal is anonymity without any opener plus user-controlled, per-verifier linkability. The breakthrough is structurally a subtraction (remove the opener) plus a substitution (per-verifier basename pseudonyms in place of manager-controlled opening). It is not an addition.Eleven years after BCC 2004, Ben Smyth, Mark Ryan, and Liqun Chen ran a formal analysis of the original BCC construction and found a retroactive privacy bug [@smyth-ryan-chen-2015]. The bug allowed certain Issuer-coalition adversaries to link signatures across basenames in ways the original security argument had not anticipated. The bug was fixed in the 2008-2010 redesigns (specifically the BCL 2009 simplified-security-notions paper [@bcl-2009] and the CDL 2016 strong-Diffie-Hellman revisitation). The reader interested in why "we proved this in 2004" is not the same as "this is provably secure in 2026" should read SRC 2015 alongside the original BCC abstract.

On paper, the BCC 2004 construction solved the Privacy-CA trap. In practice, DAA-RSA was hard to ship. The CL signature in the original scheme used strong RSA moduli at 2048 bits. A single Sign operation took several seconds on the TPM 1.2 hardware of the time. The signature itself was approximately 2.5 kilobytes -- larger than the entire AIK signature output a Privacy-CA-mediated attestation produced. TPM 1.2 shipped DAA-RSA as an optional capability when revision 94 of the spec added it in 2005 [@tpm-library-spec]. Almost no platform integrator turned it on. The cryptography worked. The implementation budget did not.

The next decade was about making the construction small enough to deploy. The path was anything but straight.

5. The Evolution: From RSA-DAA to EC-DAA (2007-2013)

Six papers in seven years, two industrial branches, one dead end, one production scheme. Why was the EC-DAA story so much harder than it should have been?

The honest answer: the entire toolkit of pairing-based cryptography arrived at the same time the TPM industry needed it, and the field discovered in real time that not every choice of pairing was safe. The path from BCC 2004 to the construction the TPM 2.0 spec actually shipped runs through five waypoints, each addressing the problem the previous one created.

5.1 Brickell-Li 2007: EPID and signature-based revocation

In 2007 Ernie Brickell, now leading Intel's trusted-computing work, and Jiangtao Li published "Enhanced Privacy ID: A Direct Anonymous Attestation Scheme with Enhanced Revocation Capabilities" at WPES 2007 [@brickell-li-epid-2007]. The journal version appeared at IEEE TDSC in 2012 [@brickell-li-tdsc-2012]. The single feature EPID added was a revocation list called Sig-RL: a list of signatures the issuer wished to disavow. A verifier, given a signature σ and a Sig-RL containing entries σ_1, ..., σ_k, could prove that σ was not produced by the same TPM as any σ_i -- without learning the linking information itself.

EPID became Intel's production attestation primitive. Wikipedia records the deployment scale: "It has been incorporated in several Intel chipsets since 2008," and "at RSAC 2016 Intel disclosed that it has shipped over 2.4B EPID keys since 2008" [@wiki-epid]. EPID is what Intel SGX enclaves used to attest, before SGX attestation migrated to the vendor-CA DCAP architecture. EPID is what certain Intel-platform Widevine L1 implementations use to attest content-decryption modules. The Intel EPID SDK (the reference implementation) was eventually marked public-archive on GitHub [@epid-sdk]. The Wikipedia entry notes that the original EPID 2.0 specification was contributed by Intel into ISO/IEC 20008 and 20009 under royalty-free terms [@wiki-epid].

EPID is not exactly DAA. EPID is a DAA variant with the Sig-RL revocation layer added. The Chen-Page-Smart construction that TPM 2.0 actually ships is closer to BCC 2004 plus an elliptic-curve substrate; EPID 2.0 is closer to BCC 2004 plus EC plus Sig-RL plus Intel's specific basename and key-management conventions. The two converge at the cryptographic core and diverge at the deployment surface.

5.2 Brickell-Chen-Li 2008: the first pairing-based DAA

At the TRUST 2008 conference, Ernie Brickell, Liqun Chen, and Jiangtao Li published "A New Direct Anonymous Attestation Scheme from Bilinear Maps" -- the first DAA scheme constructed over bilinear pairings instead of strong RSA [@bcl-2008]. Signature size dropped by an order of magnitude relative to BCC 2004, from roughly 2.5 kilobytes to a few hundred bytes [@bcl-2008]. TPM-side sign time, on hardware that supported elliptic-curve arithmetic, came down from seconds to fractions of a second [@bcl-2008]. The construction used symmetric (Type-1) pairings -- pairings where the two input groups G_1 and G_2 are the same -- which the implementation community would, two or three years later, decide were too inefficient for production TPM hardware.

A function `e : G_1 × G_2 -> G_T` on three elliptic-curve subgroups satisfying *bilinearity* (for all integers `a, b` and points `P ∈ G_1, Q ∈ G_2`, `e(aP, bQ) = e(P, Q)^(ab)`) and *non-degeneracy*. Type-3 (asymmetric) pairings, in which `G_1 ≠ G_2` and no efficient homomorphism is known between them, are the production pairing for TPM 2.0 ECDAA because they admit faster implementations and tighter security reductions than Type-1 (symmetric) pairings. The Chen-Page-Smart 2010 construction is built on Type-3 pairings over Barreto-Naehrig curves [@cps-2010].

5.3 Chen-Morrissey-Smart 2008: the asymmetric proposal and its proof flaw

Pairing 2008 hosted the next move. Liqun Chen, Paul Morrissey, and Nigel Smart published "Pairings in Trusted Computing" [@cms-pairing-2008], proposing a DAA scheme on asymmetric Type-3 pairings -- the kind that admit Barreto-Naehrig curves and the speed-ups TPM hardware needed. The same authors published a companion ProvSec 2008 paper "On Proofs of Security for DAA Schemes" providing the security argument [@cms-provsec-2008].

Two years later, in Information Processing Letters, Liqun Chen and Jiangtao Li published "A note on the Chen-Morrissey-Smart Direct Anonymous Attestation scheme" [@chen-li-2010] showing that the CMS asymmetric-pairing construction had a flawed proof. The cryptographic intuition was correct; the proof technique used an assumption that did not hold in the asymmetric-pairing setting the construction relied on.The Chen-Morrissey-Smart episode is, in 2026, one of the most cited proof-flaw stories in pairing-based cryptography precisely because the construction was simple and the flaw was subtle. The mathematical content of the scheme was salvageable. The security argument was not. The lesson the field took away -- a proof in the symmetric-pairing model does not transfer to the asymmetric-pairing model without a separate argument -- has been a load-bearing convention in cryptographic publishing since.

5.4 Chen-Page-Smart 2010: the scheme TPM 2.0 actually ships

The fix arrived at CARDIS 2010 in Passau in April 2010 [@cardis-book]. Liqun Chen, Dan Page, and Nigel Smart published "On the Design and Implementation of an Efficient DAA Scheme" [@cps-2010] [@cps-2010-eprint], proposing an asymmetric-pairing DAA over Barreto-Naehrig curves with a Sign protocol split between the TPM and the host. The TPM, in the new design, performed only the cryptographic operations that absolutely required custody of the secret f: it produced commitment points and computed a Schnorr-style response over those commitments. The host -- a comparatively powerful general-purpose CPU sitting in front of the TPM -- composed the Fiat-Shamir challenge, performed the pairing computations, and assembled the final signature.

The Chen-Page-Smart construction is the scheme TPM 2.0 actually ships. The Wikipedia DAA article makes the attribution direct, in a sentence that is itself the most-cited single primary-source extract in this article:

Chen, Page, and Smart proposed a new elliptic curve cryptography scheme using Barreto-Naehrig curves. This scheme is implemented by both EPID 2.0 and the TPM 2.0 standard. -- Wikipedia, *Direct Anonymous Attestation* [@wiki-daa] A family of pairing-friendly elliptic curves with embedding degree 12, parameterized by an integer `u` to admit Type-3 pairings whose arithmetic is fast enough for resource-constrained devices [@bn-2006]. The curve identifier `TPM_ECC_BN_P256` (`0x0010`) is the specific 256-bit instance the TPM 2.0 Library Specification mandates for ECDAA, picked because of its pairing-friendly structure rather than as a NIST P-256 equivalent.

Six years after CPS 2010, Taechan Kim and Razvan Barbulescu (CRYPTO 2016) published "Extended Tower Number Field Sieve: A New Complexity for the Medium Prime Case," giving an improved sieve attack against pairing-friendly elliptic curves at the 256-bit BN level. The improvement dropped the practical security of BN-256 from roughly 128 bits to roughly 100 bits [@kim-barbulescu-2016]. The TCG normative text for TPM 2.0 ECDAA did not, as of late 2025, change the mandatory curve in response. This is the kind of cryptographic technical debt that lives quietly in deployed systems for a decade -- specs do not migrate on the same calendar as research moves.

5.5 BFGSW 2013 and SRC 2015: the formal closure

The cryptographic engineering of EC-DAA was done by 2010. What the field still owed itself was a clean security model: one definition of "secure DAA" that captured the user-controlled-linkability property and the TPM/host split, against which any candidate scheme could be evaluated.

In 2013 David Bernhard, Georg Fuchsbauer, Essam Ghadafi, Nigel Smart, and Bogdan Warinschi published "Anonymous attestation with user-controlled linkability" in the International Journal of Information Security [@bfgsw-2013] [@bfgsw-2013-eprint]. The BFGSW paper formalized the user-controlled-linkability property the BCC 2004 abstract had described in prose, introduced a clean separation of "pre-DAA signing" (TPM-side operations) from "DAA signing" (TPM + host composition), and proved the security of a representative construction in the resulting model.

In 2015, Ben Smyth, Mark Ryan, and Liqun Chen published the retroactive analysis that closed the BCC 2004 privacy bug [@smyth-ryan-chen-2015]. By 2015 the cryptography was, formally, settled.

In 2016 Jan Camenisch, Manu Drijvers, and Anja Lehmann revisited the construction at TRUST 2016 in "Anonymous Attestation Using the Strong Diffie Hellman Assumption Revisited" [@cdl-2016] [@cdl-2016-eprint], giving a tighter security argument under the q-SDH assumption and providing a fix for a Diffie-Hellman-oracle issue in the TPM 2.0 ECDAA interface that "One TPM to Bind Them All" would document in 2017 [@one-tpm-2017]. The CDL16 scheme is what most modern DAA library code references as the canonical construction.

flowchart LR BCC["BCC 2004
RSA-DAA
TPM 1.2"] --> BL["Brickell-Li 2007
EPID + Sig-RL
Intel SGX / Widevine"] BCC --> BCL["BCL 2008
Type-1 pairing DAA"] BCL --> CMS["CMS 2008
Asymmetric pairing
(broken by CL 2010)"] BCL --> CPS["CPS 2010
Type-3 BN-curve DAA
TPM 2.0 ECDAA"] CPS --> BFGSW["BFGSW 2013
Formal user-controlled
linkability model"] BFGSW --> CDL["CDL 2016
q-SDH revisitation
Canonical modern DAA"] BCC --> SRC["SRC 2015
Retroactive BCC
privacy bug"]

By 2013 the cryptography was complete. The standards organizations took the construction and made it official -- in two different specifications, on two parallel tracks.

6. The TPM 2.0 ECDAA Surface (2014-Present)

If you own a Windows laptop with a TPM 2.0, this section is the part of the chip you have never used. What does the spec actually say?

The TPM 2.0 Library Specification, the canonical document published by the Trusted Computing Group, is a four-part normative reference [@tpm-library-spec]. Part 1 (Architecture) describes the threat model and the mathematical primitives. Part 2 (Structures) defines the data types every TPM command accepts and returns. Part 3 (Commands) defines the commands themselves. Part 4 (Supporting Routines) gives a reference C implementation. The ECDAA surface lives across all four parts.

An algorithm identifier defined in TPM 2.0 Library Specification Part 2 and selectable from any `TPMT_SIG_SCHEME` field. A signing key tagged with `TPM_ALG_ECDAA` produces signatures using the Chen-Page-Smart 2010 elliptic-curve DAA construction. The same algorithm identifier appears in any signature-scheme negotiation point in the TPM 2.0 command surface [@tpm-library-spec]. The 256-bit Barreto-Naehrig curve identifier the TPM 2.0 Library Specification mandates for any ECDAA-capable signing key. BN-P256 is *not* NIST P-256: it is a pairing-friendly curve with embedding degree 12 whose group structure admits the Type-3 pairings the DAA verification equation requires. Implementations that confuse the two will produce signatures that verify against the wrong group. The command pair defined in TPM 2.0 Library Specification Part 3 that implements the Chen-Page-Smart 2010 split-protocol structure. `TPM2_Commit(keyHandle, P1, s2, y2)` returns commitment points `(K, L, E)` plus a `counter`. The host then computes the Fiat-Shamir challenge `c` over the message and the commitment points. `TPM2_Sign(keyHandle, digest, scheme=TPM_ALG_ECDAA, validation)` returns the Schnorr-style response `s = r + c·f mod p`. The host assembles the final signature from the commitment points, the challenge, and the response [@tpm-library-spec].

The protocol split matters. The TPM, in the CPS 2010 construction, holds the secret f and must perform exactly two cryptographic operations on it: produce a freshly randomized commitment to f (via TPM2_Commit), and produce a Schnorr response that proves knowledge of f modulo the verifier's challenge (via TPM2_Sign). Everything else -- the pairing computations, the curve arithmetic in G_T, the Fiat-Shamir hash, the final signature assembly -- happens on the host CPU. This is the only reason the construction is practical on a TPM. A monolithic Sign that did pairing arithmetic inside the chip would be unshippable; the split offloads the expensive operations onto silicon that has them for free.

Note: The most common implementer mistake when working with TPM 2.0 ECDAA for the first time is to reuse the NIST P-256 ECDSA code path with the curve identifier swapped. The two curves share a bit length and a hash function and otherwise nothing. BN-P256 has a pairing-friendly group structure with embedding degree 12; NIST P-256 does not admit efficient pairings at all. Signatures produced by ECDSA over NIST P-256 will not verify against an ECDAA verifier expecting BN-P256, and the converse is true. The pairing requirement is what forces the BN curve choice; treat BN-P256 as a separate primitive with a separate code path.

The Join protocol -- the one-time exchange between the Issuer and the TPM that produces the long-lived credential -- piggybacks on a TPM 2.0 command pair already present in every Windows attestation flow: TPM2_MakeCredential and TPM2_ActivateCredential [@tpm-library-spec]. The Issuer wraps the DAA credential under an encryption key derived from the TPM's Endorsement Key, ensuring that only the legitimate TPM (the one that holds the EK private key) can decrypt the credential and bind it to its internal f.The choice of TPM2_ActivateCredential as the Join anchor is convenient. The same primitive that TPM 2.0 attestation-key certification flows use for AIK-binding gets reused for DAA-credential binding. An OEM that supports TPM2_ActivateCredential for ordinary AIK enrollment already has 80% of the firmware path the Join protocol needs. The difference is in what the Issuer ships back -- a per-TPM AIK certificate in the AIK case, an Issuer-randomized CL credential in the DAA case.

Part 1 Annex C.5 contains the informative mathematical description -- the actual ECDAA verification equation, the basename-pseudonym derivation, the proof-of-knowledge template. Part 3 contains the normative command definitions. An implementer who reads only the Part 3 command definitions without reading Annex C.5 will have correct byte-buffer-level semantics and no idea what the protocol is computing; an implementer who reads only Annex C.5 without the normative command definitions will have correct math and the wrong API.

The implementation surface, gathered into one place:

Artifact	Identifier / location	Source
Algorithm selector	`TPM_ALG_ECDAA = 0x001A`	TPM 2.0 Library Specification Part 2 [@tpm-library-spec]
Mandatory curve	`TPM_ECC_BN_P256 = 0x0010`	Part 2 [@tpm-library-spec]
First-round command	`TPM2_Commit(keyHandle, P1, s2, y2) -> (K, L, E, counter)`	Part 3 [@tpm-library-spec]
Second-round command	`TPM2_Sign(keyHandle, digest, scheme=TPM_ALG_ECDAA, validation) -> signature`	Part 3 [@tpm-library-spec]
Join anchor	`TPM2_MakeCredential` / `TPM2_ActivateCredential`	Part 3 [@tpm-library-spec]
Math description	Part 1 Annex C.5 (informative)	Part 1 [@tpm-library-spec]
Optionality status	Optional since PTP v1.04 (Feb 2020); carried through v1.07 RC1 (Dec 2025)	TCG PC Client Platform TPM Profile changelog [@tcg-ptp]

sequenceDiagram participant V as Verifier participant H as Host (CPU) participant T as TPM V->>H: send basename bsn H->>T: TPM2_Commit(keyHandle, P1, s2, y2) T-->>H: (K, L, E, counter) H->>H: compute c = H(K, L, E, message, bsn) H->>T: TPM2_Sign(keyHandle, digest=c, scheme=ECDAA) T-->>H: response s = r + c*f mod p H->>H: assemble signature (K, L, E, c, s) H->>V: ECDAA signature V->>V: verify pairing equation

The TCG published the TPM 2.0 Library Specification in 2014. From 2014 through early 2020, the PC Client Platform TPM Profile -- the document that says "to ship a TPM 2.0 in a PC-class device, these algorithms must be present" -- listed TPM_ALG_ECDAA as mandatory-if-the-platform-supports-elliptic-curve-cryptography. In v1.04 (released February 2020) the TCG PTP working group made a quiet but consequential change. The changelog records the line verbatim: "Made TPM_ALG_ECDAA and TPM_ALG_ECSCHNORR optional." The same designation has carried through v1.06 RC1 (January 2025) and v1.07 RC1 (December 2025) [@tcg-ptp]. After February 2020, an OEM can ship a Windows-class TPM 2.0 platform that does not implement ECDAA at all and remain conformant.

Note: The Trusted Computing Group's resource pages (trustedcomputinggroup.org/resource/tpm-library-specification/ and trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/) reject non-browser User-Agents at the HTTP layer. This is a long-standing anti-bot policy. Citations in this article to the TPM 2.0 Library Specification and to the PC Client Platform TPM Profile point to the canonical URLs but are flagged in the verified-source registry as UNVERIFIED_FETCH; the verbatim changelog text was extracted under primary-source rules during the Stage 0a focus-premise audit and is the audit-of-record for the optionality claim. The downstream accuracy and fact-check stages of this pipeline carry the same caveat forward.

The Pluton question is the second hedge. Microsoft Pluton is the security processor Microsoft has been shipping in successive Windows-class platforms since AMD's Ryzen 6000 in 2022, in AMD Ryzen 7040 (Phoenix) in 2023, in Qualcomm Snapdragon X Elite in 2024, and in Intel Core Ultra (Meteor Lake, December 2023; Lunar Lake, September 2024) and successive Intel Core Ultra generations. Pluton exposes a TPM 2.0 personality. The Microsoft Learn documentation page enumerates the cryptographic algorithms the processor exposes and the platform-security primitives it implements [@pluton].

The page contains zero occurrences of ECDAA or TPM_ALG_ECDAA. The honest framing here is not "Pluton does not implement ECDAA" -- the documentation neither confirms nor denies it -- but "Pluton's published surface does not advertise ECDAA." That is the hedged statement this article carries from its opening to its FAQ.

The runnable demonstration below is educational -- Microsoft ships no BCryptDirectAnonymousAttestation, no NCryptDaaSign, no Windows API at all that exposes ECDAA from a user-mode application. The code shows the logic an admin or platform engineer would follow when probing a TPM's reported algorithm set, not a working call against any shipping Windows API.

{` // Logic only. Microsoft ships no Windows API that surfaces TPM_ALG_ECDAA. // In practice an admin would parse the output of Get-TpmEndorsementKeyInfo // or use a vendor-specific tool to inspect the TPM's algorithm capability table. const TPM_ALG_ECDAA = 0x001A; const TPM_ECC_BN_P256 = 0x0010;

function probeECDAA(tpmAlgList, tpmEccCurveList) { const hasECDAA = tpmAlgList.includes(TPM_ALG_ECDAA); const hasBN256 = tpmEccCurveList.includes(TPM_ECC_BN_P256); if (!hasECDAA) return 'no ECDAA: chip omits algorithm 0x001A'; if (!hasBN256) return 'ECDAA without BN-P256: nominally compliant, practically unusable'; return 'ECDAA + BN-P256 present (Join still requires Issuer infrastructure)'; }

// Example: a Pluton-class chip whose published surface does not advertise ECDAA. const plutonLike = [0x0001 /* RSA /, 0x0008 / SHA-256 /, 0x0023 / ECDSA /]; console.log(probeECDAA(plutonLike, [0x0003 / NIST P-256 */])); // -> "no ECDAA: chip omits algorithm 0x001A"

// Example: a discrete Infineon SLB9670 TPM 2.0 (vendor docs list ECDAA + BN-P256). const discreteTpm = [0x0001, 0x0008, 0x0023, TPM_ALG_ECDAA]; console.log(probeECDAA(discreteTpm, [0x0003, TPM_ECC_BN_P256])); // -> "ECDAA + BN-P256 present (Join still requires Issuer infrastructure)" `}

The spec was written. The chips shipped. The TCG was satisfied. So why does no one verify ECDAA signatures?

7. The Standards Bridge: ISO/IEC 20008 and 20009

There is a difference between a TCG specification section number and an ISO/IEC mechanism identifier. The difference is the price of admission to a Common Criteria protection profile and to most government procurement contracts.

ISO/IEC 20008 is the international-standards anchor for anonymous digital signatures. It comes in three parts. Part 1 ("General") sets the framework and terminology [@iso-20008-1]. Part 2 ("Mechanisms using a group public key") catalogues the specific anonymous-signature schemes the international community has standardized -- and Mechanism 4 is the EPID-derived elliptic-curve DAA construction that aligns with the TPM 2.0 ECDAA surface [@iso-20008-2]. Part 3 ("Mechanisms using multiple public keys") catalogues a different family of schemes that is not the focus of this article.

The international-standards series titled "Information technology -- Security techniques -- Anonymous digital signatures." Part 1 (general framework) and Part 2 (mechanisms using a group public key) were both published in 2013. Mechanism 4 in Part 2 standardizes EPID-derived elliptic-curve DAA. ISO/IEC 20008 is the bibliographic anchor cited by Common Criteria protection profiles, FIPS 140-3 module-validation evidence, and government procurement specifications that need to reference a *named, internationally agreed* anonymous-signature mechanism rather than a vendor-specific construction [@iso-20008-2].

A note on the title. Earlier drafts of this article carried the title of ISO/IEC 20008-2 as "anonymous signatures with message recovery." That phrasing belongs to a different standard, ISO/IEC 9796. The verified ISO catalogue title for 20008-2 is, verbatim, "Information technology -- Security techniques -- Anonymous digital signatures -- Part 2: Mechanisms using a group public key" [@iso-20008-2].

ISO/IEC 20009 is the companion standard for authentication. Where 20008 standardizes signatures, 20009 standardizes the challenge-response protocols that wrap signatures into entity-authentication exchanges. Part 2 ("Mechanisms based on signatures using a group public key") is where TPM-style attestation lives in ISO terminology [@iso-20009-2]. A FIDO authenticator or a TPM-backed Kerberos client that performs an attested authentication is, in ISO-speak, executing a 20009-2 mechanism that wraps a 20008-2 signature.

Intel held patents on the EPID construction. In contributing the EPID 2.0 algorithm to ISO/IEC 20008 and 20009, Intel made the underlying intellectual property available under royalty-free (RAND-Z) terms. The Wikipedia EPID article records the contribution and notes that EPID "complies with international standards ISO/IEC 20008 / 20009" [@wiki-epid]. The licensing structure mattered: it is what made the construction acceptable to the FIDO Alliance, to the TCG for the TPM 2.0 ECDAA surface, and to the European procurement community whose conformance regimes treat royalty-bearing cryptographic primitives differently from royalty-free ones. Exact licensing-event dates are not directly indexed in publicly fetchable Intel materials; this paragraph is inference-grade reconstruction from the Wikipedia citation chain.

The procurement reason ISO standardization mattered is structural. A Common Criteria Protection Profile cannot, in the general case, reference a TCG specification section number. It can reference an ISO mechanism identifier. The Federal Information Processing Standards 140-3 evidence package for a cryptographic module must, in many cases, demonstrate that the cryptographic primitives the module implements are members of an internationally recognized standard family. The European Cyber Resilience Act, drafted in 2024 and applicable in stages from 2027 onward, treats compliance with a recognized international standard as one of the routes to a presumption of conformity. ISO/IEC 20008-2 Mechanism 4 is the door TPM 2.0 ECDAA walks through to be admissible in those regimes.

Standardization was complete by 2014. Cryptographic primitive: CPS 2010. Security model: BFGSW 2013. ISO mechanism: 20008-2 Mechanism 4. TPM normative surface: TPM_ALG_ECDAA, TPM_ECC_BN_P256, TPM2_Commit, TPM2_Sign. Every box was checked. The next question -- the one the standardization community could not answer on its own -- was whether anyone would write a verifier.

8. The FIDO Bet That Failed (2017-2021)

In 2018, the FIDO Alliance bet that ECDAA was the missing privacy story for WebAuthn. Three years later, W3C took the bet off the table.

The bet was not casual. FIDO had a real problem. WebAuthn authenticators -- the YubiKey hardware tokens, the Microsoft Hello platform authenticators, the Touch ID and Face ID modules -- need to attest that they are genuine hardware. The attestation surface FIDO Alliance had inherited from U2F was Basic Attestation: every authenticator in a manufacturing batch of 100,000 or more units shared one attestation key [@fido-cert-levels], so a relying party that checked the attestation learned only "this is one of 100,000-plus YubiKey 5 NFCs," not which device specifically. The cohort-size rule gave Basic Attestation a workable operational privacy property. But there was an architectural fork in the road for an organization that wanted cryptographic attestation privacy without the cohort-key fan-out problem.

FIDO Alliance picked the cryptographic fork. The FIDO ECDAA Algorithm v2.0 specification was published as an Implementation Draft on February 27, 2018 [@fido-ecdaa-v2]. The document is the most carefully written specification of the DAA contract from a deployment perspective; the editor was Rolf Lindemann at Nok Nok Labs. The motivation section we have already quoted in §2 names the Privacy-CA failure mode in unusually direct terms.

WebAuthn Level 1 reached W3C Recommendation status on March 4, 2019 [@webauthn-1]. Section 8 defined six attestation statement formats by fmt identifier: packed, tpm, android-key, android-safetynet, fido-u2f, and none. ECDAA was not a separate format; the WebAuthn-1 §6.4.4 attestation-type list (Basic, Self, AttCA, ECDAA, None) carried ECDAA as an attestation type supported within the packed and tpm formats. An independent verification of the live HTML returns 63 occurrences of the string "ecdaa" in the Level 1 Recommendation -- ECDAA had its own type identifier, its own signing logic, and its own verification procedure embedded inside the two formats that mattered [@webauthn-1].

WebAuthn Level 2 reached W3C Recommendation status on April 8, 2021 [@webauthn-2] [@wiki-webauthn]. The same independent verification against the live Level 2 HTML returns zero occurrences of "ecdaa." Every reference -- the type identifier, the signing rules, the verifier procedure that the packed and tpm formats invoked -- was removed in a single editorial pass. The Yubico migration guide for its Java WebAuthn server library makes the vendor view explicit: "This attestation type was removed from WebAuthn Level 2. ECDAA support has not been implemented in this library, so this value could in practice never be returned" [@yubico-migration].

Why did the bet fail? Four reasons, each visible from the public record.

First, no major browser ever shipped an ECDAA verifier inside the packed or tpm statement format paths. Chromium, Firefox, and Safari implemented WebAuthn with packed, tpm, fido-u2f, and android-safetynet attestation, but the ECDAA branch within packed and tpm stayed unimplemented. The Yubico migration guide quoted above is the vendor-side confirmation of an industry-wide outcome [@yubico-migration].

Second, the largest authenticator vendors picked the Basic and AttCA attestation types instead of ECDAA. YubiKey 5 series ships with the packed format using a Basic Attestation key shared across a 100,000+-unit cohort [@yubico-yk5-attestation] [@fido-cert-levels]. Feitian, Google Titan, and other major FIDO2 authenticator vendors ship Basic Attestation under the same FIDO certification-policy cohort rule [@fido-cert-levels]. Microsoft Hello platform authenticators on Windows TPM-backed devices use the tpm attestation statement format with an AIK that a Microsoft-operated CA certifies -- the AttCA type, functionally a Privacy-CA [@ms-hello-doc] [@azure-attestation]. The vendor base from which a WebAuthn relying party would actually see an attestation statement, in practice, never produced an ECDAA one.

Third, FIDO ECDAA v2.0 never advanced beyond Implementation Draft. The URL slug for the document literally encodes its status: fido-v2.0-id-20180227 -- the id-20180227 segment names the format <status>-<date>, and "id" is "Implementation Draft." It never reached "Proposed Standard" or "Approved Specification" in FIDO's process [@fido-ecdaa-v2]. A relying party making a long-term technology bet on an attestation statement format that has never advanced past Implementation Draft has no reason to invest in a verifier library.

Fourth, FIDO Basic Attestation's cohort-size rule (100,000+ authenticators per attestation group key, enforced contractually on the certified-authenticator side) gave the underlying privacy concern an operational answer [@fido-cert-levels]. A WebAuthn relying party that sees a Basic Attestation signature learns "this is one of at least 100,000 identical authenticators" -- a cohort large enough that the relying party cannot, in practice, recover individual identifying information from the attestation alone. The cohort rule does not require pairing arithmetic, does not need a verifier library, and works with the same packed and tpm attestation formats every relying party already implements.

The FIDO Basic Attestation cohort minimum is a particularly clean example of how operational rules can compete directly with cryptographic primitives. The privacy property a relying party wants -- "I cannot single out this device from its peers" -- can be obtained by (a) hardware-anchored zero-knowledge proofs that mathematically forbid linkage (cryptographic DAA), or (b) a contractual obligation that every batch of attestation keys covers at least 100,000 devices (FIDO Basic Attestation) [@fido-cert-levels]. The cryptographic answer is mathematically stronger. The operational answer is dramatically easier to debug, audit, and revoke. Production has consistently chosen the latter.

Key idea: ECDAA shipped chips. It never shipped verifiers. Standardization is necessary but not sufficient for production deployment: production cryptography needs verifier libraries, and verifier libraries are social phenomena -- they emerge from relying-party demand, SDK presence, incident-response tooling, and library-maintainer attention, none of which the cryptography itself produces. Cryptographic excellence does not predict deployment; library availability does.

This is the second aha. The reader entered §8 believing that a standardized cryptographic primitive backed by FIDO, three browser vendors, and a publicly authored attestation format would deploy. They exit understanding that ECDAA standardized everything except the social machinery -- and the social machinery is where production attestation actually lives.

If a consortium with FIDO's privacy mandate, browser-vendor coalition, and authenticator-vendor base could not generate enough relying-party momentum to keep ECDAA in WebAuthn, what chance did the silent option in TPM 2.0 ever have? The answer requires walking the Microsoft attestation stack.

9. Windows: A Billion Chips, Zero Production Use (2014-Present)

Microsoft has shipped over a billion Windows TPM 2.0 platforms [@ms-pluton-blog] [@wiki-windows-11]. Microsoft has not shipped a Windows DAA API. The two facts are not in tension. They are the story.

The shipping Windows attestation stack is documented and unambiguous. Microsoft Azure Attestation is the production-grade attestation service. Its public architecture document describes the protocol in five paragraphs that read, line for line, like TPM 1.1 from 2003 [@azure-attestation]:

"Every TPM ships with a unique asymmetric key called the endorsement key (EK)... A certification authority (CA) establishes trust in the TPM either via EKPub or EKCert... A device proves to the CA that the key for which the certificate is being requested is cryptographically bound to the EKPub and that the TPM owns the EKPriv. The CA issues a certificate with a special issuance policy to denote that the key is now attested as protected by a TPM."

The architecture is the Privacy-CA architecture. The Microsoft-operated CA inputs an EK certificate and outputs a JWT that downstream Microsoft services (Defender for Endpoint device-compliance, Intune Conditional Access policies, Entra ID conditional access, customer-defined Azure Attestation policies) consume. The Windows Health Attestation Service, the older Microsoft surface that predated Azure Attestation, used the same broker model with different deployment shape. The Defender for Endpoint device-compliance flow that gates Conditional Access on attested TPM boot state consumes WHAS or Azure Attestation JWTs, not raw DAA quotes.

Microsoft Pluton's published surface tells the same story from the silicon side. Pluton is the security processor Microsoft has been shipping in successive Windows-class platforms. Its Microsoft Learn page enumerates the cryptographic algorithms and platform-security primitives the processor exposes [@pluton]. The page is exhaustive about TPM 2.0 baseline algorithms (RSA-2048, ECDSA over NIST P-256, SHA-2 family). It contains zero occurrences of ECDAA, of TPM_ALG_ECDAA, or of any phrase like "anonymous attestation." Insufficient public evidence to assert that Pluton implements ECDAA; sufficient evidence to assert that Pluton's published surface does not advertise it.

The Windows API surface gap is the third piece of evidence. The TPM Base Services (Tbsi_* functions in Tbs.dll) expose TPM2_Commit and TPM2_Sign to user-mode applications -- but only as raw command-buffer submissions. There is no BCryptDirectAnonymousAttestation. There is no NCryptDaaSign. There is no Web Authentication API wrapper that surfaces ECDAA.

The TPM Platform Crypto Provider (PCP) that Windows ships as part of the Cryptography Next Generation (CNG) framework supports RSA and ECDSA TPM-backed keys but does not surface ECDAA. The TSS.MSR open-source TPM stack from Microsoft Research does not ship a DAA wrapper. An application developer who wants ECDAA on Windows today writes raw TBS_SUBMIT_COMMAND byte buffers against the documented TPM 2.0 command numbering, manages the Join protocol against an Issuer of their own provisioning, and verifies the resulting signatures with a library they wrote themselves or pulled from a research-grade implementation.

The interesting question is why. Microsoft has never published a "we considered DAA and chose the broker model because..." statement. Treating that absence honestly, the four reasons below are inferences from observable architecture decisions, not Microsoft-engineer-published rationales. The article labels them as such.

First, operational simplicity. A hosted CA with audit logs is more debuggable than a per-relying-party DAA verifier with no central audit point. When a device fails attestation in production, the on-call engineer reading the Azure Attestation logs can answer "why did this device fail?" in seconds; the same question against a DAA verifier requires reasoning about pairing arithmetic, basename derivation, and Issuer-credential validity. Engineering organizations choose architectures whose failure modes they can debug.

Second, revocation economics. A Privacy-CA can revoke an AIK by removing one certificate from its issued-certificate store. Revoking a DAA credential, in the construction TPM 2.0 ships, requires either EPID-style signature-based revocation -- which the TPM 2.0 ECDAA scheme does not provide -- or a private-key list distributed to every relying party (extracting the private key from the misbehaving TPM is presumed possible after compromise, and verifiers then check that the signing key is not on the list). The CA's revocation primitive is a database delete. The DAA revocation primitive is an SDK rollout to every consumer of the verification library.

Third, the relying-party stack. DAA verifier libraries are not present in any mainstream cloud platform's SDK. The .NET CryptoNG surface, the Java JCA, the Python cryptography library, the Go crypto standard library, the Rust ring and dalek ecosystems -- none ship an ECDAA verifier. X.509 / PKI verifier libraries, by contrast, are everywhere. A relying party building on top of mainstream SDKs gets PKI verification for free; gets DAA verification for nothing close to free.

Fourth, the Windows API surface gap is itself the obstacle. Adding a BCrypt / NCrypt / WebAuthn DAA wrapper to Windows requires designing a new key-storage provider contract, defining the JOIN-protocol service interface, writing the conformance test suite, drafting the security documentation, and rolling it out on the Windows release calendar. That is a project the size of Windows Hello's. Microsoft has not, to public knowledge, prioritized it.

flowchart TD HW["TPM 2.0 hardware
(discrete or Pluton)
TPM_ALG_ECDAA may be present"] TBS["TPM Base Services
(Tbs.dll, kernel)"] PCP["TPM Platform Crypto Provider
(BCrypt / NCrypt)
RSA and ECDSA only"] AZ["Microsoft Azure Attestation
(Privacy-CA architecture)"] WHAS["Windows Health Attestation Service
(Privacy-CA architecture)"] RP["Intune / Defender / Entra
Conditional Access enforcement"] HW --> TBS TBS --> PCP PCP --> AZ PCP --> WHAS AZ --> RP WHAS --> RP HW -.->|"ECDAA path exists
no Windows API"| HW

The deeper reading -- the one that makes Microsoft's choice look structural rather than accidental -- starts from a comparison the four inferences above already pointed toward.

Key idea: Privacy-CA brokers and DAA solve the same problem -- prove the TPM is genuine without disclosing which TPM. They differ only in where the trust assumption lives. The broker treats privacy as an operational policy (the CA promises not to log, audit logs prove it kept the promise, regulators enforce the promise). DAA treats privacy as a mathematical property (the issuer cannot link, period, no audit needed). The architecture that wins in production is the one with the smaller operational surface, not the one with the better cryptographic guarantee.

This is the third aha. The reader entered §9 believing that cryptographic superiority should eventually win in production, and that Microsoft's non-adoption of DAA must be an oversight or a missed product opportunity. They exit understanding that the deployment-economics asymmetry is structural: a broker-mediated attestation flow reduces, end-to-end, to standard X.509 plumbing every cloud SDK already ships, while a DAA-mediated flow requires bespoke verifier libraries, bespoke revocation infrastructure, bespoke debugging tooling, and bespoke incident-response runbooks. Cloud-platform organizations have spent the last ten years building world-class operational machinery for X.509 attestation. They will not throw it away for a cryptographic property no compliance regime currently demands.

Note: The four reasons compound. The broker model gives a single audit point, a database-delete revocation primitive, an SDK that ships in every major language, and a debugging story the on-call engineer can walk through at 3 a.m. DAA gives mathematical privacy and requires every one of those operational properties to be rebuilt from scratch. Cloud platforms have, repeatedly and consistently, picked the architecture whose operational properties are easier to ship -- not because they do not understand the cryptographic alternative, but because the cryptographic alternative would require them to discard the operational machinery they already have. This is the structural reason DAA has stayed in firmware on a billion chips and out of production attestation flows on all of them.

If the broker calculus is this durable, is there any future world in which DAA wins? Two, and both are research-stage with decade-long horizons.

10. Theoretical Limits and Open Problems

What can DAA never do? Where does the next decade of research go? Three open problems organize the active research community in 2026.

10.1 What DAA cannot do

The first honest statement is the negative one. A correctly implemented DAA scheme does not prevent a compromised TPM from signing for the cohort it belongs to. The EK certificate attestation must be honest at manufacture time; if a TPM's secret membership value f leaks to an attacker (through fault injection, through side-channel extraction, through a firmware backdoor), the attacker can produce ECDAA signatures indistinguishable from legitimate ones until the TPM's f is added to a revocation list. The same constraint applies to every group-signature scheme.

A second hard limit is per-basename linkability. The user-controlled-linkability property gives a TPM the choice of linkable or unlinkable signing -- but once a verifier has seen the pseudonym N_V = ζ^f mod Γ for a particular (TPM, bsn) pair, the linkage for that basename is permanent. A misbehaving TPM that wants its history with a particular relying party forgotten cannot, by signing under a different basename, retroactively unlink past sessions.

A third limit is rogue-key scalability. The TPM 2.0 ECDAA scheme detects rogue keys by checking each signature against a list of compromised-f values the verifier maintains. For small lists this is cheap. For very large lists -- imagine a deployment where 1% of the chip population leaks f to attackers and the verifier must check every signature against ten million revoked values -- the constant factor matters. EPID's Sig-RL mechanism uses signature-based revocation that scales better; the TPM 2.0 ECDAA scheme does not include it.

10.2 The One-TPM-to-Bind-Them-All fix

In 2017 a team consisting of Jan Camenisch, Liqun Chen, Manu Drijvers, Anja Lehmann, David Novick, and Rainer Urian published "One TPM to Bind Them All: Fixing TPM 2.0 for Provably Secure Anonymous Attestation" at IEEE S&P 2017 [@one-tpm-2017]. The paper demonstrated a Diffie-Hellman-oracle attack against the TPM 2.0 ECDAA interface as shipped: a malicious host could query the TPM in a way that gave the host a DH-oracle relative to the TPM's secret f, effectively breaking the unlinkability property. The proposed fix had been published the previous year by Camenisch, Drijvers, and Lehmann at TRUST 2016 [@cdl-2016] [@cdl-2016-eprint]; library implementations of DAA published from 2017 onward incorporate the fix.The CDL16 fix is library-level, not silicon-level. The TPM 2.0 ECDAA command surface in the chip remains as shipped; the software that drives it must use the corrected protocol sequence to avoid presenting the host-controlled DH oracle. As of late 2025, the TCG normative TPM 2.0 Library Specification text has not been amended to require the corrected sequence. Implementations of DAA on top of TPM 2.0 -- the FIDO ECDAA v2.0 library, the Camenisch-Drijvers-Lehmann reference code, modern academic ECDAA implementations -- follow CDL16. Implementations written against the bare TPM 2.0 Library Specification without reading CDL16 are vulnerable.

10.3 Post-quantum DAA

Shor's algorithm is fatal to DAA. Every classical DAA construction -- BCC 2004, BCL 2008, CPS 2010, CDL 2016 -- relies on the hardness of discrete logarithms in elliptic-curve groups, the hardness of strong-RSA factoring, or both. A cryptographically relevant quantum computer breaks all of them. Post-quantum DAA is therefore active research, with no production deployment as of 2026. Three candidate families are being actively explored:

Symmetric-primitive DAA. Dan Boneh, Saba Eskandarian, and Ben Fisch presented "Post-quantum EPID Signatures from Symmetric Primitives" at CT-RSA 2019 [@bef-2019], building a post-quantum group signature from one-way functions and Merkle trees. The construction has classical post-quantum security guarantees but pays a steep size cost.
Lattice-based DAA. Rachid El Bansarkhani and Ali El Kaafarani published "Direct Anonymous Attestation from Lattices" as IACR ePrint 2017/1022 [@bk-2017-eprint], the earliest such proposal in the literature. The state-of-the-art lattice DAA construction is the 2024 Collaborative Segregated NIZK ("CoSNIZK") work by Liqun Chen, Patrick Hough, and Nada El Kassem [@cosnizk-2024], achieving signatures of approximately 38 kilobytes -- an order of magnitude smaller than the earliest lattice proposals but still two orders of magnitude larger than CPS 2010 ECDAA.
Hash-based DAA. Liqun Chen, Changyu Dong, Nada El Kassem, Christopher Newton, and Yalan Wang published "Hash-Based Direct Anonymous Attestation" at PQCrypto 2023 [@hashdaa-2023], building DAA from SPHINCS+-style stateless hash-based signatures. Size and speed remain unfavorable for TPM 2.0 firmware budgets.

The blocker for any of these reaching production TPM firmware is not academic. The TPM 2.0 normative algorithm set does not include lattice primitives. A post-quantum DAA in TPM 2.0 would require introducing TPM_ALG_DILITHIUM, TPM_ALG_FALCON, TPM_ALG_KYBER, or some equivalent into the spec, mandating support in the PC Client Platform TPM Profile, and rolling out across the OEM TPM-vendor base. That is, at minimum, a three-to-five-year standards effort that the TCG has not, as of late 2025, publicly committed to. CoSNIZK at 38 kilobytes is also two to three times larger than the largest signature any deployed TPM 2.0 firmware budgets for; the TPM-side compute time at quantum-safe parameter sets is currently measured in seconds rather than tens of milliseconds.

10.4 DAA for confidential computing

The other future-world thread is confidential computing -- the family of CPU-anchored isolated-execution primitives (Intel SGX, Intel TDX, AMD SEV-SNP, ARM CCA) that need their own attestation surfaces. Intel SGX attestation initially used EPID and has since migrated to DCAP, a vendor-CA broker similar in shape to Microsoft Azure Attestation. AMD SEV-SNP and Intel TDX use vendor-rooted PKI from the start.

Whether DAA-style group-signature schemes are appropriate for VM-level attestation -- where cohorts are small (per-region TDX hosts in a given hyperscaler datacenter), where the verifier is often a small set of well-known cloud-platform endpoints, and where traffic-analysis leakage between confidential VMs and Privacy-CA-like services is itself a threat -- is an open architectural question. The 2026 default is "vendor-CA broker"; the academic community continues to argue that cryptographic DAA would be a better match for the threat model. Production has not, so far, agreed.

A note on Java Card DAA prototypes. A small number of academic implementations of DAA on Java Card secure elements appeared between 2014 and 2017 -- Camenisch and others published smartcard-class implementations as proofs of concept. None reached production deployment. The reasons appear to be the same operational-economics asymmetry that limits TPM 2.0 ECDAA adoption: Java Card environments lack the relying-party verifier libraries that would consume the output. This is inference; no Java Card vendor has, to public knowledge, published a "we evaluated DAA and chose not to ship it" statement.

These are the open problems for researchers. What about the rest of us, on Monday morning?

11. Practical Guide and Frequently Asked Questions

Five roles, one Monday morning. Where does this leave you?

For a Windows platform engineer. The minimum viable Windows DAA API surface is approximately a BCryptCreateDaaContext, BCryptDaaJoin, BCryptDaaSign, and BCryptDaaVerify set, plus an NCryptDaaKeyHandle for key-storage-provider lifecycle, plus a Web Authentication API surface that consumes ECDAA attestation. Shipping all of that costs a Hello-sized engineering investment. If Pluton's published surface ever advertises ECDAA, an OEM-side integration becomes possible. Today the answer is that DAA is not available through any supported Windows API.

For an attestation-provider product engineer. Pick a Privacy-CA broker architecture for production. The comparison table below makes the trade-offs explicit. Cryptographic DAA does not pay for the architectural switch unless the relying-party privacy threat is specifically the broker itself -- a threat model that, in 2026, no shipping production attestation product publicly assumes.

For a FIDO authenticator vendor. ECDAA attestation is not a viable production choice in 2026. The path to it becoming viable runs through verifier libraries in Chromium, Firefox, and Safari; relying-party SDK support across Auth0, Okta, Microsoft Entra, and Google Identity Platform; and a non-deprecated WebAuthn Level N specification that re-adds the format. None of those preconditions are visibly in progress.

For an academic zero-knowledge-proof researcher. Four open problems map onto production needs: post-quantum DAA at TPM-firmware-shippable signature sizes (the current state-of-the-art at 38 kilobytes is too large), threshold-issuer DAA (no single party can issue a credential), confidential-computing DAA (for small-cohort VM attestation), and IoT DAA (for milliwatt-class energy budgets). Each is publishable; none yet has a deployment path.

For a privacy-tech advocate or policymaker. The framing that helps Microsoft, Google, and AWS engineering teams hear the request is "the broker can be compelled by a subpoena; the math cannot." The framing that does not help is "your cryptography is worse than the academic alternative." The first is a threat-model conversation that engineering organizations can engage with; the second is a technology conversation they have already had and decided.

Comparison: four production architectures for attested privacy

Property	Privacy-CA broker	TPM 2.0 ECDAA	EPID 2.0	Vendor-CA (Apple, AWS Nitro, Google)
Trust assumption	Operational (CA promises not to log)	Cryptographic (issuer cannot link)	Cryptographic (issuer cannot link)	Operational (vendor CA promises not to log)
Anonymity from verifier?	If CA does not log	Yes (per-basename)	Yes (per-basename)	If vendor does not log
TPM-side sign time	Milliseconds (AIK signing)	Tens of milliseconds	Tens of milliseconds	N/A (signing on vendor silicon)
Signature size	Hundreds of bytes (AIK)	Hundreds of bytes	Hundreds of bytes	Hundreds of bytes (X.509 over signed JWT)
Revocation	CA database delete	Private-key list (TPM 2.0)	Sig-RL (signature-based)	Vendor revocation list
Implementer complexity	Low (X.509 PKI everywhere)	High (BN-P256 pairing libraries)	High (vendor SDK required)	Low (vendor SDK ships it)
Standardization	TCG (2003)	TPM 2.0 + ISO 20008-2 Mech 4	ISO 20008-2 Mech 4	Vendor-proprietary
Best suited for	Cloud attestation at hyperscaler scale	Hardware-anchored attestation where broker is the threat	Intel-deployed enclave attestation	Vendor-platform attestation
2026 deployment scale	Billions of attestations per day	Essentially zero production verifiers	2.4B+ EPID keys per RSAC 2016	Billions of attestations per day

The "essentially zero production verifiers" entry for TPM 2.0 ECDAA is the deployment story this article exists to explain. The cryptography is in firmware on hundreds of millions of devices; the verifier side, in 2026, is research-grade libraries and the FIDO ECDAA-Verify reference code. No production cloud-platform SDK ships an ECDAA verifier.

Four things, in order. First, Pluton's published surface advertises `TPM_ALG_ECDAA` and an Issuer key-management story (a Microsoft-operated DAA Issuer for Windows devices, with documented enrollment and revocation flows). Second, a Cryptography Next Generation API surface (`BCryptDaaSign`, `NCryptDaaKey*`) that exposes the TPM2_Commit / TPM2_Sign sequence behind a single managed-language call. Third, a Web Authentication API extension that surfaces ECDAA attestation as a first-class statement format the same way the `tpm` format is today. Fourth, an Azure Attestation policy mode that consumes ECDAA signatures and produces JWT outputs downstream Microsoft services already understand. None of these are technically blocking; all four require a multi-year roadmap commitment that, as of late 2025, Microsoft has not publicly made. This is a thought experiment about technical feasibility, not a forecast about Microsoft strategy.

The companion piece to this article is the TPM in Windows article, which walks the broader TPM 2.0 command surface ECDAA sits inside.

It depends on what the laptop ships. The TPM 2.0 Library Specification names `TPM_ALG_ECDAA`. The TCG PC Client Platform TPM Profile made the algorithm optional in v1.04 (February 2020) and has carried that designation through v1.07 RC1 (December 2025), so a conformant Windows-class platform is allowed to omit it. Many discrete TPM 2.0 modules (Infineon, STMicroelectronics, Nuvoton) do implement the algorithm; Microsoft Pluton's published documentation does not advertise it. The honest answer is "look at your specific TPM vendor's algorithm capability table" -- and that even if your TPM does support the algorithm, Windows ships no API to use it [@tpm-library-spec] [@tcg-ptp] [@pluton] [@wiki-daa]. Microsoft has not published an explicit rationale. Four inferable reasons are visible from the architecture: (1) operational simplicity -- a hosted CA is easier to debug than a per-relying-party DAA verifier; (2) revocation economics -- a CA can revoke an AIK by deleting a certificate, while DAA revocation requires a private-key list distributed to every verifier; (3) a missing relying-party verifier-library stack; (4) no Windows API surface for ECDAA. All four are inferences. The shipped architecture is the Privacy-CA-shaped flow documented at the Microsoft Learn attestation page [@azure-attestation]. WebAuthn Level 1 (March 2019) registered ECDAA as an attestation *type* (Basic, Self, AttCA, ECDAA, None) carried inside the `packed` and `tpm` attestation statement formats. The Level 1 specification text contains 63 references to "ecdaa." WebAuthn Level 2 (April 2021) removed the type entirely; an independent grep of the Level 2 Recommendation HTML returns zero occurrences of "ecdaa." The Yubico migration guide for its WebAuthn server library states verbatim that "this attestation type was removed from WebAuthn Level 2" and that "ECDAA support has not been implemented in this library." The format has not been resurrected as of 2026 [@webauthn-1] [@webauthn-2] [@yubico-migration]. EPID is a DAA variant with one cryptographic addition: signature-based revocation (Sig-RL), which lets a verifier prove that a candidate signature was not produced by the same signer as any signature on a revocation list. The TPM 2.0 ECDAA scheme is the Chen-Page-Smart 2010 construction; EPID 2.0 is essentially the same construction with Sig-RL added. Intel positions EPID separately because of its production deployment (2.4 billion-plus keys shipped per Intel's RSAC 2016 disclosure, used for SGX attestation, Widevine, and several Intel chipsets), its specific licensing structure (royalty-free under Intel's contribution to ISO/IEC 20008 / 20009), and its open-source SDK that Intel maintained until archiving in 2023 [@brickell-li-epid-2007] [@brickell-li-tdsc-2012] [@wiki-epid] [@epid-sdk]. Active research, no production deployment as of 2026. The leading constructions are lattice-based (CoSNIZK 2024 at approximately 38 kilobytes per signature [@cosnizk-2024]), hash-based (the 2023 PQCrypto paper from SPHINCS+ [@hashdaa-2023]), and symmetric-primitive-based (Boneh-Eskandarian-Fisch CT-RSA 2019 [@bef-2019]). The barriers to shipping any of them in a TPM are fundamental: TPM 2.0 firmware does not implement lattice primitives, signature sizes at 30+ kilobytes are incompatible with current attestation-latency budgets, and no relying-party verifier library exists. A post-quantum DAA TPM is a 2030s project at the earliest. No. The Stage 0a focus-premise audit of this article demoted that framing as not supported by evidence. The accurate claim is "standardized in the TPM 2.0 Library Specification (2014); optional in the TCG PC Client Platform TPM Profile since February 2020; present on many discrete TPMs (vendor documentation confirms); absent from Microsoft Pluton's published algorithm surface; supported by no Windows API." That hedged statement is the one the article carries from its first 200 words through to this FAQ [@tpm-library-spec] [@tcg-ptp] [@pluton].

The cryptography is finished. The standardization is finished. The hardware is in the field. What is missing is the social machinery -- the verifier libraries, the SDK presence, the operational tooling, the incident-response runbooks, the regulator demand -- that turns cryptography into deployment. Direct Anonymous Attestation is the cleanest example in platform security of a primitive that won every standardization fight and lost every deployment one. The lesson is not that the cryptography is wrong. The lesson is that cryptography is necessary but never sufficient. Production systems are social systems whose mathematical components, however elegant, must compete with operational alternatives whose properties are easier to ship.

The companion pieces in this series are The TPM in Windows (the cryptographic primitive plumbing TPM 2.0 ECDAA sits inside) and the Microsoft Pluton continuation article (Pluton's published capability surface and the negative claim this article rests its §9 hedge on). The Measured Boot piece -- forthcoming -- walks the data that a hypothetical DAA quote would attest. If those three articles arrive together, the picture of Windows attestation as a system rather than a primitive becomes complete.