Cybersecurity Requirements Are Now a Hardware Problem: How DO-326A, UN R155, and IEC 62443 Are Changing Hardware Engineering

For most of the past two decades, the division of labor around cybersecurity was simple enough that nobody questioned it: software teams owned encryption, authentication, and patching; hardware teams owned performance, power, and signal integrity. That division is over.

Three regulatory frameworks — DO-326A in aviation, UN R155 in automotive, and IEC 62443 in industrial control systems — have converged on the same conclusion: the security of a system is only as strong as the hardware it runs on. Secure boot chains, hardware security modules (HSMs), physically unclonable functions (PUFs), side-channel attack resistance, and supply chain provenance are now explicit requirements in certification and type approval processes. Hardware engineers who have not engaged with these standards are already behind on programs that are active today.

This is not a prediction about where the industry is heading. It is a description of where it already is.

Why Hardware Became the Battleground

The shift has a technical explanation and a regulatory one.

Technically, attackers adapted. Once software-layer defenses matured — code signing, encrypted communications, privilege separation — adversaries moved down the stack. Fault injection attacks use voltage glitching or electromagnetic pulses to corrupt CPU execution and bypass security checks. Power analysis attacks extract cryptographic keys from the electromagnetic emissions of a device doing legitimate cryptographic work. Supply chain compromises implant malicious functionality in silicon or firmware before a device ever reaches its operator. None of these attacks is defeated by a software patch.

Regulators noticed. The aviation, automotive, and industrial sectors each responded with frameworks that explicitly address the hardware attack surface. The language differs by domain, but the substance is converging: if you cannot demonstrate that your hardware resists physical and supply chain attacks, you cannot certify the system.

DO-326A: Aviation’s Airworthiness Security Process Standard

DO-326A (with its companion document DO-356A for airworthiness security methods) is published by RTCA and accepted by the FAA and EASA. It defines the security process that aircraft, engines, and avionics must follow to achieve or maintain type certification. The standard is explicitly tied to airworthiness: a cybersecurity vulnerability that could affect safe flight is treated as an airworthiness issue.

What it demands from hardware engineers:

DO-326A requires an Aircraft Security Risk Assessment (ASRA) that traces threats through the aircraft architecture down to individual components. For hardware, this means identifying which components are on security-critical paths and what protections they provide. Secure boot roots of trust — the hardware anchor that verifies the first firmware loaded at power-on — must be documented, their integrity argued through the ASRA, and their behavior verified in the V&V record.

The standard also requires that software/hardware partitioning decisions be made with security in mind, not just safety and performance. A hardware partition that provides security isolation between a safety-critical avionics function and a connected cabin system must be documented and its effectiveness demonstrated.

Critically, DO-326A is change-driven. Every time the aircraft configuration changes — new software load, hardware replacement, new connected service — the security case must be re-evaluated. This creates a continuous engineering obligation that document-based approaches struggle to keep current.

The gap it exposes: Most avionics programs have mature DO-178C (software) and DO-254 (hardware) processes, but those processes were designed around functional correctness and failure modes, not adversarial threat models. DO-326A does not replace those processes — it runs alongside them and demands that security requirements be traceable through the same V&V framework. Teams that manage safety requirements and cybersecurity requirements in separate tools, with separate traceability matrices, are creating exactly the kind of gap that certification authorities will flag.

UN R155: Automotive Cybersecurity Management Systems

UN Regulation No. 155, adopted under the UNECE WP.29 framework and now mandatory for new vehicle type approvals in the EU, Japan, South Korea, and other markets, takes a different structural approach. Rather than specifying technical requirements directly, it mandates that manufacturers establish and maintain a Cybersecurity Management System (CSMS) — a documented organizational process for identifying, managing, and monitoring cybersecurity risks across the vehicle development lifecycle and throughout the vehicle’s operational life in the field.

What it demands from hardware engineers:

UN R155 requires threat analysis and risk assessment (TARA) to cover the full vehicle attack surface, which explicitly includes hardware interfaces: CAN bus, LIN, FlexRay, Ethernet, USB, JTAG/debug ports, and physical access points. For each identified attack path, the CSMS must document mitigations, and those mitigations must be verified.

Hardware-specific mitigations called out in UN R155’s guidance include: disabling or protecting debug interfaces in production hardware, implementing secure boot to protect ECU firmware integrity, hardware separation between safety-critical and non-safety-critical domains, and HSM deployment for key storage and cryptographic operations.

The supply chain dimension is explicit. Manufacturers must monitor cybersecurity risks in their supply chain and ensure that Tier 1 and Tier 2 suppliers operate under compatible CSMS processes. This means hardware component sourcing decisions — choosing between two microcontrollers, for example — now carry a cybersecurity due diligence obligation that did not exist five years ago.

The gap it exposes: UN R155 does not expire at production. The CSMS obligation continues through the vehicle’s operational life, meaning threat landscapes must be reassessed as new vulnerabilities emerge. For hardware engineers, this creates a novel obligation: design for updateability and monitorability. A hardware security architecture that cannot be patched or remotely monitored may satisfy type approval but create a CSMS gap within years of vehicle launch.

IEC 62443: Industrial Control System Security by Zone and Conduit

IEC 62443 is the dominant standard for industrial automation and control system (IACS) security, developed by ISA and adopted by IEC. It applies across sectors — energy, water, manufacturing, building automation — wherever programmable controllers, HMIs, and field devices form a network that controls physical processes.

The standard is structured in layers (general, policies, system, component) and introduces the concept of Security Levels (SL 1–4), which describe resistance to attack from successively sophisticated adversaries, up to nation-state actors with unlimited resources (SL 4).

What it demands from hardware engineers:

IEC 62443-4-2, the component-level standard, places hardware requirements directly on device manufacturers. Components must support: authenticated boot and firmware update, protection of cryptographic keys in hardware (HSM or equivalent), protection of security-relevant configuration, and logging of security-relevant events.

The zone-and-conduit architecture model places an obligation on systems engineers to define security zones, assign security levels to each zone, and design the conduits (data flows between zones) with appropriate controls. Hardware decisions — which devices sit in which zone, what physical interfaces cross zone boundaries, how devices are physically secured — are architectural security decisions, not implementation details.

Side-channel resistance appears more explicitly in IEC 62443 than in the other two standards, particularly for components operating at SL 3 and SL 4. A device that stores cryptographic keys must demonstrate resistance to physical attacks including power analysis and fault injection. This is a hardware characterization requirement, not a software one.

The gap it exposes: IEC 62443 compliance is often managed by OT security teams who lack deep hardware engineering backgrounds, and by hardware engineers who lack security training. The standard’s layered structure helps — system-level and component-level requirements are addressed separately — but the integration between them must be explicitly managed. A systems engineer who has defined a zone architecture at SL 3 must be able to trace that requirement to specific hardware capabilities in the components populating that zone.

The Integration Problem: Security and Safety in the Same V&V Framework

All three standards share a common implication that is more disruptive to engineering practice than any individual technical requirement: cybersecurity requirements must live in the same requirements management and V&V framework as functional safety and performance requirements.

This is not how most programs are run today. The typical pattern is:

  • Safety requirements in DOORS or a similar tool, managed by systems engineers
  • Cybersecurity requirements in a separate threat model or risk register, managed by a security team
  • Hardware verification against functional specs, with security testing handled by a separate red team or certification consultant
  • Manual reconciliation between these artifacts at review gates, with no persistent traceability

This pattern creates structural problems. When a design change is made to address a safety concern, its cybersecurity implications may not be evaluated. When a threat assessment identifies a new attack vector, the hardware requirements that should respond to it may not be updated. Regulators reviewing DO-326A certification packages, UN R155 CSMS documentation, or IEC 62443 assessments are increasingly asking for evidence of integrated management — not separate documents that claim to be consistent.

The practical answer is architectural: security requirements need to be first-class entities in the same requirements graph as safety, functional, and interface requirements. They need to be allocated to hardware components. They need to be verified by test cases that link back to those requirements. And when the threat model changes, the impact on downstream requirements and verification activities needs to be traceable automatically — not discovered in a review meeting.

Two Hardware Requirements Most Commonly Missing

In practice, two categories of hardware requirement are consistently underaddressed in systems engineering workflows:

Side-channel attack resistance. This is not a software property. Power trace analysis during AES encryption, electromagnetic emissions during RSA key operations, timing variations during conditional branches — these are hardware characterization problems. Designing a device to resist them requires architectural decisions about power supply filtering, clock management, execution masking, and sometimes custom silicon. Most requirements management workflows have no established pattern for capturing these requirements, allocating them to hardware, and defining acceptance criteria for verification.

Supply chain integrity. All three standards require some form of supply chain assurance. In practice, this means documenting the provenance of security-critical components, requiring certificates of conformance for HSMs and secure microcontrollers, and establishing processes to detect counterfeit or tampered components. Hardware teams are often responsible for component selection and procurement but have no established process for connecting those decisions to cybersecurity requirements. The result is a gap between the TARA or ASRA (which identifies supply chain as a threat vector) and the bill of materials (which has no security provenance documentation).

How Modern Tools Are Responding

Managing the integration between safety, functional, and cybersecurity requirements across a complex hardware architecture is a tractable problem — but it requires tools designed for it.

Legacy requirements management platforms like IBM DOORS and Polarion were built around document hierarchies and tabular traceability. They can store cybersecurity requirements alongside safety requirements, but making those requirements structurally connected — so that a change to a threat assessment automatically surfaces affected hardware requirements — requires significant configuration effort and discipline to maintain.

Newer platforms, particularly those built on graph-based requirement models, handle this more naturally. Flow Engineering, for example, represents requirements, components, interfaces, and test cases as nodes in a connected graph rather than rows in a matrix. This means a cybersecurity requirement derived from a TARA finding can be directly linked to the hardware component it constrains, to the verification activity that tests it, and to the system-level safety argument it supports. When a threat model update changes a requirement, the impact propagates through the graph visibly — not as a manual change notice that may or may not reach the right engineer.

For programs working under DO-326A, UN R155, or IEC 62443, this kind of connected traceability is not a convenience feature. It is the mechanism by which the integrated security-safety V&V argument is built and maintained over the program lifecycle.

Honest Assessment: Where the Industry Is

Regulatory compliance timelines for these standards are not uniform. DO-326A is already active in FAA and EASA certification processes; programs that received type certificates before its adoption are being asked to address it during continued airworthiness. UN R155 mandatory dates have passed for new vehicle types in the EU and other adopting markets. IEC 62443 is referenced in procurement contracts across energy and industrial sectors with increasing frequency.

The gap between what the standards require and what most hardware engineering programs currently deliver is real. It is not primarily a technical gap — the hardware capabilities (HSMs, PUFs, secure boot architectures) are mature and available. It is a process gap: cybersecurity requirements are not integrated into hardware engineering workflows in a way that satisfies the integrated V&V argument the standards require.

Closing that gap is a systems engineering problem before it is a hardware engineering problem. The first step is architectural: treat cybersecurity as a requirement type with the same rigor as functional safety, allocate it to hardware, and build the traceability that connects threat models to silicon decisions. The standards are demanding exactly that. The programs that figure out how to deliver it systematically — not through heroic consultant-driven certification efforts, but through repeatable process — will have a significant advantage in certification timelines and post-certification change management.

The hardware team is now on the security team. The question is whether the tools and processes reflect that.