EV-35 — Cybersecurity

ASSUMPTION — This lesson introduces the vehicle cybersecurity framework at a conceptual level, with no vendor-specific implementation detail, key lengths, or protocol version numbers claimed as current. Deep BMS-specific content is in BMS Academy → BMS-18.

1. Why a Connected, Software-Defined EV Needs Cybersecurity Engineering

A modern EV is, in a very real sense, a network of computers that happens to also be a vehicle: dozens of electronic control units communicate over internal networks, receive software updates over the air, and exchange data with charging infrastructure and backend services. Every one of those connection points is also a potential entry point for an attacker, and unlike a laptop that can simply be disconnected from the internet when compromised, a vehicle’s controllers are wired directly into systems that affect propulsion, braking, and steering. ISO/SAE 21434 exists to bring the same systematic rigor to this problem that ISO 26262 brings to functional safety: identify threats methodically, assess their risk, and build requirements and verification around that risk rather than reacting to incidents after the fact.

FACT — ISO/SAE 21434 covers the full vehicle lifecycle — concept, development, production, operation, and decommissioning — because a vehicle that ships secure but is never patched again is not actually secure for its 10–15+ year service life.

2. The Chain of Trust: Secure Boot, Secure Flashing, and OTA

The core cybersecurity mechanisms in a vehicle exist to answer one recurring question: how does a controller know the software it is about to run is the software it is supposed to run, and not something an attacker substituted? Secure boot answers this at power-up: each stage of the boot process cryptographically verifies the signature of the next stage before executing it, so that only software signed by a trusted authority can ever run, forming an unbroken chain from a hardware root of trust up to the application software. Secure flashing extends the same idea to updates performed at a service center or factory: a new software image is accepted only if its signature validates against the expected authority, preventing an attacker (or even an unauthorized workshop) from loading modified firmware. OTA (over-the-air) security applies this again to wireless updates, adding transport-level protections — the update package must be both authentic (signed by the right party) and confidential/integrity-protected in transit — because an update channel that reaches every vehicle in a fleet simultaneously is an extremely attractive target if it can be subverted.

FACT — These three mechanisms form one continuous chain, not three separate features: a vehicle with perfect secure boot but weak OTA validation is still vulnerable, because an attacker can simply deliver malicious “signed-looking” software through the weaker channel instead of tampering with the boot process directly.

3. Key Management and Authentication

None of the mechanisms above work without a trustworthy way to create, distribute, store, and eventually revoke cryptographic keys — this is the job of key management. Keys used to sign vehicle software must be protected in hardware security modules that make extraction practically infeasible, because a leaked signing key would let an attacker produce software that every vehicle in the fleet would accept as genuine. Authentication mechanisms similarly govern which internal or external parties are allowed to communicate with which controllers, so that, for example, a diagnostic tool can only unlock the specific functions it is authorized for, rather than gaining unrestricted access to every ECU on the network.

4. Attack Surfaces

A vehicle’s attack surface is the sum of every point where an external actor could potentially inject data or commands, and mapping it out systematically is the first step of any threat assessment:

Attack surface	Why it exists
CAN / CAN FD network	Internal ECU communication; historically designed for reliability, not authentication
Diagnostics (OBD/UDS)	A standardized, physically accessible port intended for legitimate service access
Telematics (TCU)	The vehicle’s cellular/connectivity gateway to the outside world
Charging (EVSE communication)	Vehicle-to-charger communication defined by ISO 15118, including bidirectional (V2G) data exchange
OTA channel	The path by which new software reaches the vehicle remotely

FACT — During charging, the vehicle exchanges data with the charging station over a defined protocol (ISO 15118), which means this interface is also a legitimate attack surface and is addressed within that standard’s security provisions, not left unmanaged.

5. Defense in Depth

No single mechanism above is assumed to be unbreakable, and that assumption is itself a core design principle: defense in depth means the architecture is built so that compromising one layer does not automatically compromise the whole vehicle. A gateway ECU segments the vehicle network into zones (for example, separating the infotainment network, which handles less-trusted external content, from the powertrain network, which controls propulsion), so a successful attack against infotainment does not have a direct path to torque control. This segmentation mirrors, at the network level, the same layered thinking a well-designed building uses for physical security — an intruder getting past the front door should not automatically have access to the vault.

6. FAQ

Why does an EV specifically need cybersecurity, beyond what any modern car needs?

FACT — EVs typically add OTA software updates, richer telematics connectivity, and standardized bidirectional charging communication (ISO 15118, including V2G) as core features rather than options, which meaningfully expands the connected attack surface compared with many older, less-connected vehicle architectures.

What does secure boot actually prevent?

FACT — It prevents any software that is not signed by a trusted authority from executing on the controller, which blocks a large class of attacks that rely on installing modified or malicious firmware.

Is a single strong mechanism, like a very robust firewall on the gateway, enough on its own?

INTERPRETATION — No — defense-in-depth assumes any single layer can eventually be bypassed, so a gateway firewall is one layer among several (secure boot, secure flashing, OTA validation, network segmentation, key management), not a substitute for the others.

7. Summary

• ISO/SAE 21434 standardizes cybersecurity engineering across the vehicle’s full lifecycle, mirroring the systematic-risk approach ISO 26262 applies to functional safety.
• Secure boot, secure flashing, and OTA security together form one continuous chain of trust; weakening any link undermines the whole chain.
• Key management and authentication control who and what is trusted to sign software or talk to which controllers.
• CAN, diagnostics, telematics, charging communication, and the OTA channel are the vehicle’s main attack surfaces.
• Defense-in-depth, especially network segmentation via the gateway, limits how far a single successful attack can spread.

8. Sources and Verification Note

Standards referenced are ISO/SAE 21434 and ISO 15118; no vendor-specific implementation detail or protocol version is claimed as current.

• ISO/SAE 21434 — Road vehicles, cybersecurity engineering.
• ISO 15118 — Vehicle-to-grid communication interface.

ASSUMPTION — Source versions/titles may change; every source must be re-verified before publication.

Next Lesson

• EV-36 — Homologation / Regulations: UNECE, FMVSS, and type approval.