CSA security levels 1 to 4: what each level actually adds

"Which security level should we go for?" is usually the first question a supplier asks about ISASecure CSA, and it is usually asked as a budget question. The useful answer starts one step earlier: what a capability security level is, who sets it, and what changes in the evaluation at each step up. This article covers that, with the requirement counts behind every step.

What a capability security level is, and who picks it

IEC 62443 uses security levels in more than one place, which causes confusion. An asset owner assigns a target level to each zone of a plant, based on the risk assessment for that zone. A component has a capability level: the level it can support on its own, correctly configured, before the surrounding system is considered. CSA certifies capability. A certificate that says SL 2 means the component was evaluated against every IEC 62443-4-2 requirement that applies to its type at SL 2, and met them.

Who chooses the level? Both parties do, under requirement ISASecure_C.R1 of ISASecure CSA-300. The supplier names the maximum capability security level it wants on the application; the certification body awards the highest level the component qualifies for, up to that maximum. Usually the two coincide, but a component that falls short at SL 3 while meeting everything at SL 2 is certified at SL 2 rather than sent away. The reverse is allowed too: a product engineered for SL 2 may be put forward for SL 1 first, as a stepping stone. Whatever level is awarded, a CSA certificate carries exactly one level for the whole component. There is no per-interface or per-feature level; the awarded SL applies everywhere the component is exposed. If you want the next level later, that is a further evaluation, not an amendment.

In plain terms, the four levels describe four increasingly capable adversaries the component is designed to hold up against:

• SL 1 assumes nobody is trying to break in. The threat is accident and honest error: a mistyped command, a technician on the wrong screen, a configuration left open by mistake.
• SL 2 assumes someone is trying, but without much investment. Think of an opportunist with freely available tools, no particular knowledge of control systems and no reason to persist if the first attempt fails.
• SL 3 assumes a capable adversary with a budget, real expertise in industrial systems, and a specific interest in this target.
• SL 4 assumes the same kind of adversary with far deeper funding and staying power: a sustained, well-organised campaign against a component that is expected to keep holding.

The cumulative model

Requirement applicability in IEC 62443-4-2 is cumulative. Every requirement in scope at SL 1 is also in scope at SL 2, and so on up the scale. The four levels are nested scopes rather than four separate checklists.

Across all component types, 78 of the 166 CSA requirements are in scope at SL 1, 134 at SL 2, 157 at SL 3 and 163 at SL 4. The count for any individual product is lower, because the type-specific requirement families only apply to their own type; the four component types are treated elsewhere in this series.

SL 4 is the full set. The three-row gap between 163 and 166 is not a reserve of harder requirements: it is three rows the evaluation workbook keeps for numbering parity with the standard, carrying no component-level obligation.

Base requirements and requirement enhancements

The set contains two kinds of item. A base requirement is a capability the component must have. A requirement enhancement, written RE in the identifiers, strengthens a base requirement already in scope: it does not open a new topic, it raises the bar on one that already applies. Of the 166 requirements, 117 are base and 49 are enhancements.

Two things stand out in that matrix. First, not one requirement enhancement applies at SL 1. Level 1 is entirely base requirements. Second, the base row is nearly flat from SL 2 upward. Almost every base requirement that will ever apply is already in scope at SL 2; exactly one more enters above it. From SL 2 onward, going up a level is almost entirely about strengthening capabilities you were already required to have.

Base requirements tend to translate into features: a mechanism has to exist. Enhancements tend to translate into hardening: an existing mechanism has to be stronger, more complete or harder to bypass. Keep the two apart when estimating engineering effort.

The three steps, one at a time

SL 1 to SL 2 is the big jump. Fifty-six requirements enter, more than the other two steps combined: 35 new base requirements and the first 21 enhancements. This is where most of the security functionality people associate with a "62443 certified" component arrives: the base set fills in here. A product designed to SL 1 without the SL 2 set in view will typically need new capability, not tuning.

SL 2 to SL 3 adds 23. Twenty-two are enhancements and one is a base requirement, CR 2.7 in the use-control family. The work is mostly strengthening what SL 2 already made you build, but two things keep the step from being trivial: nine of the 23 carry the scheme's independent-test flag, so the lab exercises them on the product rather than reviewing your test report, and the exact set varies by component type. What it takes to reach SL 3, type by type, is the next article in this series.

SL 3 to SL 4 adds 6. All six are enhancements, and it is the same six for every component type. Whether the step is worth taking is usually a market question rather than an engineering one: will the zones your product is destined for ever carry an SL 4 target?

Choosing a target level

A few practical rules follow from the structure above.

Start from the zones you sell into. Component capability exists to meet zone targets, and the target is set by the asset owner. If your customers' specifications name a level, that is your floor. If they do not, SL 2, where the base set is essentially complete, is a natural first target for a product that has never been certified.

Name the maximum you can evidence now. The maximum you name sets the scope of the evaluation. Because the certifier awards the highest level the component qualifies for, naming SL 3 with two enhancements still open does not sink the evaluation: if every element passes at SL 2, the outcome is an SL 2 certificate. It does mean paying evaluation effort for SL 3 rows that end unmet. Name the level you can meet across the whole component and treat the next one as a roadmap item with its own delta evaluation.

Estimate by kind, not by count. Twenty-three requirements at SL 3 are not the same effort as 23 at SL 2. Sort the delta into base requirements, which usually mean feature work, and enhancements, which usually mean hardening, then flag the independently tested ones, which need a working product on a bench rather than a document.

Remember the level moves more than the functional set. The vulnerability identification scan the lab runs is the same at every level, but its acceptance threshold tightens: at SL 1 only critical findings must be addressed, and each level up adds one severity band.

Factor in your component type. Type-specific families are part of every step, and network devices carry the largest one, so the same level can cost a network device more than a software application. As an ISASecure certification body, the first thing we confirm at application is the maximum level sought together with the component type, because between them they fix the requirement set for the entire evaluation.

Where to go next

What ISASecure CSA certification actually evaluates is the map this article sits inside. Next comes the SL 3 deep-dive, which takes the 23-requirement increment apart by component type and by foundational requirement; you will find it, with the rest of the series, under the CSA filter on the Insights index. If your effort estimate for a higher level includes a lab attack on your product, read where fuzzing, load testing and penetration testing actually live before you budget for it.