What ISASecure ICSA certification actually evaluates

If your product is a connected field device or an edge gateway that pushes data to a cloud platform, and someone has asked for it to be "62443 certified," the scheme built for it is ISASecure ICSA, IIoT Component Security Assurance. It is the IIoT counterpart of CSA: the same standard underneath, IEC 62443-4-2, with an IIoT-specific layer on top, a different way of stating scope, and one obligation that continues after the certificate is issued.

This article is the map.

The certificate in one sentence

An ICSA certificate says that a specific component, at a specific version and of a stated IIoT device type, meets the IEC 62443-4-2 requirements and the ICSA-specific additions applicable to it at a stated tier, Core or Advanced, and was developed under an ISASecure-certified secure development lifecycle.

The applicant names the highest tier it seeks and the certifier awards the highest tier the component qualifies for (ISASecure_IC.R1); the awarded tier is bound into the certificate, so a Core certificate and an Advanced certificate are different products, and moving up means a further evaluation, not a relabel. The certificate names the standard and the supplier's SDLA certificate; the evaluated network interfaces are recorded in the assessment report.

Two device types, and a product can carry both

IEC 62443-4-2 has four component types. ICSA adds two of its own, the only two an ICSA certificate is issued against.

• An IIoT device is a connected product whose defining trait is that it reaches outward, to cloud services, analytics platforms or enterprise systems. An edge computing device is a sub-case of this type, not a third type.
• An IIoT gateway sits between control-side equipment and that outward path, collecting, translating and forwarding on its behalf. In IEC 62443-4-2 terms a gateway is a kind of network device, so the network-device requirement family applies to it.

A product is evaluated against every type that applies to it: one or both IIoT types, plus whichever classic IEC 62443-4-2 types it also matches. The type set decides which requirements are in scope and is fixed on the certificate; as an ISASecure certification body, we settle it with the supplier before an application is accepted.

The tier is the scope; the security level is a cross-reference

Where CSA is scoped by a capability security level, ICSA is scoped by tier: Core, the IIoT baseline every eligible component must reach, or Advanced, the same structure with stronger controls such as hardware-backed protection and separation of security functions. Every requirement in the workbook is tagged with the tiers it applies to; one tagged for neither is out of scope. Core is a subset of Advanced.

Each tier is cross-referenced to a security level so the certificate can be read against procurement language. Core corresponds roughly to the SL 2 requirement set. Advanced corresponds roughly to SL 4 for the functional requirements, the equivalence ICSA-300 draws, but its vulnerability-scan threshold, critical, high and medium, matches the CSA scan's SL 3 band, not SL 4. That divergence is intentional and the most misreported fact about the scheme; it gets its own article.

Five evaluation elements, one decision

ICSA is defined as five evaluation elements. Four produce the certificate; the fifth keeps it valid.

SDLPA-IC, the development-process prerequisite. A valid ISASecure SDLA certificate covering the development process satisfies this element; ICSA does not re-audit the process. That certificate gates the artifacts stream and anchors the maintenance-audit schedule after issue.

SDA-IC, security development artifacts. Checks that the artifacts the certified process should have produced exist for this component: per ISASecure ISDLA-312, 93 of the 118 IEC 62443-4-1 lifecycle requirements, the 77 CSA also checks plus 16 that exist only for IIoT components.

FSA-IC, functional security assessment. The IEC 62443-4-2 stream, with the ICSA additions folded in. Each applicable requirement is evaluated for the component; 47 of them, 40 at Core, are flagged for the laboratory to exercise hands-on rather than accept from the supplier's test report.

VIT-IC, vulnerability identification testing. The laboratory scans every accessible interface, cloud and wireless links included, for known, published vulnerabilities, with a pass threshold 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. Fuzzing and penetration testing stay with the supplier, as in CSA; the CSA testing article explains the split.

SMA, the Security Maintenance Audit. The element CSA does not have. It starts after the certificate is issued and is covered below.

The decision rule is the one CSA uses: every stream complete, the prerequisite verified, nothing left not met, no vulnerability finding left open, and a decision-maker who did not lead any stream, as ISO/IEC 17065 requires.

The 182 functional requirements

The functional stream draws on 182 requirements: 158 shared IEC 62443-4-2 requirements that CSA also evaluates, plus 24 additions that exist nowhere else in ISASecure.

The shared 158 follow the standard's structure, the CCSC constraints and the seven foundational requirements, with identification and authentication control, use control and system integrity carrying most of the count. The 24 additions form a ninth family, covering themes the base standard does not reach for a device on an untrusted network: secure defaults and unique initial credentials, protection of software and data in use, update handling, behaviour on interfaces that face an untrusted network, internal partitioning and zoning, and, at Advanced, hardware-backed protection and presence monitoring. Four of the 24 are evaluated per interface, and their relevance depends on which interfaces the supplier declares as facing an untrusted network.

Core evaluates 158, Advanced evaluates 182

The step from Core to Advanced adds 24 requirements: 18 from the shared base, 15 of them requirement enhancements, and the six Advanced-only additions, numbered 19 to 24 in ICSA-311. Seven of them are lab-tested.

Core is already a large evaluation, built on the SL 2 requirement set plus 18 of the 24 additions, and Advanced is the top of the scheme rather than a middle rung. Device type moves the count too: at Advanced, an IIoT device carries 158 requirements and an IIoT gateway 163, because the network-device family applies to gateways.

After the certificate: the Security Maintenance Audit

ICSA is an ISO/IEC 17067 Type 5 scheme, certification with surveillance, and the surveillance is a periodic Security Maintenance Audit of the certificate holder. It examines the IEC 62443-4-1 practices DM-1, DM-2, DM-4 and SUM-5 through four topics: the security notifications the supplier received, the issues its users reported, how severe issues were dealt with, and whether updates were delivered in time.

Results are appended to the assessment report as numbered addenda and findings go to the certification committee. ICSA-301 sets no fixed validity period: the certificate covers the certified version and its updates while the supplier holds SDLA certification covering the component, the component remains in support and the supplier stays in good standing under the audit; a lapse in SDLA starts a one-year grace period that ends in withdrawal. A nonconformity still open after its agreed grace period suspends the certificate, which is restored if every open nonconformity is closed within a year of being reported and withdrawn otherwise. Suppliers with at least a year of release history can opt into a historical audit at initial certification; otherwise the first audit falls a year after certification or at the next SDLA recertification, and later audits track SDLA recertification.

An ICSA certificate is therefore a standing commitment, not a milestone; budget the defect-handling and update-delivery evidence from the outset.

What ICSA is not

• CSA certifies the four classic IEC 62443-4-2 component types, scoped by security level, without the ICSA additions or the maintenance audit. A PLC, a relay, an HMI or an industrial switch belongs there; the CSA versus ICSA article works through the borderline cases.
• SSA certifies an integrated system built from components, against IEC 62443-3-3.
• SDLA certifies your development process, not a product. It is the prerequisite for ICSA, not an alternative to it.

Where to go next

This article opens the ICSA Fundamentals series; the rest takes each of these topics one level deeper and adds cloud and wireless interfaces and what the laboratory tests itself. Browse the set from the ICSA filter on the Insights index. For classic components, the CSA hub article is the equivalent map.