Functional Safety vs. Cybersecurity Safety: Why Hardware Teams Now Have to Manage Both
For most of automotive history, the engineer who wrote Automotive Safety Integrity Level (ASIL) requirements and the engineer who wrote penetration test criteria worked in different buildings, reported to different managers, and used different tools. The disciplines had different standards bodies, different risk vocabularies, and different certification pathways. That organizational separation was defensible when vehicles were mechanically isolated systems and the worst thing a software fault could do was stall the engine.
That separation is no longer defensible. A modern vehicle runs over-the-air software updates, routes real-time data through cellular modems, and executes decisions from perception stacks that receive external inputs. Networked industrial equipment faces the same reality. Autonomous systems are arguably more exposed than either. When a deliberate intrusion can alter sensor fusion outputs, trigger actuator commands, or corrupt safety-critical state machines, cybersecurity is no longer a parallel discipline — it is a precondition for functional safety.
This article defines both disciplines precisely, explains how their risk elicitation methods work and where they differ, and examines the specific coupling points that force modern hardware teams to manage them together.
What Functional Safety Actually Covers
Functional safety, governed by ISO 26262 for road vehicles (and IEC 61508 for the broader industrial domain), addresses risks arising from malfunction of electrical or electronic systems. The hazard it targets is unintended behavior — software bugs, hardware component failures, random hardware faults, systematic design errors. The causal chain is: a system malfunctions → the malfunction creates a hazardous condition → the hazardous condition, combined with an operational context and the absence of adequate control, produces harm.
The discipline does not ask “could an attacker trigger this?” It asks “could this fail on its own, and how bad would that be?”
The primary analytical method is the Hazard Analysis and Risk Assessment (HARA). In a HARA, engineers:
- Identify the system’s operational situations (driving at highway speed, parking in a garage, emergency braking).
- Identify hazards — physically observable unsafe conditions that a malfunction could create (unintended full braking, loss of steering, unintended acceleration).
- Evaluate each hazard against three parameters: Severity (S0–S3), Exposure (E0–E4, how often the operational situation occurs), and Controllability (C0–C3, whether a typical driver can avoid harm once the hazard appears).
- Combine those parameters to produce an ASIL: A, B, C, or D, or QM (no safety requirement). ASIL D is the most stringent.
- Derive Safety Goals from each ASIL-rated hazard. Safety Goals become the top-level functional safety requirements from which the entire requirements hierarchy descends.
The key output is a traceable chain from hazard to safety goal to functional requirement to technical safety requirement to implementation and verification evidence. ISO 26262 calls this the safety case.
What Cybersecurity Safety Actually Covers
ISO/SAE 21434, published in 2021, covers cybersecurity engineering for road vehicles. It is the basis for UNECE WP.29 Regulation 155, which mandates Cybersecurity Management Systems for vehicles sold in most major markets as of 2024. The equivalent for industrial systems is IEC 62443.
Cybersecurity addresses risks arising from deliberate, intelligent, adversarial action. The causal chain is different: a threat actor identifies a vulnerability → exploits it through an attack path → causes an impact. The system behaves exactly as designed — but the design is being used against the vehicle and its occupants.
The primary analytical method is the Threat Analysis and Risk Assessment (TARA). In a TARA, engineers:
- Define the item under analysis — the system boundary and its interfaces.
- Identify assets — components, data, or functions that have value and could be targeted (e.g., the ECU firmware, the CAN bus arbitration IDs, the GPS position data).
- Identify damage scenarios — what harm could result if an asset is compromised (loss of confidentiality, integrity, availability, or authenticity — the CIAА properties).
- Assess impact across multiple dimensions (safety, financial, operational, privacy). ISO/SAE 21434 uses a four-level impact rating.
- Enumerate threat scenarios — the specific ways an attacker could cause each damage scenario.
- Assess attack feasibility using the CVSS-like Attack Potential method: elapsed time, expertise required, knowledge of the item, window of opportunity, equipment needed.
- Combine impact and attack feasibility to produce a risk value, then assign Cybersecurity Goals and corresponding Cybersecurity Assurance Levels (CALs): CAL 1–4.
The key output is a set of Cybersecurity Goals and security controls with traceability from threat scenario through risk assessment through requirement to implementation and verification.
Where HARA and TARA Differ — and Where They Rhyme
The structural parallels are deliberate. Both frameworks produce a risk rating from two dimensions, both produce top-level goals that drive requirement hierarchies, and both require traceability through development artifacts. This similarity is not coincidence — 21434 was written with 26262 practitioners in mind.
But the threat models diverge sharply:
| Dimension | HARA (ISO 26262) | TARA (ISO/SAE 21434) |
|---|---|---|
| Cause of failure | Random hardware fault, systematic error | Deliberate attacker action |
| Worst-case actor | Physics, probability | An intelligent adversary who adapts |
| Risk parameters | Severity, Exposure, Controllability | Impact, Attack Feasibility |
| Output rating | ASIL A–D | CAL 1–4 |
| Residual risk logic | Reduce probability of malfunction | Reduce feasibility of attack + reduce impact |
| Lifecycle scope | Defined by the development project | Continuous — attacks evolve post-deployment |
That last row is where organizations most often underestimate the burden. A functional safety case is largely closed at the point of vehicle release. A cybersecurity case is never closed — 21434 mandates ongoing monitoring, vulnerability disclosure handling, and update capability across the full operational life. The tooling and process implications of that difference are significant.
The Coupling Problem: Where Safety and Security Intersect
The reason hardware teams must now manage both disciplines is not regulatory pressure alone. It is that the threat surfaces of modern systems create genuine causal paths from a security breach to a safety failure.
Consider three concrete examples:
Connected vehicles. The telematics control unit (TCU) receives cellular data. If an attacker can inject malicious CAN frames through a compromised TCU, they can reach safety-critical ECUs — the electronic stability control, the electric power steering, the braking system. The functional safety analysis may have assigned ASIL D to the braking control module, but that analysis assumed the threat was random hardware faults, not crafted network packets. The safety architecture may not protect against the attack vector.
Autonomous systems. A Level 4 autonomous vehicle relies on a perception stack that fuses LIDAR, RADAR, and camera data. If an attacker can manipulate object detection outputs — through adversarial inputs to the neural network or through spoofed sensor data — the planning stack receives corrupted inputs and may command unsafe trajectory decisions. The safety goal was “maintain safe trajectory.” The attack violates that goal through a mechanism the HARA never contemplated.
Networked industrial equipment. A safety-rated PLC controlling a robotic arm has an Ethernet interface for remote diagnostics. If that interface is exploited to alter setpoint parameters or disable protective stop functions, the attacker can bypass physical safeguards that are explicitly part of the safety architecture. The IEC 61508 safety case assumed the physical interface was the control boundary.
In all three cases, the vulnerability is in the cybersecurity domain, but the consequence is a functional safety failure. The ISO/SAE 21434 TARA needs to enumerate “safety impact” as a damage scenario. The ISO 26262 HARA needs to flag “cyber-triggered actuator command” as a hazard cause. And the two analyses need to be formally reconciled — not handed off between two separate teams who never look at each other’s work products.
ISO/SAE 21434 acknowledges this explicitly in its damage scenario impact assessment, which includes safety as one of the four impact dimensions. ISO 26262 is more indirect — it expects the safety concept to account for foreseeable misuse and external interference, but the standard predates the current attack surface by a decade. The practical guidance for coupling the two comes from technical reports like ISO/TR 4804 (for automated driving) and industry working group outputs, not from either standard itself.
Why Existing Toolchains Struggle With This
Most requirements management tools in automotive and industrial engineering were built for one discipline at a time. IBM DOORS and DOORS Next have deep pedigrees in safety-critical requirements management — they can handle hierarchical decomposition, coverage matrices, and change impact tracking at scale. But they were not designed to represent the lateral dependency between a TARA-derived cybersecurity requirement and a HARA-derived safety goal. Those relationships live in spreadsheets, review comments, and the institutional memory of senior engineers who happen to know both domains.
Jama Connect, Polarion, and Codebeamer have added safety workflow support and, more recently, cybersecurity workflow modules. The capability exists — but in most deployments, safety requirements and security requirements live in separate projects or separate modules, and the cross-domain traceability is manual. When a security control changes because a new attack vector is discovered, the process of identifying which safety goals are potentially affected — and re-evaluating whether the safety case remains intact — is largely a human exercise.
That matters because the question “does this security change invalidate any part of the safety case?” is not a simple query in a document-oriented tool. The answer requires traversing a dependency graph that spans both domains.
How Graph-Based Platforms Change the Calculus
This is the architectural advantage that graph-based requirements platforms offer over document-based ones. When requirements, risk items, safety goals, cybersecurity goals, design elements, and verification evidence are all nodes in a connected graph — with typed edges representing the relationships between them — cross-domain impact analysis becomes a structural query rather than a manual audit.
Flow Engineering (flowengineering.com) is built on this model. Rather than organizing requirements into document hierarchies, it represents every artifact — safety goals, security controls, functional requirements, test cases, risk items — as nodes in a persistent graph, with explicit, typed relationships between them. An ASIL D safety goal and the CAL 3 cybersecurity requirement that protects a critical interface sit in the same graph, connected to the shared design element they both constrain.
When a TARA is updated because a new attack path is identified — say, a newly discovered vulnerability in an OTA update parsing library — engineers can immediately see which safety goals are potentially in scope. Not by searching text fields or cross-referencing spreadsheets, but by traversing the graph. Flow Engineering’s AI-assisted analysis can surface candidate impact paths and flag requirements that may need re-review, reducing the time between “new threat discovered” and “safety case reassessed.”
For teams managing cross-functional safety and security work, the practical value is in the review workflow. A change request against a security control can automatically notify the safety team members whose requirements share graph nodes with that control. Conversely, a safety architecture change that modifies a hardware security module’s role surfaces automatically to the TARA owner. The coordination that used to require scheduled cross-discipline reviews and manual matrix reconciliation becomes embedded in the change management process itself.
Flow Engineering is explicitly scoped toward hardware and systems engineering teams in regulated industries. It is not a generalist project management layer. Teams that need deep legacy DOORS import fidelity, high-volume requirements throughput from decades of accumulated artifacts, or integration into established PLM ecosystems will need to evaluate whether a migration or integration strategy fits their context. But for teams standing up a connected product program — or for organizations that have acknowledged their existing safety/security coordination process is a gap — it represents a coherent architecture for the problem.
Practical Starting Points for Cross-Discipline Integration
If you are a hardware or systems engineer trying to make functional safety and cybersecurity work together in practice, the following are the minimum viable integration points:
1. Run HARA and TARA against the same item definition. The system boundary, operational modes, and interface definitions should be identical inputs to both analyses. Divergent item definitions are the most common source of gaps.
2. Map damage scenarios to safety hazards explicitly. For every TARA damage scenario that has a safety impact rating above negligible, identify the corresponding HARA hazard or safety goal. If none exists, you have either a missing hazard in the HARA or an overrated damage scenario in the TARA.
3. Identify “security-dependent safety requirements.” These are safety requirements whose implementation depends on a cybersecurity control being effective. Document the dependency formally. When the security control changes, these requirements need re-validation.
4. Build change impact analysis into your toolchain. Whether through a graph-based platform, a formally maintained RTM that crosses both domains, or a disciplined manual process, the question “what safety work is affected by this security change?” needs an answer faster than your next quarterly review.
5. Align your cybersecurity monitoring process with your safety case maintenance process. The post-production obligations of 21434 mean your cybersecurity artifacts will continue to change. Your safety case owner needs to be part of the triage loop for significant security findings.
Honest Assessment
The convergence of functional safety and cybersecurity is not a future problem. UNECE WP.29 R155 is in force. Autonomous vehicle programs are shipping. Industrial customers are buying connected equipment with safety ratings and expecting both disciplines to hold.
The engineering community has made significant progress on each discipline individually. The gap is in the seams between them — the handoff between the HARA team and the TARA team, the requirement that crosses from a safety module to a security module, the post-production vulnerability that intersects a safety assumption.
Solving that coordination problem at document-level tooling is possible but expensive. Solving it at the graph level — where every relationship between artifacts is explicit and queryable — is the architectural direction that modern connected product programs are moving toward. The teams who build that integration now will spend less time auditing cross-domain consistency when a new threat emerges or a safety goal changes.
The disciplines converged because the systems did. The tooling needs to follow.