TCB check

What does your product trust?

Seven questions. You get the list of everything your product depends on, and which parts you can check.

Pick the answer closest to what you ship today. Nothing you select leaves this page. New to the term? The definition tool is further down this page.

1. Where does your product run?

On hardware we ship: a device, robot or vehicle On our own servers In ordinary cloud virtual machines On rented machines or sandboxes run by someone else In confidential virtual machines In enclaves

2. Which hardware root of trust does it use?

None A TPM A secure element or DICE The processor's own, through a TEE

3. What happens at boot?

It just boots Signatures are checked (secure boot) Boot is measured and reported to a verifier

4. How is the software built and released?

Built on our CI and deployed Builds are signed Builds are signed, with provenance that feeds the verifier

5. How do updates reach it?

By hand or by re-imaging Signed updates over the network Signed updates, and the product proves the new version afterwards

6. Does it include an AI model?

No Yes, loaded like any other file Yes, and the model is measured

7. Who can log in to the running system?

Our staff have root access Access is limited and logged Nobody: there is no standing access

Answered 0 of 7

Your TCB appears when all seven are answered.

What is a TCB? The definition tool

The trusted computing base is everything that has to work correctly for a security goal to hold. Below is an ordinary computer. Pick a technology and see what changes. The full explainer has the background.

The goal used here: keep an application's code and data safe from everyone except its owner, including whoever runs the machine. For each part the tool answers two questions. Do you depend on it? And can someone outside check it?

22 parts you depend on · 0 of them can be checked · 0 no longer in the TCB

Nothing is isolated and nothing can be checked from outside. You depend on every part in this list.

Part	Do you depend on it?	Can it be checked?
Hardware
The processor and its microcodeIt executes everything. A flaw here undoes every protection above it.	Yes	No
Chipset and management engineA small computer inside the computer, running before and beside your system.	Yes	No
Memory modulesThey hold your data. TEEs encrypt it, but attacks on the memory bus in 2024 and 2025 showed that the modules still matter.	Yes	No
Firmware in disks, network cards and management controllersEach device runs its own code and sees what passes through it.	Yes	No
Plug-in devices with direct memory accessA card or cable that can read and write memory behind the operating system.	Yes	No
Firmware
UEFI or BIOSThe first code of the machine. It decides what runs next.	Yes	No
System management modeHidden code that can interrupt and override the operating system.	Yes	No
Option ROMsCode that add-on cards run during boot.	Yes	No
Boot and operating system
BootloaderIt loads the kernel and can swap it.	Yes	No
Kernel and driversThey see all memory and every key.	Yes	No
Hypervisor or host operating systemBelow your system, with full control of it.	Yes	No
System services and everything running as rootAny of them can read or change your application.	Yes	No
Your software
Libraries your code linksThe C library, the crypto library, every parser. Their bugs are your bugs.	Yes	No
Language runtime or interpreterIt runs your code and can change what it does.	Yes	No
Your applicationThe part you meant to trust.	Yes	No
Configuration and secrets handlingA wrong setting can switch protection off.	Yes	No
People and process
Administrators of your own systemThey can do anything your operating system can.	Yes	No
Cloud or hosting provider staffThey control the host your system runs on.	Yes	No
Hardware makers and their supply chainThey built the root of trust and hold its keys.	Yes	No
Your build system, compilers and CIThey decide what your source code turns into.	Yes	No
Signing keys and update serversWhoever holds them can ship new code to every machine.	Yes	No
Anyone who can touch the machinePhysical access beats most protections, including memory encryption.	Yes	No
Added by this technology
The TPM and its makerThe chip that records and signs the measurements.	Yes	No
The processor maker's launch moduleSigned code from the processor maker that performs the late launch.	Yes	No
The processor maker's attestation service and signing enclavesThey sign and certify the evidence your verifier checks.	Yes	No
The isolation firmware (TDX module, AMD secure processor)Vendor code that enforces the isolation of the virtual machine.	Yes	No
The virtual firmware inside the virtual machineThe first code that runs in the protected machine.	Yes	No
The verifier and its reference valuesSomeone has to know what the right measurements are. That someone is now part of your TCB.	Yes	No

Depend on it means: if this part is wrong or hostile, the goal fails. It does not mean the part deserves trust. Can be checked means: a verifier can find out which version runs, through attestation. No in the first column means the part can no longer read or change the application's code and data. It can still stop the application from running.

Working on your TCB? A first call takes 30 minutes and commits you to nothing. Bring your product and the one question that worries you.

Next fixed date: EU Digital Identity Wallets are due in every member state on 24 December 2026, 42 days from now.

Book a 30-minute call Get expert help

NextIs it reattestable? Take the self-check →What a TCB is →Reattestation Review →

A simplified model of common architectures. It shows where to look; it does not replace a review of your design.

What does your product trust?

What is a TCB? The definition tool

Leaves the TCB

Can now be checked

Is added