Secure boot and measured boot protect the startup process of an embedded system, but they solve different problems. Secure boot verifies that firmware is authorized before allowing it to execute. Measured boot records cryptographic evidence about each component that runs, allowing another system to evaluate the device’s state.

The distinction matters for connected products. An industrial gateway may need secure boot to prevent modified firmware from starting, while its management platform may also require measured boot to confirm remotely which software version is running. Automotive ECUs, medical devices, and IoT fleets often benefit from both.

Secure boot provides enforcement. Measured boot provides evidence. Used together, they establish a hardware-rooted chain of trust and make compromised or incorrectly configured devices easier to block, detect, and investigate.

What Is Secure Boot in Embedded Systems?

Secure boot is a boot-time verification mechanism that permits only authorized software to run. It begins with an implicitly trusted component, typically immutable Boot ROM inside the processor or microcontroller.

The Boot ROM contains, or can securely access, a public key or a cryptographic hash representing a trusted key. The corresponding private signing key remains within the manufacturer’s controlled signing infrastructure.

A typical secure boot sequence works as follows:

  1. The processor starts executing immutable Boot ROM.
  2. Boot ROM authenticates the first-stage bootloader.
  3. The first-stage bootloader authenticates the next boot stage.
  4. The bootloader verifies the operating system kernel, configuration, Device Tree, and initramfs.
  5. The operating system validates the root filesystem or application firmware before using it.
  6. If verification fails, the system enters recovery mode or refuses to boot.

Each verified component establishes trust in the following component. This produces a chain of trust extending from hardware to application software.

Verification should use a digital signature rather than a hash stored beside the image. An attacker who can replace an image could also replace an unprotected hash. A valid signature demonstrates that an approved signing key authorized the image. For more background, see What Is a Digital Certificate?.

U-Boot describes verified boot as the verification of software loaded during startup and supports signed Flattened Image Tree images containing kernels, Device Trees, and related components. Its documentation also emphasizes that the public verification key must reside in a protected location; otherwise, an attacker could replace both the software and its key. U-Boot Verified Boot documentation

What Secure Boot Protects Against

A correctly implemented secure boot chain can prevent:

  • Execution of unauthorized firmware
  • Persistent bootloader or operating system modifications
  • Installation of unsigned firmware images
  • Downgrade to an older signed image when anti-rollback protection is enabled
  • Tampering with signed boot configuration and hardware descriptions
  • Some supply-chain and maintenance-channel attacks

Secure boot does not prove that authorized software is free from vulnerabilities. A correctly signed but vulnerable firmware release will still pass verification. Secure boot must therefore be part of a broader secure development lifecycle that includes code review, vulnerability management, secure updates, and testing. See Best Practices for Secure Firmware Development for the wider development context.

What Is Measured Boot in Embedded Systems?

Measured boot creates cryptographic records of the components involved in startup. Instead of deciding whether a component may run, the current boot stage calculates a hash of the next component and stores the resulting measurement in protected hardware before transferring control.

A Trusted Platform Module is commonly used for this purpose. It maintains Platform Configuration Registers, or PCRs, which can accumulate measurements through an extend operation:

PCR new = Hash(PCR old || component measurement)

This operation makes the final PCR value dependent on both the measured components and their order. Software cannot normally reset selected PCRs to arbitrary values during the same boot cycle.

Because a PCR value alone does not explain which components produced it, the system also maintains an event log. The log identifies measured components and records their hashes. A verifier can replay these events, confirm that they reproduce the reported PCR values, and then compare the components against its security policy. The Trusted Computing Group provides detailed guidance on validating PCR measurements and associated event logs. TCG guidance on integrity measurements and event-log processing

Measurements may cover:

  • Bootloader stages
  • Boot configuration
  • Firmware images
  • Kernel and initramfs
  • Device Tree blobs
  • Security policy
  • Root filesystem metadata
  • Selected application components

U-Boot, for example, can measure boot components into TPM PCRs and provide the resulting event log to Linux. U-Boot measured boot documentation

Remote Attestation

Measurements become particularly useful when combined with remote attestation. In a typical attestation exchange:

  1. A management server sends the device a fresh random nonce.
  2. Protected hardware signs selected PCR values together with the nonce.
  3. The device returns the signed evidence and measurement log.
  4. The server verifies the signature, nonce, event log, and device identity.

Secure Boot vs Measured Boot: Key Differences

Area Secure boot Measured boot
Primary objective Prevent unauthorized software from executing Record cryptographic evidence of the boot state
Main action Verify signatures and enforce an allow-or-deny decision Hash components and extend measurements into protected registers
Response to an unexpected component Refuse to boot or enter recovery Record the component; execution may continue
Hardware requirement Immutable root of trust and protected verification key Protected measurement and attestation capability, commonly a TPM
Remote visibility Limited unless additional reporting is implemented Designed to support local or remote attestation
Update requirement New images must be signed and version-authorized Reference measurements or verification policies must recognize the new release
Main output A booted or rejected system PCR values, event log, and potentially signed attestation evidence
Core security value Prevention Detection, reporting, and policy enforcement

The terms are sometimes confused because both mechanisms hash software components. The difference lies in what happens to the result.

Secure boot compares authentication data against a trusted key and blocks an image that fails verification. Measured boot stores evidence describing the image that was encountered. That evidence only improves security if a verifier evaluates it and acts on the result.

  1. The server compares the measured state against an approved policy.

The nonce prevents an attacker from replaying evidence captured during an earlier trusted boot. Depending on the result, the server may grant the device access, place it in quarantine, withhold operational secrets, or request remediation.

Measured boot does not inherently stop unauthorized code from executing. It records what happened so that a local or remote policy engine can make a decision.

Should Embedded Systems Use Secure Boot, Measured Boot, or Both?

For most security-sensitive connected products, secure boot and measured boot should be treated as complementary controls.

A combined Linux boot chain might operate as follows:

  1. SoC Boot ROM authenticates the first-stage bootloader.
  2. The first-stage bootloader verifies and measures U-Boot.
  3. U-Boot verifies and measures the kernel, initramfs, Device Tree, and boot parameters.
  4. The kernel validates the root filesystem using a mechanism such as dm-verity.
  5. An integrity subsystem measures security-sensitive runtime files when required.
  6. A remote service requests attestation before releasing credentials or admitting the device to a protected network.

Secure boot stops untrusted images at the device. Measured boot lets fleet infrastructure distinguish approved, outdated, misconfigured, and potentially compromised devices.

NIST’s platform firmware resiliency guidance organizes firmware protection around three principles: protecting firmware from unauthorized changes, detecting unauthorized changes, and recovering securely. Secure and measured boot contribute to these goals but do not replace protected recovery and update mechanisms. NIST SP 800-193: Platform Firmware Resiliency Guidelines

Applications and Industry Relevance

Automotive ECUs

Secure boot can prevent an ECU from running firmware that was not signed by the OEM or an authorized supplier. Anti-rollback controls can additionally prevent attackers from installing an older signed version containing known vulnerabilities.

Measured boot can report the exact firmware and calibration state of a domain controller, gateway, or infotainment unit. A backend can use that evidence during diagnostics, software updates, or vehicle admission to protected services.

For more information about the surrounding startup architecture, see What’s the Purpose of Bootloaders in Automotive?.

Industrial Gateways and Controllers

An industrial gateway may boot only signed firmware while measuring its bootloader, kernel, Device Tree, and security policy. A device-management platform can then reject connections from gateways that run unapproved software or unexpected configurations.

This supports defense-in-depth strategies used in industrial cybersecurity. It is particularly relevant where operators need device inventory, configuration evidence, and controlled access across long product lifecycles.

Medical Devices

Secure boot helps prevent unauthorized software from replacing validated device firmware. Measured boot can provide additional evidence for asset management, servicing, incident investigation, and network access decisions.

Neither control alone establishes regulatory compliance or functional safety. Teams must still validate the complete update, recovery, risk-management, and software-development processes.

IoT Fleets

Physical access makes unattended IoT devices difficult to trust based only on network identity. Secure boot protects the local startup path, while attestation can help the cloud determine whether a device is running an approved software state before delivering credentials, workloads, or sensitive data.

Secure and Measured Boot Best Practices

Establish a Hardware Root of Trust

Store the initial public-key hash, root key, or trust anchor in immutable ROM, one-time-programmable memory, protected fuses, or equivalent hardware. A key stored in ordinary writable flash cannot provide a reliable root of trust.

Authenticate Every Security-Relevant Boot Component

Do not verify only the kernel. Include bootloaders, Device Trees, initramfs images, configuration, executable scripts, recovery images, and other data capable of changing system behavior.

Implement Anti-Rollback Protection

A signed image is not necessarily a safe image. Store security version counters in protected monotonic storage and reject releases below the permitted version.

Plan Key Rotation and Revocation

Devices may operate for ten years or longer. The architecture needs a controlled method to introduce new signing keys, revoke compromised keys, separate development from production trust, and recover from signing-infrastructure incidents.

Protect Recovery and Update Paths

An unsigned recovery image can bypass an otherwise correct boot chain. Recovery firmware, factory modes, OTA packages, and service interfaces must enforce equivalent trust policies. A/B partitions and fail-safe update logic help preserve availability.

Define Measurement and Attestation Policy Early

Choose which boot components map to which PCRs, how the event log reaches the operating system, and which variations are acceptable. Decide how the backend handles firmware updates, hardware revisions, optional modules, and configuration changes.

Make Attestation Fresh and Actionable

Use nonces to prevent replay. Bind evidence to a provisioned device identity and a protected attestation key. Define what happens when validation fails: quarantine, restricted operation, alerting, secret denial, or recovery.

Test Failure Conditions

Test corrupted images, wrong keys, revoked keys, interrupted updates, rollback attempts, modified Device Trees, invalid event logs, debug access, and recovery-mode abuse. Fault-injection testing may also be appropriate for products exposed to skilled attackers.

Conclusive Engineering supports these activities through its Operating Systems and Bootloaders services, Firmware Development services, and embedded Cybersecurity services.

Common Secure Boot and Measured Boot Mistakes

  • Treating a plain checksum as proof of authenticity
  • Storing the root verification key in writable, unprotected memory
  • Verifying the kernel but ignoring configuration, Device Tree, or recovery software
  • Accepting every correctly signed version without anti-rollback checks
  • Leaving production debug interfaces unrestricted
  • Using the same private signing key for development and production
  • Collecting boot measurements without validating them
  • Accepting attestation evidence without a fresh nonce
  • Failing to update reference measurements when authorized software changes
  • Designing a failure path that leaves deployed devices permanently unusable
  • Assuming encrypted firmware is automatically authenticated
  • Treating secure boot as a substitute for runtime hardening and vulnerability management

Frequently Asked Questions

Is measured boot more secure than secure boot?

No. The mechanisms address different requirements. Secure boot enforces which software may execute. Measured boot provides evidence about what executed. A system that requires both prevention and remote verification should implement both.

Does secure boot require a TPM?

No. Secure boot requires a hardware-rooted trust anchor and protected verification process, but it does not specifically require a TPM. Many microcontrollers and SoCs implement secure boot using Boot ROM, fuses, secure elements, hardware security modules, or integrated security subsystems.

Can measured boot stop malware from running?

Not by itself. Measured boot records boot-state evidence. A separate local or remote verifier must evaluate that evidence and enforce a policy. Secure boot is normally used to stop unauthorized boot components before execution.

Are a firmware hash and a digital signature equivalent?

No. A hash detects changes only when the expected hash is protected. A digital signature connects the image to a trusted private signing key and allows the device to authenticate its origin. Embedded secure boot should generally verify signatures or equivalent message-authentication data rooted in protected keys.

What happens to measured boot after a legitimate firmware update?

The update changes one or more measurements. The attestation policy must recognize the new approved state before or alongside deployment. Otherwise, correctly updated devices may be quarantined because their PCR values no longer match the previous policy.

Should a small microcontroller use measured boot?

It depends on the threat model. A standalone controller may only need hardware-backed secure boot and anti-rollback protection. A remotely managed or safety-relevant device may benefit from measurement and attestation, provided its hardware and backend can protect, transmit, and evaluate the evidence.

Conclusion

Secure boot and measured boot are not competing approaches. Secure boot prevents unauthorized firmware from entering the trusted execution chain. Measured boot creates tamper-resistant evidence describing the software and configuration involved in startup.

Secure boot is usually the baseline for products that support field updates or face realistic firmware-tampering risks. Measured boot becomes valuable when another component needs to verify device state, particularly in managed IoT fleets, industrial infrastructure, connected vehicles, and regulated systems.

The strongest architecture combines hardware-rooted verification, comprehensive boot measurements, anti-rollback controls, protected recovery, secure updates, and an attestation policy that produces a meaningful operational response. Conclusive Engineering can support this work from bootloader and firmware architecture through hardware integration, signing infrastructure, testing, and device security assessment.