Limitations of Using CSM Instead of Native UEFI

The Compatibility Support Module (CSM) is a component of modern UEFI firmware that emulates a legacy BIOS environment, allowing older operating systems and hardware to function on newer platforms. However, relying on CSM rather than native UEFI introduces critical bottlenecks in drive capacity, system security, boot performance, and hardware compatibility. This article outlines the specific limitations users face when running an operating system through CSM legacy mode.

2.2 TB Boot Drive and Partition Limits

CSM forces the operating system to boot from an MBR (Master Boot Record) partitioned drive rather than the modern GPT (GUID Partition Table) standard. MBR natively addresses a maximum of 2.2 terabytes (TB) per disk and allows only four primary partitions. If an operating system boots under CSM, any capacity beyond 2.2 TB on that boot drive remains unusable. Native UEFI supports GPT, enabling boot drives up to billions of terabytes and up to 128 primary partitions natively in Windows.

Inability to Use Secure Boot and Hardware-Based Security

Enabling CSM disables Secure Boot, a fundamental UEFI security protocol designed to prevent rootkits and bootkits from executing during the startup phase. Because CSM relies on legacy 16-bit execution environments, it cannot verify digital signatures on firmware, bootloaders, or system kernels. Furthermore, relying on CSM prevents integration with modern security frameworks such as Microsoft Pluton, Virtualization-Based Security (VBS), and Hypervisor-Protected Code Integrity (HVCI).

Slower Boot Times and Initialization

CSM introduces substantial overhead to the system’s Power-On Self-Test (POST) process. Under CSM:

  • The system must switch the processor into 16-bit real mode and load legacy Option ROMs.
  • Hardware components are initialized sequentially rather than simultaneously.
  • Features such as UEFI Fast Boot and native OS hibernation optimizations cannot function.

In contrast, native UEFI initializes system devices in parallel using 32-bit or 64-bit drivers, drastically cutting boot times.

Incompatibility with Modern Graphics Cards and Features

Modern graphics processing units (GPUs) increasingly rely on the Graphics Output Protocol (GOP) rather than legacy Video BIOS (VBIOS). Attempting to boot modern GPUs with CSM enabled often results in black screens during POST, resolution issues, or outright boot failures. Additionally, advanced performance features like Resizable BAR (ReBAR) / Smart Access Memory (SAM)—which allow the CPU full access to GPU VRAM—strictly require native UEFI and are entirely disabled when running CSM.

Deprecation in Modern Operating Systems

Modern operating systems actively reject CSM. Windows 11 explicitly mandates native UEFI mode and Secure Boot for installation; running under CSM makes a machine officially unsupported. Similarly, many modern Linux distributions are removing legacy BIOS bootloader fallbacks from their default installation media.

Lack of Seamless Firmware Updates

Under native UEFI, operating systems can deliver firmware updates directly via UEFI Capsule Updates (often delivered automatically through Windows Update or Linux fwupd). When CSM is active, the OS cannot communicate with the system firmware interface in this manner, forcing users to manually flash BIOS updates using external storage media and built-in motherboard flashing utilities.