IEC 62443 target security levels in ACSSA: the asset owner's level decides what is checked, and nothing is awarded

Ask what level a plant is "certified at" under ISASecure ACSSA and you have found its most persistent misunderstanding. ACSSA puts a security level on nothing. Each zone's target security level is the asset owner's own number, from its IEC 62443-3-2 risk assessment, and the evaluation uses it to decide which technical capabilities are checked there. Nothing is graded, computed or awarded in return. Seven myths follow from assuming otherwise.

Myth 1: "ACSSA certifies our IACS at SL 2"

ACSSA certifies an installed industrial automation and control system (IACS), the control system as deployed and operated by the asset owner accountable for it, against four parts of IEC 62443 at maturity level 3. A passing certification report carries three statements of conformity: that the owner's risk assessment conforms to IEC 62443-3-2; that, within the security context it established, the IACS conforms to IEC 62443-2-1 and IEC 62443-3-3; and that the integration and maintenance services conform to the applicable IEC 62443-2-4 requirements. None names a level reached.

Maturity levels are the evaluator's finding: level 2 means the policies and procedures are documented, level 3 means they are practised for this IACS, and certification requires level 3 on every requirement. None of the ACSSA documents that define the evaluation (ACSSA-100, -300, -303, -304 and -311) awards or computes a security level reached.

Myth 2: "The evaluator decides what level each zone needs"

The target security level, written SL-T, comes from the asset owner's IEC 62443-3-2 risk assessment, which assigns each zone and conduit a target from 1 to 4. ACSSA takes those targets as they stand, as part of the zone and conduit information the owner submits to the evaluator. A conduit that contains devices is evaluated like a zone and carries its own target; one without devices receives no separate results and is covered through the zones at its ends.

What the evaluator does examine is the risk assessment itself: whether the process that produced the targets conforms to IEC 62443-3-2 is the subject of the first evaluation phase and the first statement of conformity. The evaluator does not substitute a target of its own for one the risk assessment set.

Myth 3: "A higher target just makes the same checks stricter"

The target changes which IEC 62443-3-3 capabilities are checked, not how strictly. A capability is in scope for a zone when its own security level is at or below the zone's target, plus any capability the owner's cybersecurity requirements specification for that zone calls for on top, unless it addresses a technology the zone does not use at all, wireless networking for instance; that is recorded as NR-TZ, not required because the technology is not used there, a passing result. Applicability by level is cumulative, so the count grows with the target.

Derived from the ACSSA-311 evaluation-methods workbook, in each zone or device-bearing conduit the evaluator samples at maturity level 3 (zones outside the sample receive no result at all): a target of 1 means 45 capability methods are checked; a target of 2 brings 71; a target of 3 brings 101; a target of 4 brings all 111. Those 111 cover all 51 system requirements and 49 requirement enhancements of IEC 62443-3-3 plus four general items the workbook adds; two of the workbook's 113 capability rows are grouping headers whose sub-items carry the evaluation, hence the ceiling of 111.

Within a sampled zone, capabilities above the target are not skipped: each is recorded as NR-S, not required for the zone's target security level, a passing result. All of this happens at maturity level 3, the only level at which ACSSA evaluates IEC 62443-3-3, and asks whether the capability is configured and in use, established from documents, interviews and inspection of the configuration; the evaluator performs no testing and does not access devices. How that sample is chosen is a later topic in this series.

Myth 4: "Security levels only touch the technical standard"

They reach the asset owner's security-program requirements too. Many IEC 62443-2-1 requirements are associated with the IEC 62443-3-3 capabilities that support them, and where those capabilities span several levels the requirement gets one evaluation method per level, each evaluated at maturity levels 2 and 3. ACSSA-300's own example is USER 1.8, which it counts as four evaluation methods: security level 1 and level 2, each at maturity levels 2 and 3. In the workbook's row terms that is two rows, one per level, each carrying both maturity-level activities. AVAIL 2.1 is another, with rows at levels 1 and 3.

Of the 153 security-program methods, which cover the 87 IEC 62443-2-1 requirements, as ACSSA-303 states, plus the two policy-and-procedure-support items ACSSA adds for SR 1.12 and SR 2.4 (counting, as the workbook does, one requirement-and-level row as a method, carrying a level-2 and a level-3 activity), 86 sit at level 1 and 26, 31 and 10 at levels 2, 3 and 4. So a zone's target also decides which level-specific security-program methods apply there at maturity level 3; one above the target is recorded as not required, not skipped.

Myth 5: "A missing capability at or below the target fails the zone"

A missing capability is not automatically Not met. For each IEC 62443-3-3 requirement at or below a zone's target, there are four routes to a passing result.

CSM and NR-R are two of ACSSA's three special circumstances; the third, not feasible or allowed by law, applies to security-program and service-provider requirements, not to capabilities. Note who approves: the asset owner and the affected stakeholders, not the evaluator, who evaluates the documentation as part of the result rather than agreeing a measure in advance.

Myth 6: "Certified products make the zone pass"

A CSA or SSA certificate on the products in a zone is not a prerequisite for ACSSA and does not pass the zone by itself. It evidences that a required capability exists in the product as certified; ACSSA then asks the second question, whether that capability is configured and in use for this zone, under this owner's policies. Certified products make zone conformity likely, not certain: two products can satisfy the same requirement in ways that do not work together across the zone, which is why the evaluator still looks at the zone as a whole.

Myth 7: "It is the same level you see on an SSA certificate"

The two programs run in opposite directions. An SSA certificate awards a capability security level, SL-C, per zone of a product as sold: the supplier names a ceiling for each zone and the evaluation determines the level each zone reaches, which can be lower. ACSSA takes a target level, SL-T, for each zone of an installed system as the owner's input and determines nothing about it; it uses the target to select the capability checks and records maturity, not level. Neither program performs the other's half.

What this means in practice

Bring the targets; do not expect to be given them. Every zone and device-bearing conduit needs a target from your IEC 62443-3-2 risk assessment before the evaluation can decide what to check. As an ISASecure certification body, we take each target from the asset owner's risk-assessment documents and never set one ourselves.

Expect the number of checks, not the severity, to follow the target. A safety zone at 3 beside zones at 2 means 101 capability methods there and 71 in each of the others the evaluator samples, before anything your own specification adds.

Prepare special-circumstance documentation as evidence. A capability your zone needs but lacks passes only through a documented compensating measure or risk justification approved by you and every affected stakeholder; a capability tied to a technology the zone does not use needs no such paperwork.

Product suppliers: a CSA or SSA certificate evidences that a capability exists in your product. It carries the existence question in every zone using the product but does not close it; configuration and utilisation remain the asset owner's evidence. Integrators and service providers: your IEC 62443-2-4 evidence is a separate topic, later in this series.

Where to go next

The rest of this series sits under the ACSSA filter on the Insights index. For the other side of the comparison, read how SSA certifies the system as sold rather than the installed system and how CSA evaluates a component.