Secure-by-Design: Hardware-Software Co-Design for Robust IEDs in ICS

Industrial Control Systems (ICS) constitute the operational core of critical infrastructure such as electric power grids, water treatment networks, natural gas distribution, and transportation systems. Unlike conventional IT environments, ICS combine digital and physical systems whose behaviours directly affect tangible processes. Intelligent Electronic Devices (IEDs), including protective relays, remote terminal units, and digital controllers, provide interface points between digital networks and physical actuators. However, as these devices increasingly adopt standardized communication protocols over TCP/IP, their exposure to cyber-enabled threats also grows. The convergence of networked communications and real-time control demands a shift in the way embedded devices are designed: security must be engineered into the hardware and software from the outset, rather than added later as a reactive measure.

This aligns with recent regulatory efforts such as the European Cyber Resilience Act (CRA) and the NIS2 directive, which aim to raise the security baseline of digital products and essential services. While often perceived as bureaucratic overhead, these frameworks are a response to the urgent need for harmonized security practices across interconnected systems. The CRA, in particular, establishes a legal basis to hold manufacturers accountable for security negligence without prescribing specific technical thresholds. This creates both an opportunity and a challenge: while compliance does not guarantee robust protection, it does define when liability arises. In this context, making informed design decisions becomes a competitive and legal imperative.

Traditional cybersecurity discussions often emphasize network perimeter defences or software patches. In ICS, where a compromised device can have physical consequences, security must be embedded at the electronic design level. Approaches such as secure hardware foundations, protocol-aware defences, and robust testing against realistic threat scenarios are essential to ensure that IEDs can operate safely and predictably in the face of malicious disturbances. Another key requirement introduced by the CRA is the obligation to monitor and patch vulnerabilities throughout the product lifecycle, enforcing secure update distribution mechanisms and long-term support commitments.

Hardware-Software Co-Design for Secure IEDs

In embedded systems, hardware and software have always been tightly coupled. For secure IED design in ICS environments, this coupling must be intentional and rigorous. Hardware selection and architecture influence the capabilities and limits of software defences, and vice versa. A co-design approach enables the implementation of features such as:

• Secure Boot and Measured Boot Hardware support for cryptographically authenticated boot processes prevents unauthorized firmware from executing. Measured boot chains record the state of executed components, enabling trusted attestation during system operation.
• Dedicated Security Engines Integrated cryptographic accelerators handle encryption, decryption, and authentication operations without overtaxing the main CPU. Offloading these tasks to hardware enhances performance and reduces attack surfaces.
• Application Domain Separation Through virtualization and containerization techniques, high-risk and safety-critical software components are logically segregated. Combined with board-level signal shielding, this limits the potential impact of compromised subsystems.
• Signal Exposure Minimization PCB layout practices that avoid routing sensitive signals (e.g., between CPU and secure element) on exposed outer layers make it harder to extract cryptographic keys during brief physical access or invasive probing attacks.

Software architecture complements these hardware foundations. Modular firmware with strict privilege separation, sanitization of all external inputs, and robust handling of unexpected conditions reduce the likelihood of exploitable flaws. A well-structured RTOS with process isolation further strengthens the defence in depth.

Protocol-Aware Defence Mechanisms in IEDs

Many ICS communication protocols (e.g., Modbus TCP, DNP3, IEC 61850) were designed for closed systems with little or no threat expectations. In modern deployments where these protocols travel over routed networks, protocol awareness becomes a key defence strategy. To ensure confidentiality and integrity, these legacy protocols must be encapsulated in encrypted tunnels (e.g., SSL/TLS) or confined within secure communication channels such as VPNs.

Protocol-aware defences integrated into device hardware or firmware enable deeper inspection and contextual interpretation of received messages:

• Deep Packet Inspection (DPI) DPI engines analyse packet contents beyond header fields, identifying malformed or anomalous messages that deviate from protocol norms. By recognizing specific command structures, DPI enables devices to reject potentially harmful input early in the processing pipeline.
• Command Whitelisting and Validation Instead of accepting all syntactically valid packets, IEDs can restrict operations to a defined set of authorized commands. Coupled with state validation, this approach prevents unexpected transitions that can arise from crafted sequences.
• Dedicated Control Processors Partitioning communication handling into a dedicated microcontroller or coprocessor reduces the risk that parsing errors in protocol stacks affect control logic. This hardware segmentation enhances resilience against crafted network input targeting parsing vulnerabilities.

These techniques are applicable not only in traditional wired ICS networks but also increasingly in 5G-connected embedded boards and edge devices, where high-speed cellular connectivity exposes IEDs to broader remote attack surfaces, especially in smart energy, transportation, and distributed control applications. Emphasizing protocol semantics rather than mere syntactic verification improves the ability of devices to discern legitimate operational traffic from malicious sequences, shifting the defensive posture from reactive to proactive.

Testing Lab Setup: Simulating Realistic ICS Threats

One of the most common pitfalls in embedded system security is assuming that a device that passes functional tests in benign environments will behave securely under attack. To validate the robustness of IED designs, specialized test infrastructures—often referred to as ICS testbeds—are essential. These allow developers to simulate communication anomalies, deliberate protocol manipulation, and other threat conditions without risking live infrastructure.

A robust testing setup should include:

• Debug and Test Interfaces (Development Only) During development, the board should expose internal buses, memory, and communication lines for analysis. However, in production devices, all debug interfaces must be physically and logically disabled to prevent unauthorized access or tampering.
• Controlled Packet Injection Capabilities Tools that generate malformed or out-of-sequence protocol traffic (e.g., IEC 61850 fuzzing) allow engineers to observe how devices handle unanticipated inputs and whether recovery mechanisms operate correctly.
• Real-Time Monitoring and Logging Capturing detailed behaviour of both communications and control outputs during fault injection enables correlation of external inputs with internal states and responses, helping identify latent vulnerabilities.
• Automated Fault Replay and Regression Once a problematic condition is identified, automated reproduction ensures that fixes are effective and do not introduce regressions in other system areas.

Building a comprehensive testbed is an engineering effort similar to building the product itself: it must mimic real-world conditions and provide repeatable, measurable results to ensure meaningful validation.

From Security Features to Secure Architecture

Engineering secure embedded devices for ICS extends far beyond checking off a list of compliance requirements. While standards such as IEC 61850 (for communication profiles) and IEC 62443 (for system security) offer useful frameworks, truly robust products must be grounded in security at the circuit and system level.

By adopting a secure‑by‑design philosophy, one that integrates hardware support for cryptographic and isolation features, embeds protocol‑aware defences, and validates designs through realistic threat simulations, engineers can build IEDs capable of resisting both inadvertent faults and deliberate attacks. In an environment where the digital and physical intertwine, resilient electronic design is not optional. It is essential to protect the integrity, availability, and safety of the systems we rely on every day.