ISASecure ICSA Core vs Advanced: what the higher tier actually adds

"Core or Advanced?" is usually the first question an IIoT supplier asks about ISASecure ICSA, and usually as a budget question. The useful answer starts one step earlier: what a tier is, who sets it, and what changes when you move up.

What a tier is, and who picks it

ICSA does not scope an evaluation by security level. Its scope axis is the tier, Core or Advanced, and the tier decides which IEC 62443-4-2 requirements apply. Security levels still appear in the ICSA evaluation workbook, but only as a cross-reference to the standard; what governs scope is the tier tag every row carries. A row tagged as applicable to neither tier is outside ICSA altogether.

Who picks the tier? The supplier sets the ceiling and the evaluation sets the result, under the award rule in ICSA-300, ISASecure_IC.R1. On the application the supplier names the highest tier it wants, Core or Advanced. The evaluation runs against every requirement applicable to the device type at that tier, and the certifier awards whichever tier the product reaches, up to that ceiling. One tier is bound into the certificate for the whole product; there is no per-interface tier. Moving up later means, under ICSA-301, evaluating the requirements that differ between the tiers, rerunning the vulnerability scan in full and issuing a new Advanced-tier certificate; it is not an amendment of the Core one.

In plain terms, the tiers are two levels of ambition:

• Core is the IIoT baseline: what every eligible device or gateway should be able to do once it is exposed to networks it does not trust.
• Advanced keeps the same structure and raises the bar: stronger controls across the functional set, plus protections that expect more of the hardware and the design.

Two nested scopes

The tiers are nested: every requirement that applies at Core also applies at Advanced.

Across both IIoT device types, 158 of the 182 ICSA functional requirements are in scope at Core and all 182 at Advanced. Any individual product sees fewer, because the type-specific families apply to only one of the two IIoT types; the device-versus-gateway article in this series covers that.

One precision: the workbook does not define Advanced as "Core plus a list". Every row tagged Core is also tagged Advanced, so the nesting is a property of the published requirement set rather than a formula.

What Core is built on

Core starts from the IEC 62443-4-2 SL 2 requirement set for the rows the workbook marks as IIoT-applicable, then makes two adjustments.

Eleven rows that the standard places at SL 3 or SL 4 are pulled down into Core: CR 1.2 RE(1), CR 2.7, CR 2.9 RE(1), CR 2.12 RE(1), the 2.13 RE(1) row in each of the EDR, HDR and NDR families, CR 4.2 RE(1), NDR 5.2 RE(2), CR 6.1 RE(1) and CR 7.6 RE(1). In the other direction, three rows the standard would place at SL 2 are held back from Core in their full form: the Advanced form of CR 2.1 RE(2), and CR 7.3 RE(1), which Core carries only as a partial form.

On top of that adjusted set sit 18 of the 24 IIoT-specific additions. The result is 158 requirements, and Core is the tier the ICSA-303 sample assessment report evaluates.

What Advanced is

For the shared IEC 62443-4-2 rows, it is the complete SL 4 requirement set for every IIoT-applicable row. On top of that sit all 24 additions, including the six that exist only at Advanced, numbered 19 to 24 in the ICSA-311 workbook.

Those six show the Advanced tier's character. In theme: posture checks on portable and mobile devices before they connect, evaluated once per accessible interface; hardware compartmentalisation of security functions; independence of security functions from the product's non-control functions; limits on how much the product discloses about itself; presence monitoring, which the lab exercises hands-on; and hardware-rooted protection for the software and data the product is running. Two of the six are explicitly hardware-based: the single most important thing to know before choosing the tier.

The 24 added requirements, taken apart

By family, the step adds 6 requirements in identification and authentication control, 2 in use control, 6 in system integrity, 2 in data confidentiality, 1 in restricted data flow, 1 in resource availability, and the 6 IIoT additions. The common component security constraints and FR6, timely response to events, are unchanged between the tiers. FR1 and FR3 carry two thirds of the shared-row growth: stronger proof of who is connecting, stronger protection of what is running.

Sorted by kind rather than by family, the 24 fall into three groups: 15 requirement enhancements, the RE items that raise the bar on a base requirement already in scope at Core; three Advanced-tier forms of clauses that Core already carries in a lighter form; and the six IIoT additions above. Nothing in the shared rows opens a new topic; the step strengthens capabilities Core already required.

Seven of the 24 carry the scheme's independent-test flag, so the certification lab exercises them on the product rather than reviewing your test report: NDR 1.13 RE(1), CR 3.4 RE(2), CR 4.1B (ADV), CR 4.2 RE(2), NDR 5.2 RE(3), CR 7.3 RE(1) and FSA-ICSA-23. For scale, ICSA flags 47 requirements for independent testing, 40 of them already at Core: Advanced adds seven bench tests, not a different kind of evaluation.

The step, per device type

The 24 is the union across both IIoT types; a single product sees fewer.

An IIoT device goes from 137 requirements at Core to 158 at Advanced, a step of 21. An IIoT gateway goes from 141 to 163, a step of 22. Gateways carry slightly more at both tiers because the network-device family applies to them; devices carry the embedded-device family instead.

Choosing a tier

A few practical rules follow.

Start from where the product will be deployed. Core is the baseline for any IIoT device or gateway that faces an untrusted network; Advanced exists for products whose customers need hardware-backed protection, isolated security functions and tighter control over what connects. If your customers' specifications name a tier, that is your floor; if they name a security level, read the next rule.

Do not translate tier to security level without checking which stream. ICSA-300 places Core roughly at SL 2 and Advanced roughly at SL 4 for the functional requirement set, but the Advanced vulnerability threshold matches the band SSA-420 sets for CSA SL 3, not SL 4. Both are cross-references, not the scope; the tier-to-level article in this series takes the mapping apart.

Aim for the tier you can evidence now. A requirement left not met at a tier rules that tier out, so naming Advanced with three enhancements still open does not produce an Advanced certificate; it produces a Core certificate if everything Core asks is met, and none if a Core requirement is open too. If Advanced is the goal but not yet the reality, the 24 added requirements are a roadmap with its own later evaluation.

Estimate by kind, not by count. Sort the step into enhancements, which usually mean hardening what exists, and additions, two of which may mean hardware; then flag the seven independently tested ones, because those need a working product on a bench, not a document.

Remember the tier moves more than the functional set. The lab's vulnerability scan is the same at both tiers, but the acceptance filter moves: at Core, critical and high findings must be addressed; Advanced adds the medium band. Low findings are tolerated at both.

As an ISASecure certification body, the first thing we confirm at application is the highest tier sought together with the device type, because between them they fix the functional requirement set for the entire evaluation.

Where to go next

If you are still deciding whether your product belongs in ICSA, CSA vs ICSA: which ISASecure scheme fits your device settles that first, and what ISASecure CSA certification actually evaluates is the CSA-side map of the same three-stream structure. The rest of the ICSA series sits under the ICSA filter on the Insights index. If your Advanced estimate includes a lab attack on your product, read where fuzzing, load testing and penetration testing actually live before you budget for it.