The ACPI Tables That Quietly Secure Your Windows Machine

1. A Revoked Cert, A Secured-Core PC, A 52-Byte Table#

In September 2021, researchers at Eclypsium published a video of a Secured-Core PC -- the most heavily protected Windows configuration money can buy, with Credential Guard, HVCI, BitLocker, and Kernel DMA Protection all enabled -- being silently rooted at boot ^[1]. The malicious binary was Authenticode-signed with a Hacking Team code-signing certificate that had been revoked six years earlier. Windows ran it anyway, with SYSTEM privileges, before the user even reached the lock screen. The mechanism was a single ACPI table almost no one outside platform-firmware engineering can name.

How is this possible if every box on the security checklist was ticked? The answer is structural. Every modern Windows guarantee -- Credential Guard isolating LSASS in a higher Virtual Trust Level, the Secure Kernel partitioning a fingerprint reader away from kernel-mode drivers, BitLocker sealing volume keys against PCR[7], Kernel DMA Protection blocking a Thunderclap-class peripheral ^[2] -- assumes the hypervisor came up knowing the correct shape of the platform. That shape is not discovered by Windows. It is described to Windows, in five small ACPI tables the OEM's UEFI firmware built before the Windows boot manager even started.

Every modern Windows security guarantee assumes the hypervisor came up knowing the correct shape of the platform. That shape is described in five small ACPI tables the OEM's UEFI firmware built before the Windows boot manager even started. The hardware does the enforcement; the tables decide what gets enforced.

Their names, in the order this article walks them, are DMAR (Intel VT-d, the IOMMU table on x86 ^[3]), IORT (the Arm SMMU analogue ^[4]), WSMT (the OEM's pact with Microsoft about System Management Mode behaviour ^[5]), SDEV (the list of devices the Secure Kernel may wall off from non-secure code ^[6]), and WPBT (the channel by which the firmware can drop a binary into c:\windows\system32 and run it on every boot ^[7]). Each table is a few dozen to a few thousand bytes. Together, they are the firmware-OS contract on which everything else above the hypervisor depends.

Four questions fall out of that framing, and the rest of this article answers each in turn. Who populates these tables? Who validates them? What does Windows do when they are wrong? What does the attacker get when they forge them? Along the way we will encounter the design idiom that recurs across every one of the five: the OEM declares a property the operating system has no independent way to verify. Microsoft's own engineers say so on the public Learn page for WSMT ^[8]. Once you internalise that idiom, the rest of the article reads as five variations on a single theme.

This is the substrate article in a longer series on Windows platform security. The hypervisor-as-isolation-primitive ^[9], the trustlets that run in the Secure Kernel ^[10], Pluton-as-TPM ^[11], the discrete TPM ^[12], BitLocker ^[13], Secure Boot ^[14], application identity and code-integrity policy ^[15], and USB device-arrival policy ^[16] all rest on these five tables. We do not redefine those concepts; we trace where they touch the table set, and we link out where the curious reader wants the deeper tour.

So: where do these tables come from in the first place? They have a thirty-year history that explains the structural problem.

2. ACPI as the Firmware-OS Contract: 1996 to Now#

How did we get from "describing sleep states" to "deciding whether Credential Guard turns on"? The answer is a thirty-year drift, and it is worth a short tour because each new table answered an attack class the prior contract could not describe.

ACPI 1.0 shipped in December 1996, jointly authored by Intel, Microsoft, and Toshiba; HP, Huawei, and Phoenix joined later, and in October 2013 the ACPI Special Interest Group transferred all assets to the UEFI Forum, which still publishes the standard today (current revision 6.6, released May 13, 2025) ^[17]. The original idea was modest: replace the Advanced Power Management 1.x INT 15h real-mode mess with a generic table-passing chassis the OS could read in protected mode. APM 1.0 shipped in 1992; revision 1.2 in 1996 was the last version of the spec, and Microsoft dropped APM support in Windows Vista ^[18]. APM expected the OS to invoke real-mode BIOS routines through INT 15h; once Windows ran a hardware abstraction layer in protected mode that was no longer architecturally tolerable.

The mechanics are uniform. Microsoft's own bring-up documentation describes them verbatim: "Windows depends on UEFI firmware to boot up the hardware platform . . . The platform firmware fills in the address of either the RSDT or XSDT in the RSDP. (If both table addresses are provided, Windows prefers the XSDT)" ^[19]. Each table carries the same 36-byte header (signature, length, revision, checksum, OEM ID, OEM table ID, OEM revision, creator ID, creator revision); the body is signature-specific. The contract: firmware writes typed tables, the OS reads them, the OS trusts them.

For the first decade of ACPI, every table described power, addressing, or device topology. Then the security tables began to arrive, one per attack class, each one narrowing the gap between what hardware can do and what the OS believes the hardware will do.

timeline
title ACPI security-table genealogy
1996 : ACPI 1.0 released (Dec, Intel/Microsoft/Toshiba)
2007 : DMAR introduced (Intel VT-d / Q35)
2011 : WPBT spec dated 29 November (Windows 8 era)
2015 : IORT introduced (ACPI 6.0, April)
2016 : WSMT v1.0 dated 18 April (Windows 10 v1607)
2017 : SDEV introduced (ACPI 6.2, May)
2021 : Eclypsium discloses WPBT revoked-cert acceptance
2025 : ACPI 6.6 published (May 13)

Timeline date sources, in row order: ACPI 1.0 ^[17]; DMAR with Intel Q35 ^[3]; WPBT ^[7]; IORT in ACPI 6.0 ^[4]; WSMT v1.0 ^[5]; SDEV in ACPI 6.2 ^[20]; Eclypsium 2021 ^[1]; ACPI 6.6 May 13, 2025 ^[17].

The arc compresses to five timestamps. DMAR, around 2007 with Intel's Q35 chipset and the first VT-d implementations, was the first ACPI table whose purpose was security rather than power: it described the IOMMU translation contexts that let the OS confine a peripheral's DMA reach ^[3]. WPBT, dated November 29, 2011 in the ACPICA conformance comment and shipped with Windows 8 [@acpica-actbl3-wpbt; @eclypsium-wpbt], was the first table whose payload was executable code: a physical pointer to a binary that Windows would copy into system32 and run. IORT, introduced in ACPI 6.0 in April 2015 ^[4], extended the IOMMU-description idea to Arm; the substrate became pan-architectural. WSMT, version 1.0 dated April 18, 2016 and supported in Windows 10 v1607 [@acpica-actbl3-wsmt; @ms-oem-uefi-wsmt], was the first table whose payload was an OEM warranty about behaviour Windows cannot verify. SDEV, introduced in ACPI 6.2 in May 2017 [@acpi-65-sdev; @acpica-actbl2-sdev], was the first table whose role was to describe the security partition itself -- a hint about which devices belong inside the Secure Kernel.

A pattern unifies them. In every case, the OEM describes a boundary the OS does not have an independent way to verify. WSMT articulates the principle most explicitly: "Because SMM is opaque to the operating system, it is not possible to produce a test which runs in Windows to verify that the protections prescribed in the WSMT specification are actually implemented in SMM" ^[8]. The same shape recurs in DMAR (the firmware describes the address-translation policy; Windows trusts that the IOMMU is enabled and that no over-broad reserved memory regions punch holes in it), in SDEV (the firmware lists secure devices; Windows trusts that the listing is correct and complete), and in WPBT (the firmware nominates a binary; Windows trusts that the signature was, until 2021, sufficient to keep adversaries out).

The ACPI security-table set is attestable but not enforceable from inside Windows. The OEM declares a property; the OS reads the declaration; the OS cannot independently refute lies in the contents. Every generation of mitigation since -- Secured-core PC certification, Pluton-rooted measured boot, Windows Defender Application Control over WPBT -- is an attempt to turn one corner of that unenforceable contract into an enforceable check, either pre-ship, at boot, or per-deployment.

If the firmware describes the platform and the OS trusts the description, what happens when the firmware describes a peripheral that can DMA-read your password? That is the IOMMU question. It is the oldest of the five tables, and the cleanest example of the table describes; hardware enforces pattern. Its name is DMAR -- and on Arm, IORT.

3. DMAR and IORT: The IOMMU Tables That Make Kernel DMA Protection Possible#

In the mid-2000s a researcher named Maximillian Dornseif demonstrated, in 2004, that he could plug an iPod into a locked laptop over FireWire and read the laptop's physical memory ^[21]. The fix took fifteen years. Here is why.

The DMA-attack class is older than the IOMMU. FireWire and OHCI 1394 SBP-2 spoofing made it concrete in the 2000s; Thunderbolt 1 (2011) and Thunderbolt 2 (2013) brought the same primitive back through a different connector ^[21]; in February 2019, the Thunderclap NDSS paper by A. Theodore Markettos, Colin Rothwell, Brett F. Gutstein, Allison Pearce, Peter G. Neumann, Simon W. Moore, and Robert N. M. Watson demonstrated that even with the IOMMU on, OS-side mistakes in what the table describes let a malicious peripheral exfiltrate keys in seconds ^[2]. The paper is the load-bearing academic primary for the entire genre.

DMAR: the Intel VT-d table#

DMAR is the table whose body Windows reads to decide whether DMA remapping is even possible. The ACPICA reference header (actbl1.h) declares the signature and the conformance: #define ACPI_SIG_DMAR "DMAR" /* DMA Remapping table */ and "Conforms to 'Intel Virtualization Technology for Directed I/O', Version 2.3, October 2014" ^[3].

The body is a sequence of typed sub-tables. The taxonomy from actbl1.h, with the byte values that identify each sub-table:

The top-level Flags byte declares three platform-level properties: ACPI_DMAR_INTR_REMAP (bit 0, interrupt remapping support), ACPI_DMAR_X2APIC_OPT_OUT (bit 1), and ACPI_DMAR_X2APIC_MODE (bit 2) ^[3]. Microsoft's Windows-side opt-in piggy-backs onto the same Flags byte: bit 2 must be set, and the Microsoft OEM Kernel DMA Protection page calls it DMA_CTRL_PLATFORM_OPT_IN_FLAG, citing Intel VT-d Spec Rev 2.5 Section 8.1 as the authoritative definition ^[23]. Without that bit set, Memory Access Protection stays off even if VT-d hardware is fully functional.

IORT: the Arm SMMU table#

IORT does the same job for the Arm SMMU. The ACPICA header pins the conformance: #define ACPI_SIG_IORT "IORT" and "Conforms to 'IO Remapping Table System Software on ARM Platforms', Document number: ARM DEN 0049E.f, Apr 2024" ^[4]. The node taxonomy, from the same header:

IORT folds two responsibilities together that x86 keeps separate: in addition to describing SMMU translation contexts, it carries the GIC ITS entries that govern interrupt remapping. (On x86, interrupt remapping lives in MADT, not DMAR.) Each PCI_ROOT_COMPLEX or NAMED_COMPONENT node carries an ID-mapping array of (InputBase, IdCount, OutputBase, OutputReference) tuples that translate PCIe Requester IDs to SMMU StreamIDs. The mapping arithmetic is the IOMMU. The table just tells the OS where the arithmetic lives.

How Windows turns the table into policy#

Kernel DMA Protection enrols when a small number of conditions all hold. Microsoft's documentation lays them out [@oem-kernel-dma; @kernel-dma-thunderbolt; @dma-remapping-drivers], and they form a textbook AND-gate.

flowchart TD
A[DMAR/IVRS/IORT present?] -->|No| OFF[Kernel DMA Protection: Off]
A -->|Yes| B[DMA_CTRL_PLATFORM_OPT_IN_FLAG set?]
B -->|No| OFF
B -->|Yes| C[VT-d/AMD-Vi/SMMU enabled in firmware setup?]
C -->|No| OFF
C -->|Yes| D{"Driver opt-in?"}
D -->|No, legacy device| OFF2[Device denied DMA, KDP partially enrolled]
D -->|Yes, RemappingSupported INF directive| ON[Kernel DMA Protection: On for this device]

The driver opt-in deserves a closer look, because it is where Thunderclap left its scar. The legacy mechanism was a per-driver DmaRemappingCompatible parameter; Windows 24H2 introduced a per-device RemappingSupported INF directive that supersedes it ^[24]. The modern intent is finer-grained: a single driver may legitimately ship across compatible and incompatible device variants, and the per-device declaration is the only safe granularity. Graphics is the canonical hold-out -- WDDM 3.0+ drivers can opt in, but earlier graphics stacks could not, and shipping graphics cards before WDDM 3.0 effectively blocked Kernel DMA Protection on whole platforms ^[25].

When the AND-gate fails, Windows surfaces it as a single line in msinfo32 System Summary: Kernel DMA Protection: Off. The remediation is rarely software. "Reboot into UEFI settings, Turn on Intel Virtualization Technology, Turn on Intel Virtualization Technology for I/O (VT-d)" is Microsoft's own checklist ^[25]. If the table is missing entirely, the only fix is an OEM BIOS update.

Three failure families, observable from inside Windows#

Three observable failure families recur. Missing DMAR / IVRS / IORT surfaces as Kernel DMA Protection: Off and the only fix is a BIOS update ^[25]. Over-broad RMRR / RMR was the Thunderclap finding: even with the IOMMU on, identity-mapped memory windows that legitimately exist for USB handoff or integrated graphics can overlap sensitive memory; a malicious peripheral assigned to the same context exfiltrates secrets while the IOMMU faithfully reports it as policy-compliant ^[2]. VT-d disabled in firmware setup surfaces identically to a missing table; the remediation is a UEFI menu, not a Windows update.

function kdpDecision({dmarPresent, optInFlagSet, iommuEnabled, driverRemappingCompatible}) {
if (!dmarPresent) return "KDP: Off (reason: DMAR/IVRS/IORT table missing -- BIOS update required)";
if (!optInFlagSet) return "KDP: Off (reason: DMA_CTRL_PLATFORM_OPT_IN_FLAG not set in DMAR Flags byte)";
if (!iommuEnabled) return "KDP: Off (reason: VT-d/AMD-Vi disabled in UEFI setup)";
if (!driverRemappingCompatible) return "KDP: Off for that device (reason: driver lacks RemappingSupported INF entry)";
return "KDP: On";
}

console.log("Secured-Core PC:    ", kdpDecision({dmarPresent:true, optInFlagSet:true, iommuEnabled:true, driverRemappingCompatible:true}));
console.log("OEM omission:       ", kdpDecision({dmarPresent:false, optInFlagSet:false, iommuEnabled:true, driverRemappingCompatible:true}));
console.log("VT-d disabled:      ", kdpDecision({dmarPresent:true, optInFlagSet:true, iommuEnabled:false, driverRemappingCompatible:true}));
console.log("Driver not opted-in:", kdpDecision({dmarPresent:true, optInFlagSet:true, iommuEnabled:true, driverRemappingCompatible:false}));

The Thunderclap residual is the article's first aha moment. The IOMMU is on. The hardware is working. The OS has read DMAR and turned on Kernel DMA Protection. And a malicious Thunderbolt device exfiltrates a TLS key in a few seconds, because the table described an RMRR that overlaps the victim driver's heap, or because the victim driver shared sensitive memory with a peripheral DMA window. The hardware was not the issue. The table was. From this point forward in the article, you should not ask "is the IOMMU on?" You should ask "is the IOMMU on, and did the firmware describe the right thing?"

The IOMMU question was an above-the-board hardware boundary. The next question is below-the-board: System Management Mode, the privilege level above the kernel that the OS literally cannot inspect. Microsoft's response was to make the OEMs sign a pact about it. The pact is a 40-byte ACPI table (a 36-byte ACPI header plus a 4-byte ProtectionFlags field) called WSMT.

4. WSMT: Microsoft's Pact With OEMs About SMM#

There is a CPU privilege level above the kernel. Windows cannot see what runs there. So Microsoft made the OEMs sign a pact about it.

The attack class is older than the table. UEFI rootkits like LoJax (September 2018), attributed to Sednit / APT28 by ESET, weaponised SMM-adjacent persistence: "This persistence method is particularly invasive as it will not only survive an OS reinstall, but also a hard disk replacement" ^[27]. The 2015 Hacking Team breach published an entire UEFI rootkit module along with the code-signing certificate that Eclypsium would later reuse in 2021 ^[28]. The Hacking Team certificate that drove the 2021 Eclypsium WPBT proof-of-concept was the same one shipped with the 2015 Hacking Team UEFI module. A revoked code-signing cert from one breach became the unlock for an unrelated table six years later, because the WPBT signature gate did not check revocation. A software-only OS-side fix to the SMI-handler-pointer-validation problem is impossible by construction: Windows cannot inspect SMM code, and SMRAM is not addressable to it.

So Microsoft did the only thing that was tractable. On April 18, 2016, version 1.0 of the Windows SMM Security Mitigations Table specification was published ^[5]. The body is one 32-bit field. ACPICA codifies it:

typedef struct acpi_table_wsmt {
    ACPI_TABLE_HEADER Header;
    UINT32            ProtectionFlags;
} ACPI_TABLE_WSMT;

#define ACPI_WSMT_FIXED_COMM_BUFFERS                (1)
#define ACPI_WSMT_COMM_BUFFER_NESTED_PTR_PROTECTION (2)
#define ACPI_WSMT_SYSTEM_RESOURCE_PROTECTION        (4)

Three bits. Each bit is a warranty by the OEM that their SMI handlers behave correctly in one specific way. Microsoft's published semantics, paraphrased lightly so the bits read as English ^[8]:

When does Windows read this table? "Supported versions of the Windows operating system read in the Windows SMM Security Table early during initialization, prior to start of the ACPI interpreter" ^[29]. Prior to start of the ACPI interpreter is the load-bearing phrase. Windows has not yet booted the hypervisor when it consumes WSMT; it has not yet decided whether to launch VBS. The table is read first; the decision follows.

sequenceDiagram
participant FW as OEM Firmware (build time)
participant POST as POST / DXE
participant BL as Windows Boot Manager
participant WBL as Winload.efi
participant HV as Hyper-V
participant VBS as VBS / Secure Kernel
FW->>POST: Build WSMT with ProtectionFlags
POST->>BL: Hand off ACPI table set via EFI system table
BL->>WBL: Load winload.efi
WBL->>WBL: Read WSMT prior to ACPI interpreter start
alt Flags == 0x7 (all three asserted)
WBL->>HV: Launch hypervisor
HV->>VBS: Start Secure Kernel, enrol Credential Guard / HVCI
else Flags partial or missing
WBL->>WBL: De-feature: VBS may not start, HVCI may stay disabled
end

The OEM-VBS page makes WSMT a hard prerequisite, not a nice-to-have: "Firmware support for SMM protection -- System firmware must adhere to the recommendations for hardening SMM code described in the Windows SMM Security Mitigations Table (WMST) specification . . . Firmware must implement the protections described in the WSMT specification, and set the corresponding protection flags as described in the specification to report compliance with these requirements to the operating system" ^[30]. If the flags are clear, VBS may de-feature. Memory Integrity may not enable. Credential Guard may refuse to start. The customer never sees a banner; they see the absence of a feature.

The structural punchline lands here, in Microsoft's own words:

"Because SMM is opaque to the operating system, it is not possible to produce a test which runs in Windows to verify that the protections prescribed in the WSMT specification are actually implemented in SMM. From the operating system, the only check that is possible is to look for the presence of the WSMT, and check the state of all defined Protection Flags." -- Microsoft Learn, Windows SMM Security Mitigations Table ^[8]

This is the article's second aha moment. Windows reads the flags. Windows trusts the flags. Windows cannot verify the flags. The OEM declares; Windows reads; Windows cannot refute. Once you internalise that idiom, every other ACPI security table in this article reads as a variation on it. SDEV declares which devices are secure. WPBT declares which binary is signed. DMAR declares which RMRR ranges are legitimate. In every case, the OEM authors a property and Windows believes it.

A worked example makes the consequence concrete. Open a PowerShell prompt and run Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard. The two fields that matter are VirtualizationBasedSecurityStatus (0 = off, 1 = enabled but not running, 2 = running) and SecurityServicesRunning (an array, where 1 = Credential Guard and 2 = HVCI). On a machine where WSMT is missing or its flags are clear, you may see VirtualizationBasedSecurityStatus = 1 and an empty SecurityServicesRunning array. The system intends to run VBS. The system cannot run VBS. The cause is invisible until you consult the DeviceGuard WMI class -- and even then, the WSMT influence is implicit, not named.

WSMT tells the hypervisor what SMM promised not to do. The next table tells the hypervisor which devices to wall off from non-secure code in the first place. Its name is SDEV.

5. SDEV: The Firmware Tells the Hypervisor Which Devices Are For Trustlets Only#

Your fingerprint reader is supposed to be unreachable from a kernel-mode rootkit. How does Windows know it is the fingerprint reader the firmware claims it is, and not, say, a USB device the attacker plugged in five seconds ago?

The answer is SDEV. The ACPI 6.5 specification, Section 5.2.27, is unusually candid about what the table is and is not ^[6]:

"The Secure DEVices (SDEV) table is a list of secure devices known to the system. The table is applicable to systems where a secure OS partition and a non-secure OS partition co-exist. A secure device is a device that is protected by the secure OS, preventing accesses from non-secure OS. The table provides a hint as to which devices should be protected by the secure OS. The enforcement of the table is provided by the secure OS and any pre-boot environment preceding it. The table itself does not provide any security guarantees."

"The table itself does not provide any security guarantees." -- ACPI Specification 6.5, Section 5.2.27 ^[6]

The three states a device can be in#

The spec defines three SDEV states, and they map directly onto what the Secure Kernel does at boot ^[6]:

The two SDEV entry types are, from ACPICA's actbl2.h: ACPI_SDEV_TYPE_NAMESPACE_DEVICE = 0 (an ACPI Namespace device path like \_SB.PCI0.XHCI) and ACPI_SDEV_TYPE_PCIE_ENDPOINT_DEVICE = 1 (a PCIe Bus / Device / Function tuple). The header Flags byte uses two bits: ACPI_SDEV_HANDOFF_TO_UNSECURE_OS (bit 0) and ACPI_SDEV_SECURE_COMPONENTS_PRESENT (bit 1) ^[20]. The Allow-Handoff bit is the one that decides which of the three states above applies.

The Windows-side struct is published on Microsoft Learn as _SDEV_SECURE_ACPI_INFO_ENTRY ^[31]:

typedef struct _SDEV_SECURE_ACPI_INFO_ENTRY {
  SDEV_ENTRY_HEADER Header;
  USHORT IdentifierOffset;
  USHORT IdentifierLength;
  USHORT VendorInfoOffset;
  USHORT VendorInfoLength;
  USHORT SecureResourcesOffset;
  USHORT SecureResourcesLength;
} SDEV_SECURE_ACPI_INFO_ENTRY;

How SDEV becomes trustlet ownership#

The Secure Kernel does not consume SDEV directly to start a trustlet. SDEV is the hint; the binding to a specific trustlet is encoded in Windows policy and OEM driver INFs. The companion article on VBS trustlets walks the trustlet IDs in detail ^[10]; the routing is implicit.

flowchart TD
A[Firmware lists device in SDEV] --> B{Allow-Handoff bit set?}
B -->|Clear -- always secure| C[Trustlet-aware driver present?]
B -->|Set -- handoff allowed| D[Trustlet-aware driver present?]
C -->|Yes| E[Device owned by VTL1 trustlet -- BioIso / LsaIso / vmsp]
C -->|No| F[Device unusable -- ESS feature silently disabled]
D -->|Yes| G[Trustlet may release device to VTL0 on request]
D -->|No| H[Device falls back to VTL0 ownership]
A2[Device not in SDEV] --> I[No trustlet ownership; ESS, vTPM disabled]

Where SDEV becomes a Secured-core PC certification gate#

The current OEM Standards for highly secure Windows 11 devices page makes SDEV authoring an explicit certification gate when the platform claims Windows Hello with Enhanced Sign-in Security: "A device with Windows Hello with ESS is enabled if it has the ESS hardware built-in components for face or fingerprint authentication, and the necessary support in BIOS" ^[32]. The SDEV listing of the biometric device is, in practice, what "the necessary support in BIOS" cashes out to. Without it, the hardware exists, the driver loads, the user's face is captured -- and the secure pipeline never engages, because the Secure Kernel was never told the camera was its responsibility.

Three observable failure families recur. Device not listed surfaces as Enhanced Sign-in Security silently disabling; the user sees "Windows Hello requires additional setup" and never reaches the secure path. Listed but driver-incompatible triggers the Allow-Handoff fallback and the device is owned by the normal kernel, exactly the outcome SDEV was meant to prevent. Adversarially listed is the worst case: an attacker with a DXE foothold (the firmware-stage class that LogoFAIL ^[33] and BIOSDisconnect typify) writes a malicious SDEV entry into ACPI memory and routes a device the attacker controls into the Secure Kernel partition. That last case is what the ACPI 6.5 spec means when it says "the table itself does not provide any security guarantees." The Secure Kernel enforces the partition; the table only suggests where the partition should fall.

The article's third recurring failure family is now visible in three of the five tables: missing, malformed, forged. SDEV decides which devices the firmware says are secure. The next table -- WPBT -- decides which binaries the firmware says Windows should run. That is the dial that, when broken, turned everything-protections-on Secured-Core PCs into rootkit hosts.

6. WPBT: The OEM Rootkit That Microsoft Designed In On Purpose#

In 2012 Microsoft shipped a feature that lets the firmware drop a binary into c:\windows\system32 and run it at SYSTEM on every boot ^[1]. The reason was customer experience. The result was a designed-in rootkit channel.

The Microsoft specification, preserved verbatim by Eclypsium, describes the mechanism without flinching: "The WPBT is a fixed Advanced Configuration and Power Interface (ACPI) table that enables boot firmware to provide Windows with a platform binary that the operating system can execute. The binary handoff medium is physical memory, allowing the boot firmware to provide the platform binary without modifying the Windows image on disk" ^[1]. The ACPICA struct is small enough to read in one breath:

typedef struct acpi_table_wpbt {
    ACPI_TABLE_HEADER Header;
    UINT32 HandoffSize;
    UINT64 HandoffAddress;     /* physical pointer to the binary */
    UINT8  Layout;
    UINT8  Type;
    UINT16 ArgumentsLength;
} ACPI_TABLE_WPBT;

The single load-bearing field is HandoffAddress: a 64-bit physical pointer to the binary. The signing requirement, again preserved verbatim by Eclypsium ^[1]:

"All binaries published to Windows using the WPBT mechanism outlined in this paper must be embedded signed and timestamped. These images should be linked with the /INTEGRITYCHECK option and signed using the SignTool command-line tool with the /nph switch to suppress page hashes."

Why did Microsoft ship this? OEM customer-experience continuity across clean reinstalls. A customer who runs Windows Setup from USB and wipes their machine reasonably expects everything they paid for to come back: vendor utilities, enterprise enrolment shims, anti-theft agents. WPBT was Microsoft's answer to "how does the OEM persist its software across an OS-level reinstall?" The answer Microsoft chose was: by handing the firmware a sanctioned channel to inject a SYSTEM-level binary into every boot. Eclypsium's own coverage records that "acclaimed researcher and co-author of Windows Internals, Alex Ionescu, has been calling out the dangers of WPBT as a rootkit as early as 2012 and continues to do so today" ^[1].

sequenceDiagram
participant FW as OEM Firmware
participant ACPI as ACPI table set
participant SMSS as Session Manager (smss.exe)
participant CI as Code Integrity
participant EXE as wpbbin.exe (SYSTEM)
FW->>ACPI: Build WPBT, set HandoffAddress to in-memory binary
ACPI->>SMSS: Session manager reads WPBT during early boot
SMSS->>SMSS: Copy binary from physical memory into system32
SMSS->>CI: Validate Authenticode signature
CI-->>SMSS: Accept (until 2021: even revoked certs accepted)
SMSS->>EXE: Launch as SYSTEM, before lock screen

A history of WPBT abuse, in three acts#

The WPBT abuse history predates the table itself. The mechanism existed informally as a BIOS Option ROM trick before it was standardised; once standardised, the abuse cases scaled ^[34].

Computrace, analysed by Vitaly Kamluk and Sergey Belov in February 2014, was the legitimate ancestor. Their post documented an Absolute Software anti-theft agent that survived clean Windows reinstalls because the firmware re-injected rpcnetp.exe at every boot via a WPBT-class mechanism that predated WPBT itself: "the owner of the system claimed he had never installed Absolute Computrace and didn't even know the software was present on his computer" ^[34]. The reverse-engineering revealed a Russian-doll structure -- "rpcnetp.exe inside autochk.exe inside EFI Application inside another EFI-Application inside ROM Module" ^[34] -- and a C&C protocol weak enough that the researchers built proof-of-concept hijacking. WPBT-class persistence existed as attack surface before WPBT was a table.

LSE was the first formal-WPBT abuse. CISA's August 12, 2015 alert framed it tersely: "Certain Lenovo personal computers contain a vulnerability in LSE (a Lenovo BIOS feature). Exploitation of this vulnerability may allow a remote attacker to take control of an affected system" ^[35]. The NVD entry pinned the weakness class: "A buffer overflow vulnerability was reported, (fixed and publicly disclosed in 2015) in the Lenovo Service Engine (LSE), affecting various versions of BIOS for Lenovo Notebooks, that could allow a remote user to execute arbitrary code on the system" ^[36]. LSE injected wpbbin.exe into system32, downloaded a separate utility called OneKey Optimizer, and overwrote autochk.exe to maintain persistence. The only reliable fix was an OEM BIOS update.

LoJax came in September 2018. ESET's white paper documented the first in-the-wild UEFI rootkit, attributed to the Sednit / APT28 group: "This persistence method is particularly invasive as it will not only survive an OS reinstall, but also a hard disk replacement" ^[27]. The persistence design was directly inspired by Computrace's LoJack; ESET noted that "In May 2018, an Arbor Networks blog post described several trojanized samples of Absolute Software's LoJack small agent, rpcnetp.exe" ^[27]. A 2008-vintage anti-theft mechanism became the template for state-actor espionage.

The 2021 Eclypsium disclosure: "Everyone Gets a Rootkit"#

In September 2021, the Eclypsium research team published the structural finding that reframed WPBT from "controversial OEM convenience" to "structurally broken signature gate". The post was institutionally authored by "the Eclypsium research team" with no by-line in the rendered article body; this article preserves that institutional attribution. The finding ^[1]:

"While Microsoft requires a WPBT binary to be signed, it will accept an expired or revoked certificate. This means an attacker can sign a malicious binary with any readily available expired certificate. This issue affects all Windows-based devices going back to Windows 8 when WPBT was first introduced. We have successfully demonstrated the attack on modern, Secured-Core PCs that are running the latest boot protections." -- Eclypsium, Everyone Gets a Rootkit (September 2021) ^[1]

The proof-of-concept was elegant in the worst way. The researchers signed a malicious binary with a Hacking Team code-signing certificate that had been revoked in 2015 (a side effect of the 2015 Hacking Team breach). They placed it in firmware memory. They wrote a WPBT entry pointing at it. On a Secured-Core PC with Credential Guard, HVCI, BitLocker, and Kernel DMA Protection all enabled, Windows ran the binary at SYSTEM before the user reached the lock screen. The signature gate was the only thing standing between the firmware and arbitrary kernel-grade code. The signature gate accepted revoked certificates.

Microsoft's response was not to fix the validator ^[1]:

"Microsoft recommends customers use Windows Defender Application Control (WDAC) to limit what is allowed to run on their devices. WDAC policy is also enforced for binaries included in the WPBT and should mitigate this issue. We recommend customers implement a WDAC policy that is as restrictive as practical for their environment."

That is an explicit acknowledgement that the original signing-only model was structurally inadequate; the fix was outsourced to a customer-authored allow-list. WDAC is the App Identity sibling article's territory ^[15]; for the present article, the relevant fact is that the only mitigation Microsoft recommended did not change Microsoft's code. It changed the customer's policy.

WPBT is a designed-in OEM persistence channel that, until 2021, allowed any binary signed with any code-signing certificate -- including certificates revoked years earlier -- to execute at SYSTEM on every boot of every Windows-since-8 machine, including the most heavily protected Secured-Core PCs. The fix was not a patch to the validator. The fix was to ask customers to author Windows Defender Application Control policies that constrain what WPBT may run.

The mitigation paths a defender can take today, in order of how supported they are:

We have walked five tables: DMAR, IORT, WSMT, SDEV, WPBT. Three failure families recur in each: omission, mistake, forgery. Time to make the threat model honest.

7. Forged, Missing, and Lying Tables: An Honest Threat Model#

We have seen the tables. We have seen one of them break catastrophically. Now name the failure families honestly, because each has a different attacker, a different fix, and a different observable signal.

flowchart TD
A[Failure mode] --> B[OEM omission]
A --> C[OEM mistake]
A --> D[Adversarial forgery]
B --> B1[Cause: table absent or flag clear]
B1 --> B2[Observable: msinfo32 / Win32_DeviceGuard]
B2 --> B3[Fix: OEM BIOS update]
C --> C1[Cause: table present but lying about behaviour]
C1 --> C2[Observable: none from inside Windows]
C2 --> C3[Fix: certification, external research, OEM BIOS update]
D --> D1[Cause: attacker with DXE foothold rewrites table]
D1 --> D2[Observable: requires measured ACPI to detect]
D2 --> D3[Fix: WDAC over WPBT, Pluton-rooted attestation -- partial]

OEM omission: the most common failure#

The most common case is the simplest. Kernel DMA Protection silently shows Off because the OEM's DMAR is missing or because the DMA_CTRL_PLATFORM_OPT_IN_FLAG is clear in the Flags byte ^[23]. Windows Hello with Enhanced Sign-in Security silently disables because the fingerprint reader was never listed in SDEV ^[32]. VBS de-features because WSMT is missing or its three Protection Flags are partially clear ^[8]. The defender's observable surface is msinfo32, the Win32_DeviceGuard WMI class, and the System Summary pane; the fix in every case is an OEM BIOS update, on the OEM's release schedule, with whatever distribution latency that involves.

OEM mistake: present but lying#

The second case is the worst-case from a detection standpoint, because it is unobservable from inside Windows. WSMT may report all three Protection Flags asserted on a platform whose SMI handlers were never actually rewritten to validate nested pointers. SDEV may list a device whose driver was never hardened to enforce its trustlet ownership. DMAR may declare a tight policy for a chipset whose VT-d implementation has a documented errata that defeats it. Microsoft itself states the impossibility result for WSMT in the public Learn prose ^[8]. The only mechanisms that catch this class are (a) certification programs that audit the firmware before it ships (Windows Hardware Lab Kit, Secured-core PC requirements ^[32]) and (b) external research, after the fact. The fix is, again, an OEM BIOS update.

Adversarial forgery: an attacker with a DXE foothold#

The third case is the most consequential. An attacker with a foothold in the firmware boot environment -- the DXE class typified by LogoFAIL (CVE-2023-40238, the Insyde BMP decoder memory-corruption Binarly published at Black Hat Europe 2023 ^[33]) -- writes a new WPBT entry, or a new SDEV entry, or a different DMAR Flags value into ACPI memory before Windows reads it. The Eclypsium 2021 demonstration showed that this works against Secured-Core PCs in 2021 ^[1]. The defender's observable surface is, by construction, none unless the firmware measured the relevant tables into a TPM PCR and the hypervisor consumes that measurement. The fix is partial today: WDAC over WPBT for the binary-execution case, Pluton-rooted attestation for the table-content-drift case, and OEM BIOS hardening for everything else.

Pluton's honest residual#

Pluton-rooted attestation closes some, but not all, of the forgery gap. The TCG PC Client Platform Firmware Profile specifies how firmware events are extended into TPM Platform Configuration Registers; Microsoft requires platform firmware to extend a specific event into PCR[7] when DMA protection is disabled or downgraded: "On every boot where the IOMMU (VT-D or AMD-Vi) or Kernel DMA Protection are disabled, will be disabled, or configured to a lower security state, the platform MUST extend an EV_EFI_ACTION event into PCR[7] before enabling DMA. The event string SHALL be 'DMA Protection Disabled'" ^[23]. That is the only narrowly-specified flow in this article that lets a remote verifier learn -- via TPM quote -- that the table set was downgraded between firmware build and OS boot.

It is also a single example. The general case -- "every security-bearing ACPI table was measured into a known PCR at firmware load, and the hypervisor refuses to launch trustlets if the measurement does not match a known-good baseline" -- is not a deployed mechanism on Windows today. Pluton-as-TPM is a precondition; the measurement schema is the missing piece [@ms-pluton; @pluton-sibling].

Pluton-rooted measured boot closes the freshness gap (the table did not change between firmware build and OS parse). It does not close the contents-correctness gap (the table contents were correct at firmware build in the first place). A WSMT with all three flags asserted by an OEM that did not actually harden their SMM handlers will measure the same way every boot, and the Pluton-rooted attestation will faithfully report it as valid. The contents-correctness problem requires either out-of-band certification (Secured-core PC) or a fundamentally different architecture (a vendor-controlled hardware-software stack, as on Apple's Secure Enclave-equipped silicon) -- not measured boot.

The freshness gap and the contents-correctness gap are independent failure modes, and they need independent mechanisms. Pluton solves the first. Nothing in the deployed Windows-on-OEM-firmware model solves the second; out-of-band certification (Secured-core PC) is the closest approximation, and it works only for the sample of devices Microsoft tests pre-ship.

We can name the failures. So who is responsible for fixing each one? That is the lifecycle question.

8. The Lifecycle Question: Who Populates, Who Validates, Who Owns the Bug#

The OS reads the tables. It does not write them. So who does, and who checks the writer's work?

Population#

SDEV, WSMT, and WPBT entries are constructed by the OEM's UEFI BIOS team, sometimes via platform-controller-side helpers (Intel ME, AMD PSP) when secure-resource enumeration crosses platform-controller boundaries. DMAR is mostly built by the reference Independent BIOS Vendor code that ships with Intel and AMD reference designs (American Megatrends, Insyde, Phoenix -- the three IBVs listed in the public UEFI Forum membership directory ^[37]) and customised by the OEM. IORT is filled in by the System-on-Chip vendor's reference firmware on Arm (Qualcomm, Ampere, NVIDIA on Grace-class platforms). The table set is assembled at firmware build time, not at boot. Once Windows is running, the tables are read-only; the only way to change them is to re-flash the firmware.

Validation, pre-ship#

Pre-ship validation runs through the Windows Hardware Lab Kit and the Microsoft Hardware Compatibility Program. Secured-Core PC certification raises the bar de facto. Per the OEM Standards for highly secure Windows 11 devices page, Secured-Core requires Secure Boot enabled with the third-party UEFI CA not trusted by default; TPM 2.0 meeting the latest TCG requirements; "the device supports Memory Access Protection (Kernel DMA Protection)" (i.e., DMAR / IVRS / IORT correctly authored); "System Guard Secure Launch (D-RTM) with System Management Mode (SMM) isolation" OR "S-RTM and Standalone MM with MM supervisor (the approach implemented on FASR devices)"; HVCI enabled; Windows Hello with Enhanced Sign-in Security (i.e., SDEV authored); and BitLocker ^[32]. WSMT-flags-asserted is checked transitively via the SMM-isolation requirement.

flowchart LR
subgraph OEM
P1[Build DMAR / IORT / WSMT / SDEV / WPBT at firmware build time]
P2[Re-author on each BIOS update]
end
subgraph Microsoft
V1[WHQL / HLK pre-ship validation]
V2[Secured-Core PC certification]
V3[Post-ship: ad-hoc research only]
end
subgraph Customer
C1[Run msinfo32, Win32_DeviceGuard, Get-MpComputerStatus]
C2[Author WDAC policy that constrains WPBT-injected binaries]
C3[Apply OEM BIOS updates -- only path for table-content fixes]
end
P1 --> V1
V1 --> V2
V2 --> C1
P2 --> C3
V3 -.-> C2

Validation, post-ship#

There is almost none, except via the WHQL driver flow and ad-hoc Microsoft research after a public disclosure. The 2021 Eclypsium WPBT-cert-validation finding triggered a Microsoft re-examination, and the response was a customer-side WDAC mitigation rather than an OS-side validator change ^[1]. The servicing-velocity problem is structural: ACPI table content cannot be patched by Windows Update; it requires a UEFI BIOS update from the OEM. The 2015 Lenovo Service Engine incident required Lenovo BIOS updates [@cisa-lse; @nvd-cve-2015-5684]; the Eclypsium finding could not wait for a comparable industry-wide BIOS-update wave, so Microsoft chose the WDAC path.

Servicing#

OEM BIOS update is the only path for table-content fixes. OS-side WDAC is the only path for binary-execution constraints over WPBT. Pluton-rooted attestation is the only path for drift detection between firmware build and OS boot. The three are layered, not redundant: a defender who cares about the WPBT class needs all three.

The four open problems#

The four open problems are not implementation details. They are structural negative spaces where no shipping mechanism today fills the gap.

First, there is no industry-standard attestable claim that an OEM has actually implemented the SMM mitigations they declared in WSMT. The obvious direction is a Pluton-attested SMM-mitigation manifest: a hardware-rooted statement that the firmware that built the WSMT also includes the SMI-handler implementations that justify the flags. Not standardised today. The current WSMT flags are a free-text declaration the OEM may make for any reason; the only check is presence.

Second, SDEV does not name which trustlet a device should be routed to. The binding between an SDEV-listed device and the consuming trustlet (BioIso, LsaIso, vmsp) is encoded implicitly in Windows policy and OEM driver INFs. There is no extensibility story for future trustlets, and no way for a third-party trustlet to declare which SDEV entries it expects to consume. If Microsoft ships a new trustlet for Wi-Fi credentials in five years, SDEV cannot describe the binding without a spec revision.

Third, WPBT signing trust roots are not declared in the table. The implicit assumption was that any Authenticode-trusted certificate would do. The Eclypsium 2021 disclosure broke that assumption ^[1]. WDAC is the workaround; a fix would require WPBT to declare a narrower trust root the firmware vouches for, and the OS to enforce only that root. Such a change has not shipped.

Fourth, forged-table detection from the Secure Kernel is partial. Not all five security tables are measured into well-defined PCRs. The only narrowly-specified flow is the PCR[7] EV_EFI_ACTION "DMA Protection Disabled" event Microsoft requires when DMA protection is downgraded ^[23]. A unified "measured ACPI" PCR -- e.g., PCR[5] extended with the hash of every security-bearing table at firmware load, paired with hypervisor-side enforcement that refuses to launch trustlets if the measurement does not match a known-good baseline -- is the obvious direction. It is not deployed.

The four open problems are: (1) no attestable claim that WSMT-declared SMM mitigations are actually implemented; (2) SDEV does not name the consuming trustlet; (3) WPBT signing trust roots are not declared in the table; (4) forged-table detection from VTL1 is partial. None of these is solved in shipping Windows in 2026. This is the live frontier of the firmware-OS contract.

Knowing the failure families and the lifecycle, what should you actually do on Monday morning? That is the practical guide.

9. Practical Guide: Inventory, Procurement, Defence#

You are now equipped to read these tables on your own laptop and to argue procurement criteria with a vendor. Here is the operational toolkit.

Inventory commands#

The fastest way to find out what is actually enabled on a Windows machine is a short PowerShell session followed by an optional Linux-side dump for the table contents themselves.

A worked example brings the flags to life. Suppose you dump the tables on a Surface-class laptop. SDEV will list \_SB.PCI0.GFX0.IRCM (the integrated infrared camera used by Windows Hello) with the Allow-Handoff bit clear -- the camera is owned by the Secure Kernel for the lifetime of the boot. WSMT will show ProtectionFlags = 7 (all three bits set: FIXED_COMM_BUFFERS | COMM_BUFFER_NESTED_PTR_PROTECTION | SYSTEM_RESOURCE_PROTECTION). DMAR will show DRHD entries for each VT-d remapping unit and the Flags byte will have bit 2 (DMA_CTRL_PLATFORM_OPT_IN_FLAG) set. WPBT may or may not be present; if present, you can extract HandoffSize and the binary itself, and pass the binary to signtool verify /pa /v to read its Authenticode chain.

PS> $g = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard
PS> "VBS status: $($g.VirtualizationBasedSecurityStatus); services running: $($g.SecurityServicesRunning -join ',')"

Procurement criteria for a security-conscious buyer#

The procurement conversation is the most consequential one a defender can have. The five table set is not patchable from Windows Update; if you bought wrong, you are stuck with it for the device's lifetime. The criteria worth pinning down before you sign a purchase order:

Defender-side Monday-morning actions#

Three actions are worth doing on the next available maintenance window.

Deploy a WDAC policy that constrains WPBT-injected binaries. This is Microsoft's recommended Eclypsium mitigation ^[1]. The App Identity sibling article walks WDAC authoring in detail ^[15]. Even a permissive policy that requires a specific signing root for WPBT binaries (e.g., your OEM's production cert, no others) eliminates the revoked-cert-attack class.

Verify that Memory Integrity, VBS, and Credential Guard are actually running, not just supported. Run Win32_DeviceGuard.SecurityServicesRunning across your fleet and alert on machines where the array is empty but VirtualizationBasedSecurityStatus = 1. That signature is the classic "the prerequisites are not met" outcome -- often WSMT.

Snapshot the ACPI table set on managed endpoints; alert on deltas across BIOS updates. A WPBT delta that does not correspond to a documented BIOS-update changelog entry is a SOC alert. So is the appearance or removal of an SDEV entry between two consecutive boots. Most enterprise firmware tooling can do this; if yours cannot, the Linux-side acpidump | acpixtract | iasl -d pipeline is a workable fallback.

Two final operational anchors round out the article: a frequently-asked-questions block you can hand to a colleague, and a closing study guide for revision.

10. FAQ and Closing#

A few questions a colleague will ask#

Closing#

This article is the substrate for the rest of the Windows platform-security series. The hypervisor-as-isolation-primitive ^[9] runs only when WSMT lets it. The trustlets that run inside the Secure Kernel ^[10] reach SDEV-listed devices and only those. Pluton-as-TPM ^[11] and the discrete TPM ^[12] anchor the measured-boot chain that, in principle, could detect a forged ACPI table -- and in practice, today, detects exactly one downgraded-DMA-protection event in PCR[7]. BitLocker ^[13] seals against PCR values that are themselves measurements of the firmware that built the table set. Secure Boot ^[14] verifies the bootloader that reads the table set; LogoFAIL showed that the firmware underneath Secure Boot can patch the tables before Secure Boot's verifier fires. Application identity and code integrity policy ^[15] is the only customer-side lever for the WPBT class. USB device-arrival policy ^[16] is the only customer-side lever for the runtime portion of the DMA class.

Every guarantee those articles describe rests on five tables the firmware writes and the OS trusts. You now know the names of the tables, the names of the failure families, and the inventory commands to read them on your own machine. The next time you see Kernel DMA Protection: Off in msinfo32, you will know what is missing, who can fix it, and why it matters more than the EDR vendor's marketing slide implied. The next time someone tells you their Secured-Core PC is rootkit-proof, you will know which 52-byte table to ask about.

---WRITER METRICS---
Word count: 12316
Citations: 111 inline citation markers across 34 unique sources (26 unique URLs + 8 sibling-article placeholders)
Mermaid diagrams: 7
Definitions: 8
Sidenotes: 4
FAQ questions: 7
---END WRITER METRICS---