Measured Boot is a process that computes a cryptographic hash of each firmware, driver, and OS component as it loads, recording the measurement in a Platform Configuration Register (PCR) within a Trusted Platform Module (TPM). Unlike Secure Boot, which halts execution on untrusted code, Measured Boot logs everything—trusted or not—creating an immutable audit trail of the system's exact boot state for later remote attestation.
Glossary
Measured Boot
A process that cryptographically measures and logs each component of the boot chain into a Platform Configuration Register (PCR), allowing a remote party to verify the exact state of the booted system.
PLATFORM INTEGRITY VERIFICATION
What is Measured Boot?
Measured Boot is a security process that cryptographically records the identity and integrity of every software component loaded during the boot sequence, storing these measurements in a Trusted Platform Module (TPM) for remote verification.
This log, stored in the TPM's PCRs, allows a remote verifier to compare the recorded hashes against a known-good golden measurement policy. By validating the chain of trust from the hardware root up to the application layer, a relying party can detect the presence of rootkits, bootkits, or unauthorized modifications before releasing secrets or granting network access.
CRYPTOGRAPHIC INTEGRITY
Key Characteristics of Measured Boot
Measured Boot establishes a hardware-rooted chain of trust by cryptographically hashing each firmware and software component before execution, storing the results in Platform Configuration Registers (PCRs) for remote verification.
01
Cryptographic Hashing of Boot Components
Before any piece of boot code executes, the firmware calculates its SHA-256 hash and records it in a Platform Configuration Register (PCR). This process begins with the Core Root of Trust for Measurement (CRTM) in immutable firmware and extends through the UEFI drivers, bootloader, and OS kernel. Each measurement is appended using the formula: New PCR = Hash(Old PCR || New Measurement), creating a tamper-evident log that captures the exact sequence of software loaded.
02
Platform Configuration Registers (PCRs)
PCRs are shielded memory locations within the Trusted Platform Module (TPM) that store integrity measurements. Key characteristics:
- PCR-0: Stores the CRTM and platform firmware measurements
- PCR-7: Records Secure Boot policy and UEFI driver signatures
- PCR-11: Captures OS kernel and bootloader integrity
- PCRs cannot be overwritten arbitrarily; they only accept extend operations, making historical manipulation computationally infeasible.
03
Remote Attestation Integration
Measured Boot provides the raw integrity data that powers remote attestation. A relying party can request a TPM Quote—a cryptographically signed report containing the current PCR values and an Event Log—to verify the system's boot state. This allows cloud tenants to confirm that a server booted into a known-good Trusted Execution Environment (TEE) before provisioning secrets or launching confidential workloads.
04
Distinction from Secure Boot
While often confused, these technologies serve different purposes:
- Secure Boot: Enforces policy by preventing the execution of unsigned code. It is an enforcement mechanism.
- Measured Boot: Records what actually executed, regardless of policy. It is an audit and verification mechanism. Together, they provide both prevention and detection, forming a comprehensive platform integrity architecture.
05
Event Log Reconstruction
The TPM Event Log stored in system memory provides the human-readable context for each PCR value. During attestation, the verifier replays the event log against the claimed PCR values to confirm consistency. This allows precise identification of which specific component caused a measurement change—for example, detecting a vulnerable driver version or an unauthorized kernel module loaded during boot.
06
Hardware Root of Trust Anchoring
Measured Boot derives its security from an immutable Hardware Root of Trust. The initial measurement code resides in mask ROM or write-protected flash, ensuring it cannot be altered by software attacks. This anchors the entire Chain of Trust, guaranteeing that even if an attacker compromises the OS, the boot measurements remain a reliable forensic record of the system's launch state.
MEASURED BOOT EXPLAINED
Frequently Asked Questions
Clear, technical answers to the most common questions about the measured boot process, its cryptographic foundations, and its role in establishing a hardware-rooted chain of trust for confidential computing.
Measured boot is a security process that cryptographically measures and logs every software component executed during the system startup sequence into a Platform Configuration Register (PCR) within a Trusted Platform Module (TPM). Unlike Secure Boot, which enforces a policy by halting execution if an unauthorized binary is detected, measured boot does not stop the boot process. Instead, it creates an immutable, tamper-proof record of the exact state of the booted system. Each stage—from the Core Root of Trust for Measurement (CRTM) in the firmware, through the bootloader, to the operating system kernel—calculates a cryptographic hash of the next component before passing control to it. This hash is "extended" into a PCR using the operation New_PCR_Value = Hash(Old_PCR_Value || New_Hash), creating a verifiable chain. A remote party can then request a TPM Quote, which is a signed attestation of these PCR values, to verify the system's integrity.
BOOT INTEGRITY COMPARISON
Measured Boot vs. Secure Boot
A technical comparison of two distinct platform security mechanisms that ensure boot-time integrity, one focused on cryptographic measurement and the other on execution prevention.
| Feature | Measured Boot | Secure Boot |
|---|---|---|
Primary Objective | Cryptographically log the boot chain state for remote verification | Prevent execution of unauthorized or malicious boot code |
Core Mechanism | Hashes each component and extends values into Platform Configuration Registers (PCRs) | Verifies digital signatures of boot components against a database of authorized keys |
Enforcement Action | None; allows boot to proceed regardless of measurement | Halts boot process if signature verification fails |
Hardware Dependency | Trusted Platform Module (TPM) required | UEFI firmware with Secure Boot capability |
Attestation Support | ||
Remote Verification | ||
Protection Against Bootkits | ||
Post-Boot Auditability |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.
Enterprise searchRAGPermissions
Read more
Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.
AI agentsWorkflow automationGovernance
Read more
Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
AI integrationDecision supportModel routing
Read more
About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
LinkedIn
Limited slotsGet a Free AI Consultation
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us