Cybersecurity · Penetration Testing · ISO/SAE 21434 · UNECE R155/R156
One of the most fundamental cybersecurity mechanisms in embedded systems and automotive ECUs is the Secure Boot Chain of Trust. A compromised ECU can affect an entire vehicle. Many OEMs proudly state that they have implemented Secure Boot — but implementing it and proving it cannot be bypassed are two very different things. Requisimus has brought up and hardened Secure Boot chains on TI TDA4VM, NXP i.MX8QuadMax, and Infineon AURIX TC389 in production programs — the same class of SoCs this assessment targets.
August 2026 · Requisimus · 6 min read
| 8 Assessment Domains | ROM → App Full Chain-of-Trust Coverage | 6+ Attack Techniques Simulated | Independent Vendor-Neutral Validation | 3 SoC Platforms Delivered |
The Challenge
Secure Boot ensures that each ECU only executes firmware signed by the OEM. It is one of the most fundamental cybersecurity mechanisms in embedded systems and automotive ECUs — because a compromised ECU does not stay contained to that one module, it can affect the entire vehicle.
Many OEMs proudly state that they have implemented Secure Boot. But one critical question remains:
How confident are you that your Secure Boot implementation cannot be bypassed by an attacker?
Simply implementing Secure Boot does not guarantee security. The real assurance comes from validating that every stage of the boot process — from the hardware Root of Trust to the application — is protected against firmware tampering, unauthorized code execution, rollback attacks, debug interface abuse, and bootloader bypass techniques.
This is where independent penetration testing plays a vital role. By simulating real-world attack scenarios, security testers can verify whether the Secure Boot implementation truly enforces the Chain of Trust, or whether hidden weaknesses could allow an attacker to compromise the device.
What “Implemented” Does Not Automatically Mean
- Signed images does not mean the verification step is enforced at every single stage, with no unauthenticated fallback path.
- A Root of Trust on paper does not mean the device is resistant to reflashing an older, previously-signed, vulnerable image.
- Debug ports disabled by default configuration does not mean JTAG, SWD, or UART are actually fused off in the production build shipped to the field.
- A signed OTA package does not mean the update pipeline itself — transport, staging, fallback — is tamper-proof end to end.
Proven on the Platforms You Are Already Shipping
Requisimus does not validate Secure Boot in the abstract. Our engineers have implemented and brought up production Secure Boot chains on the SoC families OEMs and Tier-1s are already shipping — which is what lets an assessment go straight to platform-specific attack surface instead of general theory.
TI TDA4VM
HSM-based secure boot bring-up: x509 certificate chain, key-writer provisioning, and secure/non-secure firmware partitioning for a DCU (digital cockpit / driver-assist) platform.
NXP i.MX8QuadMax
AHAB secure boot deployment: OTP SRK fusing, OEM-closed lifecycle transition, and a CST-based signing pipeline covering SPL/ATF/U-Boot and the Linux OS container.
Infineon AURIX TC389
HSM-anchored secure boot and key storage for an ASIL-D AUTOSAR RTE platform, feeding the same Root of Trust into a 30+ SWC, E2E-protected architecture.
Secure Boot — Chain of Trust & Penetration Testing Architecture
Referring to the above Image of the Architecture Left: how a compliant Secure Boot chain is built — keys and unsigned artefacts flow through the signing pipeline into deployable, fused-anchor containers. Right: how Requisimus tests it — candidate and deliberately crafted attack images are pushed through the same verification gate the silicon enforces, against both a real target board and its recovery/alternate boot paths, with every result captured as evidence.
How Requisimus Validates Your Secure Boot Implementation
01 Secure Boot Chain of Trust Validation
Verify that every stage — Boot ROM → first-stage bootloader → TF-A/TrustZone → bootloader → kernel → application — authenticates the next stage before execution, with no unauthenticated fallback path anywhere in the chain.
02 Firmware & Bootloader Tampering Assessment
Modify signed images at the byte level and observe whether the boot chain detects and rejects the tampered binary at the earliest possible stage — not just at the first driver that happens to check a checksum. See the console evidence below for what this looks like in practice.
03 Digital Signature Verification Testing
Probe the signature-verification implementation itself — TOCTOU races between verify and execute, partial or short-circuited verification paths, weak or misconfigured hash/curve choices — rather than only confirming that “a signature exists.”
04 Rollback Attack Testing
Attempt to reflash older, previously-signed firmware versions with known vulnerabilities to confirm that anti-rollback counters are actually enforced by the boot chain, not merely present in the specification document.
05 JTAG / UART / SWD Interface Security Assessment
Physically probe on-chip debug interfaces to confirm they are genuinely fused off or access-controlled in production hardware — not merely disabled by a default configuration value that a later build, or an attacker, can re-enable.
06 Secure Firmware Update (OTA) Validation
Assess the over-the-air update pipeline end to end — transport security, package signing, version enforcement, and fallback/recovery behavior when an update is interrupted or deliberately corrupted mid-transfer.
07 Root of Trust & Cryptographic Key Management Review
Review how the SRK/SGK (or equivalent) key hierarchy is provisioned, stored, rotated, and revoked, and whether private-key custody controls in practice match the security claims made to the OEM.
08 Secure Boot Bypass & Recovery-Mode Testing
Exercise manufacturer recovery, fastboot, and download modes for authentication gaps that would let an attacker sideload unsigned code entirely outside the normal, audited boot path.
Correct vs. Tampered Image — What the Console Actually Shows
A report that says “Secure Boot: PASS” is not evidence. What matters is the console trace showing exactly where in the chain a bad image was stopped, and confirming a good image authenticates cleanly end to end. The three illustrative traces below (generic, not tied to a specific customer engagement) show what each case actually looks like on the wire.
1) Tampered / Incorrectly Signed Image — Rejected at Boot ROM
| # Board powered on with a boot container that fails signature verification $ power-on target-board > Boot ROM: locating signed container in flash ……… FOUND > Boot ROM: SRK hash match (fused OTP vs container) ….. FAIL > Boot ROM: authenticate SPL/ATF/U-Boot container ……. REJECTED > Result: ROM halts before any peripheral is initialized > UART output: <none — console silent, board appears “dead”> |
2) Correctly Signed Image — Full Chain Authenticates
| # Board powered on with the correctly signed, matching boot container $ power-on target-board > Boot ROM: locating signed container in flash ……… FOUND > Boot ROM: SRK hash match (fused OTP vs container) ….. PASS > Boot ROM: authenticate SPL/ATF/U-Boot container ……. PASS — no security events > UART: console live from the very first line of output > U-Boot: authenticate signed OS container (kernel+dtb) .. PASS — no security events > Linux: mount root filesystem read-write ……………. OK > Result: reaches interactive login prompt, Secure Boot fully enforced |
3) Old-but-Validly-Signed Image — the Rollback Gap
| # Older, known-vulnerable firmware — still validly signed by the same OEM key $ flash_tool –image firmware_v1.2_signed.img > Boot ROM: SRK hash match ………………………….. PASS > Boot ROM: authenticate SPL/ATF/U-Boot container ……… PASS > Anti-rollback counter check ………………………… MISSING > Result: downgrade succeeds — known-vulnerable firmware now running |
Case 2 is what most OEMs check internally — “does Secure Boot work.” Cases 1 and 3 are what an independent penetration test is designed to surface: does the chain fail safely under tampering, and does it actually block a valid-but-outdated image, not just an invalid one.
Why It Matters
Confidence Backed by Evidence
Move from “we implemented Secure Boot” to a documented, reproducible test report showing exactly which attack techniques were attempted and what happened at each stage.
Findings Mapped to Remediation
Every confirmed weakness ships with a concrete, actionable fix recommendation — not just a severity score and a CVE-style label.
Regulatory Alignment
Assessment scope maps directly to ISO/SAE 21434 cybersecurity engineering requirements and UNECE R155/R156 type-approval expectations.
Independent & Vendor-Neutral
Testing performed by a team with no stake in the original Secure Boot implementation, so findings are never self-graded.
Techniques & Standards
JTAG | SWD | UART | Voltage Glitching | Fault Injection | ARM TrustZone / TEE | HAB / AHAB | U-Boot | TF-A | Firmware Reverse Engineering | OTA / FOTA Security | HSM & Key Management | ISO/SAE 21434 | UNECE R155 | UNECE R156 | TARA
Assessment Facts
| Domains Covered | 8 |
| Chain Coverage | ROM → App |
| Engagement Type | Independent |
| Delivery | Report + PoC + Fix |
| Standards | ISO 21434 · R155/156 |
Ready to Put Your Secure Boot to the Test?
Secure Boot is not just a feature — it is a security promise. That promise must be validated, not assumed. Requisimus can help you find out before an attacker does.
Mail to: Basavaraj.Tarihalli@requisimus.com
© 2026 Requisimus. All rights reserved. · Automotive & Embedded Engineering Experts