Secure Boot and Secure Flash: How to Protect Your ECU from Firmware Attacks

Modern vehicles are no longer just mechanical machines; they are highly connected, software-driven systems. From ADAS and infotainment to battery management and powertrain control, ECUs run millions of lines of code. But with connectivity comes risk.

In 2024, the automotive industry recorded 409 publicly disclosed cybersecurity incidents, a 39% increase from 2023, with 95% of attacks executed remotely and 60% causing high to massive impact across thousands to millions of mobility assets (Upstream Security, 2025). ECU firmware attacks accounted for 8% of all automotive incidents, with ransomware representing 45% of all automotive cyber incidents in 2025. To protect vehicle software integrity, Secure Boot and Secure Flash have become essential components of automotive cybersecurity architectures.

The Growing Risk of ECU Firmware Attacks

Today’s vehicles communicate through multiple interfaces, each a potential attack entry point:

• OBD ports and diagnostic gateways
• Telematics and connectivity units
• Wireless OTA and FOTA update channels
• In-vehicle networks: CAN, LIN, Ethernet

If not properly secured, attackers can exploit these channels to:

• Inject malicious firmware into safety-critical ECUs
• Modify ECU behaviour or disable safety systems
• Install persistent malware that survives software updates
• Downgrade firmware to older versions with known vulnerabilities (rollback attacks)

In 2025, Subaru’s Starlink OTA update system was found to use weak encryption during firmware delivery, allowing researchers to demonstrate firmware injection that could disable collision-avoidance systems. At the 2025 Pwn2Own Automotive competition, participants exploited zero-day flaws in EV charging ECUs to risk battery thermal runaway, and compromised gateway ECUs to achieve full vehicle control.

This is why UNECE R155, ISO/SAE 21434, and India’s AIS-189 (effective October 2025 for new vehicle types) all explicitly mandate firmware integrity protection as a foundational element of Cybersecurity Management Systems. Two critical technologies underpin this protection: Secure Boot and Secure Flash.

What Is Secure Boot?

Secure Boot ensures that an ECU only executes trusted and authenticated software at startup. When the ECU powers on, the Secure Boot process performs cryptographic verification of the firmware. If the firmware has been tampered with, modified, or replaced, the ECU refuses to boot and enters a safe or fallback state.

How Secure Boot Works

The Secure Boot process follows a strict chain of trust:

• Step 1: ECU powers on; Hardware Root of Trust (HSM or TrustZone) validates the bootloader
• Step 2: Bootloader verifies the firmware digital signature using the OEM public key stored in protected memory
• Step 3: Firmware is executed only if authentication succeeds; ECU enters safe/fallback state if verification fails
• Step 4: Anti-rollback check confirms the firmware version is not older than the currently installed version, preventing downgrade attacks

A critical enabler is the Hardware Security Module (HSM), a dedicated cryptographic co-processor embedded in modern automotive microcontrollers such as the Infineon AURIX or NXP S32 series. The HSM executes signature verification in isolated hardware, protecting private keys from software-layer attacks even if the main application is compromised.

What Is Secure Flash?

Secure Flash protects the process of updating ECU firmware, whether at the end-of-line in production, in service at a dealership, or over-the-air via FOTA. Secure Flash ensures only authenticated and OEM-approved firmware can be programmed into ECU memory.

How Secure Flash Works

• Signing: Firmware image is digitally signed by the OEM using a private key held in a backend HSM
• Session control: UDS Security Access (ISO 14229, Service 0x27) gates the programming session; a seed-and-key exchange executed within the ECU’s HSM ensures only authenticated tools or OTA servers can unlock flashing
• Verification: ECU verifies the firmware signature using the stored OEM public key before any write operation; if authentication fails, flashing is rejected and the event is audit-logged
• RAM-resident flash driver: the code that physically writes to ECU memory is loaded into RAM only during the flash session and discarded immediately after, leaving no persistent write-access path that could be exploited in the field
• A/B dual-bank scheme: new firmware is written to an inactive partition while the ECU continues running on the current version; switchover occurs only after 100% successful verification, eliminating the risk of a bricked ECU mid-update

Secure Boot vs Secure Flash: Understanding the Difference

Both mechanisms use the same cryptographic foundation (digital signatures and HSM-backed key management) but protect different phases of the ECU firmware lifecycle. Together they form a closed loop: Secure Flash prevents malicious code from entering ECU memory; Secure Boot prevents any code in ECU memory from executing if it cannot be verified. Neither is sufficient alone.

Regulatory Requirements: AIS-189, UNECE R155, and ISO/SAE 21434

Secure Boot and Secure Flash are no longer engineering best practices; they are regulatory requirements.

• UNECE R155 (mandatory for all new vehicles in the EU since July 2024): requires OEMs to implement certified CSMS covering firmware integrity and update authentication throughout the vehicle lifecycle.
• India AIS-189 (effective October 2025 for new vehicle types): mandates the same CSMS framework aligned with ISO/SAE 21434, explicitly requiring Secure Boot, communication authentication, diagnostics hardening, and encryption.
• India AIS-190 (Software Update Management System): mandates secure OTA mechanisms with cryptographic signing, integrity checks, rollback protections, and version traceability for up to 10 years across all ECUs.

Non-compliance with AIS-189 or AIS-190 can result in type approval denial and blocked market access in India. For OEMs exporting to European markets, UNECE R155 non-compliance has the same consequence.

ElectRay’s Secure Flash Bootloader is a production-grade solution with configurable secure boot, A/B image management, HSM-backed signature verification, RAM-resident flash driver, and UDS Security Access integration, aligned with AIS-189, AIS-190, and ISO/SAE 21434.

ElectRay’s Cybersecurity and Functional Safety engineering services support TARA, CSMS development, and homologation documentation for ARAI and ICAT submission.

Best Practices for Implementing ECU Firmware Security

1. Establish a Hardware Root of Trust: Use HSMs or TrustZone-based secure elements to anchor the chain of trust. The HSM must be provisioned at manufacturing with the OEM root key, which never leaves the hardware boundary.

2. Use Strong, Modern Cryptography: Adopt RSA-2048 or preferably ECC (ECDSA P-256), and SHA-256 or SHA-3 for digest computation. Avoid legacy algorithms such as MD5 or SHA-1, which are no longer considered secure for automotive applications.

3. Protect and Manage OEM Signing Keys: OEM signing keys must be managed in dedicated Hardware Security Modules at the OEM backend. Define key rotation procedures and revocation mechanisms before production begins; a compromised signing key invalidates the entire fleet’s update pipeline.

4. Enable Anti-Rollback Protection: Store a firmware version counter in protected non-volatile memory. The bootloader must reject any firmware image with a version number lower than the currently installed version, preventing downgrade to versions with known vulnerabilities.

5. Harden Diagnostic Session Access: UDS Security Access (0x27) must gate all programming sessions. Seed-key generation should be executed within the ECU’s HSM. Implement rate-limiting and lockout mechanisms to prevent brute-force attacks on the security access sequence.

The Future of ECU Firmware Security

As vehicles transition toward software-defined architectures with centralised HPCs and zonal controllers, firmware security must scale accordingly. Emerging protection strategies include:

• Post-quantum cryptography: protects against quantum computing threats to current RSA and ECC algorithms, essential for vehicles with 15+ year lifespans
• Zero-trust vehicle architectures: every ECU verifies the identity and integrity of every message it receives, eliminating implicit trust within the vehicle network
• Software Bill of Materials (SBOM) tracking: aligned with AIS-189 requirements, enabling OEMs to rapidly identify which ECUs and vehicles are affected by a newly discovered CVE and deploy targeted patches through authenticated FOTA pipelines
• Lifecycle security commitment: AIS-189 mandates post-production monitoring and incident response for the vehicle’s entire operational life, meaning bootloader and FOTA infrastructure must support field-deployable patches, audit logging, and rollback recovery years after production ends

Conclusion

Protecting ECU firmware is no longer optional. Secure Boot and Secure Flash provide a robust defence against firmware tampering, malware injection, and unauthorised software updates. With AIS-189 now in force for new vehicle types, UNECE R155 mandatory across 54 signatory countries, and automotive cyber incidents rising 39% year-on-year, the cost of not implementing these mechanisms goes beyond engineering risk; it is a regulatory, commercial, and safety liability. In the era of software-defined vehicles, securing firmware is the first line of defence in protecting the entire vehicle ecosystem.