ISO 26262 and ISO 21434 Co-Engineering: Mapping Safety Goals to Cybersecurity Goals

When a Cyberattack Becomes a Safety Violation

A remote attacker sends a crafted diagnostic message to an ADAS ECU. The message exploits an unauthenticated UDS service to modify the calibration data controlling the emergency braking threshold. The brake assist system now fires at 60% of its intended sensitivity. No component has failed. Every sensor is working exactly as designed. The vehicle is nonetheless operating in a hazardous state.

Which standard owns this scenario?

The answer is both — and that is precisely why ISO 26262 and ISO 21434 cannot be developed independently. Functional safety analysis assumes the system behaves as designed. Cybersecurity analysis addresses intentional violation of that assumption. When an attacker can cause a safety-relevant function to misbehave, the two standards are analyzing the same physical risk from different directions. Co-engineering is the discipline of managing that overlap systematically rather than discovering it in a certification audit.

This article lays out the technical methodology: where the standards interact at the clause level, how to map safety goals to cybersecurity goals, and what the typical organizational failure modes look like.

Why the Standards Have Structural Overlap

ISO 26262 was designed around the premise of random hardware failures and systematic software faults. Its risk framework — Automotive Safety Integrity Level (ASIL) — rates severity, exposure, and controllability. It does not model adversarial intent.

ISO/SAE 21434 was designed around intentional threats. Its risk framework — Cybersecurity Assurance Level (CAL) — rates impact, ease of attack, and feasibility. It does not produce functional safety requirements.

The structural gap: ISO 26262 defines safety mechanisms to protect against faults. Those safety mechanisms are software running on hardware connected to a network. An attacker who can disable or circumvent a safety mechanism achieves the same effect as the fault the mechanism was designed to catch — without triggering any failure mode analysis.

ISO 26262-9 Clause 7 requires safety mechanisms to achieve Diagnostic Coverage (DC) targets of ≥60% (ASIL A), ≥90% (ASIL B/C), or ≥99% (ASIL D). None of those DC calculations account for a mechanism that is selectively disabled through a cybersecurity attack.

ISO 21434 Clause 15 requires threat analysis and risk assessment (TARA) to cover all assets where a compromise would have adverse consequences. A safety mechanism protecting an ASIL D function is by definition a high-value asset. If it does not appear in the TARA, the cybersecurity analysis has an unexamined hole.

The interaction is bidirectional and mandatory, not optional.

The Four Formal Interaction Points

Co-engineering requires explicit linkage at four places in the development workflow.

1. HARA Output → TARA Scope

The Hazard Analysis and Risk Assessment (ISO 26262-3 Clause 7) produces a list of hazardous events, each associated with a safety goal and ASIL rating. That safety goal list is an input to the TARA (ISO 21434 Clause 15). Every safety goal with ASIL B or higher should be reviewed for cybersecurity relevance: can an attacker cause the hazardous event that the safety goal is protecting against? If yes, the TARA must model that attack path.

2. Safety Goals → Cybersecurity Goals

Not every safety goal has a corresponding cybersecurity goal. But those that do require a formal mapping. A safety goal like "The vehicle shall not accelerate unintendedly" implies a cybersecurity goal along the lines of "The powertrain control ECU shall reject unauthenticated torque demand commands." The cybersecurity goal then drives security controls, which feed back into the software architecture that ISO 26262 is also governing.

3. Safety Mechanisms → Attack Surface

Safety mechanisms (watchdogs, plausibility checks, redundant sensors) become attack surface items in the TARA. Their asset value is directly proportional to the ASIL of the function they protect. A watchdog protecting an ASIL D brake system function needs a CAL 4 analysis — meaning attackers with significant resources and specialist knowledge must be considered in the threat model.

4. Software Architecture — Shared Work Product

Both ISO 26262-6 (software level) and ISO 21434 Clause 9 (concept phase) analyze the software architecture for partitioning, trust boundaries, and interface integrity. In a co-engineered project, this analysis happens once on a single architecture model, with safety and cybersecurity constraints applied simultaneously. Running separate analyses on separate architecture documents — a common failure — produces divergent models that neither team trusts.

Safety Goal to Cybersecurity Goal Mapping

The table below illustrates how representative ISO 26262 safety goals map to ISO 21434 cybersecurity goals across common automotive systems.

CAL derivation follows ISO 21434 Clause 15.8 and reflects worst-case impact ratings. Individual programs may justify different CAL assignments with documented rationale.

Common Co-Engineering Failures

Running HARA and TARA sequentially instead of iteratively. Safety teams complete HARA, then hand off a safety goal list to the cybersecurity team. The cybersecurity team runs TARA without reviewing whether new attack paths they identified introduce new hazardous events not captured in the HARA. The loop never closes. ISO 26262-3 Annex B explicitly anticipates that HARA may need iteration as new hazard sources are identified — cybersecurity findings are exactly such a source.

Missing the "safety mechanism as asset" mapping. TARA teams typically scope assets as ECUs, communication links, and software components. Safety mechanisms — plausibility monitors, hardware redundancy units, software watchdogs — are rarely listed explicitly as assets. An attacker who disables a software watchdog protecting an ASIL D function does not need to cause the primary fault; they only need to prevent detection of it. This entire threat class is invisible if safety mechanisms are not in scope.

Incompatible ASIL/CAL derivation criteria. ASIL severity is rated at system level (impact on vehicle occupants). CAL impact is rated across four dimensions: safety, financial, operational, privacy. Teams running separate analyses often assign different severity ratings to the same hazardous event — making it impossible to cross-reference or audit the two assessments. Co-engineering requires agreeing on a shared severity taxonomy before analysis begins.

Architecture divergence. Safety architecture review (ISO 26262-4 Clause 7) and cybersecurity architecture review (ISO 21434 Clause 10) both produce findings that modify the system architecture. When these findings go into separate issue trackers and separate architecture documents, a safety-motivated change that consolidates two ECUs may create a co-residency risk the cybersecurity team would have blocked — but they were never consulted.

No shared traceability between safety requirements and security controls. The ISO 26262 safety case must show every safety goal addressed by a requirement chain down to implementation and test evidence. The ISO 21434 cybersecurity case must show every cybersecurity goal addressed by verified security controls. When a security control and a safety mechanism address the same hazardous event through separate documents, neither case references the other. Auditors have no way to assess whether the combined coverage is sufficient or dangerously redundant in ways that create false confidence.

How ISO WIZ Handles Safety-Security Co-Engineering

ISO WIZ implements the co-engineering methodology described above as a native workflow. When you create a HARA, each hazardous event and safety goal is immediately available as a potential input to the TARA module. The platform prompts for cybersecurity relevance assessment — which safety goals could be triggered by an intentional attack? — and auto-creates linked TARA entries for those that qualify. Safety goals and cybersecurity goals share a unified traceability graph, so the relationship between a safety goal like "SG-04: Prevent unintended acceleration" and a cybersecurity goal like "CG-12: Authenticate torque commands" is visible to both teams at all times.

Safety mechanisms created under ISO 26262 appear automatically in the TARA asset list, pre-tagged with their ASIL rating as a proxy for initial asset value. The cybersecurity team refines the CAL from there, but cannot accidentally omit a high-value safety mechanism from scope.

Architecture work products are single artifacts shared across all four standards — ISO 26262, ISO 21434, ISO 21448, and ASPICE. A change to the software architecture triggers a cross-standard impact flag, notifying both safety and cybersecurity reviewers that a verification gap may have opened.

The result is a co-engineering process that does not depend on two teams coordinating across separate spreadsheets, separate tools, or separate project schedules. Gaps are surfaced automatically. Evidence is linked at creation time. The safety case and the cybersecurity case are built on the same traceability backbone.

If your program involves any safety-critical function that communicates over a network, co-engineering ISO 26262 and ISO 21434 is not optional — it is the only way to build a defensible case. Try ISO WIZ free at [isowiz.com](https://isowiz.com) and see how unified traceability changes the workflow.