Ask an IIoT supplier to list the network interfaces on a product and the answer often stops at the Ethernet port. The cellular uplink is "the cloud side," the radio is "the field side," and neither feels like something a certification laboratory would plug into. ISASecure ICSA does not see it that way. Each of those links is an accessible network interface, and in ICSA the interface list is the largest multiplier of evaluation effort after the tier.
This article explains why interfaces multiply the work, what the report template's own example looks like, what repeats per interface, how the supplier's untrusted-network declaration switches parts of the evaluation on, what the assessor additionally looks at when the product is a gateway, and how to prepare.
Why interfaces multiply the work
Most of the 182 functional requirements in an ICSA evaluation are evaluated once for the product. A subset is not: those are evaluated once per accessible network interface and rolled up worst-case, so the requirement counts as met for the component only if it is met on every interface where it applies. One interface that fails a per-interface row leaves that row not met, and the decision rule for the certificate allows no requirement in that state.
The vulnerability scan follows the same logic. VIT-IC is scoped per accessible network interface, in each operating mode where an essential function is active, and per component version. A component with no accessible interface is not scanned, and the report records why; a component with four interfaces is scanned on four. Where a per-interface row is also one the laboratory tests hands-on, that test is repeated on each interface as well.
The evaluated interfaces are recorded in the assessment report rather than on the certificate, and the list you hand over sets the scope of the per-interface rows, the scope of the scan and a large share of the bench time.
The template's own example: four interfaces, two of them cloud
ICSA-303, the assessment report template, carries a worked example. The example product declares four external interfaces: a wired control network, a wireless control-network radio, and two separate cloud networks reached over cellular links, one for operations and one for management. Every per-interface section of the report then appears four times, once for each.
Nothing in the example treats the cloud links or the radio as a special class. There is no cloud exemption, no reduced set for an interface that only talks upward, and no allowance for a radio being harder to reach. A cellular link to a management platform is an accessible interface in exactly the sense an Ethernet port is, and SSA-420, the vulnerability-testing procedure ICSA builds on, allows for wireless paths to the bench.
Device type does not change this. An IIoT device and an IIoT gateway can each carry cloud-side and wireless interfaces; the type decides which requirement families apply, the network-device family for a gateway for instance, not whether an interface is evaluated.
What repeats per interface
Read the template against the evaluation workbook and the per-interface set is this.
| What | Stream | How it is evaluated |
|---|---|---|
| CCSC 1A–1E | FSA-IC | Once per accessible interface, rolled up worst-case |
| Identification and authentication control, FR 1 | FSA-IC | The applicable rows are worked interface by interface in the template |
| Use control, FR 2 | FSA-IC | Likewise, interface by interface |
| ICSA additions 9, 10 and 11 | FSA-IC | Once per interface declared as facing an untrusted network |
| ICSA addition 19 | FSA-IC, Advanced tier only | Once per interface |
| Known-vulnerability scan | VIT-IC | Every accessible interface, in every operating mode with an essential function |
| The other 20 ICSA additions | FSA-IC | Once for the product |
Two of the four per-interface additions, 10 and 11, are also among the eight additions the laboratory tests hands-on, so on a product with several untrusted-facing interfaces those tests run on each of them. And because the roll-up is worst-case, a management link that fails an authentication row cannot be offset by a control-network port that passes it.
The untrusted-network declaration
The switch that decides where additions 9, 10 and 11 apply is a declaration the supplier makes, not a judgement the assessor makes. ICSA-300 calls it ISASecure_IC.R4: the supplier lists the product's interfaces and the protocols on each, and states which of them connect to an untrusted network. On every interface so declared, the three additions become relevant; on interfaces declared trusted, they do not.
Their themes, in plain words: whether non-human users arriving from an untrusted network are authenticated (9), whether the product protects itself from management traffic that originates on an untrusted network (10), and whether it can block its connection with an untrusted network altogether (11). Addition 19, the fourth per-interface row and Advanced-only, concerns the security status of portable and mobile devices that connect to the product.
Two cautions. Declaring an interface trusted does not take it out of the per-interface set: the CCSC rows, the FR 1 and FR 2 rows and the scan still apply to every accessible interface. And the scheme does not allow any of the 24 additions to be recorded as met by integration into a system. The component itself has to provide the behaviour on the interface in question; an upstream device in the customer's network does not count.
For most IIoT products the declaration is short: the cloud links face an untrusted network, and the control-side interfaces may or may not, depending on the architecture the product is designed for. Whatever you declare, keep the design documentation and the user guidance saying the same thing.
What the assessor additionally looks at on a gateway
None of what follows is an extra scheme requirement. It is what the assessor will look at, in the certification body's own process, when the product is an IIoT gateway, because a gateway is where the trusted and untrusted sides meet. As an ISASecure certification body, Perseus works through four things on a gateway evaluation:
- Trusted and untrusted interface delineation. The declared boundary is read against the product's architecture: which interfaces sit on which side, what crosses between them, and whether the declaration, the design documentation and the user guidance describe the same boundary.
- Software-bill-of-materials dependency analysis. The gateway's third-party components and libraries, which for a cloud-connected product usually include the client stacks that terminate the cloud links.
- Cloud-component assessment. The cloud-side components the gateway depends on to deliver its function, and how that dependency is documented. Documenting cloud dependencies is one of the five lifecycle practices that exist only for IIoT components, and the gateway review leans on it.
- Cloud-service change review at the Security Maintenance Audit. Cloud services change without a firmware release. At the periodic maintenance audit that keeps an ICSA certificate in good standing, changes on the cloud side of a gateway are reviewed alongside the defect and update handling the audit examines.
What to prepare
- An interface inventory with trust status. Every accessible network interface, wired, wireless and cloud-side, with a statement of whether it faces an untrusted network. This is the ISASecure_IC.R4 declaration, and it should be complete before the evaluation is scoped.
- Protocols and ports per interface, including the operating modes in which each interface is reachable, so the scan and the per-interface rows can be planned per interface and per mode.
- Hardening guidance per interface. The bench is configured the way your own security guidance tells a customer to configure it, not locked down for the test, so the guidance has to cover every interface, cloud links included.
- Credentials for credentialed scanning, at the roles the laboratory will need, plus any certificates or keys the cloud links expect. For cellular and wireless links, say how the laboratory will reach the interface on the bench.
- Consistency between the list you declare and the list the lab scans. The interfaces in your declaration, the interfaces on the test unit and the interfaces named in your own test evidence should be the same set. A mismatch produces a follow-up request before it produces a result.
Prepared that way, the cloud links and the radio stop being surprises and become what the scheme already treats them as: interfaces on the list, evaluated like every other. The series index has the rest of the ICSA articles; the CSA overview and the CSA testing article show the same per-interface pattern and where fuzzing and penetration testing sit relative to the scan; and if you are still deciding whether your product belongs in ICSA at all, the CSA versus ICSA article works through the borderline cases.
Frequently asked questions
Yes. A cellular or wired link to a cloud platform is an accessible network interface in the same sense an Ethernet port on the control network is. The per-interface functional rows and the vulnerability scan apply to it, and the report template's own worked example declares two such cloud links alongside a wired and a wireless control-network interface.