Every CSA application starts with a question that sounds administrative and is not: which of the four IEC 62443-4-2 component types apply to this product? The answer goes on the certificate, it decides which of the 166 functional requirements are in scope, and, in our process, it is settled at application rather than revisited mid-evaluation. Suppliers who treat it as a checkbox tend to discover, mid-evaluation, that they are being assessed against a requirement family they had never opened.
This article explains the four types in practical terms, the boundary cases most often called wrong, how the requirement identifiers encode the scope, and the per-type, per-level grid that lets you read off your own number before you apply. The series hub defines the types in a line each; this goes one level down.
The four types, in practical terms
The most reliable way to place a product is to ask two questions: who controls the platform it runs on, and is its job the process or the traffic?
Software application. What you ship is code. It installs on a computer that belongs to the customer, running an operating system you did not supply and cannot lock down. Engineering and configuration tools, a historian client, an OPC UA server sold as an installer, a SCADA package delivered without hardware: all software applications. With the platform in someone else's hands, the software-application total is the smallest of the four.
Embedded device. Hardware and firmware ship together as one sealed unit with a job in the process, and you control the entire stack from the bootloader up. A PLC, an RTU, a protective relay, a safety controller, a drive with an Ethernet port, a remote I/O module or a networked transmitter are all embedded devices.
Host device. A computer built on a mainstream operating system that you deliver as a finished product with a control role: the operating system, the hardening and the application arrive together, and you are responsible for all of it. An HMI panel PC, an engineering workstation shipped preloaded, a SCADA or historian server appliance. The distinction from a software application is ownership of the platform. Here it is yours, so it is evaluated.
Network device. Its job is to move, segment or filter traffic between other components; it is not a process endpoint. Industrial Ethernet switches, routers, industrial firewalls, VPN concentrators, data diodes, wireless access points and serial-to-Ethernet converters sit here. Its type-specific family is the largest of the four, because it is evaluated on how it handles traffic in transit.
Of the 166 CSA requirements, the number that apply to each IEC 62443-4-2 component type. The difference comes from the type-specific requirement families (EDR, HDR, NDR, SAR).
The boundary cases people get wrong
Four cases come up again and again.
"HMI" is a role, not a type. A panel PC running Windows with visualisation software on top is a host device. The same software, sold as an installer for the customer's own workstation, is a software application. A small operator panel with its own firmware and no general-purpose operating system is an embedded device. Ask what is under the screen, not what is on it.
A PLC with a web server is still an embedded device. A Linux-based runtime, an onboard web interface or a built-in OPC UA server does not push a controller into the host-device type. The deciding trait is that you control the whole stack and the customer cannot load arbitrary software onto it. What the extra services do change is your accessible-interface list, which drives the vulnerability scan and the per-interface evaluation described in the testing article.
An industrial firewall is a network device, not an embedded device. It is also a sealed box with firmware, so the embedded-device label feels natural. The question that settles it is whether the product's job is the process or the traffic. A firewall, a managed switch or a protocol gateway that only converts and forwards is a network device.
An engineering tool is a software application even if it only ever talks to your own controller. The tool runs on the customer's machine, and that machine's operating system is not part of your product. Certifying one does not cover the other.
What the identifier tells you
The identifier already tells you whether a requirement applies to your type.
| Prefix | Applies to | Count |
|---|---|---|
| CR | All four component types | The common set, the bulk of the 166 |
| CCSC | All four, with three rows that apply to embedded devices only | 11 rows |
| SAR | Software applications only | 5 |
| EDR | Embedded devices only | 16 |
| HDR | Host devices only | 17 |
| NDR | Network devices only | 25 |
The type-specific families total 63. Everything else applies to all four types.
63 of the 166 requirements belong to one component type only; the rest apply across all four.
After the prefix comes the clause number in the form x.y, where x is the foundational requirement from 1 to 7; then an optional letter where the scheme has split one clause into separately assessable rows; then an optional RE(n) marking a requirement enhancement. So EDR 3.2 is an embedded-device-only requirement under system integrity, and NDR 1.13 RE(1) is a network-device-only enhancement under identification and authentication control.
When the same clause number appears as EDR, HDR and NDR with no CR or SAR version, as with the 2.13 and 3.11 rows, the standard is dealing with something that only exists on hardware, and a software application simply has no row there.
Reading off your scope: type times level
The component type is one dial; the capability security level is the other.
| Component type | SL 1 | SL 2 | SL 3 | SL 4 |
|---|---|---|---|---|
| Software application | 52 | 81 | 95 | 101 |
| Embedded device | 57 | 93 | 109 | 115 |
| Host device | 54 | 91 | 107 | 113 |
| Network device | 58 | 96 | 115 | 121 |
Cumulative counts of the 166 CSA requirements that apply to each component type at each capability security level.
Across a row is the level dial. A network device carries 58 requirements at SL 1 and 121 at SL 4; a software application goes from 52 to 101. Every row is cumulative, so an SL 3 evaluation includes everything in the SL 1 and SL 2 columns for that type.
Down a column is the type dial. At every level the order is the same: software application lowest, then host device, then embedded device, then network device, with the gap between lowest and highest wider at the upper levels.
The SL 4 column is the full set for each type, and it matches the four totals in the first chart: 101, 115, 113 and 121. What the grid does not show is the effort behind each step, which is the subject of the SL 3 article in this series.
Type, level and certificate
The component type is not the supplier's to pick. Under CSA-300 the certifier determines which of the four IEC 62443-4-2 types apply to the product, against the standard's definitions, and the certificate names each applicable type alongside the product, its version and the capability security level. Many products fit a single definition; one that fits two is certified under both. One level per certificate, as many types as apply. The evaluated network interfaces are recorded in the assessment report rather than on the certificate, but the type is on the face of it. Arguing host device for a sealed controller does not buy a lighter evaluation; it produces a mismatch the assessor will raise.
When a product genuinely spans two types
Some products really do straddle a line: a controller with a built-in managed switch or firewall, an HMI appliance bundled with an engineering tool that customers also install elsewhere, a protocol gateway that both converts traffic and runs control logic.
CSA-300 answers this directly: the certifier determines every type that applies, the functional assessment takes in the requirements of all of them, and the certificate lists each. ISCI's own example is a level 2 certificate for a product that is both an embedded device and a network device. The consequence is scope. A controller that is also a network device faces the embedded-device and network-device families on top of the common requirements, so its requirement set is larger than either type's own total. It is far cheaper to settle that before the evaluation plan is written than after the first stream has started. As an ISASecure certification body, this is the determination we make with a supplier at application, not mid-evaluation.
IIoT devices and gateways go to ICSA
One more boundary sits outside the four types altogether. If the product is designed and sold as an IIoT device or an IIoT gateway, it belongs in ICSA, not CSA. ICSA shares the IEC 62443-4-2 base with CSA but uses two component types of its own, adds its own requirement set on top, and is scoped by a Core or Advanced tier rather than a capability security level. The rest of this series is on the CSA filter of the Insights index.
Frequently asked questions
It depends on what is under the screen. A panel PC running a mainstream operating system with visualisation software on top is a host device. The same software sold as an installer for the customer's own workstation is a software application. A small operator panel with its own firmware and no general-purpose operating system is an embedded device. HMI describes a role, not a component type.