UEFI CSM: Which Security Features Must Be Disabled?

Enabling the Compatibility Support Module (CSM) in modern UEFI firmware allows a system to boot legacy operating systems and run older hardware by emulating a traditional BIOS environment. However, because legacy boot processes lack cryptographic validation, activating CSM fundamentally conflicts with modern boot integrity features. This article outlines the specific security technologies—most notably Secure Boot, Virtualization-Based Security (VBS), and platform attestation—that must be disabled or become completely non-functional when CSM is turned on.

Secure Boot

Secure Boot is the primary security feature that must be explicitly disabled to turn on CSM. In many firmware implementations, the motherboard will automatically deactivate Secure Boot or prevent CSM from being toggled until Secure Boot is turned off manually.

Secure Boot relies on public key cryptography to verify that bootloaders, kernel drivers, and option ROMs are signed with trusted keys stored in the UEFI firmware. Legacy booting via CSM relies on the Master Boot Record (MBR) and executes raw 16-bit real-mode code that cannot carry or validate these digital signatures. Because CSM executes unsigned legacy code directly, running Secure Boot simultaneously is technically impossible.

Virtualization-Based Security (VBS) and HVCI

Windows features that depend on hardware-enforced isolation—such as Hypervisor-Protected Code Integrity (HVCI), Credential Guard, and Device Guard—cannot function under CSM.

These security features require an unbroken chain of trust that starts with UEFI Secure Boot and continues through the Windows bootloader to initialize a secure virtualized container. Because CSM breaks this chain of trust, VBS cannot verify the integrity of the operating system kernel and core security processes. Attempting to use CSM will force Windows to disable these protections.

Measured Boot and TPM PCR 7 Attestation

While a Trusted Platform Module (TPM) can technically still record boot events in legacy mode, modern Measured Boot and platform attestation features are compromised.

In a native UEFI environment, Platform Configuration Register 7 (PCR 7) binds directly to Secure Boot state and verifies the system's platform identity. When CSM is enabled, the system falls back to legacy BIOS interrupt routines (INT 19h), and PCR measurements revert to legacy registers (primarily PCR 0 through PCR 4). This shift breaks remote attestation protocols, Microsoft BitLocker's default Secure Boot binding mechanisms, and modern zero-trust network access checks.

UEFI-Only Hardware Protections and Signed Option ROMs

Running CSM forces the motherboard to load legacy Option ROMs (OpROMs) rather than UEFI-compliant drivers for add-in cards, such as network adapters and graphics cards. Consequently, firmware validation mechanisms designed to block malicious or unsigned hardware firmware are bypassed. To support CSM, you must set PCI device execution policies and storage configuration options to "Legacy" or "Do not launch," effectively shutting down UEFI-level hardware verification.