# Secure Boot > Secure boot is the mechanism that checks the integrity and authenticity of an ECU firmware image before the processor runs it. A root of trust, usually in an HSM or ROM, verifies a signature or hash over each stage before passing control to it, so modified or unsigned software does not start, or starts only in a limited recovery mode. It underpins trust in everything that runs afterwards, including SecOC and secure diagnostics. A bench test sees its effects, not its internal keys. Secure boot verifies an ECU firmware image before it runs, so unsigned or modified software does not start. How it works, the HSM role and what a bench test can observe. Source: https://auto-st.com/glossary/secure-boot ยท Updated: 2026-10-07 ## What is secure boot? Secure boot is a chain of verification that runs when an ECU powers up. The root of trust verifies the first bootloader stage, that stage verifies the next, and so on up to the application, each step checking a cryptographic signature or hash before handing over control. If a stage fails verification, the ECU refuses to run it and either halts, stays in the bootloader or enters a restricted recovery state. The result is that only software the manufacturer signed starts normally. The cryptography usually runs in an HSM or a protected ROM, so the public keys or hashes used for verification are held where application software cannot change them. ## Where is it defined? There is no single secure boot standard; it is a design pattern realised with the microcontroller vendor's security hardware, AUTOSAR crypto services and project-specific key management. ISO/SAE 21434 treats boot integrity as part of the security concept and architecture of an item. UN R156 requires that software version identification and update integrity be protected, which in practice relies on a verified boot and image check on the ECU. ## What it means in practice Secure boot is the base of the trust chain. SecOC keys, secure diagnostic credentials and any claim that the running software is the approved version all assume that the code which uses them is itself genuine. If secure boot is missing or can be skipped, an attacker who writes modified firmware can defeat the controls above it, because those controls run inside the software they are supposed to protect. From outside the ECU, secure boot is hard to observe directly. What a tester can look at is adjacent: whether the diagnostic download path enforces session and SecurityAccess before writing an image, whether an interrupted or malformed download leaves the ECU recoverable, and which version identifiers the ECU reports. Confirming that the boot chain actually rejects a modified image is firmware reverse engineering and penetration-test work. ## How AutoST tests it AutoST tests the diagnostic and bus-facing path around secure boot, not the boot verification itself. It checks whether RequestDownload (`0x34`) and the transfer services require the correct session and SecurityAccess, probes robustness under malformed or oversized TransferData, and reads version and identification data identifiers. It does not verify signatures, extract keys or attack the boot ROM; that is reverse engineering and penetration-test work. ## Common misunderstandings Secure boot does not prevent writing firmware; it governs whether that firmware runs. A single stage that skips verification breaks the whole chain. And secure boot protects startup integrity, not confidentiality or runtime memory safety, which need their own measures. ## FAQ **What is the difference between secure boot and authenticated boot?** Secure boot enforces: if verification fails, the stage does not run. Authenticated (or measured) boot records what ran, for example in a log or a register, so a later check can detect tampering, but it does not stop the boot by itself. Many ECUs combine the two. **What is the root of trust?** The first piece of code or key that is trusted implicitly because it cannot be changed in the field, typically in masked ROM or an HSM. Every later stage is trusted only because the root verified it, which is why the chain breaks if any link skips verification. **Does secure boot stop someone flashing new firmware?** Not the flashing itself. A diagnostic download can still write an image. Secure boot decides whether that image is allowed to run on the next start. The two are separate controls, which is why both the download path and the boot check matter. ## Sources - [ISO/SAE 21434:2021 Road vehicles, Cybersecurity engineering](https://www.iso.org/standard/70918.html) - [UN Regulation No. 156, Software update and software update management system](https://unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update) ## Related - [HSM (Hardware Security Module)](https://auto-st.com/glossary/hsm) - [SecOC (Secure Onboard Communication)](https://auto-st.com/glossary/secoc) - [RequestDownload (0x34)](https://auto-st.com/glossary/request-download-0x34) - [UN R156 (UN Regulation No. 156, Software Update)](https://auto-st.com/glossary/un-r156) - [Does your seed/key actually hold?](https://auto-st.com/security-access-testing) --- AutoST by Zyberum. Canonical page: https://auto-st.com/glossary/secure-boot