Below the Operating System: A Working Audit Method for Firmware and Hardware Cryptography

Enterprise security programs have matured considerably over the past decade. SBOMs are commonplace, SAST tooling is wired into CI, and third-party risk questionnaires — whatever their limitations — at least force the conversation. Yet beneath all of this sits a layer most programs treat as a black box: the cryptographic machinery baked into device firmware, TPMs, and secure enclaves. It is a blind spot with teeth. Attackers who compromise firmware gain persistence that survives reimaging, and the cryptographic guarantees that secure boot and hardware key storage promise are only as valid as their implementation.

The good news is that auditing this layer does not require a silicon lab. It requires methodical verification of a small number of well-defined properties.

Start With the Signing Chain

Every piece of firmware that claims authenticity should trace to a root of trust you can name. In practice, this means:

• Identify the root keys. For x86 servers, this is typically the OEM's key enrolled in the Intel Boot Guard or AMD Platform Secure Boot structure. For ARM devices and peripherals, it is often a key fused into the SoC. Document which keys are enrolled, who controls them, and whether the enrollment was performed at manufacture or can be modified.

• Verify the chain, not the claim. Boot a device with a deliberately modified firmware image and confirm the rejection. This sounds trivial; a surprising number of environments discover that a vendor's "secure boot enabled" setting was never actually enforced, or that a diagnostic rollback path bypasses signature checks entirely.

• Check for revocation machinery. If a signing key is compromised, is there a mechanism — key update over DMTF-compliant interfaces, revocation via firmware updates — to rotate the root of trust? A chain with no revocation path is a chain with no future.

Interrogate the TPM and Secure Enclave

The TPM on a modern server, or the secure enclave in a laptop and phone fleet, is where the most consequential keys live. The audit questions are concrete:

• Are the TPM's anti-hammering and dictionary-attack protections enabled, or has someone disabled lockout for operational convenience?
• Are sealing operations actually bound to measured boot state, or is the PCR policy so permissive that any boot configuration unseals the secret?
• For fleet management, is the endorsement hierarchy used, or is everything provisioned under the more easily cloned storage hierarchy?
• Can secrets be extracted via debug interfaces? Confirm that JTAG and UART access is fused off or locked in production units.

Verify What the Firmware Actually Does

Documentation describes intent; binaries describe behavior. Where feasible, obtain firmware images — most vendors now publish them or expose them through vendor tools — and verify:

• No hardcoded credentials or symmetric keys embedded in images (a quick scan with standard string and entropy tools catches the low-hanging fruit).
• Use of vetted cryptographic libraries rather than hand-rolled implementations, which are endemic in embedded code.
• Signed update packages with replay protection — a signature alone is insufficient if an attacker can re-deliver an old, vulnerable, but validly signed image.

Make It Recurring, Not Heroic

The single most common failure pattern is treating this as a one-time procurement exercise. Firmware cryptography changes with every BIOS update, every SoC refresh, and every vendor supply chain reshuffle. Fold the checklist above into your existing hardware lifecycle reviews, and assign ownership the same way you assign ownership of TLS certificates. The perimeter has moved below the operating system; the audit program should move with it.