ISO 21434·UN R155 Require Secure Boot, HRoT, HSM, TEE, PUF and More

Addressing Vulnerable CAN Bus and Other Issues, Higher-Level Security Mechanisms Based on CAN FD are Important

Modern vehicles can contain approximately 100 million lines of code, demonstrating the increasing software complexity of connected and automated vehicle systems. The perception that vehicles are simply manufactured as metal machines that travel on roads has long become outdated. As the proportion of software in the automotive field has grown, the attack surface of modern vehicles has expanded, and connected vehicle platforms are increasingly becoming targets of cyber threat actors.

However, software is no longer the only attack target for cybercriminals. Now, automotive hardware systems also require cybersecurity. Hardware-level attacks such as laser fault injection (LFI) are receiving increasing attention. In LFI attacks, precisely targeted laser pulses are used to induce defects within semiconductor devices, which can cause instructions to be skipped, authentication to be bypassed, or other unintended operations to occur. Such attacks may appear unlikely until they actually occur.

This article examines why automotive cybersecurity must encompass not only software but also hardware components.

■ Understanding the Expanding Attack Surface of Modern Vehicles

To understand why cybersecurity must encompass both software and hardware, it helps to examine how the automotive industry has changed over the past decade.

As automotive technology has advanced, the number of Electronic Control Units (ECUs) has increased dramatically, and each ECU contains complex code and circuitry. Today, vehicles commonly feature Advanced Driver Assistance Systems (ADAS), a broad category of technology that includes lane keeping, automatic emergency braking, adaptive cruise control, and other cognitive and control functions. Alongside this, vehicle connectivity has increased, and vehicles are now receiving real-time traffic information and messages. One of the operating principles of smart cities is that connected vehicles must cooperate with each other for smooth traffic flow. Any of these systems could become targets of cyberattacks.

As vehicle architecture evolves toward more centralized and zone-based designs, the importance of principles such as segmentation, isolation, and controlled communication paths has grown. While this approach simplifies cybersecurity implementation, if a breach is successful, the consequences can be more severe.

Threat actors can also conduct attacks by exploiting communication protocols. In 2025, researchers disclosed a zero-click wireless CarPlay attack chain that could exploit vulnerabilities in the Bluetooth pairing and iAP2 session setup processes to access a vulnerable AirPlay Software Development Kit (SDK) path via Wi-Fi and compromise affected infotainment systems. In 2015, two researchers demonstrated how easily a Jeep's infotainment system could be taken over and ultimately showed that core functions such as steering and braking could be controlled. Vehicles use Over-The-Air (OTA) software updates, Vehicle-to-Vehicle (V2V) communication, and Bluetooth, cellular, and Wi-Fi connectivity. This variety of connectivity methods requires more strengthened access control to ensure security.

Against this background, industry standards and regulatory frameworks such as International Organization for Standardization (ISO) 21434, United Nations Economic Commission for Europe (UNECE) World Forum for Harmonization of Vehicle Regulations (WP.29), and United Nations Regulation 155 (UN R155) reflect the need for stronger and standardized automotive cybersecurity. However, these regulations are not limited to simply strengthening software. Hardware must also support the integrity of secure boot and provide tampering prevention capabilities.

■ Protecting Automotive Systems at the Hardware Layer

Manufacturers must use a multifaceted approach to protect both the hardware and software components of vehicles.

One of several methods used in hardware security is Hardware Root of Trust (HRoT). HRoT provides secure boot, verifies the integrity of foundational firmware, and stores sensitive cryptographic keys. A Hardware Security Module (HSM) is a dedicated cryptographic coprocessor embedded in electronic components that can generate and store keys and provide secure authentication capabilities. These modules isolate key storage and cryptographic operations from the main application processing environment, reducing the possibility of sensitive information exposure and strengthening the overall security architecture.

Other methods physically separate data processing areas to enhance security. For example, a Trusted Execution Environment (TEE) is an isolated processing environment within the main processor where core functions are safely protected in areas inaccessible to most common operations. In data classification approaches, data is grouped according to sensitivity level. Similarly, network segmentation divides data into groups with different security controls applied.

Another method, Physical Unclonable Functions (PUFs), leverages unique microscopic differences that occur during the manufacturing process of electronic components, enabling communication that verifies these differences. For example, when a specific input voltage is applied to hardware, the semiconductor chip responds in a unique manner due to microscopic differences. Responses different from this can be identified as abnormal.

Automotive cybersecurity also focuses on protecting in-vehicle networking. The Controller Area Network (CAN) bus, a traditional communication method within vehicle systems, allows hundreds of microcontrollers to communicate with each other without a central computer. However, this system is known to be vulnerable from a security perspective because any node connected to the bus can send messages to all other nodes, and all nodes are inherently trusted by default.

New methods such as Controller Area Network Flexible Data-Rate (CAN FD) support higher data transmission rates and larger payloads than conventional CAN. While CAN FD itself does not inherently provide encryption or authentication capabilities, its extended payload and bandwidth can support higher-layer security mechanisms.

■ Accelerating Toward the Future

As vehicles increasingly transition to software-defined architectures and connectivity increases, effective automotive cybersecurity will increasingly depend on the way hardware-enabled security mechanisms such as secure boot, TEE, and protected in-vehicle communication architecture work together with software controls and regulatory compliance frameworks.

※ About the Author

Poornima Apte is an engineer-turned-writer specializing in B2B content in robotics, AI, cybersecurity, smart technology, and digital transformation. She can be found on Twitter at @booksnfreshair.