Automotive cyber security – behind the scenes.

A few decades ago, securing a car meant a sturdy lock and an alarm. Today, it means defending a rolling, always-connected computing platform – equipped with dozens of Electronic Control Units (ECUs), multiple in-vehicle networks, and high-speed links to the cloud.

In this new landscape, the High Performance Computer (HPC) is becoming the vehicle’s “brain” – orchestrating domains such as powertrain, infotainment, ADAS, and charging. In practice, it’s a data centre on wheels. The more performance, connectivity, and integration it has, the greater the cybersecurity challenges.

Where the security challenges start

System complexity

Modern vehicles blend multiple technology stacks – Linux for infotainment, Android Automotive for user experience, AUTOSAR Classic/Adaptive for safety-critical domains – all interconnected via networks like CAN, Ethernet, and LIN. Each stack has its own vulnerabilities, patch cycles, and dependencies. The result? A huge attack surface, with complexity amplified by zonal architectures and remote connectivity (Wi-Fi, Bluetooth, 5G, V2X).

External libraries and dependencies

Many vehicle features rely on third-party libraries or open-source software. These speed up development but can introduce vulnerabilities outside the OEM’s direct control. If a supplier delays a patch, the risk remains in the system until mitigated.

Regulatory requirements

For engineers and architects, compliance is not just paperwork – it’s a design constraint.

• UNECE R155 mandates a Cybersecurity Management System (CSMS), covering the entire lifecycle: from concept and design to post-production monitoring and decommissioning.
• UNECE R156 requires a Software Update Management System (SUMS) to securely deliver and verify updates over a vehicle’s lifespan.
• ISO/SAE 21434 translates these into engineering practices – from Threat Analysis and Risk Assessment (TARA) to incident response planning.
• ISO 24089 adds requirements for secure OTA update processes.
• FIPS 140 defines cryptographic module security requirements, crucial for hardware and software crypto in vehicles.
• Radio Equipment Directive (RED, EN 18031-1/2) imposes additional requirements for wireless-capable devices, mandating robust cybersecurity and resilience against network attacks.

The real challenge is embedding these into architectures that already juggle safety, performance, and cost targets – all under tight market deadlines. Non-compliance? The vehicle can’t be sold in many key regions.

Cybersecurity vs. ASPICE and development deadlines

Integrating security into established ASPICE-based development processes can be a challenging task. Cybersecurity tasks — such as code audits, threat modelling, and secure configuration checks – often add work that isn’t visible to end customers but is critical to system security and safety. Balancing these invisible tasks with delivery deadlines is a constant tension.

 Invisible work problem

Security engineering rarely produces visible “features” for customers. Implementing secure boot, encrypting data at rest, or hardening an OTA pipeline takes significant time but doesn’t change how the car looks or drives. This can make it harder to justify resources internally – even though these measures are essential for protecting the brand and the user.

What hackers do – common attacks on vehicles

Attacks can target internal networks, external interfaces, hardware, or backend infrastructure. Real-world examples include:

• CAN bus injection – exploiting lack of authentication to send malicious frames (DoS floods, fuzzed messages, impersonation, or Bus-off attacks).
• ECU reprogramming – flashing modified firmware to bypass controls or add backdoors.
• Sensor data spoofing – feeding false GPS, radar, or camera data to mislead ADAS/autonomous systems.
• Keyless entry relay attacks – extending fob communication range to unlock/start without the key.
• Wireless exploits – attacking Wi-Fi, Bluetooth, 5G, or V2V/V2I channels to pivot into critical systems.
• OTA update compromise – injecting malicious code or exploiting weak rollback protection.
• Backend breaches – compromising OEM or supplier servers to distribute malicious updates or manipulate telematics data.
• Hardware attacks – side-channel attacks on chips, fault injection, or physical tampering to extract keys or bypass security features.
• Supply chain compromise – introducing counterfeit chips, backdoored components, or malicious firmware during manufacturing or logistics.

These can be carried out by opportunistic thieves, organised cybercriminal groups, hacktivists, or state-sponsored actors – each with different capabilities and goals.

Day-to-day in automotive cybersecurity

Automotive cybersecurity is a constant cycle of anticipating threats, building defences, and responding to incidents. It starts with TARA to identify where the highest risks are, from infotainment systems to safety-critical controls, guiding design priorities. Engineers then implement measures such as:

• Secure boot – only trusted, signed code can run on ECUs/HPCs.
• Secure diagnostics – access to sensitive functions is restricted to authenticated tools.
• Secured communications – TLS, Secure Onboard Communication (SecOC), and strong key management.
• Secure OTA updates – digitally signed, encrypted, rollback-protected.
• Physical hardening – disabled debug ports, encrypted firmware.

Security is validated through penetration tests, fuzzing, audits, and code reviews, all aligned with ISO/SAE 21434 and regulatory requirements. Increasingly, vulnerability scanning and management tools are integrated into the CI/CD pipeline, automatically scanning each build and feeding fixes into the development backlog – ensuring that known issues are addressed before they can be exploited.

After production (SOP), continuous monitoring via Intrusion Detection and Prevention Systems (IDPS) and Security Operation Centres (SOC) helps detect anomalies in real-time, ensuring readiness for the worst-case scenario.

Core security principles

• Defence in depth – hardware + software + processes + supply chain controls.
• Security by design – integrate security from the concept phase.
• Regular updates – because vehicle lifecycles outlast many software vulnerabilities.
• Continuous monitoring – detect and respond before an incident escalates.

Final thoughts

Automotive cybersecurity is not a “feature” – it’s a continuous, evolving discipline that spans the full vehicle lifecycle: concept, development, production, operation, and decommissioning. It requires coordinated effort across OEMs, suppliers, regulators, and cybersecurity experts.

The vehicles of the future will be more connected, autonomous, and software-defined than ever before. Without robust, embedded security, they’ll also be more vulnerable. Getting it right isn’t just about compliance – it’s about safety, trust, and brand survival in the next era of mobility.

Sources:

• https://www.researchgate.net/publication/382736828_Automotive_Cybersecurity_Challenges_A_Practitioner’s_Guide
• http://www.diagnostyka.net.pl/Author-Piotr-Pe%C5%82echaty/284817

Karolina Olchawa

Cybersecurity and Cryptography Engineer

From the very beginning of my career, I have been involved with embedded systems, with a specialisation in automotive cybersecurity. I currently work at Endego as a Cryptography and Cybersecurity Developer, implementing security solutions for modern vehicles. Beyond my professional work, I pursue my passion for education – I conduct training in automotive diagnostics and cybersecurity, and I co-organise NextGenIT, an initiative that inspires young people to explore the world of technology.