STM32H563 or H573: Choose the Secure-Boot Owner Before Freezing the BOM

A secure-boot requirement can change the STM32H5 ordering decision. Before treating an H563 and an H573 as interchangeable application processors, decide who supplies the immutable first-stage boot code. The documented STiRoT path available on H573 is not an H563 boot option that can simply be enabled later.

This comparison concerns H563/H573 boot architecture, using RM0481 Rev 5 and ST's secure-boot guide approved on 18 May 2026. It does not claim equivalent cryptographic features across the family, certify a secure product, or provide a production option-byte programming recipe.

Start with the boot-path table

The ST secure-boot guide explicitly separates H533/553/573 boot paths from H523/56x paths. H56x does not support STiRoT or STuRoT. An OEM-controlled root of trust can instead use the middleware cryptographic library for authentication and integrity verification.

In RM0481 Rev 5, sections 4.1 and 4.2 provide different device-specific boot tables. The H573 path includes the unique boot-entry selection between STiRoT and user flash when TrustZone is enabled. The H562/H563 table uses the selected secure user-flash boot address for its corresponding provisioned states.

There is a documentation trap here. The H562/H563 datasheet, DS14258 Rev 6, includes broad descriptive text about an embedded ST-iROT in its functional overview. That paragraph is insufficient evidence that H563 offers the H573 selection. Its own device-specific boot tables, the reference manual and the explicit ST guide must be read together. Resolve procurement requirements from the supported path rather than a keyword match.

Assign an owner to the immutable stage

STiRoT is supplied by ST in system flash. OEMiRoT is customer-controlled code placed in user flash and made immutable through the appropriate protection scheme. Both can be the first stage in a chain, but they create different release responsibilities.

For an OEMiRoT product, the team must deliver the first-stage binary, its build and configuration provenance, verification policy, memory placement and protection configuration. Those artifacts remain part of the product even when most application development occurs in a separate project. Calling a file a bootloader does not establish that it is protected as the intended immutable stage.

For an STiRoT-based product, the team still owns provisioning choices, accepted-image policy, downstream firmware and integration. A factory-supplied first stage does not remove the need to qualify the complete boot chain. It changes which implementation is supplied by the silicon vendor and which one the product must build.

Decide whether the update policy needs a second stage

ST documents one-stage and two-stage secure boot. In the latter, the immutable root verifies an updatable root, which then verifies the application. The second stage is optional, so adding it should solve an actual maintenance requirement rather than serve as a generic security checkbox.

Consider a product whose application image format and update policy are expected to evolve. An updatable second stage can place some changeable policy outside the immutable first stage. That does not make the second stage freely replaceable: its authenticity and installation must remain governed by the preceding trust decision. Conversely, a simpler one-stage design has fewer independently delivered images but puts more long-lived behavior into its first-stage contract.

Write an image ownership map with one row per actual stage: supplier, immutable or updatable status, verifier, accepted format and destination. This exposes an otherwise hidden mismatch: a manufacturing package that contains an application and update service but omits the OEMiRoT needed by the selected H563.

Treat isolation levels as boot transitions

The guide describes HDPL as a protected monotonic counter managed through the system boot and security hardware. The counter advances through isolation stages; a power-on or system reset is needed to reset it. Later levels restrict access to earlier-stage code and secrets.

Therefore, a later application should not depend on calling back into a first-stage service merely because its address remains in a linker map. Identify the intended service interface and its permitted execution level. Authentication success, control transfer and the loss of access to earlier resources are separate parts of the handoff design.

Avoid copying an H573 sample's boot options into an H563 manufacturing script. Likewise, do not infer that disabling TrustZone preserves the same secure boot addresses and isolation behavior. The supported boot table depends on device, lifecycle state and TrustZone configuration.

Make the BOM decision explicit

A requirement for the documented STiRoT first stage makes H573's supported path relevant. A product willing to own OEMiRoT can evaluate H563 against its complete performance, memory and maintenance requirements. Neither conclusion follows from CPU frequency alone.

Before production, qualify the selected chain on recoverable development units with approved provisioning procedures. Verify the actual first-stage identity and rejection behavior for each downstream image. No device provisioning, binary build or boot test was performed here; the result is an architectural selection method that prevents an unsupported boot service from becoming a late manufacturing dependency.