Automotive Cybersecurity Solutions for Electric Vehicles

In 2024, the automotive and smart mobility sector recorded 409 cybersecurity incidents, a 39% increase from 2023, with 60% of attacks affecting thousands to millions of vehicles, charging stations, and connected mobility assets simultaneously (Upstream Security, 2025). Incidents affecting millions of vehicles more than tripled in a single year, rising from 5% to 19% of all cases. Software-defined architectures driving EV innovation are the same architectures cybercriminals are learning to exploit at scale. 

The EV Attack Surface is larger than it appears 

A modern EV is a network of 70 to 100 ECUs exchanging data continuously over CAN, LIN, Automotive Ethernet, and FlexRay, connected simultaneously to cloud platforms, telematics servers, charging infrastructure, mobile applications, and OTA update pipelines. Every one of these interfaces is a potential attack vector. In 2025, researchers demonstrated firmware injection into Subaru's Starlink OTA system using weak encryption, capable of disabling collision-avoidance systems across the fleet. At Pwn2Own Automotive 2025, participants exploited zero-day vulnerabilities in EV charging ECUs to induce conditions risking battery thermal runaway, and compromised gateway ECUs to achieve full vehicle control. 

These are not edge cases. They are early indicators of what happens when software complexity scales faster than security architecture. The key attack surfaces in EV platforms are: 

• OTA update pipelines: unauthenticated or weakly encrypted update channels allow firmware injection without physical access 

• ECU networks and gateway ECUs: a compromised ECU can propagate malicious commands across the vehicle's entire network if lateral movement is not blocked by access controls 

• Diagnostic interfaces: improperly secured UDS sessions or unlocked security access can allow unauthorised flashing or data exfiltration at the workshop or in the field 

• Telematics and cloud APIs: API-related attacks increased by nearly 30% in 2024, accounting for 17% of all automotive incidents, driven partly by AI-assisted API documentation exploitation 

• Charging infrastructure: charger firmware vulnerabilities enable lateral movement from charging networks directly into connected vehicle systems, as demonstrated at Pwn2Own 2025 

V2X and Charging Infrastructure: The Expanding Attack Surface 

Vehicle-to-Everything (V2X) communication and EV charging infrastructure have become primary targets. At Pwn2Own Automotive 2025, participants exploited zero-day flaws in EV charging ECUs to compromise connected vehicle networks, demonstrating that a charging station is not just a power delivery device; it is a network-connected entry point into the vehicle. India's rapid charging infrastructure expansion, with 83 Charge Point Operators running variable software standards and no mandatory communication security requirements, amplifies this risk significantly. 

Three specific vulnerabilities define this attack surface: 

• OCPP protocol weaknesses: the Open Charge Point Protocol governs charger-to-network communication and has known authentication gaps that allow rogue charger injection and session hijacking across charging networks 

• ISO 15118 plug-and-charge certificate exchange: while ISO 15118 provides a strong cryptographic framework for authenticated charging sessions, improperly implemented certificate management creates a viable attack path from the charging network into vehicle ECUs 

• V2G bidirectional communication: as vehicle-to-grid capability scales under India's BESS and smart charging programmes, the bidirectional energy and data channel between vehicle and grid becomes a new lateral movement path that must be hardened at both the ECU firmware and communication protocol levels 

ElectRay's ZEVonUDS Stack and eConnectX Connected Vehicle Platform support secure diagnostic and communication coverage for On-Board Charger (OBC) and charge port controller ECUs, providing the vehicle-side security foundation that charging infrastructure interoperability requires. 

The Regulatory Framework: From Compliance to Engineering Requirement 

Cybersecurity is now embedded in type approval requirements globally. UNECE WP.29 Regulation R155, mandatory for all new vehicles in the EU since July 2024, requires OEMs to establish certified Cybersecurity Management Systems (CSMS) covering the entire vehicle lifecycle from design through decommissioning. R156 separately mandates secure Software Update Management Systems (SUMS). Together they represent the most comprehensive vehicle cybersecurity framework ever enforced at scale. 

India's AIS-189, effective for new vehicle types from October 2025, mirrors R155 and is aligned with ISO/SAE 21434. AIS-190 mandates secure OTA with authenticated delivery, anti-rollback protection, and ECU version traceability for up to 10 years. Non-compliance results in type approval denial. Indian OEMs with export ambitions must simultaneously meet UNECE R155. 

ISO/SAE 21434 defines the engineering process standard underpinning both frameworks. Its core methodology, Threat Analysis and Risk Assessment (TARA), requires systematic identification of attack paths, threat scenarios, and risk levels for every connected ECU and interface in the vehicle. TARA is not a one-time exercise; it must be maintained and updated as the vehicle's software evolves post-production. ISO 26262 functional safety requirements run in parallel, since cybersecurity failures in EV powertrains, BMS systems, or ADAS functions can translate directly into physical safety risks. 

ElectRay's Cybersecurity and Functional Safety engineering services provide end-to-end TARA, CSMS development, ISO/SAE 21434 alignment, ISO 26262 Automotive Safety Integrity Level (ASIL) decomposition, and homologation documentation for ARAI and ICAT submission. 

Cybersecurity Architecture for EV Platforms 

Secure Boot and Secure Flash 

Every ECU security posture begins at boot. Secure Boot uses a Hardware Security Module (HSM) as the hardware root of trust, performing cryptographic verification of the bootloader and firmware before any code executes. If verification fails, the ECU enters a safe state rather than booting compromised software. Secure Flash extends this to the update process: firmware is OEM-signed via a backend HSM, ECU-verified before any write, delivered via a RAM-resident flash driver with no persistent write-access path, and protected by A/B partition management. Anti-rollback counters in protected Non-Volatile Memory (NVM) prevent downgrade to vulnerable versions. 

ElectRay's Secure Flash Bootloader delivers production-grade secure boot, A/B image management, HSM-backed signature verification, and UDS Security Access (0x27) integration, aligned with AIS-189, AIS-190, and UNECE R156. 

Intrusion Detection Systems 

Automotive Intrusion Detection Systems (IDS) monitor in-vehicle networks in real time for anomalous communication patterns, unexpected ECU message sequences, and deviations from established network baselines. At the ECU level, IDS monitors CAN bus traffic for malformed or unexpected message IDs. At the vehicle level, gateway IDS enforces network segmentation and flags lateral movement attempts. At the fleet level, cloud-based IDS aggregates telemetry across the deployed fleet, enabling OEMs to detect coordinated attacks before they propagate. 

ElectRay's Connected Vehicle Platform integrates remote diagnostics, real-time fleet telemetry, and anomaly monitoring to support fleet-level cybersecurity visibility for EV OEMs and operators. 

Secure OTA and Diagnostic Hardening 

OTA update security and diagnostic hardening are two sides of the same attack surface. Secure OTA requires authenticated firmware delivery, certificate-based server verification, encrypted transfer, and rollback-safe partition management. Diagnostic hardening requires UDS Security Access (0x27) with HSM-executed seed-key generation, session lockout mechanisms against brute-force attacks, and access tier separation ensuring field service tools cannot access OEM backend programming privileges. 

ElectRay's FOTA Solution, UDS Stack, and ZEVonUDS Stack provide authenticated OTA delivery and hardened diagnostic session management aligned with AIS-189 and ISO/SAE 21434 requirements. 

The Next Cybersecurity Frontier in EVs 

The threat landscape is evolving faster than current regulation anticipates. Three developments are shaping the next phase of automotive cybersecurity: 

• AI-powered attacks: threat actors are using generative AI to map API vulnerabilities and automate exploit development, compressing the gap between vulnerability discovery and weaponisation from weeks to hours 

• Zero-trust vehicle architectures: every ECU and service request must be authenticated before execution, eliminating the implicit trust that current in-vehicle network architectures rely on 

• SBOM and lifecycle monitoring: AIS-189 mandates post-production incident response throughout the vehicle's operational life; SBOM enables OEMs to identify affected ECUs when a Common Vulnerabilities and Exposures (CVE) entry is disclosed and deploy targeted patches via authenticated FOTA before it is exploited 

Supply Chain Security: The Hidden Vulnerability 

Over 76% of dark web threat activities targeting the automotive sector in 2024 were directed at multiple stakeholders simultaneously (Upstream Security, 2025), indicating coordinated supply-chain-level targeting rather than individual OEM attacks. An EV platform's security posture is only as strong as the weakest software component in its stack. Third-party AUTOSAR middleware, open-source communication libraries, and supplier-provided ECU software each carry their own CVE exposure. An OEM shipping a vehicle with an unpatched third-party component inherits that vulnerability across its entire deployed fleet. 

AIS-189 explicitly requires OEMs to manage cybersecurity obligations through the supply chain, not just within their own organisation. Software Bill of Materials (SBOM) tracking is the operational mechanism for this: it enables OEMs to identify precisely which ECUs and vehicle variants contain a specific software component when a new CVE entry is disclosed, and to deploy targeted patches through authenticated FOTA pipelines before threat actors can exploit the gap. 

Conclusion 

Automotive cybersecurity is not a feature that can be added after development. It is a foundational engineering discipline that must be embedded at architecture level, validated through TARA, implemented in hardware through HSMs and secure boot chains, enforced through OTA and diagnostic hardening, and maintained through the vehicle's entire operational lifecycle. With 409 incidents in 2024 and massive-scale attacks tripling in a single year, reactive cybersecurity in EVs is simultaneously a safety liability, a regulatory liability, and a commercial liability. OEMs that build security by design will not just pass type approval; they will define the trust standard the next generation of connected EVs is measured against.