CSM, short for Compatibility Support Module, is a component of UEFI firmware that emulates a legacy PC BIOS so that operating systems, boot loaders and expansion cards written for the old BIOS interface can still start on a modern computer. In boot & firmware terms, it is a bridge between two generations of platform firmware: the machine runs UEFI internally, but presents BIOS-style services to software that expects them.
For operating systems, CSM decides which boot path a computer can use. With CSM enabled, the firmware can start a disk with a Master Boot Record (MBR) in legacy mode; with CSM disabled, only native UEFI boot from a GPT disk with an EFI System Partition is possible. The setting therefore affects installation, dual-boot setups, Secure Boot and support for older graphics or network cards.
How the Compatibility Support Module works
Legacy BIOS software relies on 16-bit real-mode interrupt services, for example INT 13h for disk access and INT 10h for video output. UEFI firmware does not use these interfaces natively. The CSM supplies them by loading a legacy BIOS image inside the UEFI environment and translating requests where needed, so a traditional boot sector can run as if it were on a pre-UEFI PC.
When legacy boot is selected, the firmware completes its own initialization, hands control to the CSM, builds the legacy memory map and tables, and then loads the first 512-byte sector of the boot disk to address 0x7C00. From that moment the boot code believes it is running on a classic BIOS, and the UEFI boot services are no longer used for that boot.
The CSM also executes legacy option ROMs, the small firmware programs stored on graphics cards, network adapters and storage controllers. A modern card carries a UEFI GOP driver or other UEFI driver instead, while an older card may only have a legacy ROM and therefore needs CSM to display anything before the operating system loads.
Legacy boot and native UEFI boot compared
Enabling CSM does not simply add features: it switches the machine into a different boot model with different requirements and limits. The table below compares the two paths.
| Aspect | Legacy boot via CSM | Native UEFI boot |
|---|---|---|
| Partition scheme | MBR, at most four primary partitions | GPT, typically up to 128 partitions |
| Maximum boot disk size | About 2 TiB with 512-byte sectors | Far beyond current disk sizes |
| Boot code location | First sector and partition boot sectors | EFI files on the EFI System Partition |
| Secure Boot | Not available | Available and often required |
| Processor mode at handoff | 16-bit real mode | 32-bit or 64-bit protected mode |
| Expansion card firmware | Legacy option ROMs | UEFI drivers such as GOP |
Windows illustrates the practical rule clearly: in legacy mode it boots only from MBR disks, and in UEFI mode only from GPT disks. Linux boot loaders are more flexible, but the firmware mode chosen at installation still determines which boot loader variant is installed and how the boot order is stored.
CSM settings and UEFI class levels
Firmware setup screens expose CSM in several ways, sometimes as a single switch and sometimes as separate policies for boot devices, storage and video. The common options are summarized below.
| Option | Effect | When it is used |
|---|---|---|
| CSM disabled | Only UEFI boot and UEFI drivers | Modern operating systems, Secure Boot |
| CSM enabled, UEFI first | Tries UEFI, falls back to legacy | Mixed environments during migration |
| Legacy only | Boots exclusively through the BIOS emulation | Old operating systems or tools |
| Option ROM policy | Chooses legacy or UEFI ROM per device | Older graphics or network cards |
The industry describes firmware by UEFI class. Class 0 is a pure legacy BIOS, Class 1 is UEFI that only exposes legacy boot, Class 2 supports both paths through a CSM, and Class 3 is UEFI without any CSM. Platform vendors have been moving to Class 3 firmware, and many current systems no longer offer CSM at all.
Why modern systems turn CSM off
The strongest reason is security. Secure Boot verifies the signature of every boot component, but the CSM path loads unsigned real-mode code, so Secure Boot cannot work while legacy boot is active. Operating systems that require Secure Boot capability or rely on measured boot, such as Windows 11, expect a UEFI boot with CSM disabled.
Other features also depend on native UEFI. Resizable BAR for graphics cards, fast boot paths, large GPT boot disks and the firmware boot manager that lists multiple operating systems all work best, or only, without CSM. Keeping legacy compatibility also adds code that vendors must maintain and test, which is why it is being removed.
Migration pitfalls and troubleshooting
Changing the CSM setting on an installed system is the most frequent cause of trouble. An operating system installed in legacy mode does not boot after CSM is disabled, because its boot code lives in the MBR rather than in an EFI System Partition. The table lists typical situations and remedies.
| Symptom | Likely cause | Fix |
|---|---|---|
| No bootable device after disabling CSM | System installed on an MBR disk | Convert to GPT, for example with MBR2GPT |
| Black screen until the OS loads | Graphics card lacks a UEFI GOP ROM | Update the card firmware or enable CSM |
| Secure Boot option grayed out | CSM or legacy boot still enabled | Disable CSM, then enable Secure Boot |
| USB installer not listed | Media prepared for the other boot mode | Recreate the media for UEFI or legacy |
| Dual boot shows one system only | Systems installed in different modes | Reinstall both in the same mode |
A safe procedure is to back up first, confirm the current mode in the operating system, convert the disk layout where supported, and only then disable CSM and enable Secure Boot. Reversing the order leaves a machine that cannot start until the setting is restored.
Explained without jargon
Modern computers start up with a newer system called UEFI, while older computers used something called BIOS. CSM is a built-in translator that lets a new computer pretend to be an old one, so that an old operating system, an old installation disk or an old graphics card still works.
The translator is useful during transitions, but it comes at a price. While the computer pretends to be old, modern security checks are switched off and some newer features stop working. That is why most current systems are set to run without CSM whenever all their software supports the newer way of starting.
A typical use case
An office technician wants to upgrade a desktop PC to Windows 11, but the upgrade check reports that Secure Boot is not available. The firmware setup shows that CSM is enabled and that the existing Windows 10 installation boots in legacy mode from an MBR disk.
After making a full backup, the technician validates the disk and converts it from MBR to GPT with the built-in conversion tool, which creates an EFI System Partition. In the firmware, CSM is then disabled, the boot mode is set to UEFI only and Secure Boot is enabled. The PC boots normally in UEFI mode, the compatibility check passes and the upgrade proceeds. The whole change takes about 30 minutes and no data or reinstallation is needed.