ICSADeep diveMyth-buster

Advanced is SL 4, except when it is SL 3: the ISASecure ICSA tier-to-level trap

ICSA Advanced maps to SL 4 in the functional assessment but to SL 3 in vulnerability testing. Why the mappings diverge and how to read the certificate.

Perseus ISASecure Assessor TeamSeptember 8, 20268 min read

Ask what security level an ISASecure ICSA Advanced certificate corresponds to and you will get a confident answer: SL 4. Ask about Core and you will hear SL 2. Both are half right, and the wrong half is the one that matters when an integrator places an IIoT gateway against a specification written in IEC 62443 language.

ICSA does not have one tier-to-level mapping. It has two, one per axis the scheme scores along, and they agree only at Core. This article sets out both, explains why the divergence is a design choice rather than an error, and shows how to read an ICSA certificate against a CSA level.

Why the translation exists at all

IEC 62443-4-2 has no concept of tiers. It scopes a component by capability security level, SL 1 to SL 4, and CSA carries that level straight onto the certificate. ICSA, the scheme for IIoT devices and IIoT gateways, scopes by tier instead: Core or Advanced, one per certificate. Because procurement language is written in the standard's vocabulary, the scheme provides a way of reading a tier as a level. The trap is assuming it is a single number. The CSA-versus-ICSA comparison flagged this without room to unpack it; this article does.

Two axes, two mappings

An ICSA evaluation scores a component along two independent axes. The functional security assessment, FSA-IC, decides which IEC 62443-4-2 requirements and ICSA additions apply. Vulnerability identification testing, VIT-IC, scans every accessible interface for known vulnerabilities and decides which severities of finding must be cleared. Each axis has its own tier-to-level correspondence.

AxisCoreAdvanced
Functional assessment: which requirements applyRoughly the SL 2 set, with exceptionsThe complete SL 4 set for IIoT-applicable rows
Vulnerability testing: which findings must be addressedCritical and high, the CSA SL 2 thresholdCritical, high and medium, the CSA SL 3 threshold

Across the Core row the two mappings agree, SL 2 on both axes, corroborated by the ICSA-303 report example, which documents a Core evaluation. Across the Advanced row they part company by a full level. Both Advanced mappings are as set out in ICSA-300; the functional one is also carried in the ICSA-311 workbook's requirement tree, the vulnerability-testing one is the tier-based pass criterion the report template references as ISASecure_IC.R5.

The functional axis: Advanced really is SL 4

On the functional side, "Advanced is SL 4" is not an approximation. The workbook's requirement tree marks Advanced as exactly the complete SL 4 set for every row that applies to IIoT products, plus all 24 ICSA additions: 182 requirements, 158 shared IEC 62443-4-2 rows and 24 IIoT additions, six of which, numbered 19 to 24 in ICSA-311, are Advanced-only.

Core is the approximate one. It is built on the SL 2 set with 18 marked exceptions, and their structure is where "Core equals SL 2" breaks down.

  • Eleven rows 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) rows for embedded, host and network devices, CR 4.2 RE(1), NDR 5.2 RE(2), CR 6.1 RE(1) and CR 7.6 RE(1).
  • Three SL 2 rows are held back from Core in their full form. CR 2.1 RE(2) reaches Core in one form while its stronger, device-specific form is Advanced-only; CR 7.3 RE(1) reaches Core only as a partial form, with the full requirement at Advanced.
  • Four rows at SL 3 or SL 4 are outside both tiers. CR 1.7 RE(1), CR 2.1 RE(3), CR 2.1 RE(4) and CR 3.9 RE(1) carry no IIoT applicability mark, which in ICSA means out of scope. This is why "the complete SL 4 set" is qualified to IIoT-applicable rows.

Set against CSA's four levels, ICSA's entry tier already sits near the top of the range.

How much is in scope: CSA security levels vs ICSA tiers
SchemeEntry levelTop level
CSA (SL 1 to SL 4)78163
ICSA (Core to Advanced)158182

CSA scales from 78 requirements at SL 1 to 163 at SL 4. ICSA's entry tier already sits at 158, because Core is built on the SL 2 requirement set plus 18 IIoT additions; Advanced reaches 182.

The vulnerability-testing axis: Advanced stops at SL 3

VIT-IC is the same scan CSA runs, with the same scanner settings, against every accessible network interface in every operating mode where an essential function is active. What differs is the pass criterion. CSA ties it to the security level, a ratchet that adds one severity band per level until SL 4, where every finding down to low severity must be addressed. ICSA ties it to the tier and keeps only two rungs of that ladder.

At Core, critical and high findings must be corrected or documented as not relevant; medium and low may remain. At Advanced, medium joins the list; low may still remain. On the CSA ladder, Core sits on the SL 2 rung and Advanced on the SL 3 rung. No ICSA tier reaches the SL 4 threshold.

Vulnerability acceptance thresholds: CSA security levels vs ICSA tiers
Finding severityCSA SL 1CSA SL 2CSA SL 3CSA SL 4ICSA CoreICSA Advanced
CriticalAddressAddressAddressAddressAddressAddress
HighAddressAddressAddressAddressAddress
MediumAddressAddressAddress
LowAddress

CSA ratchets one severity band per security level up to SL 4, where every band must be addressed. ICSA's two tiers sit at the SL 2 and SL 3 rungs of that ladder: no ICSA tier reaches the SL 4 threshold.

The consequence is precise and easy to misstate. A low-severity known-vulnerability finding is tolerated at every ICSA tier, whereas a CSA SL 4 certificate tolerates none. "Advanced is SL 4" is true of the requirement set and false of the scan.

At neither tier does "addressed" mean zero findings. The testing article of the CSA series covers what the scan is and is not; the procedure is shared, only the acceptance filter differs.

Why this is not a contradiction

The two axes measure different things. The functional axis measures capability: which security functions the product implements, and at what strength. The vulnerability axis measures residual exposure: which known weaknesses may remain on the shipped version. IEC 62443-4-2 defines the first in terms of security levels; the scan threshold is a scheme construct layered on top, and nothing obliges a scheme to set the two at the same level.

ICSA sets them independently, and at the top tier it is stricter on capability than on residual tolerance of known vulnerabilities: the full SL 4 functional set for IIoT products, with Advanced-only additions covering hardware-backed protection, compartmentalisation of security functions and presence monitoring, but a scan threshold one rung short of the strictest CSA criterion. CSA moves the two together because its scope axis is the level itself; ICSA's is the tier, and each stream maps it onto the standard in its own way.

What the certificate carries

An ICSA certificate is scoped by tier, and the tier is what is bound into it: one per certificate, deciding which of the 182 requirements were evaluated. The scheme description also calls for the certificate to carry an IEC 62443-4-2 security level as a cross-reference, so that a reader can place the tier against the standard. Treat that cross-reference as a pointer whose meaning depends on the axis it was drawn from. It is not a CSA level, and on its own it says nothing about the scan threshold.

How to read an ICSA certificate against a CSA SL claim

For the reviewer holding an ICSA certificate and an "SL 4 capable" requirement:

  1. Start from the tier, not the level. Core means the SL 2-based functional set with the exceptions above plus 18 IIoT additions, 158 requirements; Advanced means the complete SL 4 set for IIoT rows plus all 24 additions, 182.
  2. Ask which axis any security-level figure refers to. At Advanced, the functional level and the scan level are different numbers. If a datasheet says "SL 4" without saying which, assume the functional mapping and confirm.
  3. For the scan, translate the tier into a severity threshold. Core: critical and high addressed. Advanced: critical, high and medium. Low findings may remain at either tier; if your specification requires that none remain, ask for the scan report, because the certificate alone does not evidence it.
  4. Do not equate Advanced with CSA SL 4. Close for the functional assessment, one level short for the scan. The CSA-versus-ICSA article covers the remaining differences.
  5. Count the additions in ICSA's favour. At either tier the certificate attests to IIoT-specific requirements a CSA certificate never evaluates.

As an ISASecure certification body for both CSA and ICSA, we meet this question most often when an applicant's customer has written its specification in CSA terms; the answer is the table above, read one axis at a time.

Where to go next

The rest of the ICSA Fundamentals series covers what Advanced adds in detail, the 24 IIoT additions, the vulnerability-testing thresholds in their own right, and the security maintenance audit that keeps a certificate in good standing.

Frequently asked questions

Only on the functional side. Advanced applies the complete SL 4 requirement set for IIoT-applicable rows, plus all 24 ICSA additions. In vulnerability testing, the Advanced pass criterion matches the CSA SL 3 threshold: critical, high and medium findings must be addressed, and low findings may remain. A CSA SL 4 certificate requires every severity band to be addressed.

ISASecure ICSAICSA Advanced tierIEC 62443-4-2 security levelICSA Core vs AdvancedIIoT device certificationvulnerability identification testing
Share this article
Back to Insights

Ready to Get Started?

Let our team of experts help you achieve and maintain compliance with industry-leading cybersecurity standards.