Focus: System security
generating time-synchronised security events that your security operations centre (SOC) or monitoring tools can consume. T e benefi ts are immediate. Secure
communications combined with enforced segmentation shrink the blast radius and make lateral movement noisier and easier to spot. Role-based access control makes day-to-day operations safer and more auditable because engineers can make routine changes, like adjusting a VLAN or an access list, for example, without gaining blanket control of the device estate. Event logging turns failed logins, confi guration changes and policy violations into data that can be searched, alerted on and presented as evidence during audits. Integrity protections and rollback support reduce the risk that failed upgrades or power dips leave devices in an unknown, potentially exploitable state. For organisations working under
regulations such as NIS/NIS2 or preparing for the UK’s Cyber Security and Resilience Bill, this is what “security by design” looks like in networking products: clearly defi ned identities, controlled access, encrypted communications, constrained fl ows, and auditable behaviour when things go wrong.
Hardening the compute layer Once the network edge is under control, attention naturally shiſt s to the hosts that sit at key junctions. Industrial PCs, gateways and embedded platforms buff er and normalise data, speak legacy or proprietary protocols, run local logic and visualisation, and bridge OT networks into enterprise or cloud systems. T ey are, therefore, attractive targets if not properly hardened. From an IEC 62443-4-2 standpoint,
a secure host device starts with the operating system. T e attack surface needs to be reduced so that only required services are enabled, unused ports are closed and unnecessary packages are removed. Integrity matters too: both OS and application packages should be signed and verifi ed before installation, so that you know what is running. On top of that, secure boot ensures that only trusted, validated code runs from power-on, while
signed packages and a reduced exposed surface; secure and, where practical, measured boot; verifi ed, repeatable patching mechanisms; hardware-backed roots of trust for keys and attestation; and long-term support commitments that align with OT maintenance practices. For UK operators, that trajectory mirrors both the UK policy direction and EU expectations under frameworks like NIS2 and the Cyber Resilience Act, especially around product security and vulnerability handling.
Moxa EDR-G9010 industrial secure router
measured boot can add attestations that remote systems can verify before they place trust in the device. Patch and update handling is just as
critical. OT maintenance windows are limited, and many plants still patch on carefully controlled cycles, so it becomes essential that the correct image is applied, that the update process is resilient to interruptions and that you can roll back safely if an issue is discovered aſt er deployment. A clumsy or opaque update mechanism is a real operational risk in its own right. Here, hardware support is a major
enabler. Trusted Platform Modules provide secure key storage and support for measured boot and attestation. Many modern SoCs include additional roots of trust that can anchor device identity and secure communications, giving you a cryptographic anchor for trust decisions rather than relying on confi guration alone. Lifecycle then becomes the next
question. Industrial hosts oſt en live in the fi eld for many years, sometimes a decade or more. In that context, long-term kernel or OS support, stable driver stacks and clear, documented update policies turn into risk controls as much as convenience features. If a device cannot be kept patched and supported over its realistic lifetime, it becomes a liability, however good its security posture was on day one. When industrial PCs and gateways are
designed to IEC 62443-4-2 expectations, you should see all of these things at once: a hardened OS and application stack with
12 December 2025/January 2026
www.electronicsworld.co.uk
Security levels, compliance and certifi cation IEC 62443 introduces security levels (SL1- SL4) to describe how robustly a component or system defends against diff erent classes of attacker. In many industrial environments, the emphasis falls on SL1 and SL2: • SL1 focuses on protection against accidental misuse and casual interference, providing a baseline around confi guration, access and integrity.
• SL2 assumes intentional attacks using simple, widely available techniques and raises expectations around hardening, key handling, service minimisation and update protections such as integrity checks and rollback safeguards. In practice, SL2 oſt en fi ts perimeter
routers, fi rewalls, managed switches and hosts that terminate remote access or perform protocol translation, because a compromise at those points can have a wide-ranging impact. SL1 may be appropriate for lower-impact monitoring or distribution layers where the consequences of compromise are more limited and where risk assessments support a lighter-weight approach. Alongside security levels, it is useful to
distinguish between compliant and certifi ed products. A compliant device is one where the supplier can demonstrate how features and processes map to IEC 62443-4-2 requirements. T e product may not have a formal certifi cate, but it has been designed with the standard in mind, and the vendor can explain how it addresses identity, access control, logging, integrity and so on. A certifi ed device has gone a step further. It has been independently assessed against
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48
