IEC 62443-4-2: component requirements
Sytance · Updated
IEC 62443-4-2:2019 is the component requirements part. It defines technical requirements for IACS components and component security capability levels through the seven foundational requirements.
Defining the component
A component is not the whole IACS. The assessment should identify the component type, product version, intended IACS use, interfaces, assumptions, excluded functions, and SL-C(component) being claimed. These details determine which uses and configurations the assessed capability applies to.
Embedded devices include controllers, PLCs, drives, gateways, and dedicated industrial devices supplied for IACS use. The component scope should name the product version, interfaces, and intended security capability.
Network devices include industrial switches, routers, firewalls, gateways, and similar products that carry or restrict IACS communication. Their component evidence does not replace conduit design.
Host devices include servers, workstations, industrial computers, and similar platforms used to run or support IACS functions. The hard part is often the boundary between the host, installed software, and the configured system.
Software applications include engineering tools, HMI software, historians, control applications, and supporting software supplied for IACS use. The product supplier still needs to connect 4-2 evidence to the secure development lifecycle behind that release.
Foundational requirements
IEC public material lists seven foundational requirements used by IEC 62443-4-2. These families organise the component requirements and capability levels; each has specific technical meaning.
- identification and authentication control (IAC);
- use control (UC);
- system integrity (SI);
- data confidentiality (DC);
- restricted data flow (RDF);
- timely response to events (TRE);
- resource availability (RA).
IAC is the foundational requirement family concerned with recognising users, software processes, devices, and other subjects before access is granted.
UC concerns authorised use after identity is known. It is distinct from identification because the question is what an authenticated subject may do.
SI concerns protection against unauthorised change, malicious code, and loss of integrity in the component or control system function.
DC concerns protection of information from unauthorised disclosure. It does not make every IACS data item equally confidential.
RDF concerns limiting data flows and communication paths. At system level, this usually connects to zones, conduits, and network segmentation.
TRE concerns event detection, reporting, and response capability. It should be read with the component's actual monitoring and logging functions.
RA concerns preserving resources needed for the component or system to perform its intended security and control functions.
Capability limit
IEC states that IEC 62443-4-2 is about SL-C(component), not SL-T or SL-A. That distinction matters. A component may have a claimed capability level, but a deployed system still needs a system under consideration, zones, conduits, risk assessment, operational procedures, and validation of the actual configuration.
Secure development under IEC 62443-4-1
Component evidence is stronger when the supplier can also show that the product was developed and maintained under an IEC 62443-4-1 lifecycle.
Integration into the system
The system designer still decides how the component is placed in a zone, what conduits it uses, and which controls surround it.
CEN-CENELEC’s 9 September 2025 webinar material describes work on EN IEC 62443-4-2:2019/A11:2026 for CRA alignment, including applicability criteria and evaluation artefacts. That planned European work should not be collapsed into a claim that every existing 4-2 certificate is a CRA harmonised-standard result.