IEC 62443-4-2: the four component types and ISASecure CSA certification, explained

IEC 62443-4-2:2019, "Security for industrial automation and control systems – Part 4-2: Technical security requirements for IACS components," is the component-level part of the ISA/IEC 62443 series: a 192-page first edition published 27 February 2019, per the IEC's own standard catalogue entry. Rather than treat "a component" as one undifferentiated thing, the certification scheme built directly on top of it — ISASecure's Component Security Assurance (CSA) program — classifies every component into exactly one of four defined types before any assessment begins: software application, embedded device, host device, or network device. This guide works from IEC's own catalogue scope text and ISASecure's published CSA scope, not a third-party paraphrase of the paywalled clause text.

The four component types

ISASecure's CSA scheme, which certifies products against IEC 62443-4-2 and IEC 62443-4-1 together, publishes these exact definitions as part of its scope:

Component type	Definition (ISASecure CSA scope)
Software Application	"One or more software programs and their dependencies that are used to interface with the process or the control system itself."
Embedded Device	"Special purpose device running embedded software designed to directly monitor, control or actuate an industrial process."
Host Device	"General purpose device running an operating system (for example Microsoft Windows OS or Linux) capable of hosting one or more software applications."
Network Device	"Device that facilitates data flow between devices, or restricts the flow of data, but may not directly interact with a control process."

In practice: a PLC or an RTU firmware image is usually an embedded device; a historian or engineering-workstation application running on Windows is a software application running on a host device; a managed Ethernet switch or industrial firewall is a network device. Getting the classification right matters because the detailed component requirements (CRs) that IEC 62443-4-2 applies differ by type — a network device is not expected to meet every requirement written for a general-purpose host, and vice versa.

Where the four types sit in the wider standard

IEC 62443-4-2's own catalogue scope states it "provides detailed technical control system component requirements (CRs) associated with the seven foundational requirements (FRs)... and defines security capability levels for control system components (SL-C)." Those seven FRs — identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability — are the same seven that organise the system-level standard, IEC 62443-3-3; 4-2 is ISA's own description of how that system-level bar gets mapped down onto an individual component, type by type. The CR text itself, and exactly how many CRs and requirement enhancements (REs) apply to each of the four component types, sits behind the paywalled standard — treat any specific count you see quoted elsewhere as unverified until checked against the purchased document.

How ISASecure CSA actually certifies a component

CSA is a named, accredited certification scheme — IEC 62443-4-2 is not self-certifying. Per the scheme's own published scope, CSA runs four distinct assessment elements:

Element	Full name	What it checks
SDLPA-C	Security Development Lifecycle Process Assessment for components	The supplier's development process against IEC 62443-4-1
SDA-C	Security Development Artifacts for components	The documentation the SDLPA-C process produced
FSA-C	Functional Security Assessment for components	The component's actual technical security capabilities against IEC 62443-4-2's CRs
VIT-C	Vulnerability Identification Testing for components	Known vulnerabilities in the component as submitted

CSA "defines four certification levels for a component, offering increasing levels of security assurance," covering capability security levels 1 through 4 — higher levels demand more rigorous functional security requirements under FSA-C. A certificate states the component type (one of the four above) and the capability security level achieved; it is evidence of what the component can natively provide, not a guarantee of how it performs once integrated into a specific zone with its own target security level (SL-T). See IEC 62443-3-3 for the SL-T/SL-C/SL-A distinction, which carries over unchanged from system to component level.

Practical steps for component makers

1. Classify your product first. Decide whether it is a software application, embedded device, host device, or network device before scoping any gap assessment — the applicable CRs differ by type, and most of the confusion in self-assessments comes from skipping this step.
2. Use CSA's four assessment elements as your evidence index, even if you are not pursuing certification: SDLPA-C and SDA-C map to your development-process paperwork, FSA-C to your component's actual technical controls, and VIT-C to your own vulnerability-scanning results.
3. Don't assume a capability level claim without a certificate or the purchased standard behind it. A vendor datasheet stating "SL-C 2" is only as credible as the evidence or accredited certification backing it.
4. Treat IEC 62443-4-2 as engineering evidence for the CRA and EN 18031, not a substitute for them. See IEC 62443-4-2 vs the Cyber Resilience Act and EN 18031 for where the mechanisms overlap and where EU law still demands separate process work (SBOM, disclosure policy, 24-hour reporting).

SoftWSP maps a component's existing security evidence against IEC 62443-4-2's four component types and the CSA assessment elements, and flags gaps before a certification submission or CRA conformity assessment: see machine builders.

This guide quotes the IEC's publicly available standard catalogue entry and ISASecure's published CSA certification scope; it is not a substitute for the purchased standard and does not constitute legal or compliance advice.