CPU Microcode Updates Explained: Loading, Signing and Checking

A CPU microcode update is a small, vendor signed patch that changes how a shipped processor executes some instructions, fixes errata and adds security controls. It does not survive a power cycle, so it is loaded again on every boot: from the platform firmware first, then usually from the operating system very early in boot. To check it, read the running revision (grep microcode /proc/cpuinfo on Linux, the Update Revision registry value on Windows) and compare it with the CPU maker's latest release.

This guide goes one level deeper than our posts on Intel CSME and AMD PSP and firmware updates with fwupd and LVFS. We read the Linux kernel's microcode loader documentation and the commits that changed it, Intel's microcode repository README and release notes, Intel's Microcode Update Guidance, the AMD microcode README in linux-firmware, two AMD security bulletins, Microsoft's support articles on microcode and speculative execution, the Debian microcode wiki and NIST SP 800-193. Every path, version and date below comes from those sources, and where a vendor does not publish a detail, we say so.

Key takeaways

• Microcode is the layer inside an x86 CPU that implements complex instructions and internal behaviour. An update can fix errata, add or change model specific registers, add security controls such as branch prediction barriers, and change which features the CPU reports. It cannot add new silicon.
• Updates are volatile. Intel's README says microcode state resets on a power reset, so the update has to be applied on every boot.
• There are several load points: the processor itself via the Firmware Interface Table (FIT) before the first BIOS instruction, the BIOS during platform init, the OS early in boot from the initramfs, and late loading on a running system. Earlier is better.
• The CPU maker produces and signs the update. AMD's own bulletin describes a signature verification check in the CPU ROM patch loader. Intel's header format describes the payload as encrypted and protected by a checksum, but Intel does not publish its signature scheme in the documents we read.
• Distributions and Windows redistribute vendor binaries unchanged. Package signatures protect delivery; the CPU's own check decides whether the patch runs.
• Linux disabled late loading by default in kernel 5.19 (2022) because it can destabilise a running system. A 2023 rework added a minimum revision field so the kernel can tell when a late load is safe.
• In 2025 AMD published a weakness in its microcode signature verification. The fix had to arrive through a BIOS update, which shows why OS delivered microcode alone is not enough.
• On recent Linux kernels, /sys/devices/system/cpu/vulnerabilities/old_microcode tells you whether the CPU booted with microcode older than the kernel's list of known releases.

What is microcode, and what can an update change in a shipped CPU?

Modern x86 processors decode most simple instructions directly in hardware, but complex instructions, unusual corner cases and many internal housekeeping flows are driven by microcode: sequences of internal operations stored in on chip ROM. Because ROM cannot be rewritten after manufacturing, the CPU also contains a small patch mechanism. A microcode update loads patches into on chip memory that override or extend specific ROM routines until the next reset.

Intel's README for its Linux microcode package describes the scope plainly. The microcode update (Intel abbreviates it MCU) "provides a mechanism to release updates for security advisories and functional issues, including errata." It also says MCUs start the SGX enclave on processors that support it and implement complex behaviours such as assists. That gives a useful picture of what an update can touch:

Two consequences follow. First, a microcode change is a security relevant change to the most privileged code on the machine, which is why it has to be authenticated. Second, because microcode can change what the CPU reports to software, the moment at which it is loaded matters a great deal. Software that has already read a CPUID bit or used an MSR can be surprised if the ground moves under it.

Revisions, signatures and file names

Every update has a revision number. On Intel parts, the revision is a 32 bit value. The open source EDK II firmware header that defines Intel's update format describes the UpdateRevision field as the "unique version number for the update" and says it is a signed 32 bit number. The same header lists the processor signature (extended family, extended model, type, family, model and stepping, matching what CPUID returns), a platform flags field that matches bits in MSR 17H, a checksum over the header and data, a loader revision, and a data size field described as "the size of the encrypted data in bytes."

Intel's README explains how a CPUID signature maps to the file name Linux uses. A processor returning 0x000906eb from CPUID becomes the file 06-9e-0b: family 0x06, model 0x9e, stepping 0x0b. A single file can serve several platform types, selected by an 8 bit mask that is matched against the platform ID in MSR 17H.

AMD names its Linux files by CPU family instead. The linux-firmware README for AMD lists container files such as microcode_amd_fam17h.bin, microcode_amd_fam19h.bin and microcode_amd_fam1ah.bin, each holding patches for several models and steppings, with a patch level such as 0x0a0011d5 for each. Families older than 15h live in a combined microcode_amd.bin.

Where are updates loaded from, and why is early loading preferred?

There are five places a microcode update can be applied. Intel's Microcode Update Guidance describes the firmware side in detail and the Linux kernel documents the OS side.

Why firmware first

Intel's README states that "MCUs are best loaded from the BIOS" and that "Certain MCUs must only be applied from the BIOS." Those BIOS only updates are never placed in the Linux package at all. The guidance explains why: some update components only take effect if loaded at or before a specific point in boot, and early loading fixes issues that could affect later firmware code such as memory initialisation. An OEM may receive a superset of updates for its firmware compared with what Intel publishes for operating systems.

AMD's 2025 signature bulletin, covered below, gives a concrete example of firmware dependence. After the fixed platform initialisation firmware is installed on some server lines, AMD notes that microcode "cannot be hot-loaded" unless the BIOS is at or above a stated minimum version, and a general protection fault occurs if you try to hot load newer microcode on older BIOS.

Why early OS loading is the next best thing

The kernel loader documentation explains the early path. During boot of the first processor, before the other cores come online, the kernel scans the initrd for a matching update. If it finds one, it applies it to the boot processor and later to every application processor as they start. It also caches the matching patch in memory so it can reapply it when CPUs resume from sleep, because a sleep state can lose the update.

The ordering matters because the kernel enumerates CPU features after the early load. The 2023 kernel commit that added a minimum revision check says it directly: for early loading "there is no restriction because OS visible features are enumerated after the early load and therefore a change has no effect." In other words, an early load can change CPUID bits safely because nothing has read them yet.

Intel's README adds that "In situations where a BIOS update isn't available, early loading is the next best alternative," and recommends the initrd method "as this method will load the MCU at the earliest time for the most coverage." Intel's guidance goes further: the OS should load a newer revision before CPUID enumeration is cached and before user space or virtual machines start.

The initramfs format

The kernel expects a combined image: microcode as an uncompressed cpio archive, followed by the (possibly compressed) normal initrd. The kernel documentation includes a short shell script that builds this image by concatenating /lib/firmware/intel-ucode/* into kernel/x86/microcode/GenuineIntel.bin and the AMD files into kernel/x86/microcode/AuthenticAMD.bin, packing them with cpio -o -H newc, and prepending the result to the existing initrd. It also says you do not normally need to do this yourself, because distribution tools do it when they rebuild the initrd. Debian and Ubuntu do it in update-initramfs, Fedora family systems in dracut, and Arch Linux in mkinitcpio through its microcode hook or by listing intel-ucode.img or amd-ucode.img as the first initrd in the boot loader.

There is a third, less common option. The kernel can carry microcode built in through CONFIG_EXTRA_FIRMWARE, for example intel-ucode/06-3a-09 or amd-ucode/microcode_amd_fam15h.bin. The documentation notes this is "not the most flexible" because you must rebuild the kernel each time the vendor releases new microcode.

How do CPUs authenticate microcode updates?

The short answer is that the CPU maker builds and signs each update, and the processor's own patch loader checks it before applying it. Nobody else in the chain (OEM, Linux distribution, Microsoft) can produce a patch the processor will accept. They can only choose which signed patch to deliver and when. How much detail the vendors publish about that check differs.

AMD: a signature check in the CPU ROM patch loader

AMD's bulletin AMD-SB-7033 is the clearest vendor statement we found. It describes "Improper signature verification in AMD CPU ROM microcode patch loader" and says the reported flaw allowed researchers to load "patches that were not signed by AMD." Read the other way round, the bulletin confirms the design: AMD signs microcode patches, and a loader in CPU ROM is supposed to refuse anything AMD did not sign.

AMD's linux-firmware README shows a second kind of check. Many recent entries carry a line such as "Minimum base ucode version for loading: 0x0a0011d9". A patch with that line will only load on a CPU that is already running at least that revision. That is a revision gate enforced on top of the signature.

Intel: encrypted payload, checksum and processor match

Intel's public material is less specific about cryptography. The EDK II header that describes the Intel update format refers to the payload as encrypted data, defines a checksum that must sum to zero across the header and data, and requires the processor signature and platform flags to match the CPU. Intel's Microcode Update Guidance says the BIOS is responsible for ensuring "the validity and the integrity of the microcode update" before it places an update in flash, and that "you can only update to a higher version of microcode." It also says some updates block loading a lower revision at all. Intel's README repeats the rule for its Linux files: downgrade is not possible with the provided instructions.

What Intel does not publish, in the README, release notes or guidance we read, is the signature algorithm or key arrangement the processor uses. We will not guess at it. For an administrator, the practical point is the same as for AMD: only an update produced by the CPU maker will load, matching is per processor signature and platform, and revisions only move forward unless the update says otherwise.

Revision checks that the OS adds

The kernel adds its own checks on top of the CPU's. For Intel parts, a 2023 change by an Intel engineer (merged for Linux 6.7) uses a field Intel added to a previously reserved part of the header: a "minimum required version". The commit explains that when microcode changes visible features, Intel sets that field to the update's own revision, which prevents late loading. The commit also notes that "The hardware/firmware ignores this header field." It is a purely OS side safety signal, not part of the CPU's authentication.

Who signs what, end to end

The table explains why distribution signatures are necessary but not sufficient. An apt or rpm signature tells you the file came from your distribution unchanged. It says nothing about whether the patch inside is safe to run. That decision belongs to the CPU, which is why a flaw in the CPU's own check is serious.

How are microcode updates distributed?

Linux: vendor repositories, linux-firmware and distribution packages

Intel publishes its OS loadable updates in the Intel-Linux-Processor-Microcode-Data-Files repository on GitHub, in the intel-ucode directory, named family-model-stepping. The README says the package "is provided for Linux distributors for inclusion in their OS releases" and that Intel "recommends obtaining the latest MCUs using the OS vendor update mechanism." A separate intel-ucode-with-caveats directory holds updates that need special kernel handling.

Releases are tagged by date. The release notes we read list 44 tagged releases going back to microcode-20190312. The three most recent at the time of writing illustrate the rhythm:

The middle row is worth remembering. A microcode release was pulled for one stepping a day after it shipped, then replaced six weeks later. Microcode is software, and it gets the same release and rollback discipline as any other software.

AMD's OS loadable updates ship in the amd-ucode directory of the linux-firmware repository. Its README lists every patch in every container file, and points to AMD's amd_ucode_info.py script, which prints the family, model, stepping and patch level for each patch in a container file.

Distributions then package these files:

On Debian, the wiki notes that both packages live in the non free parts of the archive, and that Debian 12 users must also enable non-free-firmware. The Debian package names and the Arch package names above come from those projects' own wiki pages. For Fedora and RHEL, package names have changed over time, so check your release's documentation rather than trusting a table.

Windows: Windows Update, the Update Catalog and the OS loader

Windows can also apply microcode from the operating system. Microsoft's support article for the June 2015 Intel microcode update lists the file Mcupdate_genuineintel.dll for every supported Windows version, which is the library Windows uses to carry Intel updates. Microsoft delivers new microcode as numbered knowledge base updates. Its summary article KB4093836 lists, per Windows version, the KB numbers carrying "Intel-validated microcode updates" for branch target injection, speculative store bypass, L1 terminal fault, microarchitectural data sampling and MMIO stale data, and says they are available through "Windows Update, Windows Server Update Service, and Microsoft Update Catalog."

Microsoft's server guidance (KB4072698) is explicit that this is not the only route. It says "To get all available protections, firmware (microcode) and software updates are required," that this "may include microcode from device OEMs," and that you should apply the firmware update "provided by the device manufacturer." It also recommends installing the latest Windows updates before installing any microcode updates. Surface devices are an exception noted in the article: they get microcode through Windows Update.

Firmware: the route that covers everything

Every load point after the FIT depends on the update already being in firmware or on the OS doing it every boot. A BIOS or UEFI update from the OEM refreshes the microcode that loads before anything else, and it is the only route for updates Intel marks as BIOS only. On Linux, many OEMs publish UEFI capsule updates through LVFS, which fwupdmgr installs; see our fwupd and LVFS guide for how capsule updates are verified and applied. NIST SP 800-193, published in May 2018, frames the goal for all platform firmware, including microcode embedded in it: protect against unauthorised changes, detect them, and recover.

What do microcode delivered security fixes look like in practice?

This section describes two kinds of example conceptually: speculative execution mitigations that need microcode, and a published weakness in the microcode signature check itself. We avoid attack detail on purpose.

Speculative execution mitigations that need microcode

The NVD entry for the branch target injection issue (CVE-2017-5715) was published on 4 January 2018. It describes systems whose processors use "speculative execution and indirect branch prediction" being open to information disclosure through a side channel. The mitigation needed both operating system changes and new CPU controls. The Linux kernel's Spectre documentation describes those controls: Indirect Branch Restricted Speculation (IBRS), Indirect Branch Prediction Barrier (IBPB) and Single Thread Indirect Branch Predictors (STIBP), and says the sysfs file for Spectre variant 2 reports "CPU features enabled by microcode" to mitigate it. Newer processors expose an enhanced IBRS mode in hardware, which the kernel prefers when present.

Microsoft's SpeculationControl PowerShell module reports the same split on Windows. Its documentation explains that the line "Hardware support for branch target injection mitigation is present" maps to BTIHardwarePresent, and that "The device OEM is responsible for providing the updated BIOS/firmware that contains the microcode provided by CPU manufacturers." If that line is False, Windows cannot turn the mitigation on, however up to date the OS is.

The second example is Microarchitectural Data Sampling (MDS). Intel's microcode-20190514 release lists "Security updates for INTEL-SA-00233." The Linux MDS documentation explains why the microcode mattered: the kernel mitigation clears CPU buffers on return to user space, and only microcode guarantees that the instruction it uses actually clears them. If the microcode is missing, /sys/devices/system/cpu/vulnerabilities/mds reports "Vulnerable: Clear CPU buffers attempted, no microcode." The kernel still issues the instruction on a best effort basis, partly for virtual machines whose host has the microcode but whose hypervisor does not yet advertise it.

The lesson from both is the one Microsoft's guidance states: you need firmware or microcode and OS updates together. A patched kernel on stale microcode, or new microcode under an old kernel, often leaves the mitigation off.

A published weakness in the signature check

On 3 February 2025 AMD published bulletin AMD-SB-3019, rated High, describing "Improper signature verification in AMD CPU ROM microcode patch loader" (CVE-2024-56161) and its effect on confidential virtual machines protected by SEV-SNP. On 5 March 2025 AMD published AMD-SB-7033, rated Medium, covering the broader issue (CVE-2024-36347). AMD says external researchers reported that they could load patches not signed by AMD and could forge signatures for arbitrary patches, given local administrator privilege. AMD attributes the issue to "a weakness in signature verification algorithm" and states it "has not received any reports of this attack occurring in any system."

Three things about the fix are instructive.

1. It came through firmware. AMD released fixed platform initialisation firmware to OEMs and tells customers to "contact your OEM for the BIOS update specific to your product." The bulletin lists minimum PI versions and the microcode revisions that confirm the mitigation is installed.
2. It changed late loading. For some server lines, once the fixed PI firmware is installed, newer microcode cannot be hot loaded unless the BIOS is at or above a stated minimum version.
3. OS packages had to bridge the gap. AMD's linux-firmware README now includes, for family 19h, a second patch per affected CPU for machines that have not received the BIOS update. It brings them "to the highest possible level without the microcode signing fix," so they still get some later fixes. The README says a BIOS update "is highly recommended."

The takeaway for operators is that the root of trust for microcode lives in the CPU and in firmware. When that check itself needs fixing, an OS package cannot finish the job. Track BIOS versions as carefully as kernel versions.

Timeline

What does late loading risk, and why did Linux restrict it?

Late loading means applying a new microcode revision while the system is running real workloads. The kernel documentation lists the reasons this is hard, and they are worth reading closely because they apply to any OS.

Siblings share the engine. The microcode engine is shared between the two hardware threads of a core. When one thread applies the update, the sibling gets it too. Because microcode can emulate some MSRs, those MSRs "transiently cease to exist" during the update. If the sibling happens to touch one at that moment, it can take a general protection fault. Any other instruction being patched can misbehave the same way.

Some interrupts cannot be stopped. Linux used stop_machine() to park every CPU in a spin loop during the update, which handles ordinary interrupts. It cannot stop machine checks, system management interrupts or non maskable interrupts. The documentation walks through each: a machine check during the update can lead to shutdown if a thread fails to reach the rendezvous, an SMI stops the sibling at the first instruction of the SMI handler, and an NMI on the sibling can run code that is mid patch.

The update may remove something in use. The documentation's example: a CPU at patch level 1 receives patch level 3, but patch level 2 deprecated a software visible feature. If the running kernel or an application uses that feature, for example an MSR that no longer exists, it faults. "Basically there is no way to declare a new microcode update suitable for late-loading," the documentation says, and it lists this as one of the reasons late loading was not enabled by default.

What changed in 2022 and 2023

In May 2022, the commit that became part of Linux 5.19 added a Kconfig option, MICROCODE_LATE_LOADING, labelled "Late microcode loading (DANGEROUS)" and defaulting to off. Its commit message is blunt: late loading "is dangerous and it should not be used anyway" because early loading exists. The same release removed the old /dev/cpu/microcode interface. Late loading also taints the kernel, so bug reports from such systems are marked.

In October 2023, a set of commits reworked the mechanism rather than removing it:

• The rendezvous now happens in NMI context. The commit explains that stop_machine() did not stop a spinning sibling from handling an NMI, "which is obviously violating the whole concept of rendezvous," so each CPU now sends itself an NMI and waits inside the NMI handler.
• Intel added a minimum required revision field to the update header. If the CPU is already at or above that revision, the late load is considered safe and the kernel is not tainted. Old files have the field set to zero, which the kernel treats as unknown and unsafe.
• Enforcement is optional. The current Kconfig adds MICROCODE_LATE_FORCE_MINREV, and the kernel parameter microcode=force_minrev turns enforcement on at boot. When enforced, the kernel refuses late loads whose minimum revision is zero or higher than the running revision.

AMD's linux-firmware README has its own late loading notes: for some server families, late loading needs either a minimum firmware version or a specific kernel commit, and late loading may produce one benign spurious NMI per physical core.

Late loading in one table

How to check and update microcode, step by step

These steps read state and install vendor packages. None of them write firmware. Before regenerating an initramfs, make sure you have a working fallback kernel entry in your boot menu, and know how to add dis_ucode_ldr to the kernel command line: the kernel parameter list documents it as "Disable the microcode loader," and the Debian and Arch wikis both describe it as the recovery step if a new microcode package causes a hang at boot.

Step 1 on Linux: read the running revision

# Revision reported per logical CPU; all should match
grep -m1 microcode /proc/cpuinfo
grep microcode /proc/cpuinfo | sort | uniq -c

# Same value through lscpu on recent util-linux
lscpu | grep -i 'microcode'

# Per CPU sysfs value exposed by the microcode driver
cat /sys/devices/system/cpu/cpu0/microcode/version

If the uniq -c count shows more than one revision, cores are running different microcode. Intel's guidance says software "should ensure that the same update is loaded on all cores," so treat a mismatch as a fault to investigate, often a firmware issue.

Step 2 on Linux: confirm the early load happened

journalctl -k -b | grep -i 'microcode'
# or
dmesg | grep -i microcode

On a system where the initrd carries a newer revision than the firmware, you will see a line such as microcode: Updated early from: 0x0000000e followed by the current revision, as the Arch wiki's example output shows. If you only see the current revision, either the firmware already loaded the newest revision or there is no newer one in the initrd. Then check the initrd itself:

# Debian and Ubuntu
lsinitramfs /boot/initrd.img-$(uname -r) | grep -i microcode

# Fedora, RHEL family and others using dracut
sudo lsinitrd | grep -i microcode

You are looking for kernel/x86/microcode/GenuineIntel.bin or kernel/x86/microcode/AuthenticAMD.bin, the paths the kernel documentation names.

Step 3 on Linux: identify the CPU signature

grep -m1 -E '^cpu family' /proc/cpuinfo
grep -m1 -E '^model\s' /proc/cpuinfo
grep -m1 -E '^stepping' /proc/cpuinfo

These print decimal values. Convert them to hex the way Intel's README suggests, with printf "%x\n" 158 for a model of 158. A CPU reporting family 6, model 158, stepping 11 becomes 06-9e-0b. On AMD, family 25 decimal is 0x19, so the file is microcode_amd_fam19h.bin.

Step 4 on Linux: compare with the latest release

For Intel, two methods from Intel's README and the Arch wiki:

# Option A: let iucode_tool select the update matching this CPU
sudo modprobe cpuid
iucode_tool -lS /lib/firmware/intel-ucode/

# Option B: read the revision straight from a file header
# The third 32 bit word is the revision
od -t x4 /lib/firmware/intel-ucode/06-9e-0b | head -1

Compare the revision with the "New Ver" column for your family-model-stepping in the most recent Intel release notes. If the release notes show a newer revision than your installed package, your distribution has not caught up yet, or the update for your CPU is marked BIOS only and you need an OEM firmware update.

For AMD, use the vendor's script or the README:

git clone https://github.com/AMDESE/amd_ucode_info.git
python3 amd_ucode_info/amd_ucode_info.py /lib/firmware/amd-ucode/microcode_amd_fam19h.bin

Match your family, model and stepping against the listed Patch= values. Note any "Minimum base ucode version for loading" line: if your running revision is below it, that patch will not load from the OS and you need a BIOS update first.

Step 5 on Linux: check what the kernel thinks

cat /sys/devices/system/cpu/vulnerabilities/old_microcode
grep -r . /sys/devices/system/cpu/vulnerabilities/ 2>/dev/null

The kernel's old_microcode documentation says systems that booted with microcode older than the kernel's table of released microcode will report "Vulnerable," whether the reason is security or functional. It adds that "Runtime microcode updates do not change the status," so a late load will not clear it; reboot after updating. The other files show whether specific mitigations have the microcode they need, for example the MDS line described earlier.

Step 6 on Linux: install or update the package

Debian and Ubuntu (enable the non free firmware component first on Debian, as the Debian wiki describes):

sudo apt update
sudo apt install intel-microcode     # Intel CPUs
sudo apt install amd64-microcode     # AMD CPUs
sudo update-initramfs -u

Arch Linux:

sudo pacman -S intel-ucode           # or amd-ucode
# Make sure "microcode" is in HOOKS in /etc/mkinitcpio.conf, then:
sudo mkinitcpio -P

Fedora and RHEL family systems usually update microcode with normal system updates and rebuild the initramfs with dracut when a new kernel or firmware package installs:

sudo dnf upgrade --refresh
sudo dracut --force

Reboot, then repeat steps 1, 2 and 5. The Debian wiki puts it simply: "Microcode updates are only applied at boot, so you have to reboot to activate them," and the package must stay installed because it is reapplied every boot.

Step 7 on Linux: update firmware too

sudo dmidecode -s bios-version
sudo dmidecode -s bios-release-date
fwupdmgr get-updates

If your OEM publishes UEFI capsules through LVFS, fwupdmgr will list them. If not, use the OEM's own tool or download page. A firmware update is the only way to get BIOS only microcode and, as the AMD signature case showed, sometimes the only way to get a fix at all. A firmware flash that loses power can leave a machine unbootable, so plug laptops into power, confirm the model and update file match, and follow the OEM's instructions exactly.

Late loading on Linux, if you must

Only on a kernel built with CONFIG_MICROCODE_LATE_LOADING=y, and only if you accept the risks above:

# Confirm the interface exists first
ls -l /sys/devices/system/cpu/microcode/reload

# After installing newer files into /lib/firmware
echo 1 | sudo tee /sys/devices/system/cpu/microcode/reload
grep microcode /proc/cpuinfo | sort | uniq -c

Then rebuild the initramfs so the next boot loads the same revision early. Intel's README lists that step explicitly. Many distribution kernels do not enable late loading; the Arch wiki notes that Arch's official kernels do not.

Step 1 on Windows: read the running revision

Intel's Microcode Update Guidance gives the command:

reg query HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0 /v "Update Revision"

Compare the revision it reports with the one listed for your CPU in the vendor's release notes or the OEM's BIOS release notes. Intel's guidance also mentions its Processor Identification Utility as a cross platform way to read the version. To identify the CPU, Get-CimInstance Win32_Processor | Select-Object Name, ProcessorId in PowerShell returns the name and the CPUID based ID.

Step 2 on Windows: check whether mitigations have microcode

Microsoft documents the SpeculationControl module:

$SaveExecutionPolicy = Get-ExecutionPolicy
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
Install-Module SpeculationControl
Import-Module SpeculationControl
Get-SpeculationControlSettings
Set-ExecutionPolicy $SaveExecutionPolicy -Scope CurrentUser

Lines that start "Hardware support for ... is present: False" mean the microcode the mitigation needs is not loaded. Microsoft's explanation of BTIHardwarePresent puts the responsibility on the device OEM's firmware.

Step 3 on Windows: install updates

Install the latest cumulative updates from Windows Update first, as Microsoft's KB4072698 recommends. Then check KB4093836 for any Intel microcode KB that applies to your Windows version and CPU, and install it through Windows Update, WSUS or the Microsoft Update Catalog. Finally, apply the OEM's latest BIOS or UEFI update. Reboot and repeat steps 1 and 2.

How does microcode compare with other low level updates?

Microcode differs from the others in one important way: the OS can supply it, but it is not stored anywhere persistent by the OS. If the package is removed or the initrd is rebuilt without it, the next boot silently falls back to whatever the firmware carries. Measured boot can help you see that change. See our posts on Secure Boot, trusted boot and measured boot and TPM 2.0 PCRs and the event log for how firmware components are recorded before the OS starts.

Common mistakes

• Assuming the OS package is enough. Intel says some updates are BIOS only and never appear in the Linux package. AMD's 2025 signature fix required a BIOS update. Track firmware versions as well.
• Installing the package and not rebuilding the initrd or not rebooting. The update is applied at boot. Until you reboot with an initrd that contains it, nothing changes.
• Building the initrd on a different machine with host only mode. Some initrd tools include microcode only for the CPU they run on. Arch's wiki notes that if the autodetect hook comes before microcode, only the current CPU's microcode is included. Golden images built on one CPU type and deployed on another can boot without the right update.
• Using late loading as the normal path. Linux turned it off by default for good reasons. Late loads can change features under running software, taint the kernel and, per the kernel docs, do not clear the old_microcode status.
• Reading one core and assuming all match. Check every logical CPU. Mixed revisions point to a firmware problem.
• Forgetting virtual machines. A guest's mitigations depend on the host's microcode and on the hypervisor exposing the right CPUID bits. The kernel's MDS docs describe this exact gap.
• Treating a microcode release as untouchable. Intel pulled one stepping's update a day after release in August 2026. Stage microcode like any other change: a canary group first, then the fleet.
• Removing the microcode package to "fix" a boot hang permanently. Use dis_ucode_ldr to boot, then find the cause and a fixed revision. Running without microcode updates leaves known errata and security issues in place.

FAQ

How do I check my CPU microcode version on Linux?

Run grep microcode /proc/cpuinfo | sort | uniq -c or lscpu | grep -i microcode. Then run journalctl -k -b | grep -i microcode to see whether the kernel updated it early in boot, and read /sys/devices/system/cpu/vulnerabilities/old_microcode to see if the kernel considers it out of date.

How do I check the microcode revision on Windows?

Intel's guidance gives reg query HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0 /v "Update Revision". For mitigation status, install Microsoft's SpeculationControl PowerShell module and run Get-SpeculationControlSettings.

Do microcode updates survive a reboot?

No. Intel's README says microcode state resets on a power reset, so the update must be loaded on every boot, either by firmware or by the OS. Intel's guidance adds that a warm reset generally clears it too.

Who signs CPU microcode updates?

The CPU maker. AMD's bulletin describes a signature check in the CPU ROM patch loader and refers to patches "signed by AMD." Intel's format describes an encrypted payload with a checksum and processor match, though Intel does not publish its signature scheme in the documents we read. OEMs, distributions and Microsoft redistribute these signed files; they cannot create patches the CPU will accept.

Is it safe to install the intel-microcode or amd64-microcode package?

For most systems, yes, and it is how Intel recommends getting updates. Debian's wiki calls the risk of problems "very low, but not zero" and suggests checking for a BIOS update first. Keep a fallback boot entry and know the dis_ucode_ldr parameter in case a new revision causes a hang.

Why is late microcode loading disabled in Linux?

Because it can break a running system. The kernel docs explain that sibling threads share the microcode engine, some interrupts cannot be stopped during the update, and an update may remove a feature the kernel is already using. Linux 5.19 made it off by default; a 2023 rework added NMI based synchronisation and a minimum revision check.

Can I downgrade CPU microcode?

Generally no. Intel's guidance says you can only update to a higher version and some updates block loading a lower revision. AMD patches can require a minimum base revision. In practice, a downgrade means booting without the newer OS supplied revision so the CPU runs the firmware's version.

Does a BIOS update include microcode?

Usually, yes. OEM firmware carries microcode loaded through the FIT or by the BIOS, and Intel notes OEMs may receive updates that never ship for OS loading. Check your OEM's release notes for the included revision.

Do I need microcode updates on a virtual machine?

The guest cannot load microcode into the real CPU. The host must be updated, and the hypervisor must expose the resulting CPU features to the guest. The kernel's MDS documentation describes guests that see "no microcode" because the hypervisor has not yet advertised the feature.

What was the AMD microcode signature vulnerability?

AMD bulletins AMD-SB-3019 (3 February 2025) and AMD-SB-7033 (5 March 2025) describe improper signature verification in the CPU ROM microcode patch loader that could let a local administrator load unsigned microcode. AMD said it had no reports of exploitation and delivered the fix through platform firmware updates via OEMs.

Where Safeguard fits

Safeguard does not read CPU microcode revisions, scan firmware images or verify that a host booted with current microcode, and it is not an endpoint or device management tool. The fit is indirect. The work around microcode is ordinary software: the configuration management code that installs intel-microcode across a fleet, the scripts that build golden images and initramfs files, the container images your build hosts run, and the internal tools that collect /proc/cpuinfo and BIOS versions into an inventory. Those are source repositories and images with open source dependencies, and Safeguard can scan them with safeguard scan --dir ., --image for a container image, or --sbom for an SBOM file, writing results as JSON under ./output.

A rebuilt or reimaged machine pulls its tooling and dependencies again, and the fleet automation that keeps microcode current is itself built from open source packages that receive CVEs. The steps below cover that software, not the microcode or firmware, which still has to come from Intel, AMD, your OEM or your OS vendor.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The demos below show Safeguard on ordinary software projects, not on CPUs or firmware. They apply to the repositories and images that manage your fleet: the playbooks that install microcode packages, the image build pipeline, and the inventory tools that report revisions.

The first demo is a real Safeguard CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repository, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It ends with /permissions, /model and /scan. The same ask, approve and test loop fits a fleet automation repository where every change should be reviewed before it runs.

Click through it at your own pace, or open it full screen.

Image build hosts and provisioning servers are often kept on restricted networks. The local runner demo shows how to set up the runner on your own machine, approve it with its device code, and then scan from the terminal. A runner on a build host can scan the image build tree and the containers stored there.

Click through it at your own pace, or open it full screen.

If your team uses Claude, the third demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. An engineer can then ask about known vulnerabilities in the projects that hold your provisioning and inventory tooling, using only the tools you allowed.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Linux kernel documentation: The Linux Microcode Loader
• Linux kernel documentation: Old Microcode
• Linux kernel documentation: Spectre side channels
• Linux kernel documentation: MDS, Microarchitectural Data Sampling
• Linux kernel: arch/x86/Kconfig (MICROCODE_LATE_LOADING and MICROCODE_LATE_FORCE_MINREV)
• Linux kernel: kernel-parameters.txt (microcode= and dis_ucode_ldr)
• Linux kernel commit a77a94f: x86/microcode: Default-disable late loading (25 May 2022)
• Linux kernel commit 7eb314a: x86/microcode: Rendezvous and load in NMI (2 Oct 2023)
• Linux kernel commit cf5ab01: x86/microcode/intel: Add a minimum required revision for late loading (2 Oct 2023)
• Linux kernel commit 4e2c719: x86/cpu: Help users notice when running old Intel microcode (22 Apr 2025)
• Intel Processor Microcode Package for Linux: README
• Intel Processor Microcode Package for Linux: release notes
• Intel: Microcode Update Guidance
• EDK II: MdePkg/Include/Register/Intel/Microcode.h (Intel update header format)
• linux-firmware: amd-ucode README
• AMD: amd_ucode_info README
• AMD-SB-7033: AMD CPU Microcode Signature Verification Vulnerability
• AMD-SB-3019: AMD SEV Confidential Computing Vulnerability
• Microsoft Support: KB4093836, Summary of Intel microcode updates
• Microsoft Support: June 2015 Intel CPU microcode update for Windows (KB3064209)
• Microsoft Support: Understanding Get-SpeculationControlSettings PowerShell script output
• Microsoft Support: Windows Server guidance to protect against speculative execution side channel vulnerabilities (KB4072698)
• NVD: CVE-2017-5715
• Debian Wiki: Microcode
• ArchWiki: Microcode
• Ubuntu: intel-microcode package on Launchpad
• NIST SP 800-193, Platform Firmware Resiliency Guidelines (May 2018)

Last reviewed: 23 October 2026. Microcode revisions, package names and kernel options change often; check your CPU maker's latest release notes and your OS vendor's documentation before acting.