How Do You Structure Requirements for a System That Must Be Both Safe and Secure?

The question sounds straightforward. It isn’t.

Safety and cybersecurity are both mature engineering disciplines. Each has established standards, established methods, and established toolchains. ISO 26262 has been guiding automotive functional safety for over a decade. IEC 62443 has a long track record in industrial control systems. The problem is not that either discipline lacks rigor. The problem is that when you put them in the same system, their requirements interact in ways that neither standard was designed to handle — and those interactions can kill people.

The automotive industry arrived at this tension with force. ISO 21434, the cybersecurity engineering standard for road vehicles, was published in 2021. Regulators and OEMs immediately began asking how HARA (Hazard Analysis and Risk Assessment, the ISO 26262 entry-level analysis) and TARA (Threat Analysis and Risk Assessment, the ISO 21434 equivalent) should be reconciled when they generate conflicting requirements for the same system element. Medical device manufacturers face the same problem under IEC 62304 and IEC 62443. Industrial control system engineers deal with it under IEC 61511 and IEC 62443. The standards bodies have begun publishing guidance on convergence, but that guidance largely describes what must be done, not how to build the requirements structures that make it tractable.

This article addresses the how.

Why Safety and Security Requirements Conflict

To understand the structure you need, you first have to understand the nature of the conflict. It is not a political conflict between teams with competing priorities. It is a technical conflict between requirements that share system states and respond to them in opposite ways.

Security measures can block safety responses. Consider an automotive brake control module with network connectivity. A sound cybersecurity architecture requires message authentication — the module should only execute commands from authenticated sources. A sound safety architecture requires that the module respond to a valid brake command within a bounded latency, unconditionally. Now introduce the scenario where a hardware security module (HSM) is processing a heavy cryptographic load when a safety-critical brake command arrives. The security measure (authentication before execution) imposes latency. The safety requirement (deterministic bounded response) cannot tolerate that latency. You have a genuine conflict between two correct requirements, and it must be resolved at the architecture level, not papered over in a requirements document.

Safety responses can create security vulnerabilities. Fail-safe behavior in safety-critical systems often involves broadcasting system state. A power grid controller that detects an unsafe condition may open contactors and broadcast its diagnostic state to upstream supervisory systems so operators can respond. That broadcast is a data source for an attacker building a model of the system. A ventilator that enters a safe mode and announces it over a hospital network has just told any listener which devices are degraded. Safe states that require state visibility are security liabilities — and the safety engineer and security engineer are both right.

Safety independence requirements conflict with security monitoring. ISO 26262 and IEC 61508 both require that high-integrity safety functions be independent of lower-integrity functions. A common safety architecture pattern is to run safety-relevant software on isolated compute with no external interfaces. Security architecture, by contrast, benefits from comprehensive monitoring and telemetry — you cannot detect anomalies in systems you cannot observe. The safety requirement says: isolate this. The security requirement says: instrument this. Both are correct.

These conflicts are not edge cases. They appear systematically across safety-relevant systems with connectivity, which is most modern safety-relevant systems. The engineering task is to make them visible and resolvable, not to pretend they can be avoided.

The Requirements Structure for Converged Analysis

A converged safety-security requirements structure has three characteristics that distinguish it from running two parallel processes with a handoff.

1. Shared System Model, Not Shared Documents

Both HARA and TARA reason about system states. HARA asks: what functional states lead to hazards? TARA asks: what system states can an attacker achieve, and what are the consequences? Both analyses require a model of the system’s functional architecture — components, interfaces, states, and behaviors.

If safety engineers and security engineers work from different models of the same system, divergence is guaranteed. The safety team models the brake control module at one level of abstraction; the security team models it at a different level; neither model is wrong, but they cannot be compared, so conflicts between the derived requirements are invisible until integration.

The structural solution is a single system model that both analyses reference. This means functional decomposition, interface definitions, and behavioral state descriptions must be agreed before either HARA or TARA begins in earnest. That model becomes the common substrate. Safety failure modes and security threat conditions are both expressed in terms of the same system elements, which makes their interactions traceable.

2. Explicit Interaction Nodes

A converged requirements structure must include requirement nodes — or links between requirement nodes — that explicitly represent the interaction between a safety requirement and a security requirement on the same system element.

The practical form of this varies. Some teams use a dedicated requirement type (an “interaction requirement” or “interface requirement”) that has traceability links to both the parent safety requirement and the parent security requirement it mediates. Others model the interaction as a constraint on the system element: “the authentication latency of the HSM under load must not exceed X ms, as required by both [SAFETY-REQ-047] and [SEC-REQ-019].” Either approach works. What does not work is treating the two requirement sets as separate hierarchies that touch only in prose.

3. Explicit Safety-Security Conflict Resolution Records

When a safety requirement and a security requirement cannot be simultaneously satisfied by any single design choice, the resolution must be a traceable engineering decision, not a judgment call made silently in detailed design. This means: the conflict is documented as a typed link or node in the requirements model, the proposed resolution is attached, the assumptions the resolution depends on are explicit, and the verification approach for those assumptions is traceable.

This is not bureaucratic overhead. In a certification audit for both ISO 26262 and ISO 21434, you will be asked to demonstrate that safety and security have been co-engineered. A model with explicit conflict-resolution nodes is evidence. A set of Word documents with footnotes is not.

How the Analysis Process Works in Practice

Convergence is not achieved by merging HARA and TARA into a single meeting. The methods are different and serve different purposes. What convergence requires is structured exchange at specific points.

Before analysis begins: Agree the system boundary, functional decomposition, and external interfaces. Both teams work from this. Any changes to it during analysis require notification to both teams.

During HARA: When a hazardous event is identified, evaluate whether a plausible threat scenario could cause or amplify it. Flag those. They become candidate inputs to TARA.

During TARA: When a threat scenario leads to a consequence that affects a safety function, flag it. The consequence assessment in ISO 21434 includes safety impact — this is not optional. Flag these as candidate inputs to HARA.

At architecture definition: For every system element that has both safety integrity requirements (ASIL in automotive, SIL in industrial) and security requirements (CAL in automotive, security level in IEC 62443), explicitly document the interaction and resolve conflicts before the architecture is baselined.

At requirement allocation: Requirements allocated to the same component that originate from different domains (safety vs. security) should be checked for conflicts before the component specification is finalized.

At verification planning: Verification of safety-security interactions may require test scenarios that neither a pure safety test nor a pure security test would cover. A penetration test that exercises the brake control module during a high-load cryptographic operation is a safety-security interaction test. Plan for these explicitly.

How Modern Platforms Support Converged Analysis

The toolchain question is not secondary. Running converged analysis with document-based tools — requirements in Word, HARA in Excel, TARA in a separate Excel, both linked by filename conventions — is technically possible the same way building a satellite with hand calculations is technically possible. It is not the reason people fail. But the toolchain either makes the structural requirements above tractable, or it makes them theoretical.

The core toolchain requirement is traceable heterogeneous modeling: the ability to hold safety requirements, security requirements, system model elements, analysis artifacts (HARA, TARA, FTA, attack trees), and their relationships in a single queryable model. Document-based tools do not provide this. Legacy requirements management platforms like IBM DOORS provide traceability within a requirements hierarchy but were not designed to model the analysis artifacts — HARA tables, FMEA results, attack trees — as first-class connected objects. Adding that capability requires customization that is expensive and fragile.

Graph-based, AI-native platforms are better suited to this problem because they model relationships as the primary artifact, not documents. Flow Engineering, built specifically for hardware and systems engineering teams, structures requirements as nodes in a connected model where every requirement can carry typed relationships to other requirements, to system model elements, and to analysis artifacts. A safety requirement and a security requirement can both point to the same functional component; a query can return all components that have both types of requirements, flagging them as candidates for interaction analysis. Conflict-resolution records are modeled as explicit nodes with their own traceability, not as comments in a table.

This matters for converged analysis because the interactions between safety and security requirements are graph relationships. They are not document relationships. A document can contain both a safety requirement and a security requirement, but it cannot tell you that they conflict on a shared system state — that requires a model that understands what both requirements depend on.

Flow Engineering’s AI layer supports this in a practical way: it can scan a requirement set and surface candidate conflicts — pairs of requirements that reference the same component and make demands that may not be simultaneously satisfiable — for engineering review. This is not automated resolution; the conflicts still require human engineering judgment. But surfacing them systematically, before architecture review rather than during it, is the difference between managing the problem and being surprised by it.

Legacy platforms like Jama Connect and Polarion have added traceability improvements and some AI-assist capabilities, and both are capable tools for organizations with established workflows. The limitation in the converged safety-security context is that their data models were designed around document-centric requirements management, and grafting a graph-relationship model onto that structure requires workarounds that reduce the fidelity of the interaction representation. That is a real limitation, not a dismissal — both tools have large installed bases and will continue to serve organizations that have built processes around them.

Where to Start

If your team is facing a converged safety-security requirement problem for the first time, the practical starting points are:

Establish the shared system model first. Do not let safety and security analyses begin from separate functional decompositions. The time spent aligning the model before analysis is recovered immediately when conflicts surface cleanly rather than as late-stage integration surprises.

Require cross-domain review at HARA and TARA completion. Before either analysis is baselined, the other team reviews it for missed interactions. This is a process control, not a toolchain feature, and it costs less than a single late-stage rework cycle.

Model interactions explicitly in whatever tool you use. Even in DOORS or a spreadsheet, create a column or link type for “safety-security interaction.” The discipline of explicitly flagging interactions, separate from the resolution, is more valuable than the tool.

Plan verification for interactions, not just requirements. Your verification matrix needs rows for safety-security interaction scenarios. If it does not, you will discover gaps during audit.

The standards are converging. ISO 21434 and ISO 26262, IEC 62443 and IEC 62304, IEC 62443 and IEC 61511 — the gaps between them are narrowing with each revision cycle. The engineering practice needs to be ahead of that, not catching up to it. Structuring your requirements to make safety-security interactions visible is not a nice-to-have for future programs. For any connected safety-critical system entering development today, it is a certification prerequisite.