Secure Boot & measured boot

Every stage this level has covered — Winload preparing the kernel, SMSS bringing up sessions — assumes the software running at each stage is genuinely what it claims to be, unmodified by anything malicious that got there first. Secure Boot and measured boot are the mechanisms that make that assumption something Windows can actually verify, rather than simply hope for.

A chain of verification, link by link

Secure Boot works by having each stage of boot verify the signature of the next stage before executing it, rather than blindly running whatever code happens to be present:

1. UEFI firmware, configured with a set of trusted signing keys, checks the signature of the boot manager before running it.
2. The boot manager, in turn, verifies Winload (Boot loader to kernel handoff) before handing off to it.
3. Winload verifies the kernel image and every boot-critical driver it loads, rejecting anything unsigned or signed with an untrusted key.

The specific threat this closes: a bootkit — malware that installs itself into the boot chain, running before Windows (and before any Windows-level antivirus or security software) even starts, specifically to evade detection entirely. Without signature verification at each stage, a bootkit occupying an early link in this chain could load silently, with nothing later in the sequence able to detect the substitution had ever happened.

Measured boot: recording, not blocking

Measured boot is a related but distinct mechanism: rather than (or in addition to) rejecting untrusted code outright, it records cryptographic measurements of each boot component into the TPM's PCRs (Platform Configuration Registers) as boot proceeds. This creates a tamper-evident record of exactly what actually ran during this specific boot — which later software (an attestation service, or Windows' own BitLocker) can check against an expected, known-good baseline, and can use as a condition: certain protected keys, notably BitLocker's own encryption keys, can be configured to release automatically only if the recorded measurements match an expected, trusted boot sequence, and to withhold the key (forcing an additional recovery step) if anything measured along the way looks different from what was expected.

Two genuinely different problems: verifying vs. encrypting

Worth stating precisely, because the two get conflated constantly: Secure Boot validates that early boot software is genuine and untampered — it says nothing about whether your data is encrypted. BitLocker protects data at rest — encrypting drive contents so they're unreadable without the correct key — and says nothing, by itself, about whether the boot chain that eventually decrypts that data was itself trustworthy. The two are complementary, and in fact directly connected (BitLocker's automatic-unlock behavior can depend on measured-boot attestation, as described above) — but they solve different problems, and neither is a substitute for the other.

A worked example: why a driver update can suddenly stop booting

An unsigned, or improperly signed, boot-critical driver — perhaps from a well-intentioned but incorrectly-packaged update — will be rejected by Winload during signature verification, before the kernel even finishes initializing, on a Secure Boot-enabled system. This produces a boot failure that can look alarming (the machine won't start at all) but is, structurally, the security mechanism working exactly as designed: rather than silently running unverified boot-critical code, Secure Boot stops the sequence entirely rather than proceed on an unverified basis.

A common mistake

Treating "Secure Boot" and "encryption" (or "antivirus") as roughly synonymous security features misses what each one actually does. Secure Boot answers a narrow, specific question — "is the software running at each early boot stage genuinely what it claims to be" — and has nothing to do with protecting data confidentiality or detecting malware running after Windows has already started; those are separate problems, solved by separate mechanisms (BitLocker, and ordinary runtime security software, respectively).

Where this connects

• Boot loader to kernel handoff is exactly the stage whose components get verified by this chapter's signature-checking chain.
• HAL & boot and the kernel it introduces are the ultimate target this entire chain of trust is protecting the integrity of.