Sources checked 11 Sep to 15 Oct 2026

Compute verification

The Verification Stack

Three of the stack’s 50 mechanisms fail if a chip gives up its key. Published attacks have extracted identity or attestation keys from four families of security hardware; for NVIDIA’s data-centre GPUs, a search on 7 October 2026 found no published extraction.

The stack’s 50 mechanisms in seven layers, from physical integrity at the bottom to institutional checks at the top. Factory key provisioning, set in italic, is an assumption the standards record.The stack’s 50 mechanisms in seven layers, from physical integrity at the bottom to institutional checks at the top. Factory key provisioning, drawn dotted, is an assumption the standards record. Select any box to read it in the card.Tap any square to read it below.

Assume this fails

Shipping or in practice today
Demonstrated
Proposed
Argued against
Italic: an assumptionAn assumption
Assumed to fail
Fails with it
Dependency, pointing to the part that needs it
Dependency, pointing to the part stronger with it
The failure’s path
The part in the card

If Hardware identity key fails, these fail with it:

Remote attestation needs it, 4 of the 35 documents that state how mechanisms relate
Workload attestation needs it, 2 of the 35 documents
Delay-based location needs it, 9 of the 35 documents

A dependency is one mechanism needing another, or stronger with it.

Count a dependency when it is stated in

Any document 197 dependencies · 30 mechanisms fail2 or more documents 39 dependencies · 3 mechanisms fail3 or more documents 19 dependencies · 2 mechanisms fail

At this setting, 39 dependencies count; 158 stated by one document do not. Never counted: 109 stated for one design only and 62 that Scrutica inferred.

Silicon root of trust · shipping in hardware today

Hardware identity key

Assumed to fail. In 2 or more documents, three mechanisms need it; it needs two others and is stronger with one.

These fail with it

Remote attestation needs it, 4 of the 35 documents that state how mechanisms relate
Workload attestation needs it, 2 of the 35 documents
Delay-based location needs it, 9 of the 35 documents

A dependency is one mechanism needing another, or stronger with it.

Count a dependency when it is stated in

Any document 197 dependencies · 30 mechanisms fail2 or more documents 39 dependencies · 3 mechanisms fail3 or more documents 19 dependencies · 2 mechanisms fail

At this setting, 39 dependencies count; 158 stated by one document do not. Never counted: 109 stated for one design only and 62 that Scrutica inferred.

A secret cryptographic key held inside the chip (fused or stored at manufacture) that lets the chip sign challenges, so a remote party can tell that a message really comes from that physical chip. Its value depends on the key staying unextractable.

A device-specific public and private key pair are created on the device, ideally using a dedicated security module. The public key is shared externally.

Aarne et al. 2024, p. 14

It needs: Factory key provisioning, 2 of the 35 documents that state how mechanisms relate
Hardware root of trust, 2 of the 35 documents and 2 more that imply it (Scrutica’s reading; not counted)
Is stronger with Tamper response, 3 of the 35 documents
Needed by: the three listed above.

More dependencies and other relations (18)

Not counted at this setting

Is needed by Confidential computing, 1 of the 35 documents
Strengthens Hardware root of trust, 1 of the 35 documents
Is needed by Workload classification, 1 of the 35 documents
Is needed by Interconnect limits, 4 of the 35 documents say it holds for one design only (not counted)
Is stronger with Tamper evidence, 2 of the 35 documents say it holds for one design only (not counted)
Is needed by Offline licensing, 3 of the 35 documents, none counted: 1 that says it holds for one design only and 2 that imply it (Scrutica’s reading)
Is needed by Chip registry, 1 of the 35 documents says it holds for one design only (not counted)
Is needed by Declarations and inventories, 1 of the 35 documents says it holds for one design only (not counted)
Strengthens Declarations and inventories, 1 of the 35 documents says it holds for one design only (not counted)
Is needed by On-chip compute metering, 1 of the 35 documents says it holds for one design only (not counted)
Is needed by Weight-snapshot logging, 1 of the 35 documents says it holds for one design only (not counted)
Is needed by Hardware root of trust, 1 of the 35 documents implies it (Scrutica’s reading; not counted)
Is needed by On-site inspection, 1 of the 35 documents implies it (Scrutica’s reading; not counted)
Strengthens Workload attestation, 1 of the 35 documents implies it (Scrutica’s reading; not counted)

Other relations

Can be replaced by Chip serial numbers, 1 of the 35 documents
Enables Weight-snapshot logging, 1 of the 35 documents
Can be replaced by Hardware fingerprinting, 1 of the 35 documents
Weakens Delay-based location, 1 of the 35 documents implies it (Scrutica’s reading; not counted)

Eleven verified published results break it; three more, partly verified, claim to; one more recovered part of an identity key.

Results not counted (4)

Partly verified: Intel CSME boot-ROM IOMMU window, SGX.Fail and Intel SGX Fuse Key0 extraction on Gemini Lake.

Part of an identity key only: Google Project Zero / Google Cloud security review of the AMD Secure Processor.

Of the 35, 13 propose it, 1 argues against relying on it for location checks and 4 discuss it; 9 of the 14 reports charted below take a position.

The documents, by position (18)

Proposed in Aarne et al. 2024, Brass and Aarne 2024, Brass 2025, Petrie et al. 2025, Petrie and Aarne 2025, Baker et al. 2025, Scher and Thiergart 2024, Shavit 2023, Petrie 2024, O’Gara et al. 2025, Feldgoise et al. 2026, Avellar and Grunewald 2026 and Rahman and Tajdari 2026.

Argued against relying on it for location checks in Tee and Happel 2026.

Discussed in Kulp et al. 2024, Harack et al. 2025, Heim et al. 2024 and Cankaya 2026.

Quotations (7)

It establishes

Cryptographic proof of identity, which is used to verify that the replies the landmarks are getting are actually coming from the real asset.

Brass and Aarne 2024, p. 17

It leaves open

While it is difficult to be confident, existing chips are likely insecure: they do not appear to have undergone extremely rigorous testing, and the threat model assumed in this report is that of the most capable nation-state actors.

Scher and Thiergart 2024, p. 16

Why ‘shipping in hardware today’

This device-unique private Identity Key (IK) is burned into fuses of each H100; the public key is retained, but all copies of these private keys are destroyed during the manufacturing process.

NVIDIA, Confidential Compute on NVIDIA Hopper H100 (WP-11459-001 v1.0), p. 22

Statements about different attackers

Are today’s chips secure enough to host governance mechanisms?

Against physical attacks repeated across thousands of chips

Public documentation suggests that NVIDIA’s H100 AI chip already has these security features

Petrie 2024, PDF p. 1

Without additional hardware modifications, the system is susceptible to physical hardware attacks. However, these attacks might require expensive equipment and could be difficult to reliably apply to thousands of AI chips.

Petrie 2024, PDF p. 1

Against the most capable nation-state actors, or sophisticated physical attacks

Scher and Thiergart 2024, p. 16 (quoted under ‘It leaves open’)

Note in particular that the implementation on NVIDIA’s Hopper chips is not intended to be robust against sophisticated physical attacks.

Harack et al. 2025, p. 50

Terms recorded for it in the documents (4)

device-specific public and private key pair
Unique secret keys
a chip’s private key
a private key for the chip

The hardware register records which accelerators document an identity key.

Where the reports stand on each mechanism

Eight of the 14 reports propose hardware root of trust, workload attestation, chip registry and training-run declarations, more than any other mechanism.

Each column is a report, by year; each row a mechanism; each mark is the report’s position and opens the page that states it. Select a mechanism’s name to list its positions with their pages.Columns are reports, by year; rows are mechanisms. Select a row to list its positions with their pages.

Proposes
Discusses
Mentions in passing
Argues against
Proposes, with an objection in the same report
Hardware identity key, selected on the stack

flexHEG I–III: the three-part report Flexible Hardware-Enabled Guarantees for AI Compute (2025)

Kulp et al. 2024, on what it proposes (p. 58): “We do not have sufficient confidence in HEM based solutions to recommend them for use, but we are confident that the topic warrants further research.”

Positions of 14 reports on the 50 mechanisms, each linked to the page that states it
Mechanism	Shavit 2023	Fist and Grunewald 2023	Egan and Heim 2023	Kulp et al. 2024	Aarne et al. 2024	Sastry et al. 2024	Heim et al. 2024	Brass and Aarne 2024	Scher and Thiergart 2024	flexHEG I–III, 2025	Kulp et al. 2025	Harack et al. 2025	Baker et al. 2025	Scher et al. 2026a
Mechanism	2023’23			2024’24						2025’25				2026’26
Physical integrity
Tamper evidence	p. 7	Technical annex		p. ix p. 58	p. 2	p. 39			p. 69	I, p. 19	p. 12	p. 60	p. 20
Tamper response				p. 31 p. 58	p. 2				p. 6	I, p. 7		p. 157	p. 6
Silicon root of trust
Hardware identity key	p. 9			p. 19	p. 14		p. 30	p. 17	p. 69	I, p. 7		p. 42	p. 20
Hardware integrity checks									p. 17	I, p. 6		p. 15	p. 6
Hardware root of trust	p. 13			p. 20 p. 58	p. 3	p. 57		2025 brief, p. 3	p. 68	II, p. 41		p. 49	p. 3
Firmware integrity
Confidential computing	p. 13		p. 13	p. 19	p. 2		p. 30	p. 20	p. 6	I, p. 18		p. 2	p. 15
Guarantee processor									p. 5	I, p. 3		p. 53	p. 21
Multi-party authorisation						p. 5				II, p. 3
On-chip rule enforcement					p. 13				p. 29	II, p. 6 I, p. 24 I, p. 25 III, p. 27			p. 13 p. 5
Identity and attestation
Chip serial numbers	p. 7	Technical annex		p. 44 p. 58	p. 15	p. 39		p. 7	p. 69 p. 69	II, p. 25		p. 44		PDF p. 26
Hardware fingerprinting	No position in the 14 reports
Remote attestation	p. 8			p. 19 p. 58	p. 3	p. 56	p. 30	p. 7	p. 69	I, p. 19		p. 48	p. 21	PDF p. 9
Workload attestation	p. 9			p. 47	p. 10	p. 41	p. 29 p. 29		p. 6	I, p. 19	p. vi	p. 111	p. 4	PDF p. 23
On-chip governance
Delay-based location					p. 10			p. 4	p. 4	I, p. 19	p. vi	p. 52
Interconnect limits	p. 9			p. ix p. 58	p. 10	p. 5		p. 9	p. 5	II, p. 25	p. vi	p. 108	p. 59	PDF p. 32
Offline licensing				p. viii p. 58	p. 2	p. 55		p. 9	p. 28	II, p. 38	p. vi	p. 108	p. 21	PDF p. 47
On-chip compute metering				p. 32 p. 58	p. 10		p. 28		p. 28	I, p. 18	p. 9		p. 42
Operating limits	p. 9			p. 35 p. 58	p. 27	p. 54		p. 9	p. 25	II, p. 38	p. 11	p. 122		PDF p. 32
Remote disable				p. 37	p. 9 p. 10	p. 5		p. 3		I, p. 33		p. 101		PDF p. 31
Unilateral backdoor				p. 38	p. 2
Verified shutdown									p. 25	I, p. 34		p. 105	p. 18	PDF p. 31 PDF p. 34
Weight-snapshot logging	PDF p. 1				p. 12				p. 6	I, p. 26		p. 41
Off-chip and workload checks
Analog-sensor accounting						p. 26	p. 29		p. 26	II, p. 10		p. 61	p. 4	PDF p. 31
Capture-and-commit records	p. 9								p. 40	II, p. 34		p. 13	p. 57
Model evaluations									p. 39	I, p. 18		p. 16	p. 26	PDF p. 25
Network taps									p. 77	II, p. 13		p. 14	p. 3
Neutral data centre	p. 12								p. 26	III, p. 32		p. 13
Other location methods		Technical annex	p. 12		p. 5			p. 5	p. 71					PDF p. 48
Proof-of-training	PDF p. 1		p. 20	p. 47	p. 16	p. 41	p. 39		p. 85	I, p. 28		p. 104	p. 43
Provider-side accounting			p. 3			p. 38	p. 4		p. 5	II, p. 2	p. 10		p. 65	PDF p. 32
Vendor fleet telemetry	No position in the 14 reports
Workload classification	p. 9		p. 12	p. 37	p. 13	p. 5	p. 23		p. 26 p. 93	II, p. 44	p. 9	p. 32	p. 32	PDF p. 6
Workload re-execution	p. 22 p. 10				p. 35				p. 5	II, p. 14		p. 118	p. 26	PDF p. 31
Zero-knowledge proofs	p. 22 p. 4					p. 58	p. 39		p. 116	II, p. 6		p. 80	p. 64
Institutional checks
Challenge inspection												p. 41	p. 32	PDF p. 21
Chip consolidation				p. 31					p. 4			p. 85		PDF p. 6
Chip registry	p. 6	Recommendation 1		p. 45	p. 3	p. 5	p. 34	p. 6	p. 15	III, p. 4	p. vi	p. 16	p. 14	PDF p. 26
Containment and surveillance	p. 13				p. 28		p. 20		p. 15	III, p. 11		p. 60	p. 32	PDF p. 31
Declarations and inventories						p. 38	p. 31	p. 8	p. 15	I, p. 31		p. 60	p. 3	PDF p. 26 PDF p. 9
End-use checks		Recommendation 2			p. 9	p. 39		2025 brief, PDF p. 1	p. 136	I, p. 11		p. 95	p. 8
KYC for compute providers			PDF p. 1	p. 8	p. 31	p. 5	p. 21		p. 83			p. 115	p. 57	PDF p. 48
National technical means			p. 14			p. 25		p. 12	p. 15 p. 142	III, p. 15		p. 10	p. 4	PDF p. 5
On-site inspection	p. 13	Technical annex		p. 28	p. 21	p. 77	p. 39		p. 4	III, p. 14	p. vi	p. 13	p. 52	PDF p. 6
Personnel interviews						p. 42			p. 46			p. 39	p. 4 p. 29	PDF p. 6
Personnel monitoring									p. 75	III, p. 11		p. 11
Production monitoring	PDF p. 1					p. 74			p. 4	III, p. 4		p. 35		PDF p. 5
Sampled chip inspection	p. 2	Recommendation 1		p. 28	p. 2				p. 15	III, p. 12	p. 11	p. 41	p. 26
Training-run declarations	PDF p. 1		p. 11	p. 38	p. 2	p. 5	p. 17		p. 26	III, p. 25		p. 103	p. 2	PDF p. 5
Transfer reporting	p. 13	Technical annex				p. 39	p. 34	2025 brief, p. 3	p. 67	III, p. 14		p. 35	p. 26	PDF p. 25
Whistleblower programmes			p. 14			p. 71	p. 34		p. 46	II, p. 55		p. 39	p. 3	PDF p. 25

About the columns

The columns are the reports named in Scrutica’s research brief, by year; the three flexHEG papers share one, as do the IAPS location report and its 2025 brief.

Positions come from 34 documents: the 17 these columns hold, and 17 more that only the mechanism cards above list; 32 of them are among the 35 documents that state how mechanisms relate, and the other 2 state no relation. Three of the 34 were read in selected sections only.

Published attacks on security hardware, 2001–2026

Eleven verified results extracted an identity or attestation key; of the 17 physical attacks whose sources state a cost, 14 needed $1,000 of equipment or less.

Each mark is one of the 123 published results, at its date, in the row of the hardest access it needed; a physical result is drawn in the cheapest band that holds the setup cost its source states.

Extracted an identity or attestation key
Forged attestation
Bypassed secure boot or rollback protection
Bypassed a performance limiter
Read or altered protected data
Hollow: partly verified against its sources
Ringed: TEE.fail, the result in the card

Show results on

All platforms 123Trusted execution environments in CPUs 64GPUs and GPU systems 29Trusted Platform Modules 5Boot code and signing keys 20Standalone security chips 10

Eight results are counted under two or more platforms and four under none, so the platform counts add to 128 for the 123 results.

94 of 123

Disclosed 28 Oct 2025 · IEEE Symposium on Security and Privacy 2026

TEE.fail

Chuang et al., TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition

It extracted an identity or attestation key from Intel SGX and TDX, with privileged software and physical access; its source puts the equipment at $1,000 or less.

Defeated

Key extraction, forged attestation, integrity and confidentiality.

Key taken

Intel SGX and TDX: Intel’s device-specific Provisioning Certification Key, from its Provisioning Certification Enclave.

In the stack

Breaks Hardware identity key, on Intel SGX and TDX; Remote attestation and Confidential computing, on the platforms listed as affected. The stack’s parts are generic and do not distinguish vendors.

Scrutica’s inference (no source states it): it also bears on Delay-based location, Workload attestation and On-chip compute metering.

Platforms (3)

Intel Xeon Scalable 4th/5th Gen and Xeon 6 with DDR5 (TDX, SGX); attack demonstrated on 5th Gen Xeon Scalable
AMD EPYC Zen 4 and Zen 5 with SEV-SNP and DDR5 (authors’ statement); attack demonstrated on Zen 5 with Ciphertext Hiding
Relayed, no key taken: NVIDIA Confidential Computing attestation (H100) as consumed by dstack-based applications

The keys it extracts are Intel’s, from SGX and TDX machines. NVIDIA’s attestation, as dstack-based applications consume it, was relayed from GPUs the attackers did not own:

Basically, the fact that Nvidia’s attestation reports are not bound to the identity of a specific CVM means we can ‘borrow’ Nvidia attestations from devices that aren’t ours.

tee.fail, FAQ, Oct 2025

Quotations (6), all from the authors

Needed

Moreover, our attack can be done in under $1000 by computer hobbyists using equipment readily available on the secondhand market.

tee.fail, p. 1, Sec. 1.1

Performing the above steps on our target machine described in Section 3 in an UpToDate attestation status, our attack took about 2 minutes to create the ciphertext mapping, and 13 minutes to execute the PCE and trace the ECDSA signing.

tee.fail, Sec. 6

Defeated

More specifically, we break SGX and TDX security guarantees by extracting attestation keys from machines in a fully trusted UpToDate attestation status.

tee.fail, p. 2, Sec. 1.1

Key taken

Combining this observation with Intel’s use of deterministic AES-XTS encryption, we are able to use our memory interposition setup to break the confidentiality of the PCE enclave, extracting its Provisioning Certification Key (PCK).

tee.fail, p. 2, Sec. 1.1

The PCE derives a device-specific provisioning certification key (PCK) via EGETKEY on a root provisioning key and CPU version info. This PCK is a 256-bit ECDSA key and is used to certify the QE’s identity and its attestation key.

tee.fail, p. 9, Sec. 6.2

As TEE.fail does not directly attack any Nvidia CC elements, there are no mitigations from the Nvidia CC side.

In answer to Are there any mitigations? How do I protect myself with Nvidia CC? · tee.fail, FAQ, Oct 2025

Vendor responses (3)

This most recent research, released in a paper titled ‘TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition’, does not change Intel’s previous out of scope statement for these types of physical attacks.

Intel · intel.com, 28 Oct 2025

AMD does not plan to provide mitigations since physical vector attacks are out of scope for AMD SEV-SNP.

AMD · amd.com, 28 Oct 2025

Intel has indicated that it is impossible to issue a microcode to update the inner workings of the memory encryption engine.

Intel, as reported by the authors · tee.fail, Oct 2025

NVIDIA: no public statement found as of 7 October 2026.

Identity and attestation keys extracted, by family of security hardware

A family is counted when a verified result has extracted a device-unique key that the hardware uses to prove its identity or attest its state.

Identity or attestation key extracted, verified
Partly verified, so not counted
A result on GPUs or GPU systems

AMD Secure ProcessorInsecure Until Proven Updated 2019, One Glitch to Rule Them All 2021 and MilanLaunchy + BadFuse 2026.
Intel CSME and PTTTPM-Fail 2019.
Intel SGX and TDXForeshadow 2018, SGAxe 2020, ÆPIC Leak 2022, Battering RAM 2025, WireTap 2025 and TEE.fail 2025.
RISC-V KeystonePhysical Memory Please 2026.
NVIDIA’s data-centre GPUs (Hopper, Blackwell). No published extraction of an identity or attestation key. Searches for attacks on H100-class confidential computing and for GPU attestation-key extraction last ran on 7 October 2026, and none of the 29 results the record holds on GPUs and GPU systems extracts one.

Not counted: 3 partly verified, 2 other kinds of key, 6 other families

Partly verified

Intel CSME and PTT · Intel CSME boot-ROM IOMMU window 2019.
Intel SGX and TDX · SGX.Fail 2022 and Intel SGX Fuse Key0 extraction on Gemini Lake 2024.

Other kinds of key from the four families

AMD Secure Processor · Google Project Zero / Google Cloud security review of the AMD Secure Processor 2022 (part of an identity key: parts of the SEV Platform Endorsement Key’s private ECDSA scalar).
Intel SGX and TDX · Downfall 2023 (another kind of key: an SGX sealing key from a test enclave, with no attestation key decrypted).

Families with no counted extraction

Google Titan M · Attacking Titan M with Only One Byte 2022 (another kind of key: keys protected by StrongBox, with no statement that the device attestation key was among them).
Infineon security controller · EUCLEAK 2024 (another kind of key: one account’s FIDO credential key, with no report that the attestation key was extracted).
NXP secure element · A Side Journey to Titan 2021 (another kind of key: a per-account FIDO credential key).
Raspberry Pi RP2350 · Antifuse OTP secret extraction by focused-ion-beam passive voltage contrast 2025 (no whole key: the bitwise OR of two adjacent antifuse rows).
Samsung TrustZone Keymaster · Samsung TrustZone Keymaster key extraction 2022 (another kind of key: hardware-protected keys of Android apps, among them the private key of a FIDO2 WebAuthn credential).
STMicroelectronics TPM · TPM-Fail 2019 (another kind of key: an ECDSA signing key of no stated kind).

The quotation each family is counted on (4)

AMD Secure ProcessorUsing this patched SEV firmware, we extracted the SEV state, see Section 3.1, including the CEK private key of three different AMD Epyc CPUs.Insecure Until Proven Updated 2019, arxiv.org, PDF p. 7, Section 3.3
Intel CSME and PTTWe generated a unique ECDSA attestation key (AK) using the Intel fTPM device on the VPN server.TPM-Fail 2019, usenix.org, p. 2067
Intel SGX and TDXUsing Foreshadow we have successfully extracted the attestation keys, used by the Intel Quoting Enclave to vouch for the authenticity of enclaves.Foreshadow 2018, foreshadowattack.eu
RISC-V KeystoneUsing this primitive, we demonstrate end-to-end attacks on the popular RISC-V Keystone TEE, achieving full enclave memory disclosure and, ultimately, completely undermining remote attestation guarantees by extracting the long-term platform measurement key.Physical Memory Please 2026, ojs.ub.rub.de, Abstract

About the record (5 results left off)

123 published results from 122 publications, each placed by the hardest access it needed; 25 are only partly verified. Five more in the record are left off: four defeat no stated property, and one could not be verified.