Every ICSA application opens with a question that decides more than it seems to: is this product an IIoT device or an IIoT gateway, or is it both? ICSA recognises exactly two IIoT types, and the answer fixes which of the 182 functional requirements are in scope before the tier is even chosen. As in CSA, the product is assessed against every type that applies, so the question is not "pick one" but "list all that fit"; what ICSA adds is a second axis of types on top of the classic IEC 62443-4-2 ones.
This article describes the two types in practical terms, shows how the IEC 62443-4-2 requirement families split between them, gives the per-type, per-tier numbers, and explains what happens when a product does both jobs. If you are still deciding between CSA and ICSA, start with the comparison article.
The two types, in practical terms
The most useful way to place a product is to ask what it connects to, and on whose behalf.
IIoT device. A product with a job in the physical process, sensing or acting, that also reaches out on its own to a network it cannot trust: a cloud platform, a mobile carrier, an enterprise analytics service. A vibration sensor that reports straight to a cloud condition-monitoring service over cellular, a smart valve positioner with its own diagnostics uplink, a power meter that pushes readings to a fleet dashboard.
An "edge computing device", a field unit that runs analytics or logic locally before sending anything onward, is not a third type. For scoping purposes it is an IIoT device with more processing on board.
IIoT gateway. A product whose job is to sit between the local side and the outward path. On one side it faces a field network, a wireless sensor cluster or a set of IIoT devices; on the other it faces the network it cannot trust, and it collects, translates and forwards on behalf of what is behind it. A cellular edge box aggregating Modbus and OPC UA traffic to a cloud broker, a protocol-translation gateway with an MQTT uplink, a wireless-sensor-network base station with a cloud connection.
The point that catches suppliers: ICSA treats a gateway as a kind of network device, so the network-device family of IEC 62443-4-2 applies to it, and that is the largest of the type-specific sets. A gateway that looks like a sealed box with firmware is nevertheless evaluated on how it handles traffic in transit.
| Device type | Core | Advanced |
|---|---|---|
| IIoT Device | 137 | 158 |
| IIoT Gateway | 141 | 163 |
Cumulative counts. Gateways carry more because the network-device requirement family applies to them; devices carry the embedded-device family instead.
How the shared families split between the pair
ICSA does not write its own device-type families. It maps the existing IEC 62443-4-2 type prefixes onto the two IIoT types, so the identifier tells you whether a row applies to your product before you read it.
| Prefix | In ICSA, applies to | Rows |
|---|---|---|
| CR | Both IIoT types | The common set, the bulk of the 182 |
| CCSC | Both, with three rows (1D, 1E, 1H) that apply to IIoT devices only | 10 |
| SAR | Both IIoT types | 5 |
| HDR | Both IIoT types | 16 |
| EDR | IIoT devices only | 15 |
| NDR | IIoT gateways only | 23 |
| FSA-ICSA | Both IIoT types | 24 |
Two things in that table differ from CSA. First, the host-device and software-application families, which in CSA each belong to one type, apply to both IIoT types here. Second, the 24 IIoT-specific additions do not separate the two types at all; every one applies to both. What separates a device from a gateway is the embedded-device family on one side and the network-device family on the other, plus a few rows at the edges.
Adding it up: 139 requirements apply to both types. Nineteen are device-only, the three CCSC rows plus the 15 EDR rows plus one more. Twenty-four are gateway-only, the 23 NDR rows plus one more. The "one more" on each side is the same use-control clause, CR 2.1 RE(2), which the scheme carries in a gateway-only form and in a separate device-only form that applies at Advanced. That gives an IIoT device 158 requirements at the full Advanced tier and an IIoT gateway 163.
Reading off your scope: type times tier
The type is one dial; the tier is the other. ICSA scopes by Core or Advanced, one tier per certificate, with the IEC 62443-4-2 security level as a cross-reference only. Core is a subset of Advanced, so the Advanced column of the first chart is each type's full set.
Across a row is the tier dial. An IIoT device carries 137 requirements at Core and 158 at Advanced, 21 more. An IIoT gateway carries 141 at Core and 163 at Advanced, 22 more. Down a column is the type dial: at both tiers the gateway is the larger scope, because the network-device family is the bigger of the two.
Cumulative: Advanced includes everything at Core plus 24 further requirements, six of them IIoT-specific additions.
Neither type alone reaches the 158 and 182 in the second chart. Those are the union of both types; a single-type product never sees the whole set, because the device-only and gateway-only rows are never both in scope for it. The only product that faces all 182 carries both types, which brings us to the scoping conversation.
A product is assessed against every type that applies
CSA already assesses a product against every IEC 62443-4-2 component type the certifier finds applicable. ICSA does the same on two axes at once.
On the IIoT axis, a product that senses or acts and also bridges other devices outward is both an IIoT device and an IIoT gateway. It carries the embedded-device family for one role and the network-device family for the other, so its functional scope is the union: 158 requirements at Core and 182 at Advanced.
On the classic axis, the product still has its IEC 62443-4-2 component types, and those are recorded too. A cellular edge gateway with a general-purpose operating system and local control logic can be an embedded device, a host device and a network device all at once, as well as an IIoT device and an IIoT gateway; the scheme's own sample report describes a product carrying all three classic types and both IIoT types. The assessment report names both lists. Neither replaces the other.
This is why the type list is settled at application, before the evaluation plan is written. Declaring a device-plus-gateway product as a device only does not buy a lighter evaluation; it produces a mismatch the assessor will raise as soon as the network-device rows come up. As an ISASecure certification body, we fix the type list with the supplier before an application is accepted, not mid-evaluation.
Cloud and wireless interfaces belong to either type
A common misreading is that a cloud connection makes a product a gateway, or that a wireless radio makes it a device. Neither is true. The type is about the product's role; the interfaces are about where the evaluation repeats.
Cloud-side and wireless interfaces are ordinary accessible network interfaces, whichever type the product is. A subset of the functional requirements is evaluated once per accessible interface and rolled up worst-case, and the vulnerability scan runs on each. The ICSA sample report shows the pattern with a product declaring four external interfaces, a wired control network, a wireless control network and two cloud connections over cellular, and every per-interface section repeats four times.
Separately from the type, you will declare which interfaces face an untrusted network; that declaration, not the device type, decides where a handful of the per-interface IIoT additions apply. The per-interface rule and the cloud and wireless specifics have their own article in this series, listed on the ICSA index.
When the product belongs in CSA instead
What makes a product IIoT, for ICSA's purposes, is the outward connection to a network it cannot trust. A controller on an isolated control network, a managed switch inside the plant, an engineering tool on the customer's workstation: all CSA, under the four classic types the CSA hub covers. The comparison article works through the borderline cases, such as a field device with a cloud agent bolted on.
Whichever type you are, the laboratory's own hands-on work is the vulnerability scan and the flagged functional subset; fuzzing, load testing and penetration testing remain your lifecycle activities, as the testing article explains. The type decides how many rows you face, not who tests them.
Where to go next
The rest of the ICSA series takes the tier, the 24 additions, the per-interface rule and the maintenance model one at a time. Browse the whole set from the ICSA filter on the Insights index.
Frequently asked questions
No. ICSA has exactly two IIoT types. A field unit that runs analytics or logic locally before sending anything onward is scoped as an IIoT device; the on-board processing changes what you have to demonstrate under some requirements, not which requirement family applies.