Safety-Security Co-Engineering: Managing Both in a Single Requirements Baseline

A braking system cannot be overridden remotely. That single sentence is simultaneously a safety requirement and a security requirement. It traces to a functional safety goal (ISO 26262 ASIL D), to a cybersecurity goal (UNECE WP.29 threat category), and to a specific software architecture constraint. If your organization manages it in two separate databases—one owned by the safety team, one by the cybersecurity team—you have a coordination problem dressed up as a process problem. The actual risk is that neither database contains the requirement that sits at the intersection.

This article explains what safety-security co-engineering means in practice, why parallel requirement trees create specific and predictable failure modes, what interface requirements look like in three regulated domains, and how to structure your baseline so these interactions are visible rather than buried.

What Safety-Security Co-Engineering Actually Means

Safety engineering asks: what can go wrong due to faults, failures, or unintended behavior, and how do we reduce the probability and severity of harm?

Security engineering asks: what can go wrong due to intentional adversarial action, and how do we reduce the attacker’s ability to cause harm?

For most of the twentieth century, these disciplines evolved separately because connected systems were rare. An industrial pump controlled by a local PLC was a safety problem. The same pump, now accessible via OT network, is a safety problem and a security problem—because a successful attack on the PLC can trigger the same consequence as a hardware fault. The attacker has become a threat actor in your fault model.

Safety-security co-engineering is the practice of analyzing these disciplines together, explicitly identifying where a security failure produces a safety consequence and where a safety mitigation creates a security exposure, and encoding those interactions as first-class requirements with explicit ownership and traceability.

The output is not two sets of requirements that happen to share a document. It is a connected requirement structure where safety-security interface requirements are distinct artifacts, traceable in both directions, with explicit attributes that identify them as boundary objects between disciplines.

Why Separate Requirement Trees Fail

The failure mode is predictable and follows the same pattern across domains.

Organizational separation creates structural blind spots. The safety team delivers their hazard analysis and risk assessment (HARA) or preliminary hazard analysis (PHA). The security team delivers their threat analysis and risk assessment (TARA) or security risk assessment. Both documents are reviewed in separate review cycles by separate discipline experts. The interface—where a threat exploits a vulnerability to trigger a hazard—appears in neither document because each team scoped their analysis at their organizational boundary.

Assumptions become invisible. Safety cases depend on assumptions. A safety function assumes that the communication channel carrying its commands is authenticated. That assumption is a security requirement. But it lives, informally, as a note in the safety architect’s head rather than as a traceable requirement allocated to the cybersecurity workstream. When the security team makes a different architectural decision—perhaps accepting an unauthenticated CAN bus because it’s on an internal network—the safety assumption is violated. Neither team has a process trigger that surfaces this conflict because the requirement that would capture it was never written.

Verification gaps emerge at integration. Safety verification confirms that the braking system responds correctly to commanded inputs. Security verification confirms that unauthorized commands are rejected. Neither test exercises the scenario where an attacker sends a plausible-but-malicious command that passes the security check and then triggers an unsafe state because the safety logic was not designed to handle this input combination. This scenario lives in the gap between test plans owned by different teams.

Mitigations create new exposures in the other domain. A safety mitigation that adds a watchdog timer with automatic system shutdown improves safety availability metrics. It also creates a denial-of-service vector: an attacker who can force the watchdog to trigger has a mechanism to cause controlled shutdown of a safety-critical system. The safety team approved the mitigation without security review. The security team was never told the mitigation existed.

These are not hypothetical failures. The UNECE WP.29 regulation exists in large part because automotive cybersecurity incidents demonstrated that attackers could exploit vehicle connectivity to affect safety functions.

Domain-Specific Interface Requirements

Automotive: ISO 26262 + UNECE WP.29

ISO 26262 governs functional safety for automotive electrical and electronic systems. UNECE WP.29 Regulation No. 155 (Cybersecurity Management System) requires that manufacturers address cybersecurity throughout the vehicle lifecycle, including interactions with safety.

The interface between them is not optional. R155 explicitly requires that threat analysis consider safety impacts, and ISO 26262 Part 1 defines a system element that includes cybersecurity among the development interface agreement (DIA) items that must be exchanged between parties.

Concrete interface requirements in this domain look like:

• Authentication requirement with safety rationale: The electronic control unit (ECU) implementing the autonomous emergency braking function shall reject any brake command that is not authenticated using [mechanism] before executing the command. Safety trace: HARA hazard H-07, ASIL D. Security trace: TARA threat T-03, attack category: spoofing of safety-relevant commands.

• Security diagnostic isolation: Diagnostic commands received via OBD-II port shall not be capable of disabling or overriding safety monitors during normal driving operation. Safety trace: safety goal SG-04. Security trace: TARA threat T-11, attack path: physical diagnostic access.

• Software update integrity with fail-safe: Over-the-air software updates to ASIL-C or ASIL-D rated components shall fail to a safe state if the cryptographic signature verification fails. The safe state shall be defined in the safety architecture. Safety trace: SG-02. Security trace: TARA threat T-08.

Each of these requirements belongs to both the safety case and the threat model. In a baseline where safety and security are separate trees, none of them have an obvious home. They fall between organizational owners.

Avionics: DO-326A and the Security/Safety Interface

DO-326A (Airworthiness Security Process for Commercial Aircraft) was issued specifically because DO-178C and DO-254—the avionics software and hardware standards—were written before networked aircraft were a significant attack surface. DO-326A establishes an Aircraft Security Risk Assessment (ASRA) that must interact with the System Safety Assessment (SSA) required by ARP4754A.

The FAA’s guidance on this interaction (AC 119-1) requires that security threats which could affect safety be identified and that mitigations be coordinated between the security and safety processes. The standard explicitly uses the term “safety effects of security failures.”

Interface requirements in avionics include:

• Data bus isolation with safety classification: The avionics open system interconnect (AOSI) domain shall be isolated from the passenger information and entertainment services (PIES) domain such that no data path exists that could allow PIES-originated data to influence AOSI functions rated DAL A or DAL B. Safety trace: SSA item FHA-12. Security trace: ASRA threat ST-04.

• Security monitoring without safety interference: Security intrusion detection system (IDS) logging shall not consume more than [X%] of the processor budget of any DAL A function. The IDS shall fail silently—generating no interrupt or fault signal—if its own processing capacity is exceeded. Safety trace: processor load budget derived from FHA-14. Security trace: ASRA mitigation M-09.

• Maintenance mode access control with safety bounds: Ground maintenance access mode shall not disable safety monitors. Safety monitors shall remain active and shall log any condition that would have triggered a safety alert during maintenance mode operations. Safety trace: SSA CM-06. Security trace: ASRA threat ST-07.

The second requirement is a canonical example of a safety-security interface requirement. The safety team wants the IDS to not affect DAL A processing. The security team wants the IDS to generate alerts. The interface requirement specifies the behavior at that boundary—and it belongs to neither team’s conventional scope.

Industrial Control Systems: IEC 62443 and Functional Safety

In industrial control, IEC 62443 (security for industrial automation and control systems) and IEC 61511 (functional safety for process industries) govern the same physical infrastructure from different angles. A safety instrumented system (SIS) protecting a chemical reactor is an IEC 61511 system. If that SIS is connected to the plant network, it is also an IEC 62443 asset.

IEC 62443-3-3 and the IEC 61511 Part 1 Edition 3 addendum both acknowledge that cybersecurity threats must be considered in the safety lifecycle. The interaction is now a compliance requirement, not just good practice.

Interface requirements in industrial control:

• SIS network isolation as safety measure: The safety instrumented system network shall be physically isolated from the process control network. Where a data connection is required for safety data historian functions, that connection shall be unidirectional (data diode) and shall carry read-only process data. No command traffic shall traverse the boundary. Safety trace: SIS Safety Requirements Specification SR-14, SIL 2. Security trace: IEC 62443-3-3 SR 5.2.

• Bypass management with dual authorization: Safety function bypasses used during maintenance shall require concurrent authorization from both the operations supervisor (safety authorization) and the cybersecurity officer (access authorization). Bypass state and duration shall be logged to an immutable audit trail. Safety trace: SIS bypass procedure BP-03. Security trace: IEC 62443-3-3 SR 2.8.

• Firmware update with safety holdoff: Firmware updates to any SIS controller shall not be applied while any safety function is in a degraded state. The update process shall verify safety function status before initiating and shall abort without applying partial updates if safety status changes during the update window. Safety trace: SR-22 (SIL integrity maintenance). Security trace: IEC 62443-3-3 SR 7.6.

Structuring Your Requirements Baseline for Safety-Security Interactions

The goal is a baseline structure where safety-security interface requirements are first-class artifacts, not footnotes in either team’s documents. This requires deliberate choices about data model, attributes, and process.

Define interface requirements as a distinct requirement type. Your requirement taxonomy should include a type—call it SSIR (Safety-Security Interface Requirement)—with mandatory attributes: a shared hazard/threat identifier that exists in both the HARA/PHA and the TARA, an interaction type (security-enables-safety, safety-enables-security, mutual-constraint, or conflict), and dual ownership (a safety owner and a security owner, both responsible).

Trace bidirectionally into both analysis artifacts. An SSIR without a trace to both a safety case item and a security threat model item is incomplete. Your baseline tool must support this—a requirement that traces only to the safety case is indistinguishable from a pure safety requirement, and the security analysis will not know it exists.

Run joint HARA-TARA sessions at system definition. The most efficient way to identify interface requirements is to run a combined workshop where the safety team walks through their hazards and the security team simultaneously identifies which threats could trigger those hazards. This produces the shared hazard/threat IDs that anchor SSIRs. Doing this after both analyses are complete means refactoring two completed documents.

Use change impact analysis across disciplines. When a safety requirement changes—a revised ASIL rating, a changed safe state definition—the change analysis must traverse the traceability graph into the security domain. A change to a safe state definition changes the security requirement for what an attacker must achieve to cause harm. Without graph-based traceability, this cross-discipline change propagation requires manual coordination between teams who may be in different organizational silos.

Enforce SSIR coverage in review gates. Make SSIR completeness a gate criterion for your safety case review and your security assessment review. Neither review should pass without verifying that all identified interaction points have corresponding SSIRs with dual traceability.

How Modern Tools Support This Structure

Document-based requirements management tools make this structure difficult. A Word document or PDF cannot represent bidirectional traceability. An Excel RTM that is maintained by two separate teams in two separate files will diverge. The safety team’s RTM will not reference the TARA items because those live in the security team’s tool instance.

Graph-based requirements tools represent requirements as nodes and relationships as edges, which means a safety-security interface requirement is naturally expressed as a node with edges to safety case items and threat model items simultaneously. Changing any connected node surfaces the impact on the SSIR.

Flow Engineering (flowengineering.com) implements this model specifically for hardware and systems engineering teams. Its graph-based architecture allows teams to define SSIRs as a requirement type with typed relationships—a “safety-enables-security” edge is structurally distinct from a “derives-from” edge—and to traverse impact paths across what would otherwise be separate discipline silos. When a safety architect revises a hazard classification, the system surfaces which SSIRs are connected to that hazard, which surfaces the corresponding security implications. This is the kind of cross-discipline change propagation that prevents the “silent assumption violation” failure mode described earlier.

The practical value is not just in initial authoring. It is in maintenance across a development program where safety and security analyses are updated continuously as the design evolves.

Starting Points for Teams New to Co-Engineering

If your organization currently maintains separate safety and security requirement trees, you do not need to rebuild your entire baseline. Three concrete starting points:

First, identify your interface inventory. List every place where a security failure could trigger a safety consequence, and every place where a safety mitigation creates a security surface. This does not require a new tool—it requires a cross-discipline workshop that produces a numbered list. That list is the input to your SSIR authoring process.

Second, add safety-security interaction as an attribute to existing requirements. Requirements in either tree that reference the other domain should be tagged. A safety requirement that assumes authenticated communications is a candidate SSIR. Tagging these does not require restructuring the baseline—it makes the interface visible.

Third, align review cycles. Safety design reviews and security assessments should share a calendar point where interface requirements are jointly reviewed. This does not require organizational restructuring. It requires a standing agenda item and a shared attendee list.

Honest Assessment

Safety-security co-engineering is not a solved problem. The standards are ahead of tool support in many areas, and tool support is ahead of actual team practice in most organizations. The coordination overhead of joint HARA-TARA sessions is real, particularly in organizations where safety and security report to different vice presidents and bill to different programs.

But the alternative—discovering a safety-security interaction during a cybersecurity incident investigation or a certification authority audit—is more expensive by an order of magnitude than the coordination overhead. The automotive industry learned this through high-profile remote exploitation demonstrations. Avionics is learning it through the connected aircraft ecosystem. Industrial control learned it through Stuxnet and subsequent ICS-targeted malware campaigns.

The requirement that the braking system cannot be overridden remotely must exist somewhere in your baseline with a named owner, bidirectional traceability, and a verification method. If you do not know where it lives right now, that is the gap that safety-security co-engineering is designed to close.