LHP Blog and Technical Articles

What does ISO/SAE 21434 mean for electrification powertrain programs?

Written by Marty Muse | May 18, 2026 8:22:03 PM

What does ISO/SAE 21434 mean for electrification powertrain programs?

Key takeaways

  • EV charging-protocol cybersecurity is the attack surface most electrification powertrain programs are under-managing in 2026. ISO/SAE 21434 puts the charging interface squarely inside the vehicle's Cybersecurity Management System (CSMS) scope.
  • The ISO 15118 plug-and-charge handshake, the Open Charge Point Protocol (OCPP) backend connection, and the vehicle-to-grid (V2G) high-voltage control path are three distinct surfaces. Each requires its own Threat Analysis and Risk Assessment (TARA) outputs.
  • UN Regulation 155 (UN R155) ties the CSMS to type approval. The charging interface evidence that satisfies an ISO 21434 audit is also the evidence that closes the UN R155 type-approval gate; programs that build it once carry it forward.
  • The most common audit finding LHP sees on EV cyber programs is a TARA that scopes the powertrain ECU but stops at the charging-port connector, leaving the charge-handshake state machine and the backend communications path unaddressed.
  • The retrofit cost rises sharply after the Start of Production (SOP). The defensible posture is to make the charging interface a TARA scope item at concept, not after the first penetration test report lands.

The first generation of EV programs treated the charging port as a power connection. The second generation treated it as a communications port. The third generation, which most Tier-1 suppliers are now delivering against, has to treat it as a cybersecurity attack surface bound by ISO/SAE 21434 and UN R155. The shift is not theoretical. The plug-and-charge handshake is a bidirectional, authenticated, certificate-exchanging protocol that gates high-voltage delivery into the battery management system (BMS). It is exactly the kind of surface an ISO 21434 Threat Analysis and Risk Assessment (TARA) is built to scope.

Most EV powertrain programs LHP has audited in the last 18 months scope the cybersecurity case to the powertrain electronic control unit (ECU) and stop at the charging port connector. That is a defensible architecture for analog interfaces. It is no longer a defensible scope under ISO 21434 once the interface speaks ISO 15118.

Why does this matter now?

ISO/SAE 21434:2021 (Road vehicles: Cybersecurity engineering) became the global reference standard for automotive cybersecurity in 2021. UN R155 has been applied to new vehicle types in contracting parties since July 2022 and to all new vehicles produced since July 2024, requiring a certified Cybersecurity Management System (CSMS) as a precondition for type approval. The two work in tandem. ISO 21434 is the engineering standard; UN R155 is the regulatory hook that makes the standard non-optional in regulated markets.

The EV-specific consequence is that the charging interface is no longer a passive port. ISO 15118 (the international standard for vehicle-to-grid communication, particularly the plug-and-charge feature) defines an authenticated handshake between the vehicle and the charging station that exchanges X.509 certificates, validates the contract identifier of the driver, and negotiates the power schedule. Each of those steps is a TARA scope item under ISO 21434. The Open Charge Point Protocol (OCPP) governs the backend communication between the charging station and the charging network operator; that path is the lateral movement route a sophisticated attacker would use after a station compromise. V2G adds a high-voltage control path back into the battery, which means the cybersecurity case now overlaps with the functional safety case at the BMS boundary.

The convergence of these standards is changing what an EV powertrain program is responsible for. Programs that treated the charging surface as a future-state problem in 2023 are now finding it in pre-launch audit findings.

What attack surfaces does EV charging actually expose?

Three distinct surfaces, each governed by a different protocol layer, each requiring its own TARA threat scenarios under ISO 21434.

The plug-and-charge handshake (ISO 15118). A certificate-authenticated session between the vehicle's communication controller and the charging station's communication controller. Threat scenarios include certificate spoofing, replay attacks against the contract identifier exchange, and downgrade attacks that force the session to fall back from authenticated plug-and-charge to less protected external identification means (such as RFID card readers). The mitigations are standard PKI hygiene at the vehicle side (certificate validation, revocation list checking, secure storage of private keys in a hardware security module or HSM) and the same at the charging-station side.

The backend connection (OCPP). A WebSocket-based protocol that the charging station uses to communicate with its operator's backend, typically over TLS. Threat scenarios include compromise of the charging station's TLS certificates, man-in-the-middle attacks against the OCPP message bus, and lateral movement from a compromised station into the operator's central system. From the EV's perspective, this is an upstream risk, not a direct vehicle attack surface. From the OEM's perspective, the operator's compromise can result in unauthorized billing, denial of charging, or, in extreme cases, coordinated charge-rate manipulation across a fleet.

The V2G high-voltage control path. When the vehicle is configured to deliver power back to the grid or to a home backup system, the charging interface becomes a bidirectional power path. The TARA threat scenarios here cross into the functional safety case: a successful attacker who can manipulate the charge/discharge command path may be able to over-discharge the battery, force a thermal runaway scenario, or coordinate a fleet-wide grid attack. ISO 26262 hazard analysis and risk assessment (HARA) outputs typically did not cover bidirectional power delivery; programs adding V2G capability mid-cycle need to revisit HARA in parallel with TARA.

The three surfaces do not share threat scenarios. A program that treats charging cybersecurity as a single line item in the TARA underestimates the scope.

How does ISO/SAE 21434 actually require these surfaces to be managed?

ISO 21434 defines a cybersecurity lifecycle running concept, product development, production, operations, maintenance, and end-of-life. The standard requires a TARA as the central artifact at the concept phase and again whenever the item's threat model changes substantively. For the EV charging interface, that means TARA outputs at three points minimum: at item definition (which charging protocols the vehicle supports, in which markets), at architecture definition (which ECU implements each protocol, what trust boundaries exist between them), and at any post-launch change that adds a new protocol or new backend partner.

The clause-level requirements that bite hardest on EV charging programs:

Clause 9.3 (Item definition) requires the operational environment to be defined. For a vehicle with ISO 15118 plug-and-charge, the operational environment includes the charging network's PKI infrastructure, which the vehicle does not control. The item definition must name the trust anchors and the certificate validation policy.

Clauses 9.4 and 9.5 (Cybersecurity goals and concept) require threat scenarios at the item level, with damage scenarios traced to vehicle-level consequences. For V2G, the consequences include functional safety consequences (battery damage, thermal event), not only confidentiality and integrity consequences. The cybersecurity goals must reference the ISO 26262 safety goals where they overlap.

Clause 11 (Continuous activities) requires vulnerability management across the lifecycle. For a vehicle that will be in service for 12 to 15 years, the charging protocol stack will see protocol updates, PKI rotations, and new vulnerabilities disclosed across the certificate authority ecosystem. The CSMS must describe how those events become product updates.

The most common audit finding LHP sees on EV cyber programs is item-definition scope drift: the TARA covers what was true at concept, the architecture has since added a backend partner or a new protocol, and the TARA has not been updated. Continuous activities are the clause that closes that gap.

How LHP approaches EV charging cybersecurity

LHP runs electrification cybersecurity engagements inside the same ISO 21434 lifecycle discipline applied across LHP automotive cybersecurity work, with three EV-specific patterns. First, the charging interface is its own item in the TARA, with the three surfaces (handshake, backend, V2G) decomposed explicitly. Second, the BMS boundary is treated as the cybersecurity-functional safety convergence point, with cross-references between the cybersecurity case and the ISO 26262 safety case at every shared sub-claim. Third, the operational environment definition names the charging-network PKI partners and the trust anchors explicitly, with a documented refresh procedure for certificate authority changes over the vehicle's service life.

For programs already in flight, LHP runs a focused TARA audit on the charging interface specifically, identifies the scope gaps against the ISO 21434 clauses above, and returns a prioritized remediation roadmap before the next UN R155 type-approval window. The methodology is tool-agnostic and integrates with existing cybersecurity case management environments.

What this means for your next program

If your next program is an EV with ISO 15118 plug-and-charge, an OCPP-connected charging station network, or V2G capability, the charging interface is no longer a future-state cybersecurity item. It is in scope for the TARA at concept, in scope for the CSMS for the life of the vehicle, and in scope for UN R155 type approval.

The concrete step worth taking this quarter: pull your most recent TARA and check whether the three surfaces (ISO 15118 handshake, OCPP backend, V2G high-voltage control) each have their own threat scenarios and damage paths. If two of the three are missing or sized as a single line, the gap is the size of the policy and engineering work you need to add before the next CSMS audit.

Frequently asked questions

What is the difference between ISO 21434 and UN R155 for EV charging?

ISO/SAE 21434:2021 is the engineering standard that defines how to do automotive cybersecurity across the lifecycle. UN Regulation 155 is the type-approval regulation in force across UNECE member states that requires a certified Cybersecurity Management System (CSMS) as a precondition for vehicle approval. ISO 21434 is what the engineering team executes; UN R155 is what the regulatory team submits. For EV charging, the same TARA outputs and CSMS evidence satisfy both demands when the engineering work is done to the ISO 21434 standard from the start.

Does ISO 15118 plug-and-charge require a hardware security module (HSM) in the vehicle?

ISO 15118 requires certificate-authenticated communication and secure handling of private keys, with ISO 15118-20:2022 upgrading transport security to TLS 1.3 over the earlier 15118-2 baseline. The standard does not name a hardware security module (HSM) as the only acceptable implementation, but in practice, OEM cybersecurity teams implement secure key storage in an HSM or a secure element inside the charging communication controller to demonstrate that ISO/SAE 21434 threat scenarios on certificate compromise are adequately mitigated. The defensible posture is to scope secure key storage into the architecture at concept rather than retrofitting it after a TARA flags certificate handling as a high-impact threat scenario.

Where does V2G change the ISO 26262 safety case?

V2G turns the charging interface into a bidirectional power path. The ISO 26262 HARA needs to address discharge scenarios as hazards, not only charge scenarios. The safety goals tied to over-current, over-temperature, and over-discharge protection in the battery management system (BMS) must reference the V2G command path as a triggering condition. The cybersecurity case and the safety case share a boundary at the BMS: a successful attacker who can manipulate the V2G command path can trigger a hazardous event that the safety case is supposed to prevent.

How often does an EV charging TARA need to be updated?

ISO 21434 Clause 11 (continuous activities) requires the TARA to be reviewed whenever the item's threat model changes substantively. For EV charging interfaces, substantive changes include adding a new charging-network backend partner, adding a new protocol version (ISO 15118-20 versus ISO 15118-2), rotating the trust anchor PKI, or any disclosed vulnerability against a protocol the vehicle implements. Programs that try to manage the TARA on a static, SOP-frozen basis fall out of compliance the first time a charging-network operator changes its certificate authority or a protocol-level vulnerability is disclosed.

Sources

  • ISO/SAE 21434:2021, Road vehicles: Cybersecurity engineering, particularly Clauses 9.3, 9.4, 9.5, and 11.
  • ISO 15118 family of standards, Road vehicles: Vehicle to grid communication interface; particularly ISO 15118-2 (first edition, 2014) and ISO 15118-20:2022 (second-generation network and application layer requirements).
  • Open Charge Point Protocol (OCPP) 2.0.1 specification, Open Charge Alliance.
  • UN Regulation No. 155, Uniform provisions concerning the approval of vehicles with regard to cybersecurity and cybersecurity management system; applicable to new vehicle types in contracting parties from July 2022 and to all new vehicles produced from July 2024.
  • ISO 26262:2018, Part 3 (Concept phase) and Part 4 (Product development at the system level), for the HARA cross-reference at the BMS boundary.

About LHP Engineering Solutions

Since 2001, LHP Engineering Solutions has helped companies deliver technology that must perform as intended, every time. Our clients operate in safety-critical, operation-critical, and mission-critical environments such as on-highway, off-highway, aerospace, defense, and oil & gas, where failure is not an option, and delays cost market share.

LHP helps organizations design, architect, validate, and monitor complex systems. Our global team of engineers supports the development of advanced technologies, including high-voltage power electronics, hybrid and electric powertrain controls, connectivity, and ADAS platforms, enabling OEMs and Tier-1 suppliers to bring next-generation products to market quickly and with confidence.

In compliance-driven industries, LHP uses our model-based systems engineering (MBSE) approach, enhanced through AI, to help companies move quickly while meeting rigorous standards, including functional safety, ASPICE, and cybersecurity. Our teams have helped global technology companies achieve functional safety certification and ASPICE compliance in months rather than years, and established enterprise-grade safety and cybersecurity management systems for leading OEMs.

When organizations must make major technology leaps, such as launching next-generation platforms, future-proofing vehicle architectures, or proving new concepts to secure market-defining programs, LHP delivers the engineering disciplines, solutions, and on-time execution required to succeed.

Because in industries where technology must perform as intended, precision engineering matters.