Independent testing in ISASecure ICSA: the 47 requirements the lab exercises

Suppliers arrive at ISASecure ICSA with one of two assumptions about independent testing. Those who have been through CSA expect the hands-on load they saw there. Those new to ISASecure read "Core" as the entry tier and expect the laboratory to spend most of its bench time on Advanced. Both fail for the same reason: the scheme flags independent testing requirement by requirement, and the ICSA rows do not behave like the CSA rows.

This article covers what the flag means in ICSA, how many requirements carry it by tier and device type, what the laboratory does with the rest, why the interface list drives bench time, and what to have ready.

Myth 1: Core is the light tier, so the lab barely touches the product

The ICSA evaluation workbook, ICSA-311, lists the 182 functional requirements in an ICSA evaluation: 158 shared IEC 62443-4-2 requirements and the 24 IIoT-specific additions. For every row it records whether the requirement must be validated by an independent test, on a column of its own for ICSA, so the ICSA count is not the CSA count carried over. On the ICSA set, 47 rows carry the flag.

What overturns the myth is where those 47 sit: 40 are already in scope at Core. The Advanced tier adds 24 requirements, and only seven of them are flagged. Most of the laboratory's hands-on work in ICSA happens at the entry tier, because Core is built on a large requirement set to begin with.

For a flagged row, the laboratory exercises the requirement on the product itself: it configures the unit, drives the behaviour, observes the outcome and records the result. Your test report is context; the result rests on the lab's execution. For every other row, the evaluation is evidence review of your test results, design documentation and, where it helps, a live demonstration. Both routes produce a result per requirement in the assessment report, and a single row left not met, whichever route it took, raises a nonconformity that blocks the certificate, with 30 days to respond with root cause, correction and corrective action.

The flag is spread across the whole set rather than confined to one family:

System integrity alone accounts for 14 of the 47; timely response to events has none. For comparison in one line: CSA flags 34 of its 166 functional requirements, so ICSA asks more of the laboratory in absolute terms and in proportion.

Myth 2: the IIoT additions are a documentation exercise

The 24 additions are the requirements that exist only in ICSA, and suppliers coming from CSA tend to treat them as a paperwork layer on a familiar base. Eight of them are lab-tested.

Seven of the eight apply at Core. Two, additions 10 and 11, are among the four additions evaluated once per accessible interface rather than once for the product, and whether they apply on a given interface follows from your declaration of which interfaces face an untrusted network. The laboratory connects to each declared interface in turn, so that declaration is the test plan for those rows.

Myth 3: independent testing means the lab attacks the product

"Independent" in the flag means one thing: for that row, the test is executed by the laboratory, on the product, instead of being accepted from the supplier. It does not mean the laboratory fuzzes your protocols, floods your cellular link or tries to break into your cloud back end. Fuzz, network-load and penetration testing belong to your development lifecycle under IEC 62443-4-1; the laboratory reviews their scope, interface by interface and protocol by protocol, and does not repeat them. The split is the one CSA uses, and the CSA testing article walks through it.

The second thing the laboratory runs itself is the vulnerability identification scan, VIT-IC. Every accessible interface is scanned for known, published vulnerabilities, cloud and wireless links included, and the pass threshold is set by tier: at Core, critical and high findings must be corrected or documented as not relevant; Advanced adds medium; low-severity findings are tolerated at both tiers. The scan has its own article in the ICSA series.

So the laboratory's hands-on work in ICSA comes down to the 47 flagged functional requirements and the scan. Both are laboratory activities performed under ISO/IEC 17025 accreditation, with the method control and records that implies. Evidence review of the remaining requirements is assessment work, and the certification decision is governed by ISO/IEC 17065. As an ISASecure certification body, Perseus keeps those three roles distinct on every ICSA evaluation.

Interface count drives effort, and IIoT products have more interfaces

A subset of the functional requirements is evaluated once per accessible network interface and rolled up worst-case: the requirement is met for the component only if it is met on every interface where it applies. A flagged row in that subset is tested by the laboratory on each interface, and the vulnerability scan is run per accessible interface as well.

In CSA that is a point worth noting. In ICSA it is the main driver of bench time, because an IIoT product is defined by reaching outward. The worked example in the scheme's report template, ICSA-303, declares four external interfaces, a wired control-network port, a wireless control-network radio and two cellular links to separate cloud services, and every per-interface part of that report repeats for each of the four. A cloud uplink and a radio are ordinary accessible interfaces for the flagged tests and the scan alike; a connection that terminates outside the plant earns no exemption.

Device type and tier: what a single product actually sees

The 47 is the flagged set across the whole workbook. No single product sees all of it: some flagged rows belong to the embedded-device family and apply only to IIoT devices, others to the network-device family and apply only to IIoT gateways. Per product, the hands-on load is:

The Advanced step adds these seven flagged rows:

Two of the seven are network-device rows, which is why a gateway's count rises by seven and a device's by five. CR 7.3 RE(1) is the full form of a requirement whose partial form is already lab-tested at Core, so there Advanced deepens a test the laboratory has already run. The full list of 47 lives in the workbook, row by row; before you finalise the test unit and the interface list, ask for the flagged rows that apply to your device type at your tier.

Who decides, and why it is not the tester

The certification decision is made by someone who led none of the streams: not the development-artifact review, not the functional assessment, and not the vulnerability scan. That separation is a requirement on certification bodies under ISO/IEC 17065 and a condition of issuing the certificate. The assessor who exercised your product and the person who signs the certificate are never the same individual.

What to prepare

• A test-ready unit at the exact version under evaluation, in the configuration a customer would deploy, hardened to your own published guidance, with the documentation needed to operate it. A locked-down unit nobody can reach fails the flagged tests before they start.
• Access to every accessible interface, including the cloud uplink and any wireless or cellular path: network reachability, radio access, SIMs or test endpoints, and whatever adapters and cabling the laboratory will need.
• Credentials and accounts at every role the flagged requirements will need, administrative and low-privilege alike, plus any certificates or keys the product expects.
• The declared interface list, complete, consistent with the unit you ship, and stating which interfaces face an untrusted network. It sets the per-interface scope for the flagged tests, decides which additions apply on each interface, and defines the scan set.
• The evidence package for the non-flagged rows: test results and design documentation tied to the version under evaluation and organised by requirement identifier, plus a named contact who can demonstrate on request.

Prepared that way, the laboratory's hands-on work is a known quantity: a defined set of requirements on a defined set of interfaces, with the outcome resting on what the product does rather than on the paperwork. The series index has the rest of the ICSA articles; if you are still choosing between the two component schemes, the CSA versus ICSA article covers the choice.