How to Specify Cybersecurity Requirements for Connected Hardware Systems
Connected hardware systems — industrial controllers, fly-by-wire avionics, automotive ECUs — are not the same engineering problem they were ten years ago. They are now nodes in a network, with persistent remote access, software update channels, and data flows that cross organizational boundaries. Every one of those connections is an attack surface. Specifying requirements that actually govern how these systems resist attack, across a product lifecycle that may span fifteen years, is one of the most underspecified engineering challenges in the field.
This article answers the question directly: what is the right way to specify cybersecurity requirements for a connected hardware system? The answer depends on which regulatory framework governs your domain — and on understanding a distinction that practitioners routinely blur.
The fundamental distinction: requirements versus architecture decisions
A cybersecurity requirement states what the system shall do — or what it shall prevent — in terms of behavior visible from outside the system boundary. A security architecture decision states how the system achieves that behavior through internal mechanisms.
This separation is not academic. When you write “the system shall use AES-256 encryption for all data in transit,” you have written an architecture decision, not a requirement. The requirement is “the system shall protect the confidentiality of all data transmitted between the field device and the control server against interception by unauthorized parties.” AES-256 is one way to satisfy that requirement. So is ChaCha20. So is a physically isolated network segment. The requirement constrains the outcome; the architecture decision constrains the implementation.
Conflating the two creates problems in every direction:
- Requirements reviewers who are not cryptographers cannot evaluate correctness because they cannot distinguish intent from implementation.
- Verification teams write test cases against the mechanism rather than the behavior, so a change in cipher suite invalidates test coverage even if security posture is unchanged.
- When a vulnerability is discovered in the specified mechanism, it is unclear whether changing the mechanism requires a requirements change — triggering full regulatory re-review — or whether it is a contained design update.
All three major frameworks — IEC 62443, DO-326A, and UNECE WP.29 — implicitly or explicitly enforce this separation. Understanding how each one does so is the first step toward writing requirements that will survive regulatory scrutiny and a fifteen-year lifecycle.
IEC 62443: Industrial automation and control systems
IEC 62443 is a family of standards covering industrial cybersecurity from policy (Part 2-1) through system-level requirements (Part 3-3) to component-level requirements (Part 4-2). For connected hardware, Part 3-3 is the most directly relevant: it defines Security Level requirements for industrial automation and control systems (IACS) and specifies the foundational requirements (FRs) and system requirements (SRs) that map to them.
The standard’s structure enforces the requirement/architecture distinction by design. FR 3, for example, is “Data Integrity” — a statement about what the system shall ensure, not how. The SRs under FR 3 then decompose this into verifiable system behaviors: “SR 3.1: Communication Integrity — The control system shall provide the capability to protect the integrity of transmitted information.” This is still a requirement, not an architecture decision. How you implement communication integrity — whether through cryptographic message authentication, physical layer isolation, or protocol-level sequence numbering — is left to the implementer.
Where threat analysis enters
IEC 62443-3-2 defines the Security Risk Assessment (SRA) process, which is the structured threat analysis that drives derived security requirements. The process:
- Identifies assets within the IACS and their associated consequences of compromise.
- Identifies threats and vulnerabilities against those assets.
- Assesses risk as a function of consequence and likelihood.
- Determines the target Security Level for each zone and conduit.
- Derives specific security requirements to achieve that target Security Level.
The derived requirements in step 5 are where most specification errors occur. Teams often carry forward threat analysis conclusions as findings (“attacker can intercept Modbus traffic on Segment B”) without converting them into requirement statements (“the system shall authenticate all Modbus traffic between the HMI and PLC on Segment B before executing write commands”). The threat analysis output tells you what to worry about; the derived requirement tells the design team what to build and the verification team what to test.
DO-326A: Airworthiness security for avionics
DO-326A (with its companion DO-356A for implementation assurance) is the RTCA standard accepted by FAA and EASA for addressing intentional unauthorized electronic interaction (IUEI) in airborne systems. It is explicitly modeled on the DO-178C / DO-254 safety assurance framework, which means it inherits that framework’s emphasis on traceability from high-level requirements through low-level requirements to implementation and verification.
The threat analysis method in the aviation domain is the Information Security Risk Assessment (ISRA), defined in DO-326A Section 5. The ISRA produces security requirements that are assigned an Airworthiness Security Process Assurance Level (ASPAL), analogous to Design Assurance Level (DAL) in safety. The higher the assessed impact of a successful attack, the more rigorous the process for specifying, implementing, and verifying the countermeasure.
Several things distinguish DO-326A from IEC 62443 in how it handles requirement specification:
Traceability is mandatory and auditable. DO-326A requires that each security requirement be traceable back to the threat it addresses, forward to the design implementation, and forward again to verification evidence. This is not a documentation recommendation; it is a certification requirement.
“Security environment assumptions” are first-class requirements artifacts. The standard requires that the operational environment for the aircraft (aircraft operator procedures, ground infrastructure, maintenance access) be explicitly captured as assumptions that bound the security analysis. When those assumptions change — a new maintenance tool is introduced with a new attack surface — the security requirements derived from them must be re-evaluated.
Architecture decisions must be separated from security requirements. The standard distinguishes Security Requirements (SRs) from Security Implementation Decisions (SIDs). An SR might be: “The avionics network shall prevent unauthenticated commands from the passenger cabin domain from reaching flight-critical functions.” An SID implementing it might be: “A data diode shall be installed on the cabin-to-avionics bus interface.” The SR is what gets verified; the SID is what gets reviewed for correctness.
UNECE WP.29: Automotive cybersecurity management
UNECE WP.29 Regulation No. 155 (R155) mandates that automotive OEMs implement a Cybersecurity Management System (CSMS) as a condition of type approval in signatory markets (EU, Japan, South Korea, and others). ISO/SAE 21434 is the technical standard that most OEMs use to implement R155 requirements.
The core threat analysis method in 21434 is TARA — Threat Analysis and Risk Assessment. TARA is a structured process that:
- Identifies damage scenarios (what can go wrong and what harm it causes).
- Identifies threat scenarios (how an attacker causes the damage scenario).
- Assesses attack feasibility.
- Derives a risk level.
- Selects a risk treatment: avoid, reduce, share, or accept.
When risk treatment is “reduce,” the treatment decision generates a cybersecurity goal — a high-level security requirement that the vehicle item or component shall satisfy. Cybersecurity goals are then refined into cybersecurity requirements at the system, hardware, and software levels.
The critical distinction in 21434 is between cybersecurity goals and cybersecurity requirements. A cybersecurity goal is intentionally technology-agnostic: “The telematics unit shall prevent unauthorized remote control of vehicle dynamics functions.” A cybersecurity requirement operationalizes it at an appropriate level of abstraction: “The telematics unit shall authenticate all remote commands using a challenge-response mechanism before forwarding them to the vehicle network.” The choice of specific authentication protocol — HMAC-SHA256, certificate-based mutual TLS — is a design decision that traces to the requirement but is not the requirement itself.
The evolving attack surface problem
All three frameworks share a structural assumption that creates operational difficulty: the threat analysis is primarily conducted at design time, before deployment. But the attack surface of a connected hardware system does not freeze at launch. It evolves because:
- Software updates add new interfaces, libraries, and communication patterns.
- New vulnerabilities are disclosed in components that were secure at design time.
- The operational environment changes — new network segments, new third-party devices connected to the same bus.
- Regulatory authorities update threat guidance based on observed attacks across the industry fleet.
IEC 62443 addresses this through its Operations and Maintenance phase requirements (Part 2-1, Part 2-3), which require ongoing vulnerability management. UNECE R155 explicitly requires OEMs to monitor cybersecurity threats post-deployment and to trigger re-analysis when new threats emerge. DO-326A requires that security environment assumptions be re-validated when changes occur.
The gap between the regulatory intent and typical engineering practice is significant. Most programs treat TARA or SRA or ISRA as documents produced once during development and maintained through controlled change management. In practice, when a new CVE is disclosed against a communications library embedded in a deployed ECU, the question “does this change our risk rating, and if so, which requirements are now under-satisfied?” often has no clean answer because the traceability from threat model to requirements to verification evidence was never built to be navigated in that direction.
Specifying requirements correctly in the first place only solves half the problem. The other half is maintaining the connection between threat evidence and requirement status as both evolve.
How modern tooling approaches this problem
This is where the practical toolchain question becomes unavoidable. Traceability between TARA outputs, derived security requirements, design decisions, and verification evidence is not something you can manage sustainably in a word processor or a spreadsheet — not because those tools are philosophically wrong, but because they have no mechanism to surface broken links when upstream artifacts change.
Flow Engineering (flowengineering.com) is built around the model that requirements and their evidence exist in a graph, not a document. In that model, a TARA threat scenario is a node. The derived cybersecurity goal it generates is a linked node. The system-level security requirement refined from that goal is another node. The verification record that closes the loop is a fourth node. When the threat model is updated — because a new attack path was identified, or a risk rating changed — the impact on downstream requirements and open verification gaps is computable rather than manually hunted.
For programs operating under DO-326A, where traceability is a certification artifact, this structure maps directly onto what an airworthiness authority expects to see: a connected chain from threat through requirement through implementation through test evidence. For automotive programs under R155, where post-deployment threat monitoring must trigger re-analysis, Flow Engineering’s live graph means that a threat model update that elevates a previously accepted risk immediately surfaces the requirements and verification records that need re-evaluation — rather than requiring an engineer to manually reconstruct which requirements were derived from the affected threat scenario.
Flow Engineering is purpose-built for hardware and systems engineering programs rather than general product development, which means the traceability constructs match the vocabulary that systems engineers actually use: security requirements linked to threat scenarios, not user stories linked to epics. That focus also means it does not currently offer the deep document publishing workflows that legacy tools like IBM DOORS or Jama Connect provide for programs that still need to generate structured regulatory submission documents in word-processor format — that is a deliberate trade-off, not an oversight.
Practical starting points
If you are beginning or restructuring a cybersecurity requirements program for a connected hardware system, the sequence matters:
1. Run the threat analysis first, with output that generates requirements. TARA, SRA, and ISRA are not risk registers. They are requirement generators. Structure the output so that each identified risk that is treated (reduced) produces a discrete, named cybersecurity goal or security requirement — not just a finding.
2. Write requirements in behavioral terms, without mechanism. Test each candidate requirement: if it names a technology, an algorithm, or a component, it is probably a design decision, not a requirement. Move the mechanism to a design artifact that traces to the requirement.
3. Assign verification methods at requirement time. Each security requirement should have an assigned verification method — test, analysis, inspection, demonstration — before design begins. If you cannot describe how you would verify it, the requirement is not well-formed.
4. Build the traceability graph bidirectionally. You need to navigate from threat to requirement to verify — but also from “new threat” to “which existing requirements are affected” and from “requirement changed” to “which tests are now invalid.” Tools that only support forward traceability will fail you post-deployment.
5. Plan for post-deployment threat model updates as a repeating engineering activity. Identify who owns the threat model, on what cadence it is reviewed, and what the workflow is for a change in risk rating to propagate to open or closed requirements. If there is no workflow, the regulatory requirement to monitor threats is unfulfillable in practice.
Getting cybersecurity requirements right is not primarily a documentation problem. It is a systems engineering problem with a documentation consequence. The frameworks provide the structure. The engineering discipline — separating what from how, keeping traceability live, treating threat model updates as requirement-driving events — is what makes that structure useful in a deployed system’s real lifecycle.