Trusted computing base

What is in your TCB?

Your security rests on more parts than you think. Count them.

The trusted computing base, or TCB, is everything that has to work correctly for a security goal to hold. If one part of it is wrong or hostile, the goal fails, and nothing inside the system can tell you.

Most people name the application and the operating system. On an ordinary computer the list is much longer. It includes code you never installed, chips you never chose and people you never met.

Start with an ordinary computer

On an ordinary computer you depend on every part in the table, and none of them can be checked from outside. Pick a technology to see what it changes.

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.

Two things you can do with a TCB

Make it smallerLate launch, enclaves and confidential virtual machines remove parts. Each also adds a little of its own, and none removes the processor, its maker or your own build.

Make it checkableMeasurement and attestation leave a part in the TCB, and let someone outside check which version runs. You still depend on it. A checked part that changes has to be checked again. That is re-attestation.

Why "trusted" is a misleading word

In this field "trusted" does not mean "good". It means "able to break your security". A smaller TCB is better because there is less that can fail. A checkable TCB is better because you can find out what you are depending on. Neither makes a part correct.

A teaching model. Real platforms differ in detail, and each technology has known limits. See the vulnerability tracker.

Now do it for your own product. Seven questions show what is in its TCB, what you can prove and what you take on trust.

Check your product's TCB

What is in your TCB?

Start with an ordinary computer

Leaves the TCB

Can now be checked

Is added

Two things you can do with a TCB

Why "trusted" is a misleading word