Is your UEFI Secure Boot real? PKfail, dbx and KEK checks

In short

• FDIE runs four Secure Boot checks on UEFI firmware: test keys such as PKfail, the revocation list (dbx) and the KEK that updates it, revoked boot modules, and SMM callouts.
• On eight public UEFI images, it found outdated default dbx lists on two consumer motherboards, missing AArch64 revocations in a Debian variable store and Debian's SnakeOil test key in its test variant.
• A check passes only when something was examined. Where an image gives it nothing to judge, the check says "not assessed".

Secure Boot is only as good as four variables set at the factory:

• the Platform Key (PK)
• the Key Exchange Keys (KEK)
• the allowed signature database (db)
• the forbidden database (dbx)

Get them wrong and the device trusts code it should not, or cannot learn about code it should stop trusting. These mistakes are hard to fix in the field. That is why they belong in a release check, not an incident report.

UEFI firmware is not only for laptops. It runs x86 NVR appliances, industrial PCs, edge gateways and a growing number of Arm boards. In October 2026 we added four UEFI Secure Boot checks to FDIE and measured them on eight public UEFI images. Here is what each check does, what it found and where it cannot judge.

What does a UEFI image hold?

A UEFI image is a set of firmware volumes holding FFS files: drivers, SMM modules and applications, most of them PE32 images. It also holds authenticated variables with the Secure Boot keys and lists.

The PK identifies the platform owner. Keys in the KEK may change db and dbx. The db lists trusted signers and hashes, and the dbx lists revoked ones. Capsules wrap firmware updates in the same structures.

FDIE walks every module of every volume, nested ones included. It lists each Secure Boot certificate in the crypto inventory with its variable, key and expiry date. On the 13 UEFI files of the eight images, its module inventory matched the previous version of our engine exactly. Both found 1,716 distinct modules, identical by GUID, name, type and SHA-256, and the same 25 certificates.

Check 1: no test keys in Secure Boot databases

This check fails when the PK, KEK or db holds a certificate known to be a test key. That problem was published as PKfail (CVE-2024-8105).

CERT/CC's note on PKfail says test keys often carry labels such as "DO NOT TRUST". It also says "there is no programmatic safeguard" to stop them reaching final products. FDIE looks for the "DO NOT TRUST" and "DO NOT SHIP" labels. It also recognises, by certificate hash, test keys whose private keys are published.

One of those is the SnakeOil key that Debian ships in its qemu-efi-aarch64 package, next to the private key file. It is there so that people can test Secure Boot in virtual machines. In the package's AAVMF_VARS.snakeoil.fd variable store, the PK, KEK and db are all that key, and the check fails.

That is the right answer for that file, since Debian ships it deliberately for testing. On a device, it would mean anyone could sign boot code your product trusts.

Check 2: a current revocation list and a KEK that can update it

This check compares the image's dbx with Microsoft's published revocations. It also fails a KEK that holds Microsoft's 2011 KEK certificate without the 2023 one.

FDIE uses the revocation data Microsoft publishes in its secureboot_objects repository (677 entries in the version we pinned). It judges only what applies to the image: revocations for the certificate authorities the image's db trusts, and for the instruction sets its DXE modules use. Entries Microsoft marks optional are left out. The previous version of our engine shipped with an empty list, so it never judged a dbx at all.

Two of the eight images are firmware for consumer motherboards, BIOS releases from 2020 and 2021. We call them board A and board B. What it found:

• Board A. The default dbx holds 1 hash and none of the 291 x64 revocations that apply.
• Board B. The default dbx holds 77 hashes. 264 of the 291 applicable revocations are missing, and the newest one present dates from 2018.
• Debian qemu-efi-aarch64, AAVMF_VARS.ms.fd. Its dbx holds 443 of the 445 x64 hashes and none of the 26 AArch64 ones. So an AArch64 platform starting from it lacks exactly the revocations for its own architecture. That is an easy mistake to make when a list is copied from x86 work.

The default dbx in a firmware image is what a new or reset device starts with. An operating system may apply dbx updates later, so this is not proof that a deployed machine is exposed. But it is the state you ship.

The KEK half of the check is about the next update. Microsoft's support article on Secure Boot certificate expiry lists the Microsoft Corporation KEK CA 2011 as expiring on 24 June 2026. Its replacement is the Microsoft Corporation KEK 2K CA 2023, and the article says the KEK "Signs updates to DB and DBX".

A platform whose KEK holds only the 2011 certificate cannot accept revocations signed with the 2023 key, so FDIE fails it. Both motherboard images failed for this reason too.

Check 3: no UEFI module with a published vulnerability

This check computes the Authenticode digest and the file hash of every PE module. It fails when one has been revoked, such as a revoked signed shim or shell shipped inside the firmware.

The Authenticode digest is the value a dbx lists. It is a hash of the PE image that skips the checksum field, the certificate table entry and the signature itself. FDIE's digest was identical to LIEF 0.16.6 on all 430 PE modules of three images. On Debian's signed shim, it also equals the digest inside Microsoft's own signature.

To test the failure path end to end, we built a firmware volume holding the shim from Debian shim-signed 1.33 (shim 15, from 2019). Microsoft revoked that shim on 1 April 2021, and the volume fails the check. None of the real images carried a revoked module.

Image-parser names linked to LogoFAIL (CERT/CC VU#811862) are kept as leads for review, not failures. A module name alone does not prove the vulnerable code is present.

Check 4: no SMM callouts, at low confidence

This check flags x64 SMM modules that appear to call through pointers outside protected SMM memory. It is a heuristic, so its findings are low-confidence leads.

Code in System Management Mode runs with more privilege than the operating system. Suppose it calls a function through a pointer that ordinary code can change, such as one taken from the boot services table. An attacker who changes that pointer then gets code running in SMM. A static pattern can show the call, but it cannot prove the pointer is reachable by an attacker.

FDIE's findings were the same as our previous engine's on every file: 8 on board A and 13 on board B. Treat them as items for your firmware vendor to explain, not as confirmed vulnerabilities.

What did the checks find on eight public images?

Every check gives one of pass, fail, not assessed or not applicable, with the reason. The day before this work, every UEFI image left all four checks not assessed.

Two things in that table are deliberate. First, a check passes only when something was examined, so an image with no Secure Boot variables is "not assessed", never "passed". Second, images whose modules sit in a vendor's own packing, such as Dell PFS or the HP image here, are coverage gaps, listed as such in the results. Routers and cameras that are not UEFI firmware get "not applicable", so these checks never clutter their reports.

What should you check before shipping UEFI firmware?

If your product boots through UEFI, settle these questions for every firmware release, whatever tool you use.

• Own your PK. Generate a platform key for your product line and keep the private key out of build machines. Check that no test or sample certificate is left in PK, KEK or db.
• Ship a current dbx for each architecture you ship. The AArch64 gap above is easy to miss when an x64 list is reused.
• Check the KEK against the 2026 expiry. If you rely on Microsoft-signed components, include the 2023 KEK, or your devices will not take the next revocation update.
• Never ship a revoked boot component inside a firmware volume, however convenient an old signed shim or shell is for manufacturing.
• Ask your BIOS vendor about SMM callout leads and keep their answer with the release.

NIST SP 800-193 frames platform firmware security as protection, detection and recovery. These four checks sit on the protection side, where they are cheapest to act on: before the image leaves your build.