IEC 62443-4-2: The Complete 2026 Component Security Guide

IEC 62443-4-2 is the part of the IEC 62443 series that defines the technical security capabilities a single industrial automation and control system (IACS) component must have, whether that component is a PLC, an engineering workstation, an industrial switch or a historian application. Edition 1.0 was published in February 2019. It organizes its component security requirements under the same seven foundational requirements (FRs) used for whole systems and grades them by capability security level (SL-C), from 1 to 4.

Two groups read it for different reasons. Product teams use it to design, test and certify what they ship. Asset owners use it to write purchase specifications and check whether supplier claims hold up. This guide covers both views.

One point up front: the standard describes what a component can do when configured the way its supplier documents. How secure your plant is depends on the zone the component sits in, its configuration and how you operate it.

What IEC 62443-4-2 covers, and what it leaves out

The current edition is IEC 62443-4-2:2019, published 27 February 2019, and the IEC’s current copy includes an August 2022 corrigendum. In the US, the equivalent standard is ANSI/ISA-62443-4-2-2018. Our overview of all IEC 62443 parts shows where it fits in the series.

The standard does three things:

• Defines component requirements (CRs) derived from the system requirements in IEC 62443-3-3, grouped under the seven FRs.
• Adds component-specific requirements for four component types.
• Defines the capability security level of a component, SL-C(component). Target (SL-T) and achieved (SL-A) levels are out of scope.

It also sets four common component security constraints (CCSCs): support of essential functions, compensating countermeasures, least privilege, and software development process. The second matters to buyers, because a component may rely on documented system-level countermeasures for something it cannot do itself. The fourth ties the product to a development lifecycle that follows IEC 62443-4-1.

The four component types and their requirement prefixes

Common CRs apply to every component type. Where a requirement only makes sense for one kind of product, the “CR” label is replaced by a component-specific prefix.

Component type	Prefix	What it is	Typical examples
Software application	SAR	Software that interfaces with the process or the control system	Engineering software, historian, HMI application
Embedded device	EDR	Special-purpose device running embedded software to monitor, control or actuate a process	PLC, safety controller, RTU, protection relay
Host device	HDR	General-purpose device running an operating system that can host applications or data stores	Engineering workstation, operator station PC, historian server
Network device	NDR	Device that facilitates or restricts data flow, usually without touching the process directly	Industrial Ethernet switch, router, firewall, wireless access point

Some requirements repeat per device type. Integrity of the boot process appears as EDR 3.14, HDR 3.14 and NDR 3.14, with no SAR version because an application does not boot hardware. Others carry a single prefix, such as NDR 5.2 Zone boundary protection. A product can be assessed as more than one type, so check which type a claim refers to.

Component security requirements under the seven FRs

The component security requirements mirror the system requirements of Part 3-3, rewritten for a single product. If your team already works with IEC 62443-3-3 system requirements, the numbering will look familiar. Requirement enhancements (REs) add capability at higher security levels.

Foundational requirement	Example requirement	What to look for
FR 1 Identification and authentication control	CR 1.1 Human user identification and authentication	Individual accounts, no shared or hard-coded logins
FR 2 Use control	CR 2.1 Authorization enforcement	Roles you can map to operators, engineers and vendors
FR 3 System integrity	CR 3.4 Software and information integrity	Detection of unauthorized software and configuration changes
FR 4 Data confidentiality	CR 4.1 Information confidentiality	Protected credentials and sensitive settings
FR 5 Restricted data flow	CR 5.1 Network segmentation	Support for separating control traffic
FR 6 Timely response to events	CR 6.1 Audit log accessibility	Logs you can read and export
FR 7 Resource availability	CR 7.1 Denial of service protection	Essential functions keep running in a degraded mode

Capability security levels (SL-C): what the number means

SL 1 protects against casual or coincidental violation. SL 2 covers intentional violation using simple means with low resources, generic skills and low motivation. SL 3 assumes sophisticated means, moderate resources, IACS-specific skills and moderate motivation. SL 4 keeps the sophisticated means and IACS-specific skills but assumes extended resources and high motivation.

• SL-C (capability): what a component can deliver when configured as its supplier documents. This is the only level IEC 62443-4-2 defines.
• SL-T (target): what a zone or conduit needs, set by the asset owner’s risk assessment.
• SL-A (achieved): what the installed system actually delivers.

SL-C is often shown per FR as a vector of seven values, such as {2 2 2 2 2 2 2}. A product can reach SL 3 on authentication but SL 2 on data confidentiality, so one headline number can hide a gap. Compare the vector with your zone’s SL-T, FR by FR. A high SL-C is a ceiling, not a result: ignore the hardening guide and SL-A falls well below it.

IEC 62443-4-1 vs IEC 62443-4-2: process versus product

Tenders regularly confuse these two parts. Part 4-1 covers how a supplier builds products; Part 4-2 covers what one product can do.

Aspect	Part 4-1	Part 4-2
What it assesses	The supplier’s secure development lifecycle	Technical security capabilities of one component
Edition	Ed 1.0, January 2018	Ed 1.0, February 2019
Structure	Eight practices, from security management to security guidelines	CRs under seven FRs, plus SAR, EDR, HDR and NDR requirements
ISASecure program	SDLA	CSA, which also assesses the development process
Certificate scope	The supplier’s development process	Named component models and versions

The link is by design. CCSC 4 expects components to be developed under a 4-1 process, and ISASecure CSA likewise includes a lifecycle assessment. A 4-1 certificate alone shows engineering discipline but says nothing about the security features in the box you are buying, so ask for evidence of both.

IEC 62443-4-2 certification: ISASecure CSA and IEC TS 62443-6-2

IEC 62443-4-2 certification is voluntary. A widely used scheme is ISASecure Component Security Assurance (CSA), which certifies components against Part 4-2 together with the supplier’s development practices under Part 4-1. CSA version 1.0.0 took effect on 28 August 2019 and absorbed the older EDSA program for embedded devices. The ISASecure certification programs page lists CSA alongside related schemes.

A CSA evaluation has four elements:

• SDLPA-C: assessment of the development lifecycle process used for the component.
• SDA-C: review of the component’s security development artifacts.
• FSA-C: functional assessment of security capabilities, with more requirements at higher levels.
• VIT-C: testing for known vulnerabilities.

ISASecure also runs ICSA for IIoT components, and in August 2026 announced a High Criticality Component Security Assurance (HCSA) program with the NSA, still under development. You may also see IECEE certificates under its Industrial Cyber Security Capability scheme. Supplier self-assessments help with detail but are not independent evidence.

Behind the evaluations sits IEC TS 62443-6-2, published 21 January 2025, which sets an evaluation methodology for Part 4-2 components aimed at repeatable, reproducible results. It is not a certification scheme, it does not evaluate the development lifecycle (Part 4-1 is a prerequisite), and it names no testing tools.

How to read a vendor’s IEC 62443-4-2 certificate

Check these fields before accepting a certificate as evidence:

1. Scheme and version: ISASecure CSA (for example CSA 1.0.0), an IECEE certificate, or a supplier self-declaration?
2. Component type and model: exact model numbers and the type assessed. An embedded device certificate does not cover the software that configures it.
3. Product version: the hardware revision and firmware or software version you will actually receive.
4. SL-C: the level per component type, and per FR if a vector is shown. Flag any FR below your target.
5. Certifying body: who issued it, and whether they are accredited for that scheme.
6. Date and status: the issue date, and whether the product still appears on the scheme’s public list. ISASecure’s list shows supplier, type, model, version, certificate and certification date.
7. Conditions: the security guidance the level depends on, including compensating countermeasures you must provide.

Procurement questions for asset owners

“IEC 62443 compliant” on a datasheet is not a specification. Put these questions into your request for quotation and keep the answers on file:

1. Which component types, models and versions are certified, and under which scheme?
2. What is the SL-C per FR, and does it meet the SL-T of the zone where the component will be installed?
3. Which requirements rely on compensating countermeasures, and who provides them?
4. Is product development covered by a 4-1 process assessment or SDLA certification?
5. How are security updates delivered, and how does the component verify them before installing?
6. Is there a hardening guide for the level claimed, and can logs and security settings be exported?
7. How does the supplier receive vulnerability reports and notify customers of fixes?

Write the required SL-C into the specification as per-FR values for each component type, then have acceptance testing check the delivered firmware version against the certificate.

IEC 62443-4-2 and the EU Cyber Resilience Act

The Cyber Resilience Act, Regulation (EU) 2024/2847, places obligations on manufacturers of products with digital elements. Its reporting obligations have applied since 11 September 2026, and it fully applies from 11 December 2027.

In September 2025, CEN-CENELEC said CLC/TC 65X WG3 is adapting EN IEC 62443-4-2:2019 through an amendment labeled A11:2026. The work includes adapting CRs and REs to the CRA, adding REs where gaps exist against its essential requirements, defining applicability criteria, and integrating the IEC TS 62443-6-2 evaluation approach. A parallel amendment covers EN IEC 62443-4-1.

Do not overstate where this stands. As of October 2026, no harmonized standard has been cited in the Official Journal under the CRA, so conformity with Part 4-2 does not currently give a presumption of conformity. A component certificate can support a manufacturer’s technical documentation but is not CRA compliance on its own. Our guide to how the CRA relates to IEC 62443 covers the mapping.

If you are on the buying side, the IEC 62443 Toolkit gives asset owners and service providers 117 editable templates (82 Word, 35 Excel) in 16 sections, written against IEC 62443-2-1:2024. It includes an SL-T, SL-C and SL-A gap workbook plus supply chain documents for specifying and verifying supplier component capability. It covers Part 4-2 from the procurement side only. It is not built for product teams pursuing 4-1 or 4-2 certification, and no template set can certify anyone.

IEC 62443-4-2 FAQs

Is IEC 62443-4-2 certification mandatory?

No. Certification is voluntary, although some asset owners and sectors ask for it in tenders. The CRA does not require it, and no IEC 62443 part is currently cited as a harmonized standard under the CRA.

How is Part 4-2 different from IEC 62443-3-3?

Part 3-3 sets system requirements for a whole control system made of many components. Part 4-2 derives component requirements from them and applies them to a single product. Integrators use certified components as building blocks, then show the system meets its targets under 3-3.

Can legacy components meet the standard?

Often not fully, because capabilities such as boot integrity depend on hardware. The standard allows documented compensating countermeasures at system level. In practice, legacy devices usually go into a tightly controlled zone.

Does a certificate cover future firmware versions?

Not automatically. Certificates name specific versions, and each scheme sets its own maintenance rules; ISASecure publishes a maintenance specification for CSA (CSA-301). Ask how new releases are covered before you approve an upgrade.