What it takes to reach SL 3 in ISASecure CSA, by component type

Once a product is at SL 2, the next question is how far away SL 3 is. The honest answer is closer than you expect in count and further than you expect in depth, and this article puts numbers on both halves: what ISASecure CSA adds between SL 2 and SL 3 under IEC 62443-4-2, how the increment differs across the four component types, where it lands by foundational requirement, and which new items the certification lab exercises on the product itself.

New to the cumulative security-level model or the four component types? The series opener covers both.

The SL 3 step in one number

Going from SL 2 to SL 3 adds exactly 23 requirements to the functional security assessment: 22 requirement enhancements and one new base requirement, CR 2.7. Across the whole set, the count in scope moves from 134 at SL 2 to 157 at SL 3. For comparison, the climb from SL 1 to SL 2 adds 56 and the step from SL 3 to SL 4 adds six, all enhancements. SL 3 sits in between at well under half the SL 2 increment, but with a character of its own: almost everything in it is an enhancement.

Why "enhancement" matters for planning

IEC 62443-4-2 builds every requirement family out of base requirements and requirement enhancements. A base requirement introduces a capability the component must have. An enhancement does not introduce a new capability; it attaches to a base requirement and raises the bar for it at a higher security level. The same mechanism has to be stronger, cover more cases, hold up against a more capable adversary, or rely less on a person doing the right thing.

That structure shows in the counts. None of the 49 enhancements in the CSA set applies at SL 1; they are entirely an SL 2 and above construct. And of the 23 items added at SL 3, only one is a base requirement.

The planning consequence is direct. Reaching SL 3 is mostly deepening rather than widening: you are not adding 23 features, you are revisiting 22 things you already built for SL 2 and proving a stronger version of each. Whether that is cheap or expensive depends on the margin the SL 2 implementation left. A mechanism built to the minimum will often need a redesign; one built with headroom may already satisfy the enhancement and simply need evidence.

The increment by component type

The 23 is the whole-scheme figure; any one product sees fewer, because type-specific families apply only to their own type.

Fourteen of the 23 carry the CR prefix and apply to every component type, and that is exactly the software application's increment: it picks up no type-specific items at SL 3. An embedded device and a host device each add two type-specific enhancements on top, for 16. A network device adds five, for 19, which makes it the type with the most ground to cover.

In cumulative terms, the SL 3 set is 95 requirements for a software application, 109 for an embedded device, 107 for a host device and 115 for a network device.

The certificate is issued against the full cumulative set for your type, not the increment. The 23 is the right list for a product that already meets SL 2; one starting from SL 1 has the 56-requirement step to cross first.

Where it lands, by foundational requirement

The increment is not spread evenly. Three families absorb most of it.

Identification and authentication control, 7 added. The largest slice, and six of the seven are common to every type. Everything the product does for identity and credential handling at SL 2 acquires a stronger SL 3 form. Start here: the answers tend to sit in platform decisions that are costly to reopen late, such as where identities and credentials live, how they are protected, and what the authentication mechanism can withstand. A network device picks up one type-specific item as well, and the lab tests it.

Use control, 6 added. The only new base requirement, CR 2.7, lives here, with two common enhancements and a type-specific enhancement for each of the three device types. Use control governs what an authenticated user or process may do and how that is enforced; the SL 3 forms tighten the enforcement. CR 2.7 and the device-specific 2.13 enhancement are both on the lab's hands-on list.

System integrity, 4 added. One common enhancement, CR 3.4 RE(2), plus the 3.11 enhancement in its embedded, host and network device forms. A software application therefore adds only one item here. For the three device types, the 3.11 answer usually sits in hardware or platform design rather than application code, which makes it the longest lead-time item on the list.

Data confidentiality, 2 added. Both are enhancements of CR 4.2 and both apply to every type. RE(2) is lab-tested, so the confidentiality mechanism has to be demonstrable on the bench, not only in a design document.

Restricted data flow, 2 added. Network devices only: NDR 5.2 RE(2) and NDR 5.2 RE(3), both lab-tested. This family is the main reason a network device carries the largest increment and the heaviest hands-on load. The other three types add nothing here.

Timely response to events and resource availability, 1 each. One common enhancement apiece, CR 6.1 RE(1) and CR 7.6 RE(1). Small, easy to overlook, in scope for everyone, and CR 7.6 RE(1) is on the lab's hands-on list.

Common component security constraints, 0 added. All 11 CCSC rows apply at every security level and carry no enhancements, so nothing changes here.

The full list

The 2.13 RE(1) and 3.11 RE(1) entries each exist as a separate row for embedded, host and network devices, which is how the 19 entries below make up 23 requirements, and how the seven lab-tested entries make up nine flagged rows.

The nine the lab tests itself

Of the 166 requirements in the CSA set, 34 are flagged for independent testing: the laboratory exercises them on the product rather than accepting the supplier's test report. Nine of the 23 added at SL 3 carry that flag:

• Common to every component type: CR 2.7, CR 4.2 RE(2) and CR 7.6 RE(1)
• One row per device type: EDR 2.13 RE(1), HDR 2.13 RE(1) and NDR 2.13 RE(1)
• Network devices only: NDR 1.13 RE(1), NDR 5.2 RE(2) and NDR 5.2 RE(3)

A network device sees seven of the nine in scope, an embedded or host device four, and a software application three. CR 2.7, CR 4.2 RE(2) and CR 7.6 RE(1) apply to every type; the rest follow the type.

For the other 14 items, the evidence you bring decides the result: test records, design documentation and demonstrations, evaluated by the assessor. For the nine, the lab needs a representative, working configuration of the product and the time to exercise each one. As an ISASecure certification body, this is where we spend bench time in an SL 3 evaluation, so those nine are worth rehearsing against your own test procedures before the product arrives.

The scan threshold moves too

The functional requirements are not the only thing that tightens. The lab's vulnerability identification scan of every accessible interface is identical at every level, but the pass threshold ratchets by one severity band per level. At SL 3, critical, high and medium findings must all be corrected or documented as not relevant before the stream can close; at SL 2, medium findings are tolerated. What the scan does and does not do, and where fuzzing, load testing and penetration testing sit alongside it, is in the testing article.

Planning the step

1. Treat the 23 as a gap list, not a feature list. Sort each item against your SL 2 implementation into three buckets: already met with headroom, met after a configuration or documentation change, or needs redesign. The third bucket is your schedule.
2. Sequence by lead time. Hardware- and platform-bound items first: the device-specific integrity enhancement and the identity and credential items. Configuration and documentation items last.
3. Prepare two kinds of evidence. Written test and design evidence for the items evaluated by review; a working bench configuration for the nine the lab exercises.
4. Rerun your own scan with the SL 3 filter. Medium findings now count. Fix them, or have the not-relevant rationale written, before the lab finds them.
5. Remember the whole set. The certificate covers all 95, 107, 109 or 115 requirements for your type. If you are certifying at SL 2 now, work the 23 in parallel so the next step is a delta rather than a restart.

The rest of the series is on the CSA filter of the Insights index.