Secure boot.
Signed updates.
A chain worth trusting.

A connected product can receive new software through a service tool, removable media or a network. The engineering problem extends from accepting a package to deciding what may execute after the next reset. A signed download is useful only if the device verifies it correctly and the subsequent boot path preserves that decision.

Start with the assets and trust boundaries: boot configuration, firmware images, verification keys, update metadata, service interfaces and any remotely supplied components. Agree what an attacker can reach and which failure modes the product must tolerate.

A typical chain begins with a hardware-backed trust anchor. An early boot stage authenticates the next stage before execution; subsequent stages continue verification for the images they load. The exact mechanism depends on the SoC or MCU and its boot architecture.

The implementation must define which images and configuration are covered, where trusted verification keys or their hashes reside, and how production debug access is controlled. A failed check needs an explicit response, such as refusing the image and entering a restricted recovery path.

Anti-rollback is a related design decision. An old image can still have a valid signature while containing a known vulnerability. Where the threat model requires rollback protection, version policy and trusted version state must be part of the design.

The update path must establish who authorised the software and whether its contents are intact. A CRC can detect accidental corruption; it does not authenticate the software publisher. The package signature and the integrity checks need to cover the intended payload and relevant metadata.

Before installation, check product compatibility, package completeness and any version restrictions. Plan the transition between download, staging, activation and the next boot. Network transport protection complements package authentication; each protects a different boundary.

A signing private key and a device verification key have different roles. Device-side HSM integration can protect supported local key operations, while release signing needs its own controlled infrastructure. Define provisioning, rotation, revocation and recovery responsibilities with the OEM.

Dual-bank or A/B designs can keep a previous bootable image while a new one is staged. Resource-constrained devices may need a different recovery scheme. In either case, the design must explain how the device returns to an accepted state when installation is interrupted or the new image cannot start.

Fallback policy must also agree with rollback protection. Returning to a previous image is only acceptable if the product’s security policy still permits that version. Recovery must preserve the intended authentication checks.

Deliver the configuration, test setup, software versions, expected outcomes and actual results. Link each test to an agreed requirement. Record assumptions and unresolved findings so the OEM can incorporate the results into its product-level assessment.

The CRA sets risk-based product security and vulnerability-handling requirements. Secure boot and authenticated updates can support software integrity and remediation, but their presence alone does not establish conformity. The manufacturer must determine the applicable requirements and how the complete product satisfies them.

Crossware’s contribution is a defined engineering delivery: platform integration, verification and traceable evidence. Product classification, the conformity route, support policy and regulatory reporting remain part of the wider manufacturer-led programme.

Technical background: this guide develops the BSP, middleware and verification topics in Crossware’s cybersecurity service scope. The architecture and test cases are illustrative, rather than a claim that every mechanism is available on every target.

Regulatory references: Regulation (EU) 2024/2847, Annex I and the European Commission CRA overview.