Published Jan 21, 2026, 4:01 PM EST

I’m Adam Conway, an Irish technology fanatic with a BSc in Computer Science and I’m XDA’s Lead Technical Editor. My Bachelor’s thesis was conducted on the viability of benchmarking the non-functional elements of Android apps and smartphones such as performance, and I’ve been working in the tech industry in some way or another since 2017.

In my spare time, you’ll probably find me playing Counter-Strike or VALORANT, and you can reach out to me at adam@xda-developers.com, on Twitter as @AdamConwayIE, on Instagram as adamc.99, or u/AdamConwayIE on Reddit.

Sign in to your XDA account

When you press the power button on your computer, you probably expect Windows, macOS, or Linux to spring into action. But here’s something most people don’t realize: by the time you see your desktop, your computer has already executed millions of instructions across multiple independent processors. It has already executed a large amount of firmware code across multiple controllers, potentially verified boot components with cryptographic signatures, trained memory, initialized devices, and prepared the machine to load an OS. And all before your actual operating system even begins to load.

This invisible layer of pre-boot code is where some of the most vulnerable parts of your computer operate. Understanding what happens in these first few seconds can help you troubleshoot stubborn boot problems, protect yourself from attacks, or even just better understand your computer and what’s going on internally. As well, it reveals just how complex modern computing has become, and how there’s a lot more going on in your system than meets the eye.

A small subsystem kickstarts the entire boot process

Intel and AMD both have it

Before your main CPU even wakes up, there’s already code running on your machine. Both Intel and AMD processors contain separate, autonomous security processors that power on the moment your motherboard receives electricity, even when your computer is "off," and we’ll start with what happens on Intel. If you have an Intel processor made after 2008, your computer likely contains the Intel Management Engine (ME). This is a subsystem within the platform with its own operating system (MINIX 3 as of firmware version 11), complete access to your system’s memory, and can even provide out-of-band network management when the host OS is down.

The ME has access to everything: your RAM, your storage, your network adapter. And it runs constantly in a low-power state as long as it’s receiving standby power. This isn’t a bug or a backdoor, though security researchers and organizations like the Electronic Frontier Foundation have raised concerns about its potential for misuse. While the EFF says that ME "now constitutes a separate computing environment that is designed to deny users the control of their computer," it’s designed to enable enterprise features like remote management and hardware-level security.

AMD’s equivalent is the Platform Security Processor (PSP), present in AMD chips since around 2013. On AMD platforms, the Arm Cortex-A5 PSP boots before the x86 cores are fully released and participates in early platform initialization and root-of-trust checks. That’s what makes it so interesting: your x86 processor cores literally cannot start until the PSP allows them to. It verifies your firmware’s authenticity before your main CPU executes a single instruction.

Both of these security processors represent the first layer of code execution, running before anything you’d typically think of as "your computer" even begins.

How firmware grew up, and what it actually does

From BIOS to UEFI

Press the power button on your computer; it may seem instant, but nothing actually happens until the security processor gives the green light. This is when your CPU wakes up and immediately looks for instructions at a specific memory address called the reset vector. On x86 processors, this is memory location FFFFFFF0h (16 bytes below 4 GB). The CPU begins fetching from that address, which is mapped to firmware via chipset mapping, and what it finds there is your system’s firmware. That system firmware has grown enormously over the decades.

The original IBM PC BIOS fit in 8 kilobytes of ROM. Modern UEFI firmware can be up to 32 megabytes, a 4,000-fold increase, and this is because your firmware now handles a significant number of tasks that would have been unimaginable in 1981. If you find yourself wondering what the difference between a BIOS and a UEFI is, to the end-user, they achieve the same goal, but they’re very different under the hood.

If you’ve bought a computer in the last decade, it almost certainly uses UEFI (Unified Extensible Firmware Interface) rather than BIOS (Basic Input Output System). Legacy BIOS operates in 16-bit real mode, can only access 1 MB of memory, and is limited to booting from drives smaller than 2.2 TB due to Master Boot Record (MBR) limitations. Its interface is text-based and keyboard-only. UEFI, though, runs in 32-bit or 64-bit mode with access to your full system memory. It can boot from drives up to 9.4 zettabytes (theoretically) using GPT partition tables. It supports graphical interfaces with mouse input, can initialize hardware in parallel for faster boot times, and includes built-in networking support.

Most importantly for security, UEFI introduced Secure Boot, a mechanism that validates the digital signatures of boot components using typically RSA-based (commonly RSA-2048, depending on platform policy) certificates before allowing them to execute. This creates a chain of trust from firmware to bootloader to operating system kernel. While both UEFI and BIOS enable your computer to boot and can manage low-level settings, they’re very different systems in terms of implementation.

Validating the chain of trust

The POST process is complex

When we talk about a computer POSTing, what we mean is that the computer passed the Power-On Self-Test. This is the POST and initialization sequence that most computers typically undergo:

• Initialize your CPU and load microcode patches to fix processor bugs
• Tests and configure RAM, requiring complex timing calibrations
• Initialize storage controllers, USB ports, network interfaces, and display adapters
• Run diagnostic tests to verify hardware functionality
• Manage boot device selection and priority
• Validate cryptographic signatures on boot components (if Secure Boot is enabled)
• Load additional firmware from expansion cards and peripherals

That last point is especially important, as your graphics card, network adapter, RAID controller, and other peripherals each have their own embedded firmware called Option ROMs. These run during boot to initialize their respective hardware, adding yet more code to the pre-OS execution environment.

Secure Boot (when enabled) enforces signature checks for UEFI bootloaders and UEFI drivers in the pre-OS environment. But not every piece of firmware on the bus is automatically verified in the way you might assume, especially once you include third-party option ROMs and the many device controllers that initialize themselves. This is why the Trusted Platform Module, or TPM, is also important, as it’s a dedicated security chip that is used for measured boot. This means that firmware and early boot components record cryptographic measurements (hashes) into TPM Platform Configuration Registers, which are special memory registers used by the TPM. Tools like BitLocker can use those measurements to detect unexpected boot changes and require recovery

Typically speaking, this is a high-level overview of the boot process on a modern Windows 11 machine:

• The security processor (ME/PSP) verifies the firmware
• The firmware verifies the bootloader (via Secure Boot)
• Secure Boot validates the signatures of UEFI boot components (the Windows Boot Manager, or winload). After handoff, Windows’ own code integrity mechanisms enforce kernel and driver-signing policy.
• The kernel verifies drivers and system components

In theory, this creates an unbroken chain of trust from hardware to software. In practice, researchers keep finding ways to break it.

Firmware attacks are dangerous, and vulnerabilities keep piling up

BlackLotus is one of many examples

Firmware-level malware (often called bootkits) can survive OS reinstalls since reformatting your drive doesn’t touch firmware. It evades antivirus software because security tools run at the OS level while firmware runs below it. Remember how we mentioned that Intel’s Management Engine is a concern when it comes to security? It’s often described as running at ring level -3, meaning that it’s below the operating system, and anything running at this level can be impossible to detect. What’s more, code running this early can see all subsequent activity.

The only close-to-reliable way to remove firmware malware is often to reflash the firmware itself, assuming that it didn’t target SPI descriptor locks, capsule update paths, or persist in attached devices. In other words, if you find your motherboard infected, it’s probably safer to just buy a new motherboard. There have been multiple UEFI bootkits over the years, with BlackLotus being one of the most famous examples that abused Secure Boot ecosystem weaknesses and revocation gaps. However, there are also other problems that have arisen even just over the last year.

• January 2025: ESET researchers discovered a UEFI Secure Boot bypass (CVE-2024-7344) affecting the majority of UEFI-based systems.
• June 2025: Researchers discovered "Hydroph0bia" (CVE-2025-4275), a Secure Boot bypass that allows malicious code execution during early boot on systems that appear to have all protections enabled.
• July 2025: Gigabyte motherboards were found to be susceptible to memory corruption vulnerabilities in System Management Mode (SMM), a special CPU operating mode that runs below the OS level (CVE-2025-7026, CVE-2025-7027, CVE-2025-7029). These flaws could enable persistent bootkit installation that survives operating system reinstalls. Neither Intel Boot Guard nor UEFI Secure Boot can prevent these attacks, as Secure Boot doesn’t stop SMM exploitation.
• December 2025: Discovered by Riot games, early-boot DMA attack vulnerabilities were found (CVE-2025-14304, CVE-2025-11901, CVE-2025-14302, CVE-2025-14303) affecting motherboards from ASRock, ASUS, GIGABYTE, and MSI. These allowed attackers with physical access to inject malicious code via PCIe devices because the firmware incorrectly reported that DMA protection is active when it wasn’t.

Another flaw of modern UEFI implementations is the requirement to update the on-board certificate that verifies that the UEFI itself is not tampered with. The Microsoft UEFI CA 2011 certificate expires in June 2026, and is used on many older devices. While most UEFI implementations disable certificate date checking, Microsoft has stated that systems will need updated Secure Boot certificates to continue running Windows and receiving regular updates when Secure Boot is enabled. Linux systems may also face boot issues on systems with Secure Boot enabled if certificates aren’t updated.

It all happens behind the scenes

There’s a happening under the hood

What happens in those first few seconds after you press the power button matters more than you’d think. The security processors, the firmware layers, and the cryptographic verification are invisible to most people. But when someone figures out how to get past Secure Boot by exploiting a firmware bug, there are serious ramifications. Malware sticking around after you’ve wiped a drive and reinstalled Windows is the least of your concerns; it’s finding out you even have it in the first place. Your antivirus certainly won’t pick it up.

Thankfully, the security community has been paying significant amounts of attention to UEFI and Secure Boot, and hardware manufacturers are being more careful and patching things fater. Even still, there’s an awkward truth here. Modern boot processes are so complicated that with every fix introducing more code, we’re led to a place where there are more opportunities for things to go wrong.

If you’re a regular, typical user, the advice is simple. Keep your system updated, leave Secure Boot enabled, and install BIOS updates when they’re released. If you’re someone who needs to think more about this kind of thing, then understanding how everything works together can help you make better decisions of what hardware to trust and what actions to undertake to protect yourself further.

Your computer is busy long before you see your desktop; multiple processors are checking signatures and initializing hardware at the same time as the other important steps like memory training are underway. There are millions of instructions happening all before your operating system even gets a turn. The most amazing about all of it is that you never really have to think about it.