The Firmware Supply Chain Is Defense's Biggest Unlocked Door

Walk into any defense procurement review and you'll see a mountain of paperwork dedicated to component provenance. Where was the chip fabbed. Who touched the board. Was the connector sourced from an approved vendor. All reasonable questions. Almost none of them get asked about the firmware sitting in the flash memory of that same board.

Photo by Yena Kwon on Pexels.

This is the gap. Hardware gets inspected, X-rayed, sometimes even delidded and imaged under a microscope. Firmware gets a checksum, maybe a signature check, and then it's trusted for the next ten years of the system's service life. Nobody re-audits it. Nobody tracks whose code actually ended up in that binary blob, because most of the time nobody can, since the vendor shipped a compiled image with no source attached and no build record worth trusting.

The numbers on this are not comforting. Independent research over the last few years (Eclypsium's work is the most cited, but far from the only source) has repeatedly found that a meaningful fraction of devices shipping into regulated environments, including defense-adjacent supply chains, contain firmware components that are unsigned, outdated, or built from open-source code with known unpatched vulnerabilities. Network cards, baseboard management controllers, power supplies, even the connectors with embedded EEPROMs: all of them run code, and almost none of that code gets the scrutiny applied to the silicon it sits on.

Why this matters more in defense than anywhere else

Commercial IT has started to take firmware seriously, largely because ransomware groups figured out that persistence below the OS is the best kind of persistence. Defense systems have a longer problem horizon. A radar subsystem or an avionics bus controller might run the same firmware image for fifteen or twenty years, through multiple prime contractors, subcontractors, and depot-level repairs. Every one of those handoffs is an opportunity for firmware to get reflashed by someone whose verification process amounts to "it booted."

And unlike a counterfeit capacitor, bad firmware doesn't show up on an X-ray. It doesn't fail a continuity test. It can sit completely dormant, passing every functional check the program has, until a specific trigger condition (a GPS week rollover, a particular packet, a date) flips it active.

graph TD
    A[Firmware Source] --> B(Vendor Build)
    B --> C{Signed?}
    C -->|No| D[Unverifiable Binary]
    C -->|Yes| E[Signature Checked at Boot]
    D --> F[Deployed to Field]
    E --> F
    F --> G[Depot Reflash Over Lifecycle]
    G --> C

That loop back into the signing question at depot reflash is the part programs tend to skip. A unit gets repaired, a new firmware image gets loaded to restore function, and the verification rigor from initial fielding quietly doesn't follow it into the field service process.

What an actual fix looks like

The fix isn't exotic. It requires treating firmware as a first-class item in the software bill of materials, not a footnote. That means source-available builds wherever contractually possible, reproducible builds so a given binary can be independently regenerated and compared byte-for-byte, and signed attestation chains that extend through every depot touch, not just the factory floor.

Some of this is already policy on paper. NIST's SP 800-193 covers platform firmware resiliency, and DoD's software supply chain guidance increasingly name-checks firmware explicitly. The gap is enforcement at the subcontractor level, three or four tiers down from the prime, where a component vendor is shipping a network interface card with firmware nobody above them has ever looked at.

Hardware roots of trust help, and plenty has been written about that layer. But a root of trust that verifies a signature on firmware nobody can read, built by a process nobody can audit, is verifying the wrong thing well. The actual fix is upstream of the chip: know what code is running, know who wrote it, and know every time it changed. That's not a cryptography problem. It's a discipline problem, and defense has been slow to apply it to the layer of the stack that quietly runs everything else.