Secure boot was introduced as a hardware‑rooted guarantee that a machine only runs firmware and operating‑system code that has been signed by a trusted authority. The Trusted Platform Module (TPM) is the cornerstone of that guarantee: it stores cryptographic keys, validates signatures, and can lock the boot chain against tampering. In practice, many vendors ship devices with TPM secure‑boot enabled, yet they omit the measured‑boot component that records a hash of every firmware component into the TPM’s Platform Configuration Registers (PCRs). The omission creates a blind spot that sophisticated attackers can exploit to inject malicious firmware while still passing the TPM’s signature checks.

What “Secure Boot” Actually Verifies

At a high level, secure boot performs three actions:

  1. It checks that each bootloader stage is signed by a key that resides in the firmware’s Allowed Signature Database (db).
  2. It verifies that the public key used for verification is itself trusted, typically by being rooted in the platform’s Platform Key (PK) stored in the TPM.
  3. It aborts the boot process if any signature fails, preventing unsigned code from executing.

What secure boot does not do by default is keep a tamper‑evident record of what was actually loaded. That record is the purpose of measured boot: each component’s hash is extended into a PCR, creating a chain of trust that can be later examined by remote attestation services.

The Hidden Gap When Measured Attestation Is Missing

Without measured boot, the TPM only knows that a signature was valid at the moment of verification. An attacker who can replace a signed firmware image with a new version that carries the same valid signature—perhaps by compromising the signing key in the supply chain— will see the TPM happily accept the image. The platform’s PCRs will remain unchanged because the hash of the loaded image is never recorded. Consequently, any remote verifier that queries the TPM will receive the same PCR values as a pristine system, even though the underlying code is malicious.

Real‑World Attack Vectors That Exploit This Gap

Several recent incidents illustrate the danger:

  • Supply‑Chain Key Theft: An adversary exfiltrates a vendor’s private signing key, crafts a malicious UEFI image, and signs it. The compromised image passes secure‑boot verification because the signature is technically correct.
  • Firmware Re‑signing via Rogue Firmware Update Tools: Some OEMs ship update utilities that can be tricked into signing arbitrary firmware blobs when supplied with a manipulated manifest. The signed blob then boots without triggering any alarm.
  • Physical Access and TPM Reset Attacks: An attacker with physical access can clear the TPM’s PCRs and reinstall a malicious bootloader that re‑uses the original signing keys. The system boots, and the lack of PCR measurement means the compromise remains invisible to remote integrity checks.

Why Organizations Continue to Skip Measured Boot

The primary reasons are operational complexity and legacy compatibility:

  1. Complexity of PCR Management: Maintaining a baseline of known good PCR values across heterogeneous hardware fleets requires a robust attestation infrastructure, which many enterprises lack.
  2. Vendor Fragmentation: Not all firmware vendors expose a consistent measured‑boot API, leading to gaps in coverage.
  3. Performance Concerns: Extending hashes into PCRs adds a few milliseconds to the boot process, a cost that some manufacturers deem unacceptable for low‑end devices.

Hidden Internals: How Measured Boot Extends Trust

When measured boot is enabled, each stage of the boot process performs the following steps: 

hash = SHA256(read(firmware_blob));
PCR[n] = SHA256(PCR[n-1] || hash);

The concatenation of the previous PCR value with the new hash guarantees that any change in any earlier component will cascade forward, altering every subsequent PCR. Remote attestation services can then request the PCR bundle and compare it against a known‑good reference database. If the PCRs diverge, the server can refuse network access, trigger a quarantine, or request a forensic dump.

Practical Steps to Close the Gap

Enterprises that have already deployed TPM‑based secure boot can retrofit measured boot without a full hardware refresh:

  • Enable PCR Extension in Firmware Settings: Most modern UEFI implementations expose a toggle for “Measured Boot”. Turn it on and verify that the firmware logs hash extensions during the next boot.
  • Deploy an Attestation Service: Use an open‑source solution such as tpm2‑tools combined with a cloud‑native verification service to collect PCR values from each endpoint. Store baselines in a version‑controlled repository.
  • Integrate with Identity‑Based Access Control: Bind the attestation result to the device’s identity in your Zero‑Trust network. Devices that present unexpected PCRs should be denied access to critical resources.
  • Automate Firmware Signing Audits: Enforce a policy that any new firmware image must be signed with a key that has an auditable lifecycle. Rotate keys regularly and keep a signed manifest of allowed hashes.

When Measured Attestation Is Still Not Sufficient

Even with measured boot, attackers can target the runtime environment:

  • Runtime Code Injection: Once the OS is running, malicious modules can be loaded that do not alter the boot PCRs. Complement measured boot with runtime integrity monitoring (e.g., kernel integrity checks, signed kernel modules).
  • Side‑Channel Leakage: TPMs do not protect against side‑channel attacks that extract keys after the boot process. Deploy hardware mitigations and limit privileged access to the TPM.

Conclusion

Relying solely on TPM‑based secure boot creates an illusion of safety that can be shattered by sophisticated firmware attacks. The missing measured‑boot component eliminates the ability to prove that the exact code that ran matches a trusted baseline. Organizations that ignore this gap expose themselves to supply‑chain compromises, rogue updates, and physical tampering—all while believing their TPM is doing the heavy lifting.

The remedy is straightforward: enable measured boot, build a reliable attestation pipeline, and extend integrity checks into the runtime phase. Only by coupling signature verification with immutable measurement can the promise of hardware‑rooted trust be fulfilled.