ISO 26262 and ISO 21434 for Heavy-Duty Zero-Emission: Functional Safety and Cybersecurity in Parallel

This article walks through the two standards as a heavy-duty zero-emission integration partner sees them: what each requires, how they interact in practice, and where co-development adds the most leverage.

ISO 26262 in three lines

ISO 26262 (current edition: 2018, second edition) defines the functional safety lifecycle for E/E systems in road vehicles up to 3.5 tonnes, with explicit extensions to heavy-duty vehicles in Part 1 Clause 1 of the second edition. The lifecycle starts with an item definition, runs through Hazard Analysis and Risk Assessment (HARA), assigns Automotive Safety Integrity Level (ASIL) classifications, derives technical safety requirements, validates them through testing and analysis, and continues into production and operation through a safety case.

ASIL is the central concept. It is not an absolute safety rating; it is a quantification of how rigorous the development process has to be for a given hazard. ASIL A is the lightest, ASIL D the most stringent. Most heavy-duty traction-related functions land at ASIL C or D; HMI functions tend to ASIL A or QM (quality-managed, no ASIL).

ISO 21434 and ECE R155 in three lines

ISO 21434 (2021) defines the cybersecurity engineering lifecycle for road vehicles. It mirrors ISO 26262 in structure: concept, development, production, operation, decommissioning. Where 26262 has HARA, 21434 has TARA (Threat Analysis and Risk Assessment). Where 26262 has ASIL, 21434 has CAL (Cybersecurity Assurance Level).

ISO 21434 is not directly a regulation. The regulation is ECE R155, which mandates a Cybersecurity Management System (CSMS) for any vehicle entering the EU market from July 2024 (new types) or July 2026 (all types in production). Compliance with ISO 21434 is the standard route to demonstrating the CSMS. ECE R156 mirrors this for software-update management, mandating a Software Update Management System (SUMS) for over-the-air updates.

Where the two standards overlap

The two standards were written by different working groups but with conscious cross-references. They share more than they diverge. The overlap is most visible at four points in the lifecycle.

An OEM that runs the two lifecycles separately will discover, around month 9 of a heavy-duty program, that the two teams have written conflicting requirements on the same ECU. The fix is structural: run a single workshop for HARA and TARA on the same item, in the same week, with both teams in the room.

Where they conflict, and how to resolve

The overlap is genuine, but it is not seamless. Three conflict patterns are common.

Conflict 1: fail-safe versus secure-state

ISO 26262 requires that on detection of a fault, the system enters a defined safe state (often torque cut, isolation open, brakes applied). ISO 21434 requires that on detection of a cybersecurity event, the system enters a secure state, which sometimes means continuing to operate while alerting. The two states can be different, and on a heavy-duty platform the safe state is sometimes risky in cybersecurity terms (shutting down a vehicle on a public road creates a different attack surface).

Resolution: define a unified state machine at architecture phase, with explicit transitions between safe state and secure state, and document the trade-off in both safety and cybersecurity cases.

Conflict 2: update integrity

ISO 26262 requires that any change to safety-relevant software triggers a regression-test cycle proportional to the affected ASIL. ISO 21434 and ECE R156 require that cybersecurity patches reach the fleet within defined timelines. The two requirements pull on opposite ends: thorough re-validation versus rapid deployment.

Resolution: pre-qualified update channels with pre-built regression test packages, so a patch can be released within hours while still meeting 26262 evidence requirements.

Conflict 3: ASIL versus CAL

ASIL and CAL look similar on paper but they grade different things. A function can be ASIL D (highest safety integrity) and CAL 2 (moderate cybersecurity assurance), or ASIL B and CAL 4. Hardware budget allocation to either can pull the architecture in different directions.

Resolution: an integrated risk register that lists every function once, with both ASIL and CAL, and uses the higher of the two as the development discipline driver. This avoids two parallel architectures.

What changes for heavy-duty zero-emission specifically

Heavy-duty zero-emission programs add three concrete differences from passenger-car ISO 26262 / 21434 work.

• HV battery as ASIL D component. Loss of battery isolation is a hazard with potential for fire and electrocution. Most heavy-duty programs classify battery isolation monitoring at ASIL D, which forces redundant sensing and a high-rigor development process.
• Charging interface as cybersecurity attack surface. Any plug-in interface (CCS2, MCS) is a potential entry point. ISO 15118 introduces TLS-secured Plug and Charge, but the certificate management at fleet scale is a CSMS topic, not a charging-protocol topic.
• Off-highway operating modes. Many heavy-duty platforms have non-public-road modes (construction site, mine, port). HARA scoping has to cover both. Some hazards that are negligible on a public road are critical in a port (where a fully laden electric reach stacker can damage a vessel).

The integration partner’s role

Functional safety and cybersecurity work spans concept, development, validation and production. The integration partner adds value at three points specifically.

1. Item definition workshop: co-author the document that anchors both HARA and TARA, ensuring it is fit for both purposes.
2. HARA + TARA in parallel: facilitate the workshop, document hazards and threats simultaneously, identify shared mitigations.
3. Technical safety + cybersecurity case: assemble the evidence in the format both ECE R155 and the WVTA technical file expect.

OEMs that try to do this internally for the first heavy-duty zero-emission program almost always end up with two parallel documentation chains, each with gaps. An integration partner that has run this for prior programs delivers a single chain with cross-references where they belong.

Timeline: where 26262 and 21434 land in a typical heavy-duty program

A 36-month heavy-duty zero-emission program from concept to type approval usually structures the safety and cybersecurity work like this. The dates are illustrative but the sequencing is consistent across programs.