IEC 62443-4-2 Technical Security Requirements for IACS Components

IEC 62443-4-2 is the international standard for technical cybersecurity requirements for components of industrial automation and control systems (IACS). Other parts of the IEC 62443 series deal with management systems, risk assessment, or systems. IEC 62443-4-2 specifies which security requirements a single component must meet, whether it is a controller, a sensor, a switch, or a piece of software. The current revision and further documents of the IEC 62443 series make the standard even more relevant for modern industrial products.

Contents
  1. Where IEC 62443-4-2 fits in the IEC 62443 series
  2. The essential prerequisite: IEC 62443-4-1
  3. The seven foundational requirements
  4. Security levels by threat profile
  5. What counts as a component under the standard
  6. IIoT components and IEC 62443-1-6
  7. Security profiles for specific component categories: IEC 62443-5-x
  8. Evaluation methodology: IEC TS 62443-6-2
  9. The draft amendment to EN IEC 62443-4-2 (prAA)
  10. Link to EN 50742 and the Machinery Regulation
  11. Outlook

Where IEC 62443-4-2 fits in the IEC 62443 series

IEC 62443-4-2 covers technical requirements for components. This makes it the standard that directly affects product manufacturers. IEC 62443-3-3 sets technical requirements for systems, that is, for integrating several components into an industrial automation and control system. IEC 62443-4-2, by contrast, focuses on the single component, taking into account the context of use defined by the manufacturer.

There is a decisive link to IEC 62443-4-1, which sets requirements for the secure development process. IEC 62443-4-2 explicitly requires components to be developed under a process that conforms to IEC 62443-4-1.

The essential prerequisite: IEC 62443-4-1

You cannot apply IEC 62443-4-2 in isolation. The standard explicitly requires that components claiming conformity have been developed under a development process that conforms to IEC 62443-4-1.

This link is fundamental. Even if a component meets all technical requirements of IEC 62443-4-2 today, it cannot be considered conformant if it was not developed under IEC 62443-4-1. This reflects the understanding that product security is not just a set of technical features. It covers the whole lifecycle, from requirements analysis through development to long-term support.

The seven foundational requirements

The core of IEC 62443-4-2 is a set of seven foundational requirements (FR) that cover the different aspects of component security systematically. Each FR includes several component requirements (CR), which must be met depending on the target security level:

FR 1 Identification and authentication control (IAC)

Covers how a component identifies and authenticates users, processes, and other devices. This includes unique identification of all entities, requirements for password management, multifactor authentication at higher security levels, and protection of the authentication mechanisms themselves.

FR 2 Use control (UC)

Governs authorization, that is, what an authenticated entity is allowed to do. The requirements include authorization enforcement, segregation of duties, the principle of least privilege, and specific controls for privileged access. A component must support a fine-grained permission model.

FR 3 System integrity (SI)

Covers protecting the integrity of the component itself: its software, configuration, data, and communication. Central aspects are communication integrity, protection against malicious code, integrity verification, and input validation as a fundamental security measure against injection attacks.

FR 4 Data confidentiality (DC)

Requires protecting confidential information in transit and at rest. At higher security levels, encryption is mandatory, and where cryptographic methods are used, they must meet current standards.

FR 5 Restricted data flow (RDF)

Covers control of communication. Components must support network segmentation mechanisms, implement the deny-by-default principle, and apply specific security measures at zone boundaries.

FR 6 Timely response to events (TRE)

Requires the capability to detect, record, and respond to security-relevant events. A well-designed logging approach with trustworthy timestamps is fundamental here, complemented by continuous monitoring at higher security levels.

FR 7 Resource availability (RA)

Covers protection against threats to availability, such as denial-of-service attacks and resource exhaustion. Mechanisms such as rate limiting, resource management, and the ability to create backups are central.

Together, these seven requirements form a security model that covers all essential aspects of component security.

Security levels by threat profile

A central concept of IEC 62443-4-2 is the distinction between security levels. They do not describe the quality of a product in the sense of “good” or “bad”. They describe which attacker profiles the product protects against:

Security level 1

Protects against casual or coincidental violation. It does not assume a deliberate attacker.

Security level 2

Protects against intentional violation using simple means. The attacker uses available tools but has no in-depth knowledge of the specific target system.

Security level 3

Protects against targeted attacks with moderate resources. The attacker has specific skills for IACS and a clear motivation.

Security level 4

Protects against attackers with extended resources, specific skills for the target system, and high motivation, such as state-sponsored actors or well-equipped organizations.

Not every component has to reach SL 4. Choosing the appropriate security level is a risk-based decision that depends on the intended context of use.

What counts as a component under the standard

IEC 62443-4-2 defines four types of components, which show how broad the scope of the standard is:

Software applications

Software applications are software products used in industrial environments. Examples include SCADA systems, historian databases, MES applications, engineering tools, and asset management software. What matters is not whether the software runs on dedicated hardware or on standard PCs, but that it performs a function in an industrial context.

Embedded devices

Embedded devices are devices with built-in software and specialized functions. Typical examples are programmable logic controllers, frequency converters, smart sensors with network communication, actuators with their own logic, and edge gateways. These components usually run embedded operating systems or firmware.

Host devices

Host devices are computer-based systems that perform industrial functions. They include industrial PCs, human-machine interface (HMI) terminals, operator panels, data servers in automation, and engineering workstations. These devices usually run standard operating systems such as Windows or Linux, configured for industrial use.

Network devices

Network devices include all components for network communication: industrial switches, routers, gateways between network levels, industrial firewalls, VPN gateways, and protocol converters. Here too, what matters is the function in an industrial context.

Modern product categories also fall within this scope. IIoT gateways, industrial edge computing platforms, cloud connectors for industrial data, and condition monitoring sensors with their own intelligence are all components under the standard.

IIoT components and IEC 62443-1-6

The Industrial Internet of Things (IIoT) is a fundamental challenge when applying IEC 62443-4-2 to modern components. The new IEC PAS 62443-1-6, “Application of the 62443 series to the Industrial Internet of Things (IIoT)”, deals with this topic and gives manufacturers of IIoT components useful guidance.

IIoT components differ from traditional industrial components in several ways. They often communicate directly with cloud services, combine functions that used to be spread across several separate devices, and rely on ubiquitous network connectivity as a basic principle.

Security profiles for specific component categories: IEC 62443-5-x

The technical requirements of IEC 62443-4-2 apply to all types of components. For specific industries or application areas, however, security profiles are being developed and standardized as IEC 62443-5-x. The scheme for these profiles is defined in IEC TS 62443-1-5, “Scheme for IEC 62443 security profiles”.

A security profile specifies several aspects for a particular component category:

  • Which foundational requirements are particularly relevant?
  • Which requirements are typically needed for this product category?
  • Which security levels are appropriate in which use scenarios?
  • Which system-specific or product-specific characteristics must be considered during implementation?

Profiles give guidance to both manufacturers and asset owners. Manufacturers better understand which requirements apply to their product category and how other manufacturers of similar products interpret the standard. Asset owners can select products that meet their requirements more precisely and have clearer criteria for comparison.

Evaluation methodology: IEC TS 62443-6-2

The technical specification IEC TS 62443-6-2, “Security evaluation methodology for IEC 62443-4-2”, defines how test laboratories and certification bodies can verify that a component actually meets the requirements of IEC 62443-4-2.

IEC TS 62443-6-2 matters because, without a common evaluation methodology, different certification bodies might apply different yardsticks. The methodology makes certificates consistent and comparable.

For each requirement and each requirement enhancement of IEC 62443-4-2, the methodology defines which evaluation steps to carry out, which evidence the manufacturer must provide, and which tests must be performed. It distinguishes between several evaluation approaches: document review for organizational and process aspects, code review for security-critical software components, configuration review for the default configuration of the component, and functional security testing.

The draft amendment to EN IEC 62443-4-2 (prAA)

An important current development is the CENELEC draft amendment EN IEC 62443-4-2:2019/prAA to the European edition of the standard, published in October 2025. It brings clarifications and additions that have come out of practical use of the standard. The security test grades described in our article on security test grades in IEC 62443 also come from this draft.

Among other things, the prAA clarifies how to interpret certain requirements that proved ambiguous in certification practice. It specifies documentation requirements more precisely and adds guidance on implementing certain security requirements. It also makes the connection to other standards and regulatory frameworks more transparent.

An important cross-reference exists to EN 50742, which was developed in the context of the new EU Machinery Regulation. This standard covers cybersecurity requirements for machinery. Its annex contains a mapping that shows how the requirements of IEC 62443-4-2 (and of IEC 62443-3-3 at system level) relate to the cybersecurity requirements of the Machinery Regulation.

The mapping matters because many components are both stand-alone products and parts built into machinery. A control component, a drive, or a safety system can be placed on the market on its own, and then the requirements for components apply. Once the component is integrated into a machine, however, the machine manufacturer must ensure that the Machinery Regulation is also met.

For component manufacturers who supply machine builders, this means that conformity with IEC 62443-4-2 makes it easier for machine builders to comply with the Machinery Regulation.

Outlook

IEC 62443-4-2 is the central international standard for the technical cybersecurity of industrial components. With its seven foundational requirements, it provides a systematic framework that covers all essential aspects of component security, from authentication and authorization through integrity and confidentiality to availability and event handling.

The standard continues to evolve:

  • The draft amendment brings clarifications from practice.
  • IEC PAS 62443-1-6 shows how to apply the standard to modern IIoT architectures.
  • IEC TS 62443-6-2 provides a standardized evaluation methodology for comparable certifications.
  • The profiles under IEC 62443-5-x specify requirements for particular product categories.
  • The link to EN 50742 shows where it overlaps with the Machinery Regulation.

For manufacturers of industrial components, IEC 62443-4-2 is unavoidable. Asset owners, regulation, and competition are increasingly turning the standard into a market requirement. If you act early and implement both the technical requirements and the secure development process under IEC 62443-4-1, you gain an advantage over your competitors.

Choosing a CRA consultant? Here is how to find the right one.

Get the guide

Book a call

Send us your request. Together we will look at where your company stands, which questions are still open, and what the sensible next steps are.

For information on how we process your data, see our privacy policy.

Guide: How to choose the right CRA consultant

CRA consulting offers are hard to compare. One provider delivers only a gap analysis, another also supports the technical implementation, and both call themselves “CRA consultants.” If you ask the wrong questions, you end up paying for services you don't need, or you find out halfway through the project that key expertise is missing.

Our guide shows manufacturers what really matters when choosing a provider, from the expertise you need to the right pricing model and the 20 questions you should ask every provider.

What the guide covers:

  • the seven areas of expertise a complete CRA implementation requires
  • four support models depending on your in-house capacity and expertise
  • 20 specific questions for your next provider meeting
  • a red flag card for spotting warning signs quickly
  • a scoring sheet with rating guidance for a structured comparison of providers

Download it for free

Newsletter

For information on how we process your data, see our privacy policy.

Free templates: CRA reporting process

Prepare your company for the reporting obligations under the Cyber Resilience Act. You get process descriptions and templates tested in practice for:

  • reporting actively exploited vulnerabilities
  • reporting severe incidents
  • the required early warning notifications, notifications, and final reports
  • clear responsibilities, escalation paths, and deadlines

Enter your contact details and we will email you the files.

Newsletter

For information on how we process your data, see our privacy policy.

Free template: Risk assessment according to EN 50742

We use this template in our consulting projects for systematic threat assessment. You get an Excel template with:

  • a structured threat assessment for your machinery
  • a systematic way to determine safety-related security levels (SRSL)
  • documentation of vulnerabilities and protective measures

Enter your contact details and you will receive the template within minutes.

Newsletter

For information on how we process your data, see our privacy policy.

Free template: SBOM

We use this template in our consulting projects to meet the CRA requirements for the software bill of materials.

Enter your contact details and you will receive the template within minutes.

Newsletter

For information on how we process your data, see our privacy policy.

Free template: Vulnerability disclosure policy

We use this template in our consulting projects to meet the CRA requirements for vulnerability handling. You get a Word template with:

  • a structure based on EN 40000-1-3
  • predefined sections for reporting channels, response times, and responsibilities
  • safe harbor clauses for security researchers

Enter your contact details and you will receive the template within minutes.

Newsletter

For information on how we process your data, see our privacy policy.