Skip to content
All articles
October 5, 2026 12 min read

Roots of Trust: TPM, Secure Boot vs. Measured Boot, and the Trusted Computing Base

Chris Rees

Chris Rees

25+ years in IT · Pluralsight author, 4.6/5 across 2,000+ ratings

Roots of Trust: TPM, Secure Boot vs. Measured Boot, and the Trusted Computing Base
Skillthropicwww.skillthropic.com

Full-disk encryption protects a laptop only if the code that asks for the passphrase is the code the vendor shipped. An access control decision is only as good as the kernel that enforces it. CISSP Domain 3 spends objectives 3.4 and 3.5 on the layer under everything else: the hardware and firmware that the rest of the system has to trust because it cannot verify them. The vocabulary is dense, but it reduces to one question asked at each layer: what is the smallest thing we have to trust, and how do we know it is what we think it is?

Trust has to start somewhere

A root of trust is the component you cannot check, because there is nothing below it to check with. Everything above it can be verified by something below it, all the way down to that root. Modern platforms put the root in hardware, because hardware is harder to change than software, and build a chain upward from it: firmware verified by hardware, bootloader verified by firmware, kernel verified by bootloader, and so on.

The exam's framing for the software half of this is older than the hardware and still tested.

The trusted computing base and the reference monitor

The trusted computing base is everything that enforces the security policy: the kernel, the security-relevant drivers, the hardware they depend on. The design goal is to keep it small, because every component inside it is a component whose failure breaks security. That is why "minimize the TCB" sits beside "keep it simple" in the secure design principles.

Inside the TCB, the reference monitor is the concept of the thing that checks every access. It has three required properties, and the exam tests them: it must be tamper-proof, it must be always invoked (no access can bypass it), and it must be small enough to be verified. The security kernel is the actual implementation of the reference monitor in a real system: the code that does the checking. Concept versus implementation is the distinction a stem will probe.

Protection rings

Four concentric protection rings: ring zero at the center holding the kernel with the most privilege, ring one for operating system components, ring two for drivers and utilities, ring three at the outside for user applications with the least privilege, and a note that most systems use only rings zero and three PRIVILEGE DECREASES OUTWARD ring 0 ring 1 ring 2 ring 3 Ring 0: the kernel full hardware access; the reference monitor lives here Ring 1: operating system services rarely used as a separate ring in practice Ring 2: drivers and utilities most modern systems fold this into ring 0 or ring 3 Ring 3: user applications least privilege; must ask the kernel for everything A process in ring 3 that gains ring 0 execution has escalated past every software control at once, which is why kernel exploits are prized.
Rings are the hardware's way of enforcing the TCB boundary. The lower the ring, the more it can do and the less of it there should be.

Protection rings are the processor's mechanism for separating the TCB from everything else. Ring 0 runs the kernel with full hardware access; ring 3 runs applications that must request everything through the kernel. Rings 1 and 2 exist in the model and are seldom used as distinct levels. The exam's questions are about the boundary: an application in ring 3 cannot touch hardware directly, a driver flaw that runs in ring 0 compromises everything, and process isolation (each process in its own address space, with data execution prevention and address space layout randomization making memory attacks harder) is how the operating system keeps ring 3 processes from reaching each other.

The TPM: what it actually holds

A Trusted Platform Module is a small, tamper-resistant chip on the motherboard, and candidates overestimate what it does. It does not encrypt the disk; the operating system does that. The TPM holds the key, and it releases the key only when the platform is in the state the key was bound to.

Three things inside it matter for the exam. Keys, generated and stored where software cannot read them out. Platform configuration registers (PCRs), which hold hash measurements of the boot components: each stage of boot measures the next and extends the value into a PCR, so the registers end up describing exactly what booted. And sealing, which encrypts a secret so that it can be unsealed only if the PCRs match the values at sealing time. Full-disk encryption sealed to the TPM means that if the bootloader has been tampered with, the PCRs differ, and the disk key is never released.

Secure boot versus measured boot

These two are the distinction Domain 3 tests hardest in this area, and they answer different questions.

Two boot chains side by side over the same stages, firmware, bootloader, kernel and drivers: secure boot verifies each stage's signature before running it and halts on a mismatch; measured boot hashes each stage into a TPM register and continues, leaving a record that can be attested later SAME CHAIN, TWO QUESTIONS Secure boot "is this signed by someone I trust?" firmwareverify signature bootloaderverify signature kernel: modifiedsignature fails boot haltsuntrusted code never runs Measured boot "what exactly ran, and can I prove it?" firmwarehash into PCR bootloaderhash into PCR kernel: modifiedhash differs, continues attestationPCRs prove what ran Secure boot prevents. Measured boot records, and lets something else decide: refuse to release the disk key, or refuse network access. Most platforms do both. The exam asks which one a scenario is describing by whether the outcome was a halt or a report.
Secure boot is a gate; measured boot is a witness. A halted boot is secure boot. A device that booted and then failed a health check is measured boot plus attestation.

Secure boot checks a signature at each stage and refuses to run anything not signed by a trusted authority. It is preventive: tampered firmware or a bootkit simply does not execute. Its limitation is that it only knows about signatures, so a signed but vulnerable component passes.

Measured boot hashes each stage into the TPM's PCRs and keeps going. It prevents nothing on its own. What it provides is attestation: a signed report of the PCR values that a remote party, a network access control system or the disk encryption logic can compare with known-good values and act on. A scenario where a laptop boots normally but is denied network access because its measurements changed is measured boot with attestation, and a NAC policy doing the deciding.

TEEs, enclaves, and HSMs

Three more hardware terms complete the objective, and they are distinguished by what they protect and where they live.

Component Where Protects Typical use
TPM a chip on the board keys and boot measurements disk encryption keys, attestation
Trusted execution environment an isolated region of the main processor code and data while executing payment, biometrics, DRM, confidential computing
Secure enclave a vendor's implementation of a TEE, often a separate coprocessor the same, with its own key store device unlock, key management on phones
Hardware security module a dedicated appliance or card high-value keys and the operations that use them certificate authorities, payment signing, root keys

The line the exam draws: a TPM protects keys at rest and measures the platform; a TEE protects data in use, while the processor is working on it, from everything else on the same machine including a compromised operating system; and an HSM is where you put keys so valuable that they must never exist outside tamper-resistant hardware, with the operations performed inside the module and only the results coming out. A question about a certificate authority's root key is an HSM question. One about processing sensitive data on a cloud host you do not fully trust is a TEE question. One about binding a disk key to the state of a laptop is a TPM question.

Four stems, decoded

  1. A stolen laptop with full-disk encryption was found booting to a modified bootloader, and the drive never unlocked. The disk key was sealed to the TPM's PCRs; the modified bootloader changed the measurements, so the TPM refused to release it. Measured boot and sealing did their job.
  2. A workstation refuses to start at all after a firmware update from an unknown source. Secure boot rejected an unsigned or wrongly signed image. Preventive, and exactly as designed.
  3. An organization wants to process sensitive records on a cloud provider's hardware without the provider's administrators being able to read them in memory. Data in use on someone else's machine: a trusted execution environment, which is what confidential computing offers.
  4. A certificate authority stores its root private key on an encrypted file server with strict permissions. The key exists outside tamper-resistant hardware, so it can be copied by anyone who reaches the file. A hardware security module, with signing performed inside it.

Exam traps

  • The TPM does not encrypt the disk; it guards the key. The operating system's encryption does the work.
  • Secure boot halts; measured boot reports. If the scenario ends in "the device would not start," it is secure boot.
  • Degrading the TCB is the attacker's goal. Any answer that adds code to ring 0 without need makes the TCB bigger and the system weaker.
  • The reference monitor is a concept; the security kernel implements it. Tamper-proof, always invoked, verifiable are its three properties.
  • Certification versus accreditation sits in the same objective: certification is the technical evaluation of a system against a standard; accreditation is management's formal acceptance of the residual risk and authorization to operate.

Key takeaways

  • A root of trust is what you cannot verify; everything above it is verified by what is below. Keep the trusted computing base small.
  • The reference monitor mediates every access and must be tamper-proof, always invoked and verifiable. The security kernel is its implementation; rings enforce the boundary in hardware.
  • A TPM stores keys and boot measurements in PCRs and seals secrets to a platform state. It guards the disk key; it does not do the encryption.
  • Secure boot verifies signatures and halts; measured boot hashes and attests. A halt is one, a health check is the other.
  • TEE protects data in use; HSM protects the keys that must never leave hardware. Match the component to what the scenario is protecting.

System security capabilities are objectives 3.4 and 3.5 of CISSP Domain 3, Security Architecture and Engineering, 13% of the exam, and they are the hardware beneath the security models the same domain tests and the PKI whose root keys live in the HSM. Work all 45 topics with our CISSP Domain 3 study guide.

#CISSP #ISC2 #TPM #SecureBoot #MeasuredBoot #TrustedComputingBase #HSM #SecurityArchitecture #InfoSec #CyberSecurity

CISSP Domain 3 · security architecture and engineering

Turn the models into marks

Security models are one of ten modules in CISSP Domain 3, 13% of the exam. Study all 45 topics: secure design principles, models, cryptography, site design and the information system lifecycle, with our objective-mapped guide and 100 practice questions.

Get the CISSP Domain 3 guide

Share this article

Keep reading

CISSP deep dives

Which Layer Is It? Mapping Attacks to the OSI Model, Plus IPsec AH vs. ESP

The OSI model is on every networking exam, and the CISSP is the one that asks what attacks live at each layer. All seven layers with their unit, device and protocols, the attack the exam pins to each, the TCP/IP model's four-layer collapse, and IPsec pulled apart: AH versus ESP, transport versus tunnel mode, and what IKE and the security association actually negotiate.

Read CISSP deep dives

Ciphertext-Only to Golden Ticket: The Thirteen Cryptanalytic Attacks CISSP Tests, and What Each One Actually Breaks

AES has never been broken and the CISSP knows it, which is why objective 3.7 is not about the math. It is about the nonce that repeated, the comparison that returned early, the certificate nobody validated and the hash that worked as well as the password. Every named cryptanalytic attack sorted by what the attacker holds, why 2DES failed, why a 128-bit hash gives only 64 bits of collision resistance, and the one countermeasure that belongs to each attack.

Read CISSP deep dives

Clear, Purge, Destroy: Data Remanence, Sanitization, and End-of-Life the CISSP Way

Deleted data is not gone, and the CISSP asks about the difference in a dozen ways. Domain 2 on what happens after the useful life of data and the assets that hold it: remanence and why deletion is a lie, the clear, purge and destroy ladder and which media each applies to, cryptographic erasure and the SSD problem, end-of-life versus end-of-support, and the ownership roles that decide who is accountable at every step.

Read

Enjoyed this? Get the AI security news that matters.

Join The AI Security Brief for the top AI security news, plus what's important to the C-suite. Free, straight to your inbox.

No spam. Unsubscribe anytime.