Everything your product trusts before your code runs.

• The boot chain, link by link. What verifies what, with which key, and what happens on failure. A chain whose every link verifies and whose recovery mode does not has exactly one link.
• The signature check as implemented. Not whether verification exists, but whether the parsing before it is attacker-reachable, whether rollback is accepted, and whether the failure path is fail-closed.
• Attestation and key handling. Where the root of trust is, what it measures, and whether a measurement anybody can influence is treated as evidence.
• The update and recovery path, which is the most common way a hardened product gets owned: downgrade, partial write, interrupted update, factory reset, debug mode.
• The components nobody scoped: the embedded controller, the BMC, option ROMs, Wi-Fi and Bluetooth firmware, the retimer.
• The mitigation inventory, read out of the binary rather than from a build flag somebody believes is set.

Where the review is feeding a regulatory file, the same evidence lands in the shape the CRA page describes, with the obligation and its limit in the same row.