Modern vehicles are becoming software-defined systems, and a recent Autocar Professional discussion argues that their security work must begin below the application layer. Experts from Infineon Technologies and Vector Informatik focused on the chip, the electronic control unit and the vehicle architecture rather than treating cybersecurity as a final software patch. That matters because a connected car can carry several communication paths and safety-critical functions at the same time.

The discussion appeared in the second episode of Autocar Professional’s Cybersecurity Dialogues. Girish Kamala of Infineon Technologies and Divyakanth M C of Vector Informatik described a layered approach that starts with the semiconductor and extends through software, networks and the complete vehicle. The program does not announce a new vehicle or a single product for consumers. It explains why security design is becoming part of the basic engineering brief for connected vehicles.

Infineon’s automotive cybersecurity material provides the hardware context. The company lists microcontrollers with embedded Hardware Security Modules, secure NOR flash and trusted-platform components among its security portfolio. Its AURIX documentation describes protected key storage, cryptographic acceleration and secure boot functions. These tools are intended to create a hardware-rooted trust boundary for vehicle systems, not to replace every software security control.

Vector’s MICROSAR HSM documentation shows how the software side connects to that hardware. The firmware provides cryptographic services, protected key storage and secure boot on microcontrollers with a secure core. Vector says the HSM can also support secure onboard communication and secure software updates. In practical terms, the design lets an electronic control unit verify software and protect keys without asking the main application processor to perform every security task.

Secure boot is important because a vehicle needs to know what software is starting before that software controls a function. A signature check at startup can help detect an altered or unauthorised image. It does not prove that the application is bug-free, and it does not stop every attack after the system has booted. It is one control in a broader chain that includes updates, monitoring, access management and testing.

The experts also pointed to the problem of protecting one interface while leaving another exposed. Connected cars can include Bluetooth, Wi-Fi, mobile links, USB ports, keyless systems, telematics and several in-vehicle networks. A single weak entry point can create work for the rest of the architecture. That is why the discussion framed security as an end-to-end vehicle responsibility rather than a feature attached to infotainment.

This approach is especially relevant as manufacturers add over-the-air updates and more centralised computing. An update can improve a vehicle long after it leaves the factory, but the process must authenticate the software and protect the signing keys. Secure communication also has to preserve message integrity between electronic control units. The exact implementation will vary by platform, supplier and vehicle program.

Standards are part of the engineering process as well. Infineon and Vector both reference ISO or SAE 21434 in their automotive security material, while Vector also discusses alignment with UNECE vehicle cybersecurity requirements. Compliance does not automatically make a vehicle safe, but it creates a structured way to identify risks, set security goals and validate controls across the product life cycle. That work continues after launch because connected systems change over time.

For drivers, chip-level security is not a visible dashboard feature. Its value appears when a vehicle accepts a legitimate update, rejects unauthorised code or keeps sensitive keys away from ordinary application software. The hardware also has to work within limits on cost, power, heat and real-time response. Security engineering is therefore a design trade-off, not a single switch that can be added near the end of production.

The Autocar Professional discussion points to a broader shift in vehicle development. As cars gain more software and connectivity, manufacturers and suppliers need to treat trust as an architectural property that starts in silicon and continues through code and operations. Infineon and Vector document technologies that support that model, but each vehicle program still needs its own threat analysis and validation. The central message is straightforward: protecting a software-defined car begins before the first line of application code runs.