Secure Boot, Measured Boot, and Memory Integrity: Auditing the Windows Boot Chain

Every security control you run — antivirus, EDR, application allowlisting, this audit tool — starts from an assumption it almost never states out loud: that the operating system underneath it is honest. If an attacker can plant code that runs before Windows, or load a kernel driver that Windows shouldn't trust, then everything above that layer is reporting from a compromised vantage point. A rootkit in the boot path doesn't have to evade your EDR; it can simply lie to it. The boot chain is the one part of the stack where "assume breach" isn't enough — you need to be able to prove the foundation was measured and trusted from power-on.

That proof is exactly what Secure Boot, measured boot, virtualization-based security (VBS), and Hypervisor-Protected Code Integrity (HVCI) provide. They are also, conveniently, all local machine settings — which means their real failure mode isn't that they can't be turned on, it's that nobody ever checks whether they still are.

The four layers, from power-on upward

These controls stack. Each one closes a gap the layer below it leaves open, so it helps to see them as a sequence rather than a checklist:

• Secure Boot is the UEFI firmware refusing to hand control to a bootloader that isn't signed by a trusted key. It stops the classic bootkit — malicious code that replaces or shims the Windows Boot Manager to load before the kernel and neuter it.
• Measured Boot uses the TPM to record a cryptographic hash of every component in the boot path into Platform Configuration Registers (PCRs). It doesn't block anything by itself; it produces tamper-evident evidence that can be attested remotely — so a machine whose boot state changed can be caught and quarantined.
• VBS uses the CPU's virtualization extensions to carve out an isolated memory region the normal kernel can't touch, moving the most sensitive secrets and security decisions out of reach of ordinary kernel-mode code.
• HVCI (a.k.a. Memory Integrity) runs on top of VBS and enforces that every kernel driver is properly signed before it's allowed to execute — which is the direct countermeasure to Bring-Your-Own-Vulnerable-Driver attacks, where an attacker loads a legitimately signed but exploitable driver to get a foothold in the kernel.

Secure Boot proves nothing malicious loaded before Windows; HVCI proves nothing malicious loaded into the kernel after it. Between them they close the two doors a rootkit needs.

Why this is a live problem, not a legacy one

It would be comforting to treat boot-chain security as solved by modern hardware. It isn't. Signed-but-vulnerable drivers are catalogued by the hundreds and abused in real intrusions to disable endpoint protection from the inside. Bootkits that survive OS reinstalls have moved from research curiosities to shipped malware. And the controls that defend against them are routinely off: Secure Boot gets disabled to dual-boot or flash firmware and never re-enabled; HVCI is skipped because an old third-party driver isn't compatible; a TPM is present but never provisioned. The capability is in the silicon — the configuration is where it falls down.

Verify it on the machine in front of you

You don't need a lab to check any of this; Windows exposes all of it. The fastest single call is Confirm-SecureBootUEFI (it returns True, False, or throws "not supported" on legacy BIOS), and the VBS/HVCI status lives in a WMI class:

# Secure Boot state (True = enabled, False = off, throws on legacy BIOS)
Confirm-SecureBootUEFI

# VBS + code-integrity (HVCI) running state
$g = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard `
  -ClassName Win32_DeviceGuard
"VBS running        : {0}" -f ($g.VirtualizationBasedSecurityStatus -eq 2)
# 2 in SecurityServicesRunning == HVCI (Memory Integrity) is actually enforcing
"HVCI enforcing     : {0}" -f ($g.SecurityServicesRunning -contains 2)

# TPM present, ready, and owned?
Get-Tpm | Select-Object TpmPresent, TpmReady, TpmEnabled

The subtlety that trips people up: VBS and HVCI have a configured state and a running state, and they are not the same thing. A GPO can request HVCI while the machine silently fails to enforce it because an incompatible driver blocked it at boot — so a group policy report says "on" while SecurityServicesRunning says otherwise. The only answer that matters is the runtime one, read from the machine itself. That gap between "we set the policy" and "the machine is actually enforcing it" is the entire reason a live audit beats a config export.

Make it a fact you re-check, not a memory

Boot-chain posture is brittle in the most ordinary ways — a firmware update, a driver rollback, a reimage, an OEM image that shipped with Secure Boot off. Because these are runtime-verifiable settings, they're a natural fit for continuous auditing. WinSentinel reads exactly these facts — Secure Boot state, TPM presence and readiness, VBS and HVCI running status — and folds them into one posture score alongside the rest of the machine's configuration:

winsentinel audit
winsentinel score

Re-run it after any firmware or driver change and the score moves the instant HVCI stops enforcing or Secure Boot gets flipped off — so "is our boot chain still trusted?" becomes something you confirm today, not something you assumed since setup day. It runs entirely on the local machine, free and unlimited across all 33 audit modules, with no account and no cloud.

When one machine becomes a fleet

One laptop with Secure Boot disabled during a firmware flash is a five-minute fix. Fifty laptops, where any one of them might have silently dropped HVCI after a driver update or shipped from the OEM with Secure Boot off, is a genuinely hard assurance problem — and boot-chain settings are exactly the kind that revert quietly and invisibly. That fleet-wide guarantee is what WinSentinel Pro is for: lightweight agents report each machine's boot-integrity posture to a central node, so an endpoint that loses Secure Boot or stops enforcing Memory Integrity surfaces as a drift alert instead of a blind spot. The depth of each machine's audit is identical to the free single-machine scan; Pro adds the central console, fleet history, compliance rollups, and drift alerting that let you trust the foundation across an entire estate.

The takeaway

Boot-chain security is the assumption every other control quietly depends on: that the OS reporting to you hasn't already been subverted below the waterline. Secure Boot keeps a bootkit from loading before Windows, measured boot makes tampering provable, and VBS with HVCI keeps a vulnerable driver from turning the kernel against you. All four are settings the hardware already supports and that drift off in the most mundane ways. So don't assume them — read them from the machine, check the running state and not just the policy, and re-verify after every firmware and driver change. Free and unlimited on the machine in front of you; fleet-wide with Pro when one machine becomes many.