IIoT vulnerability testing: how ISASecure ICSA's two tiers set the pass threshold

Suppliers of IIoT devices and gateways preparing for ISASecure ICSA ask the same question their CSA counterparts do: what will the vulnerability scan find, and what do we have to fix? In ICSA the answer hangs on the tier you are certifying to, Core or Advanced, rather than on a security level, and the two tiers set the threshold in a way that is easy to state and easy to misreport.

This article covers how ICSA's vulnerability identification testing (VIT-IC) is defined, the two tier bands, why the scan itself does not change between tiers, how scope works when the product has cloud links and radios, and who does what.

Defined as a delta

ICSA does not have a vulnerability-testing specification of its own. The scan procedure is the component scheme's, defined in ISASecure SSA-420: same tool, same bench conditions, same per-interface rule. What ICSA changes is the pass criterion. ICSA-300 puts a tier-based criterion, identified in the scheme documents as ISASecure_IC.R5, in place of the security-level one. Everything else is inherited.

VIT-IC carries 18 requirements. Two are specific to ICSA: one covering the procedure itself, one stating the tier criterion. Sixteen are shared with the component and system schemes; 14 of those 16 apply verbatim, and the other two refer to the pass criterion by cross-reference, which in ICSA resolves to the tier rule instead of the level rule. Ten of the 18 are about reporting and reproducibility, all of them shared rows: the scheme wants a result that can be traced to a specific check and re-run later. The rest cover the scanner policy, the currency of its vulnerability feed, and a fallback path for products the standard scanner cannot support.

Two bands, not four

CSA sets its scan threshold as a ratchet with one rung per security level. ICSA keeps two rungs.

At Core, every critical and every high finding must be addressed. At Advanced, medium joins the list. Low and informational findings are reported at both tiers and block neither.

"Addressed" carries the same meaning it has in CSA: corrected, or documented with a rationale for why the finding is not relevant to the product as deployed. Both routes are recorded. A pass at either tier therefore never requires zero findings; it requires a disposition for every finding inside the band, and the lab judges each rationale on its merits rather than accepting it on assertion.

Placed against the CSA ladder, the Core band is the SL 2 rung, corroborated by the ICSA-303 report template, whose worked example is a Core-tier evaluation. The Advanced band is the SL 3 rung, as set out in ICSA-300, and specifically not the SL 4 rung. That trips people up, because the functional security assessment treats Advanced as roughly the SL 4 requirement set. The two mappings are set independently: one decides which requirements apply, the other which severities must be cleared. The CSA versus ICSA comparison covers the practical consequence; the tier-to-level article in the ICSA series takes the divergence apart.

Same scan, moving filter

Nothing about the scan changes with the tier. The scanner policy is the same 36 settings the component scheme uses, and it has no tier field: there is no Core policy and no Advanced policy, only one.

What moves is the filter applied to the results afterwards. A supplier who steps from Core to Advanced does not face a harder scan; it faces the same result list with the medium findings now on the work list instead of the information list. That makes the tier decision partly a decision about medium findings: at Advanced each one needs a fix or a rationale, at Core they are recorded and left.

Low findings are tolerated at both tiers

Because ICSA stops at the SL 3 rung, no ICSA tier requires low findings to be addressed, where CSA SL 4 tolerates none. A supplier coming from CSA SL 4 can drop the low band from its work list. Informational findings never count at any tier or level.

Scope: per interface, per mode, per version, with cloud and wireless included

The unit of scanning is the accessible network interface, and each is scanned on its own. Where the product has operating modes in which an essential function is active, the scan repeats in each. The whole set is tied to the component version under evaluation. A product with no accessible interface is not scanned, and the report records that outcome with its reason.

What IIoT adds is the shape of the interface list. A cloud-side connection and a wireless radio are accessible network interfaces like any other, scanned the same way and reported per interface; neither a cloud far end nor a radio medium exempts them. The ICSA-303 report template's worked example declares four external interfaces on one device: a wired control-network port, a wireless control-network radio, and two cellular links to separate cloud services. Every per-interface section of that report, the scan included, repeats four times.

Your interface list populates the scan set; an interface missing from it is missing from the scan. The same declaration states which interfaces face an untrusted network, which matters elsewhere in the evaluation but not here: untrusted or not, an accessible interface is scanned.

The known-good state

The lab scans the product in the state a customer would reasonably deploy it: hardened to your own published hardening guidance, with administrative credentials supplied so the scanner can log in, and with services running unless that guidance says otherwise.

For an IIoT product this makes the hardening guide a test input in two directions. A service the guide says to disable leaves the bench and leaves the findings; a cloud link or radio the guide is silent about stays on and stays in scope. Suppliers who write hardening guidance for the wired port and forget the cellular modem get the modem scanned in whatever state it ships.

A scan, not an attack

VIT-IC looks for known, published vulnerabilities. It does not fuzz protocols, flood interfaces or attempt exploitation. Those remain supplier activities under the IEC 62443-4-1 development lifecycle, and the lab reviews their scope rather than running them; the division of labour is the same as in CSA. If you were expecting the lab to attack your gateway, it will not; it will scan it, and a scan can be rehearsed.

Who does what

Every item on the supplier's list is a test input. On the lab's side, raw scanner output is never handed over: the lab removes what it can show to be a false positive first, then discloses the remaining findings with their severity. As an ISASecure certification body, we release findings only after that triage, so the list you receive is shorter than the one the tool produced.

Preparing for the tier you chose

Because the scan is a known quantity, rehearse it against your tier. Build a unit to your own hardening guide, scan each interface (cloud links and radios included) credentialed and per operating mode with the scanner's protective defaults off, then sort by band: for Core, critical and high are the work list; for Advanced, add medium. Write a disposition for each item now, fix or rationale, tied to the hardening guide. Low findings go in the report either way and need nothing from you.

A supplier who arrives with an interface list that names every cloud link and radio, a hardening guide that speaks to each of them, credentials, and a per-finding disposition for its tier has removed most of the uncertainty from the one test the lab performs. The rest of the ICSA series, and the CSA counterpart of this article, are on the Insights index under the ICSA and CSA filters.