The 24 IIoT-specific requirements ISASecure ICSA adds to IEC 62443-4-2

An ISASecure ICSA evaluation covers the shared IEC 62443-4-2 requirement set, the common component security constraints and the seven foundational requirements, and then turns to a sheet of its own. The evaluation workbook calls it the ICSA additions: 24 functional requirements written for products that connect to untrusted networks, identified FSA-ICSA-1 to FSA-ICSA-24, which no CSA evaluation sees.

Those 24 are the substantive difference from a CSA evaluation of a comparable product, and the part suppliers most often under-prepare for. This article covers the sheet theme by theme, how tier, interface and hands-on testing apply, and the one rule that makes the additions stricter than the base they sit on.

Where the 24 sit

FSA-IC, the functional stream of ICSA, draws on 182 requirements at the Advanced tier: 158 shared with IEC 62443-4-2 plus the 24 additions. Core draws on 158, and Advanced includes everything at Core. Three facts decide how much of the sheet applies to your product.

Tier. Eighteen additions, FSA-ICSA-1 to FSA-ICSA-18, apply at both tiers; six, FSA-ICSA-19 to FSA-ICSA-24, apply at Advanced only. The additions are scoped by tier alone and carry no security-level cross-reference of their own.

Device type. ICSA recognises two IIoT types, IIoT device and IIoT gateway. In the shared set the type matters: the embedded-device family applies to devices, the network-device family to gateways. All 24 additions apply to both types.

Evaluation scope. Twenty of the 24 are evaluated once, for the product as a whole. Four, FSA-ICSA-9, 10, 11 and 19, are evaluated once per accessible network interface, with the worst result across interfaces carrying.

The 24 at a glance

The table lists all 24 by theme, in the numbering of the current ICSA-311 workbook; an earlier edition of the report template orders three rows differently. The theme column describes what each row is about in plain language, not the requirement itself.

Seven themes

Secure defaults and credentials (1, 2). These address the moment a unit leaves the factory. An IIoT product is often installed by someone who will never open a hardening guide and may be reachable from an untrusted network as soon as it is powered on, so the as-shipped configuration must already be secure and each unit must carry credentials of its own.

Protecting software and data in use (3, 4, 8; 24 at Advanced). Three rows protect what the product is running and handling against tampering, disclosure and unauthorised change. At Advanced, row 24 requires that protection to be anchored in hardware. This is where platform choice matters most: without a hardware root of trust, row 24 is a problem firmware cannot fix.

Update and upgrade control (5, 6, 7). A small lifecycle: updates arrive remotely, the customer decides whether and when to apply them, and applying one does not quietly reset the security settings the customer had made. Row 7 is lab-tested: configure, update, see what survived.

Untrusted-network protections (9, 10, 11). The reason ICSA exists. Across an interface facing a network the product cannot trust, non-human users must prove who they are, management traffic is guarded against, and the product can cut the connection. All three are evaluated per interface and depend on your declaration, covered next.

Partitioning and zoning (12 to 16). Five rows carry zone-and-conduit thinking into the product: applications kept apart, zone boundaries where trust changes, safety-related functions and enterprise-side connectivity in zones of their own, and established separation mechanisms. Rows 13, 14 and 15 are lab-tested. For a gateway this is close to the product's purpose; for a device it is about how its internal structure supports the segmentation around it.

Safety-function separation and power (17, 18). Physical separation of safety-related functions, and predictable, secure behaviour as a battery runs down. Where a theme genuinely does not apply, the outcome is recorded as not relevant rather than as a failure.

The Advanced-only set (19 to 24). Six rows sharing a character: assurance built into hardware and posture rather than configuration. Row 23, monitorable presence, is the one Advanced row the lab tests hands-on. If Advanced is your target, check feasibility here first; most of these are design decisions, not features.

The declaration that decides three of them

When you apply for ICSA certification, ICSA-300 requires information about the product under its requirement ISASecure_IC.R4, and part of it is which of the product's network interfaces connect to an untrusted network. That statement, made by the supplier, decides where rows 9, 10 and 11 apply.

Each accessible interface is evaluated separately for those rows. On an interface you declared as connecting to an untrusted network, they are in play; on one you did not, they are recorded as not relevant for that interface. The result can differ between interfaces on the same product: row 10, about management traffic, may apply on a cloud management connection and not on the cloud operations connection beside it.

Three consequences follow. The scope of those rows is in your hands, and the report shows which interfaces were treated as untrusted. Cloud-side and wireless interfaces are ordinary accessible interfaces; the report template's worked example declares four, a wired control network, a wireless one and two cloud connections over cellular. And because ICSA exists for products that connect to untrusted networks, a declaration with no such interface is a scoping conversation to have before applying.

The rule that makes the additions stricter than the base

In the shared IEC 62443-4-2 set, the standard states for each requirement whether the function must come from the component itself or may be delivered by integrating the component into a system. Where the second path is allowed, the supplier documents the dependency, the requirement is recorded as met by integration into the system, and the dependency becomes a condition on the certificate. The base-set mechanics are covered in what ISASecure CSA certification actually evaluates.

None of the 24 additions offers that path. Every one must be provided directly by the component, so the passing outcome is met and the only alternative is not relevant.

For an IIoT product this is the practical crux, because the temptation to defer to the platform is strongest exactly where the additions apply: initial credentials issued by a cloud service, update control in a fleet-management console, zoning delegated to the surrounding network. Each may be a sound design. None satisfies the addition. The evidence must show the product doing it.

What the lab tests itself

Eight of the 24 are exercised hands-on by the laboratory rather than accepted from the supplier's evidence: FSA-ICSA-7, 8, 10, 11, 13, 14, 15 and 23. They sit inside the 47 requirements the ICSA workbook flags for independent testing across the whole functional stream. The other 16 are evaluated through evidence review. Hands-on testing lands where behaviour can be provoked on a bench. As with the shared set, fuzzing, load and penetration testing are not part of this; they remain supplier lifecycle activities whose scope the lab reviews, as explained in where fuzzing, load testing and penetration testing actually live.

As an ISASecure certification body, we evaluate the 24 additions in the same FSA-IC stream as the shared requirements, with the eight flagged rows tested in our own laboratory.

What to prepare

• Get the untrusted-network declaration right first. It fixes the scope of three rows and is visible in the report. List every accessible interface, cloud and wireless included, and decide honestly which face a network you do not control.
• Prepare evidence per theme, showing the product itself doing it. Provisioning records and the shipped configuration, the update mechanism and the customer's control over it, the partitioning and zoning design, the physical separation of safety functions.
• Run row 7 yourself before the lab does. Configure security settings, apply an update, compare.
• Settle the not-relevant rows early. No safety function, no battery, no management path over an untrusted interface: each is legitimate, and each needs a short rationale.
• If Advanced is the target, feasibility-check 19 to 24 before applying. Hardware compartments and hardware-anchored protection are platform decisions; discovering them during evaluation is expensive.

Where to go next

For how ICSA differs from CSA as a whole, see CSA vs ICSA: which ISASecure scheme fits your device. The rest of this series is on the ICSA filter of the Insights index.