IEC 62443-4-2: Component Security Requirements and How to Meet Them

This page is part of the IEC 62443 compliance hub.

IEC 62443-4-2 is the part of the standard that product vendors and device manufacturers are most directly accountable to. It defines the technical security requirements that individual IACS components must meet, sets out how those requirements scale with security level, and drives the testing obligations that certification assessors focus on most closely.

This guide explains what IEC 62443-4-2 requires, which component types it covers, how security levels affect your obligations, and how ProtoCrawler helps you generate the empirical evidence that component-level compliance demands.

What Is IEC 62443-4-2?

IEC 62443-4-2 is the component-level technical security requirements standard within the IEC 62443 series. Published in 2018, it defines the cybersecurity capabilities that individual industrial automation and control system components must possess in order to meet a stated security level.

Where IEC 62443-3-3 addresses security requirements at the system level, IEC 62443-4-2 goes deeper, applying requirements directly to the individual devices and software components that make up an IACS environment. It is the part of the standard that product vendors, device manufacturers and component suppliers are most directly responsible for meeting.

The requirements in IEC 62443-4-2 are inherited from IEC 62443-3-3 but adapted to apply at the component level. System Requirements become Component Requirements, denoted CR rather than SR, and the specific obligations are calibrated to the type of component being assessed.

---

The Four Component Types

IEC 62443-4-2 applies to four distinct categories of component. Understanding which category your product falls into determines the specific requirements that apply.

Embedded devices are special-purpose devices running embedded software designed to directly monitor, control or actuate an industrial process. PLCs, DCS controllers and intelligent electronic devices are typical examples. These are the component type most commonly encountered in IEC 62443-4-2 assessments and the type where protocol-level security testing has the most direct relevance.

Host devices are general-purpose devices running a full operating system capable of hosting one or more software applications. Engineering workstations, data historians and operations computers fall into this category. Host device requirements include OS hardening, patch management and application-level security controls alongside protocol robustness requirements.

Network devices facilitate data flow between components or restrict the flow of traffic between zones. Firewalls, switches, routers and industrial protocol gateways are the primary examples. For network devices, the security of the protocols they handle and the robustness of their traffic processing logic are central compliance concerns.

Software applications are application-layer components such as SCADA software, historian applications and HMI platforms. Software application requirements focus on input validation, authentication enforcement and secure communications alongside the functional security requirements that apply across all component types.

---

The Seven Foundational Requirements

IEC 62443-4-2 organises its Component Requirements under seven Foundational Requirements, inherited from IEC 62443-3-3. Each Foundational Requirement covers a distinct security domain, and Component Requirements within each domain are numbered CR followed by the FR number and a sequential requirement number.

Identification and Authentication Control (FR 1) covers requirements for uniquely identifying and authenticating users, devices and processes before granting access. CR 1.1 through CR 1.13 address requirements including human user authentication, software process authentication, account management and wireless access controls.

Use Control (FR 2) covers requirements for controlling what authenticated entities can do. CR 2.1 through CR 2.12 address authorisation enforcement, wireless use control, session lock and session termination.

System Integrity (FR 3) covers requirements to protect against unauthorised modification of hardware, software and firmware. CR 3.1 through CR 3.9 include communication integrity, malicious code protection and security functionality verification.

Data Confidentiality (FR 4) covers requirements for protecting information from unauthorised disclosure. CR 4.1 and CR 4.2 address information confidentiality and information persistence.

Restricted Data Flow (FR 5) covers requirements for network segmentation and the restriction of data flows between zones. CR 5.1 through CR 5.4 address network segmentation, zone boundary protection and remote session management.

Timely Response to Events (FR 6) covers requirements for audit logging, monitoring and response to security events. CR 6.1 and CR 6.2 address audit log accessibility and continuous monitoring.

Resource Availability (FR 7) covers requirements for maintaining availability and capacity under adverse conditions. CR 7.1 through CR 7.8 include denial-of-service protection, resource management, backup integrity, recovery and emergency power. FR 7 is the Foundational Requirement most directly addressed by protocol fuzz testing.

---

How Security Levels Work in IEC 62443-4-2

IEC 62443-4-2 uses the same Security Level framework as the rest of the IEC 62443 series, but applies it at the component level. Security Levels define the degree of protection a component is designed to provide against progressively more capable threat actors.

SL 1 addresses protection against casual or unintentional violations. Components at SL 1 must meet the baseline Component Requirements across all seven Foundational Requirements. This represents the minimum acceptable security capability for components deployed in IACS environments.

SL 2 addresses protection against intentional violation using simple means with low resources. This is the level most commonly required by customers and regulators for components deployed in operational critical infrastructure. At SL 2, requirements are extended and the depth of testing evidence expected increases substantially.

SL 3 addresses protection against intentional violation using sophisticated means with moderate resources. This level is relevant for components deployed in critical national infrastructure environments where the threat profile includes well-resourced adversaries. Penetration testing becomes mandatory at SL 3.

SL 4 addresses protection against state-sponsored attacks. Very few commercial components are assessed at this level, and it applies to the most sensitive environments only.

The security level you are targeting determines not just which requirements apply but the depth and breadth of testing evidence required to support a credible compliance claim. Moving from SL 1 to SL 2 significantly increases the testing obligation, and assessors will expect to see evidence that reflects this.

---

The Key Clauses That Drive Testing

Several Component Requirements within IEC 62443-4-2 have direct implications for protocol-level security testing. These are the clauses that certification assessors focus on most closely when reviewing component compliance evidence.

CR 3.5 (Input Validation) requires that components validate the syntax and content of inputs from all sources. This means devices must safely handle malformed, out-of-range and unexpected inputs without entering unsafe or undefined states. Buffer overflows, state machine failures and unexpected behaviours triggered by malformed protocol messages are all findings that directly indicate a failure to meet CR 3.5. This requirement applies to all four component types and all security levels.

CR 7.1 (Denial of Service Protection) requires that components protect against denial-of-service conditions resulting from resource exhaustion or other attacks. Devices that reset, freeze or become unresponsive when subjected to unexpected traffic volumes or malformed inputs fail this requirement. Protocol fuzz testing is the primary method for generating evidence that CR 7.1 is met.

CR 7.2 (Resource Management) requires that components manage the resources they consume to avoid resource exhaustion conditions. This is related to CR 7.1 but focuses on how the component manages memory, processing and communications resources under load.

CR 1.1 (Human User Identification and Authentication) and related authentication requirements drive testing of how components handle malformed or absent authentication data. Missing authentication headers, replayed credentials and out-of-sequence authentication messages are all test cases that protocol fuzz testing covers systematically.

CR 3.1 (Communication Integrity) requires that components protect against unauthorised modification of transmitted information. For components implementing industrial protocols, this means testing that integrity mechanisms cannot be bypassed through malformed or crafted inputs.

For the detailed clause-by-clause mapping to specific fuzz testing requirements, see the IEC 62443 fuzz testing guide.

---

IEC 62443-4-2 vs IEC 62443-4-1: Understanding the Difference

IEC 62443-4-2 and IEC 62443-4-1 are closely related but address fundamentally different questions, and understanding the distinction is important for planning your compliance programme correctly.

IEC 62443-4-2 is about what your product does. It defines the technical security capabilities that a component must demonstrate and assesses them at a stated security level. The evidence required is empirical: does the device actually behave securely under test conditions?

IEC 62443-4-1 is about how your product is built. It defines the requirements for a secure product development lifecycle and assesses the processes used to develop, test and maintain a product. The evidence required is procedural: does your development process incorporate the security practices the standard requires?

The two parts are complementary. A product that meets IEC 62443-4-2 technical requirements but was developed without a compliant IEC 62443-4-1 process cannot achieve full certification. ISASecure’s Component Security Assurance certification, the primary third-party certification route for IEC 62443-4-2, requires that the supplier has first achieved or is concurrently working towards SDLA certification under IEC 62443-4-1.

In practice, most UK product vendors begin with the technical requirements of IEC 62443-4-2, generate testing evidence against the relevant Component Requirements, and then address the process requirements of IEC 62443-4-1 as they formalise their secure development lifecycle. For guidance on the certification process and timelines, see the IEC 62443 certification UK guide.

For the full breakdown of IEC 62443-4-1’s eight practices, maturity levels and tester independence requirements, see the IEC 62443-4-1 secure development lifecycle guide

---

IEC 62443-4-2 Certification

IEC 62443-4-2 is certifiable through several schemes. The two most relevant for UK product vendors are ISASecure Component Security Assurance and IECEE CBTL product testing.

ISASecure CSA certification covers four component types at security levels 1 and 2. Achieving CSA certification requires passing three assessment elements: the Security Development Lifecycle Process Assessment for Component Development, which assesses development process alignment with IEC 62443-4-1; the Security Development Artefacts assessment, which reviews the outputs of the development lifecycle; and the Functional Security Assessment, which tests the component’s security capabilities against IEC 62443-4-2 requirements directly. Accredited ISASecure laboratories include Exida and TÜV Rheinland.

IECEE CBTL testing provides an alternative route through the IEC’s own certification body framework. Accredited laboratories assess products against IEC 62443-4-2 requirements and issue CB reports that can be used as the basis for national certification.

Customer-led assessments against IEC 62443-4-2 requirements are more common in practice than formal third-party certification for many UK vendors. The evidence requirements are essentially the same and structured protocol testing evidence from ProtoCrawler maps directly to what both formal assessors and customer procurement teams look for.

---

Why Protocol Testing Is Central to 4-2 Compliance

IEC 62443-4-2 is a technical requirements standard. Demonstrating compliance means demonstrating that your component actually meets the requirements under test conditions, not just that your documentation says it should.

For embedded devices and network devices in particular, the protocol stack is where most of the technical security requirements manifest. CR 3.5 input validation, CR 7.1 denial-of-service protection and CR 1.1 authentication enforcement are all requirements that are tested at the protocol level. A device’s behaviour when it receives malformed, out-of-sequence or deliberately crafted protocol messages is the empirical test of whether these requirements are met.

Generic IT security tools cannot perform this testing. They do not understand the application-layer structure of Modbus, DNP3, IEC 61850 or IEC 60870-5-104. They cannot generate the protocol-specific inputs that surface real implementation vulnerabilities in these protocols.

Protocol fuzz testing with a tool that understands industrial protocols at the application layer is the mechanism that bridges the gap between documented intent and empirical evidence for IEC 62443-4-2 compliance.

---

How ProtoCrawler Supports IEC 62443-4-2

ProtoCrawler is Cytal’s automated protocol fuzz testing platform, built specifically for OT and industrial environments. It addresses the IEC 62443-4-2 testing requirements directly and produces the structured evidence that assessors require.

For CR 3.5 input validation, ProtoCrawler generates thousands of malformed, out-of-range and unexpected inputs across all protocol fields and message types, records exactly how the device responds to each, and scores findings based on severity. This produces direct evidence of whether the component meets the input validation requirement at the stated security level.

For CR 7.1 denial-of-service protection, ProtoCrawler exercises devices under sustained adverse traffic conditions and records whether they maintain availability, degrade gracefully or fail. The output is evidence that directly addresses the denial-of-service protection requirement.

For authentication-related requirements in FR 1, ProtoCrawler tests how devices handle malformed, absent and replayed authentication data within protocol messages, surfacing authentication bypass vulnerabilities that only manifest when the protocol stack is exercised under adversarial conditions.

ProtoCrawler’s reporting capability produces outputs that are directly usable as IEC 62443-4-2 compliance evidence, including scope documentation, test configuration records, scored findings mapped to specific requirements, and coverage traceability. Reports can be customised for sharing with certification bodies and customer procurement teams.

For the full list of industrial protocols supported by ProtoCrawler, see the protocol models page. For a broader view of what a complete IEC 62443 compliance testing programme involves, see the IEC 62443 compliance testing guide.

---

Ready to build your IEC 62443-4-2 compliance evidence? Book a demo to see how ProtoCrawler tests your component against the requirements that matter most.

Explore the full IEC 62443 compliance hub for the complete set of guides covering certification, compliance testing and protocol security requirements.