CSA vs ICSA: which ISASecure scheme fits your device

Two ISASecure schemes certify an individual product against IEC 62443-4-2: CSA, Component Security Assurance, and ICSA, IIoT Component Security Assurance. They share a standard, a structure and most of a requirement set, which is why suppliers get stuck choosing between them. The differences are few, but each one changes what you apply for, what you are evaluated against, and what happens after the certificate is issued.

This article puts the two side by side, then works through the one question that settles most cases and the handful that settle the rest.

The comparison at a glance

Start with the list your product is on

CSA is the scheme for the four component types IEC 62443-4-2 has always recognised: software applications, embedded devices such as controllers and protective relays, host devices such as HMI stations and servers, and network devices such as industrial switches and firewalls. The first article in this series covers how each type shapes the evaluation.

ICSA is the scheme for two product types that did not fit that list cleanly. An IIoT device is a connected product whose defining characteristic is that it talks outward, to cloud services, analytics platforms or enterprise-side systems, often from a position a classic zone-and-conduit design would have kept isolated. An IIoT gateway sits between control-side equipment and that outward path, collecting, translating and forwarding on its behalf.

So the first question is not which scheme is stricter, faster or cheaper, but which list your product is on. Usually that takes a sentence: a PLC is an embedded device and goes to CSA; a cellular edge box pushing telemetry to a cloud platform is an IIoT gateway and goes to ICSA.

Security level versus tier

CSA states its scope as a capability security level. Under CSA-300 (ISASecure_C.R1) the applicant names the maximum level sought, SL 1 through SL 4, and the certification body awards the highest level the component actually meets, up to that ceiling. CSA-300 also notes that a product built for SL 2 can be certified at SL 1 as an interim step. The certificate still carries exactly one level. The requirement set is cumulative, so each level includes everything below it, and the level is the biggest driver of how much is evaluated.

ICSA states its scope as a tier, Core or Advanced, which decides the applicable requirements in the same way, and the award rule under ICSA-300 (ISASecure_IC.R1) has the same shape: the applicant names the highest tier sought and the certification body awards the highest tier the component earns. Because IEC 62443-4-2 itself has no concept of tiers, the scheme maps each tier to a security level as a cross-reference, so that a reader can place the tier against the standard.

This matters at procurement time. If a customer specification asks for a component "capable of SL 2," a CSA certificate answers directly; an ICSA certificate answers through the tier's cross-reference, which, as shown below, is not the same number in every part of the evaluation.

Same base, one extra sheet

Both schemes evaluate against the IEC 62443-4-2 requirement set: the four common component security constraints, CCSC, and the seven foundational requirements, FR 1 to FR 7. In CSA that set runs to 166 requirements, filtered by component type and security level.

ICSA starts from the same base and adds a sheet of ICSA-specific requirements on top: 24 additional requirements, of which 18 apply at both tiers and 6 only at Advanced. Those additions are the substantive difference between the two evaluations; almost everything else is naming and scoping.

An ICSA evaluation is never smaller than the CSA evaluation of a comparable product; if you have already built a CSA evidence set, the structure carries over and the ICSA additions are the extra work.

Same three streams, same prerequisite

Both schemes run the same three assessment streams in parallel and converge on one independent decision.

• Development artifacts, SDA-C in CSA and SDA-IC in ICSA. The supplier's SDLA certificate proves the development process is sound; this stream checks that the artifacts the process should produce exist for the product under evaluation.
• Functional security assessment, FSA-C and FSA-IC. Each applicable requirement is evaluated for the product, with a defined subset tested hands-on by the laboratory rather than accepted from the supplier's report.
• Vulnerability identification testing, VIT-C and VIT-IC. The laboratory scans the product for known, published vulnerabilities on its accessible network interfaces.

Both require a valid ISASecure SDLA certificate before the product evaluation can conclude, and both apply the same shape of decision: every stream complete, nothing left not met, nothing left open. In both, the laboratory's own hands-on work is the vulnerability scan plus the flagged functional subset; fuzzing, load testing and penetration testing remain supplier activities, as the testing article in this series explains.

The vulnerability-testing trap

This is the one difference that catches people.

In CSA, the scan pass criterion is tied to the security level: four criteria, one per level. At SL 1 only critical findings must be addressed, and each level up adds one severity band. In ICSA, the pass criterion is tied to the tier: two criteria, one for Core and one for Advanced.

The trap is that the Advanced tier does not sit at the same point on the security-level scale in every stream. In vulnerability testing, the Advanced criterion corresponds roughly to the SL 3 criterion in CSA. In the functional assessment, Advanced is treated as roughly the SL 4 requirement set. An Advanced-tier product is held to something like the full functional set but to the second-highest scan threshold.

Two things follow. Do not plan functional coverage from the vulnerability-testing equivalence; you would under-scope by a full level. And if a customer asks whether an ICSA Advanced certificate is equivalent to a CSA SL 4 certificate, the honest answer is: for the functional assessment, roughly; for the vulnerability scan, no.

After the certificate

Neither scheme puts a fixed validity period on the certificate, and CSA runs no surveillance audit. Under CSA-301 a CSA certificate covers the certified version and its updates for as long as the supplier holds an SDLA certification whose scope includes the component and keeps the component in support. If SDLA lapses, a one-year grace period runs before withdrawal; supplier-notified end of support also ends in withdrawal. At each SDLA recertification the certificate is amended with the supported update versions; that SDLA cycle, not a CSA validity period, is the source of the three-year figure sometimes attached to CSA.

ICSA-301 keeps the SDLA and support conditions and adds one: the supplier must stay in good standing under the Security Maintenance Audit, the scheme's periodic surveillance audit of how the supplier has handled security issues, user reports, unfixed severe findings and update delivery. An open audit finding gets an agreed grace period of 30 to 90 days; if it stays open the certificate is suspended, closing every open finding within a year of its report restores it, and otherwise it is withdrawn. That is a standing commitment on the team that shipped the product, and should be budgeted from the outset.

Deciding

For most products the decision is short.

• Connectivity is the point of the product. If its defining function is connecting control-side equipment to cloud services, analytics platforms or enterprise systems, or it performs a gateway role, ICSA is the scheme built for it.
• The product is a classic control component. A controller, a relay, an HMI, a historian client, an industrial switch: CSA, scoped to the security level your target market specifies.
• The product is borderline. A field device with a cloud agent bolted on, a network device with an outward-facing management path, an application fronting a fleet of connected devices: do not choose by preference; have the certification body scope it before you apply, because type and scheme are fixed on the certificate.

As an ISASecure certification body for both CSA and ICSA, we run that scoping conversation with the supplier before an application is accepted.

Where to go next

This is the closing article in the CSA Fundamentals series. If your product belongs in CSA, the series index walks through the component types, security levels, streams and testing split. If it belongs in ICSA, the ICSA articles pick up where this one leaves off.