Secure Boot can be switched on and still trust a test key or a stale revocation list. FDIE reads UEFI firmware volumes and capsules, lists every module and checks the Secure Boot keys the firmware ships with, so you find PKfail-style test keys and missing revocations before a customer or a researcher does.
The challenge
Platform Keys meant only for testing, whose private keys are public, have shipped in production firmware. Anyone holding such a key can sign boot code that Secure Boot accepts.
The revocation list (dbx) blocks boot modules with known flaws. An image that ships an old list starts every new or reset machine trusting them again.
A UEFI image carries modules from the chip vendor, the BIOS vendor and the board maker. Few teams know which of them have published vulnerabilities.
How FDIE helps
FDIE reads UEFI firmware volumes and capsules and lists every module they hold, with the Secure Boot keys and the revocation list. Volumes a vendor packs in its own format, such as Dell PFS, are shown as coverage gaps rather than guessed at.
Device checks look for test keys in the Secure Boot databases, such as PKfail, check the revocation list and the KEK that updates it, flag modules with a published vulnerability and report SMM callouts. A check passes only when something was examined; otherwise it says not assessed, with the reason.
Compare two firmware releases: components added, removed, upgraded and downgraded, with findings and device checks side by side. You see whether an update brought the revocation list up to date or left a test key in place.
Your release rules say ship or hold, with the reasons. A CI token lets your build pipeline upload each image and fail on the gate, and reports are signed PDFs that customers and auditors can check.
How it works
Upload a UEFI firmware volume or capsule, or let your build pipeline send each one.
FDIE opens the volumes, lists every module and reads the Secure Boot keys and the revocation list.
Replace test keys, update the revocation list and the KEK, and look at revoked modules and SMM leads.
Compare the update with the last release, export signed reports and let the gate say ship or hold.
Know the split
FDIE analyses the firmware, not the device. Knowing the split tells you what to fix before the lab and what to prepare for it.
Rules by market
For products sold in the EU, the EU CRA covers PCs and servers as products with digital elements, and EN 18031 applies to those with a radio. Industrial PCs often answer to IEC 62443-4-2.
Article 14 reporting since 11 September 2026; the rest from 11 December 2027
Applies since 1 August 2025
Component evidence for federal buyers, not a legal verdict
For industrial components such as gateways
Evidence and gap finding, not certification: the lab or certification body decides.
Deliverables
Test keys, the revocation list, revoked modules and SMM leads for each release.
Every module in the firmware's volumes, kept with the release it came from.
What changed between two firmware releases, as a signed PDF.
A signed PDF of checks, findings and fixes for the release.
Ship or hold for every firmware build, with the reasons.
Vendor-packed volumes and what could not be read, with the reason.
PKfail (CVE-2024-8105) is the shipping of test Platform Keys whose private keys are known. Anyone holding such a key can sign boot code that Secure Boot will accept.
Not necessarily. The operating system may have applied revocation updates since. The check reports what the firmware ships with, which is where a new or reset machine starts.
A check passes only when something was examined. When the modules sit in a vendor-packed format FDIE does not unpack, or the image holds no Secure Boot variables, the check says not assessed and gives the reason.
Volumes a vendor packs in its own format, such as Dell PFS, are listed as coverage gaps today, not unpacked.
No. UEFI volumes and capsules are read, not booted.
A 45-minute call with our team. Bring one firmware image.