Image integrity and cryptographic authenticity are distinct.
Start with the decision to run
Write down the conditions for application handover before choosing the transport. Which hardware and image versions are compatible? Which checks must pass? What state is safe if they do not? These decisions define the boot path and the evidence needed to accept it.
Keep the checks distinct
An integrity check detects some forms of corruption. Cryptographic authentication establishes that an image was authorised by a trusted signing identity. Neither should be used as shorthand for the other. A version policy is another decision: an intact, authentic image may still be unsuitable for a particular device or release.
Make recovery an explicit path
Agree what happens if power is lost during programming, validation fails or the new application cannot start reliably. A second image slot can enable a recovery strategy, but its presence alone does not establish safe switching or rollback. The flash layout, state changes and interrupted-write behaviour must support the chosen policy.
Turn those decisions into acceptance tests
Use a matrix covering the normal update, invalid images, interrupted programming, failed first boot and recovery. For each scenario, record the initial state, expected decision and evidence to capture. Include the host tool and transport where their behaviour affects the result.
What to bring to the first discussion
Provide the target MCU and flash arrangement, current boot path, update transport, image format, version rules and any security requirements. If there is an existing implementation, bring its build instructions and known failure cases. That makes a scoped review much more useful than a generic request for a secure bootloader.