Firmware Signing vs Secure Boot: Producing Trusted Code vs Enforcing It at Startup

Firmware signing and Secure Boot are two halves of one trust decision, and most failures happen because the team that owns one half assumes the other half is sound. Firmware signing is a producer control: a vendor or device maker runs a pipeline that turns approved code into a signed image with keys it must protect for the life of the product. Secure Boot, and the wider family of verified boot and authenticated update mechanisms, is a consumer control: a device checks that signature against trust anchors it holds and refuses anything that fails. This guide is for product security teams that ship firmware, and for enterprise and OT teams that buy and operate devices. It covers the signing pipeline against the device root of trust, what happens when signing keys leak, how revocation actually works through dbx, SBAT and version numbers, and how IoT update signing differs from PC Secure Boot. Measured boot and attestation are covered in Measured Boot vs Secure Boot and are only summarised here.

Key takeaways

• Signing produces trust, Secure Boot enforces it. A signature is only as good as the key behind it, and enforcement is only as good as the trust anchors and deny lists on the device.
• Enforcement cannot tell a stolen key from a real one. Secure Boot accepts any code that verifies against its databases, so a leaked signing key or a shipped test key defeats it completely until revocation reaches the device.
• Revocation is the weakest link in both. UEFI dbx space is small, revoking a widely used certificate breaks legitimate software, and keys fused into silicon at manufacture cannot be revoked at all.
• Signing keys are long-lived machine identities. Treat them as the most privileged non-human credentials you own: hardware-held, split by product and stage, with named custodians and an audited approval step.
• Anti-rollback closes the gap signatures leave. An old, validly signed image with a known flaw passes every signature check; version numbers and sequence numbers are what stop it.

The short answer

If you build devices, you own signing end to end, and its quality decides whether every Secure Boot check in the field means anything. If you operate devices, you own enforcement: Secure Boot on, trusted keys minimised, dbx and firmware current. A perfectly enforced boot chain trusting a leaked key is open, and a perfectly protected key is worthless on a device that boots unsigned code.

Firmware signing: the producer side

Threat model

The attacker wants code that every device of a model will accept. The cheapest route is not breaking cryptography but obtaining a signature: stealing the private key, compromising the build so malicious code reaches the signer, abusing a signing service that signs whatever it is sent, or finding a development key that reached production. Because firmware keys often protect product lines for a decade or more, one theft has a very long tail.

Architecture in words

A mature pipeline separates four roles. Developers commit code; a controlled build system produces a reproducible image; a release approver authorises that specific image digest; a signing service holding the key in a hardware security module signs the digest and logs the event. NIST SP 800-193 requires updates to be signed with an approved algorithm of at least 112 bits of security strength and verified before they are committed to storage. SP 800-147 also describes an option for high-security environments where the organisation countersigns approved updates, which gives an operator its own veto over vendor images.

• Key hierarchy: an offline root, with separate signing keys per product family and per stage (development, pre-production, production), so one leak does not cover everything.
• Hardware custody: production keys generated and used inside an HSM, never exported. For publicly trusted code signing certificates, the CA/Browser Forum Baseline Requirements have required subscriber keys to be generated, stored and used in a hardware crypto module since 1 June 2023. Most OEM firmware keys sit in private PKIs outside that scope, so the discipline has to be self-imposed. See the HSM Deployment Guide.
• Approval on the digest: sign hashes of reviewed, reproducible builds, with two-person approval for production keys.
• Metadata in the signed payload: version or security version number, hardware compatibility identifiers and, for shim-based Linux boot, an SBAT section. Anything outside the signed region can be altered.

Failure modes

Keys on build servers or laptops rather than in hardware, one key for every product and stage, supplier test keys left in production images, and signing services with no policy. Each is expanded under Common failure patterns below.

Secure Boot and verified update: the consumer side

Threat model

Here the attacker already has some foothold, often administrator rights or physical access, and wants persistence below the operating system: a bootkit (MITRE ATT&CK T1542.003), modified system firmware (T1542.001) or a downgrade to an older signed component with a known flaw. Enforcement is meant to make each of these fail at the next boot.

Architecture in words

On UEFI PCs and servers the NSA Secure Boot customisation guidance describes four stores: the Platform Key (PK), which authorises changes to the Key Exchange Keys (KEK); KEKs, which sign updates to the allow list (db) and deny list (dbx); and dbx, which is checked first and has veto power. Below UEFI, hardware roots such as Intel Boot Guard and AMD Platform Secure Boot verify the first firmware code against a key hash set at manufacture. Linux distributions add shim and Machine Owner Keys (see the Linux Secure Boot and Shim Guide). Embedded and IoT devices use a boot ROM or immutable bootloader with a trust anchor store. The update path is a separate enforcement point: NIST SP 800-193 calls it the Root of Trust for Update and requires its key store to be changeable only through an authenticated or secure local update.

Failure modes

• Secure Boot disabled, left in setup mode, or switched off for a driver and never re-enabled.
• Trusting more than needed: third-party CAs, leftover MOK entries or vendor keys for software the device never runs.
• Stale dbx: the device enforces signatures but still trusts components that have been revoked elsewhere.
• UEFI administrator passwords shared or absent, so anyone at the console can reset keys. NSA advises protecting these credentials, ideally unique per endpoint.

When signing keys are compromised

Two incidents show what happens when the producer side fails and the consumer side keeps working exactly as designed.

MSI, 2023. After a ransomware group claimed a breach of MSI in April 2023, analysis of the leaked data by Binarly, reported by Help Net Security, found private firmware image signing keys for 57 MSI products and Intel Boot Guard keys for 116 products. A Boot Guard key is checked by hardware against a value set at manufacture, so devices built to trust it cannot simply be told to stop. See the MSI Signing Keys Leak 2023 breach analysis.

PKfail, 2024. CERT/CC VU#455367 (CVE-2024-8105) describes test Platform Keys from the firmware supply chain shipping in production devices, some labelled "DO NOT TRUST". UEFI only checks keys against its local database, so whoever holds the private half of such a PK can authorise their own KEK and db entries and sign boot code that Secure Boot will run. CERT/CC recommends updating firmware and replacing test PKs, and points to a tool published for that purpose.

For a structured response, use the Compromised Code Signing Certificate Playbook and, if implants are suspected, the Firmware and Bootkit Compromise Playbook.

Revocation: dbx, SBAT and version numbers

Revocation is where signing and enforcement meet, and it is harder than either. The shim project's SBAT design document explains that UEFI offers two revocation mechanisms, by certificate or by image hash, and that revoking the Microsoft UEFI CAs by certificate is impractical because it would revoke too much legitimate software. The BootHole response in 2020 added 3 certificates and 150 image hashes to dbx, using about 10 kB of roughly 32 kB of revocation storage typically available.

Microsoft's BlackLotus guidance (KB5025885, CVE-2023-24932) shows all of these combined: add the Windows UEFI CA 2023 certificate to db, move to boot managers it signs, add the Windows Production PCA 2011 certificate to dbx, and optionally write an SVN. The article warns that revocations persist even after reformatting the disk, advises updating recovery and installation media first and testing one device per class, and, as checked in November 2026, says the enforcement phase will not begin before January 2026 without stating a date. The certificate expiry side of that change is covered in Secure Boot Certificate Expiry 2026.

The producer lesson: design for revocation before you sign.

IoT and embedded firmware update signing

On constrained devices there is often no UEFI and no dbx. Trust lives in a boot ROM or immutable bootloader and an update agent. IETF RFC 9019 (Informational, April 2021) sets out the SUIT architecture: an author produces the image, a device operator decides when to deploy, and a trust provisioning authority installs trust anchors out of band. Its points translate directly into requirements you can put in a procurement contract.

• Signed manifest: authentication and integrity protection of the manifest are required; confidentiality of the image is optional.
• Anti-rollback: a sequence number lets the device refuse an image older than the one it runs.
• Multiple signers: a device can require both the author and the operator to sign, giving the operator a veto similar to SP 800-147 countersigning.
• Protected trust anchor store: resistant to unauthorised insertion, deletion and modification.
• Post-quantum readiness: RFC 9019 recommends hash-based signatures for ROM-resident bootloader code, because that code cannot be changed later. See the PQC Code Signing Guide.

Manifest formats and OTA design are covered in the IoT Secure Firmware Update Guide (SUIT, signed OTA).

Where measured boot and attestation fit

Signing and enforcement both trust whatever verifies. Measured boot and remote attestation let a verifier spot a validly signed but unexpected component, exactly the blind spot a leaked key creates, so use them where a silent signing failure would matter most. The design choices are in Measured Boot vs Secure Boot, and device identity on constrained hardware in IoT Device Identity with TPM and DICE Guide.

Where identity fits

A firmware signing key is a non-human identity with more reach than almost any service account: it speaks for every device of a model, for years. Govern it like one. Each key needs an owner, a documented scope (product, stage, component), an inventory entry with expiry, controlled access to the HSM partition through named, multi-factor human approvers and a dedicated signing service identity, and a rotation and revocation plan. The Signing Keys and Certificates in Breaches guide shows how often stolen signing material features in incidents.

Decision criteria

• You ship firmware: invest first in key custody and per-product hierarchy, then in version metadata and revocation design. Enforcement on your devices is only as credible as these.
• You run Windows and Linux fleets: enforcement and revocation hygiene are yours: Secure Boot on, dbx current, unnecessary CAs and MOKs removed, PKs inventoried.
• You run OT or IoT estates: make signed, rollback-protected updates a purchasing requirement and ask who holds the signing keys and how they would be rotated.
• You need control beyond the vendor: custom Secure Boot keys or organisational countersigning give you a veto, at the cost of signing every boot component yourself and owning the keys.
• Small versus large organisations: small teams should rely on vendor keys and keep firmware and dbx current; large or regulated ones add attestation for high-value systems and signing practice in supplier assurance.

Worked scenario

A manufacturer of industrial gateways learns that a contractor's build server holding the pre-production signing key has been compromised. Production uses a separate HSM-held key and the boot ROM trusts only its hash, but one firmware branch had also enrolled the pre-production key in the update trust anchor store "for testing". Product security identifies the affected versions, ships a signed update that removes the key and increments the anti-rollback counter, and notifies operators, who pause automatic updates, verify images against published digests and deploy through pilot sites first. The lesson: stage separation worked, but enrolling a non-production key anywhere in production undid it.

How to implement

1. Inventory both sides. Producers: every signing key, its HSM, scope and expiry. Operators: Secure Boot state, PK identity, KEK and db contents and dbx version per device model.
2. Move keys into hardware. Generate production keys in an HSM, separate by product and stage, and require two-person approval to sign.
3. Put version data inside the signature. Add security version numbers, sequence numbers or SBAT entries before the next release.
4. Remove test and surplus trust. Check for test PKs, replace them through vendor firmware or owner keys, and remove CAs and MOKs not needed.
5. Test enforcement in audit mode. Use UEFI Audit Mode or report-only policies in a pilot ring to find unsigned option ROMs and drivers before enforcing.
6. Roll revocations in rings. Update recovery media first, then one device per hardware class, then broader rings, keeping BitLocker or disk recovery keys at hand.
7. Plan rollback. Keep vendor-signed images and documented recovery procedures; remember dbx entries cannot be undone by reinstalling the operating system.
8. Rehearse key compromise. Run a tabletop on losing each key class and confirm the device-side path to trust a new key.

Detection and measurement

Producers should log every signing operation with requester, approver and digest, and alert on signing outside release windows or for unrecognised digests. Operators should collect Secure Boot state, dbx version and firmware version from endpoint management, watch for Secure Boot being disabled, and use firmware integrity scanning or attestation for high-value systems.

• Signing keys in hardware: percentage of production firmware signing keys held only in HSMs (target 100 percent).
• Signatures with approval: percentage of production signatures with a recorded second approver.
• Secure Boot coverage: percentage of capable devices with Secure Boot enforced.
• Revocation currency: percentage of devices on the current dbx or SBAT level, and median days from vendor release to fleet coverage.
• Test key exposure: number of device models found with test or untrusted PKs, trending to zero.
• Rollback protection: percentage of product lines with an enforced version or sequence number.

Common failure patterns

• One key for everything. A single signing key across products and stages means any revocation hits the whole fleet, so nobody revokes.
• Treating Secure Boot as proof of integrity. It proves only that something trusted signed the code. The MSI leak shows how far that trust extends when keys escape.
• Shipping supply-chain test keys. PKfail came from reference keys that were never replaced. Check the PK on every model you build or buy.
• Revoking before recovery media is ready. dbx changes survive reinstallation; teams that skip media updates create unbootable devices and then disable Secure Boot to recover.
• No anti-rollback. Attackers reinstall an older signed image with a known flaw, and every signature check passes.
• Signing service without policy. An HSM that signs whatever an authenticated build account submits only moves the theft target from the key to the account.

Framework mapping

Related technique pages: T1553 Subvert Trust Controls, M1045 Code Signing, M1046 Boot Integrity and D3-BA Bootloader Authentication.

Practitioner checklist

• Hold every production firmware signing key in an HSM, separated by product and stage.
• Require two-person approval on the image digest for production signing, and log every signature.
• Embed version, SVN or SBAT data inside the signed payload of every release.
• Check every device model you build or buy for test or untrusted Platform Keys.
• Enforce Secure Boot on capable devices and remove trust anchors you do not need.
• Apply dbx and boot manager revocations in rings, updating recovery media first.
• Require signed, rollback-protected updates and a key rotation plan from OT and IoT suppliers.
• Use attestation on high-value systems to catch validly signed but unexpected components.
• Rehearse loss of each signing key class, including how devices will learn to trust a replacement.

Standards and references

• NIST: SP 800-193 Platform Firmware Resiliency Guidelines
• NIST: SP 800-147 BIOS Protection Guidelines
• IETF: RFC 9019 A Firmware Update Architecture for Internet of Things
• NSA: UEFI Secure Boot Customization
• CERT/CC: VU#455367 Insecure Platform Key used in UEFI system firmware signature
• Microsoft: How to manage the Windows Boot Manager revocations for CVE-2023-24932
• shim project: UEFI shim bootloader Secure Boot life-cycle improvements (SBAT)
• CA/Browser Forum: Baseline Requirements for Code Signing Certificates

Related NHI Mgmt Group resources: Firmware and Boot Security Guide · Measured Boot vs Secure Boot · Code Signing Security Guide · Hardware Root of Trust Guide · IoT Secure Firmware Update Guide (SUIT, signed OTA)