BMS Cybersecurity - Battery Design

A modern BMS is no longer an isolated controller — it sits on the vehicle’s CAN, DoIP and Automotive Ethernet networks, runs AUTOSAR-managed software that can be updated over the air, and exposes diagnostic services that can read and write safety-relevant parameters. That connectivity is also an attack surface: a compromised diagnostic session or a spoofed CAN message can, in principle, reach the same contactor control and cell-balancing functions that a functional safety case is built around. This page covers cybersecurity from the BMS side specifically — how the process defined in ISO/SAE 21434 plays out against a BMS’s actual attack surface, and how it is secured in practice. Because a successful attack can create a safety hazard, this is normally treated as the companion discipline to functional safety rather than a separate, optional add-on — the two disciplines share threat-and-hazard reasoning even though ISO 26262 addresses unintentional faults and ISO/SAE 21434 addresses intentional attacks.

TARA Applied to a BMS

The ISO/SAE 21434 page covers the Threat Analysis and Risk Assessment (TARA) framework in general terms; applied to a BMS specifically, it works through:

Asset identification — what needs protecting: cell balancing commands, contactor control, calibration and diagnostic data, firmware images, cryptographic keys.
Threat scenario identification — how each asset could realistically be attacked, e.g. a spoofed CAN frame commanding contactors closed outside their safe operating window, or a manipulated diagnostic session altering balancing thresholds.
Impact rating — the consequence of a successful attack, scored across safety, financial, operational and privacy categories (severe / major / moderate / negligible).
Attack feasibility rating — how practical the attack actually is, scored across elapsed time, specialist expertise, knowledge of the item, window of opportunity, and equipment needed.
Risk determination and treatment — combining impact and feasibility into a risk level, then deciding whether to reduce, share, avoid or accept it.

Each identified threat scenario is also assigned a Cybersecurity Assurance Level (CAL) — broadly the security analogue of an ASIL in ISO 26262 — which sets how rigorously the corresponding requirement must be developed, verified and maintained. Unlike a raw risk score, which can change as new attack techniques emerge, the CAL is meant to stay fixed for the life of the item once assigned during the concept phase.

SecOC: Securing the Messages Themselves

TARA sets the risk targets; AUTOSAR’s Secure Onboard Communication (SecOC) module is one of the concrete mechanisms used to meet them at the message level. SecOC wraps an ordinary CAN or Ethernet payload (an “Authentic I-PDU”) into a “Secured I-PDU” by adding a Message Authentication Code (MAC) and a freshness value before transmission. The receiving ECU recomputes the MAC using a shared key and checks the freshness counter or timestamp before accepting the message — which defeats both message tampering (the MAC won’t verify) and replay attacks (a captured, retransmitted message fails the freshness check even if the MAC is valid). Full MACs are often truncated to save bus bandwidth, trading a small amount of cryptographic margin for frame size; the truncation length is itself a parameter the TARA-derived CAL should drive, since it affects how hard the authentication is to brute-force. For a BMS, SecOC is the natural mechanism to protect exactly the message classes the TARA process flags as high-impact — contactor commands and balancing control in particular — on top of the transport-layer coverage the site’s BMS communication architecture page already describes.

Why Safety and Security Are Run Together

On a networked BMS, a security failure can directly cause a safety failure: an attacker who can inject a spoofed contactor-close command has effectively created the same hazard a functional safety analysis is meant to prevent, just through a different door. A safety case that assumes inputs are always trustworthy, and a security case that doesn’t know which messages are actually safety-relevant, each leave a gap the other is meant to close — which is why a functional safety analysis and a TARA are increasingly run against the same item definition rather than in isolation.