Independent testing in ISASecure SSA: eleven flagged requirements, one scan, one reference system

System suppliers read "independent testing" in ISASecure SSA two ways, and both miss. One assumes the laboratory will exercise every IEC 62443-3-3 requirement in every zone of every layout. The other assumes the lab will attack the system: fuzz its protocols, probe the conduits between zones, try to break in. The scheme does neither. What the certifier tests with its own hands is written down: eleven FSA-S rows flagged in the SSA-311 workbook, plus the one vulnerability scan specified in SSA-420, all on a single reference system.

Myth 1: the lab tests every requirement in every zone

It does not. The SSA evaluation workbook, SSA-311, lists 116 assessable rows covering the whole of IEC 62443-3-3 and records for each whether an independent test is required. Eleven rows carry that mark; 104 do not; and one, FSA-S-RDF-1, is marked not applicable because the workbook calls for no validation of it.

For the eleven, the laboratory exercises the behaviour itself on the reference system, zone by zone, and records what it observes. Your own test report is useful context at the bench, but the result rests on the lab's execution.

Three things stand out. The flag concentrates in the first two foundational requirements: five rows in identification and authentication control, four in use control, one each in system integrity and resource availability, none elsewhere. Seven of the eleven are enumerated items, the lettered parts of a base requirement that the workbook lists separately, so the hands-on work clusters around a few base requirements; four of the five SR 1.9 items are flagged, all but FSA-S-IAC-9.2. And the flag is cumulative with the zone level, like every other row.

A zone at SL 1 brings four lab-tested rows, a zone at SL 2 nine; from SL 3 all eleven apply and SL 4 adds nothing. A system with a zone at SL 2 and a safety zone at SL 3 therefore sees nine rows tested in the first and eleven in the second, each recorded per zone.

Myth 2: independent testing means the lab attacks the system

This is the costlier misreading; it sends preparation in the wrong direction.

The certifier runs exactly two kinds of test: the eleven flagged FSA-S rows, and VIT-S, the known-vulnerability scan specified in SSA-420. Every IP-addressed component is scanned, interface by interface, from a scanner inside the component's own zone, with the system wired to the reference layout and hardened the way your own security guide tells a customer to deploy it. It is a scan, not an attack, and its pass threshold is set per component by the level of the component's zone, so a pass never requires zero findings.

Nothing else is lab-run. Certifier-run robustness testing was removed in the v3.1 SSA documents, and there is no lab fuzzing, network-load test, penetration test, firewall-rule or "conduit" test, or cross-zone attack simulation anywhere in SSA-300, SSA-311 or SSA-420. The scheme uses the IEC 62443 zone and conduit model to describe the system but scores and certifies zones only; no SSA requirement addresses a conduit, so nothing is tested on one.

Fuzz testing and network-traffic-load testing do happen, in your IEC 62443-4-1 lifecycle under the SVV-3 rows. The certifier verifies them rather than repeating them, in its review of the lifecycle artifacts and FSA-S (the two ISCI documents place the check differently): that they ran on a reference-layout system, covered every external interface and protocol that available tooling could exercise, and monitored essential functions while running; the interface-by-protocol coverage becomes an annex to the SSA-303 report. Penetration testing, SDLA-SVV-4, is marked as system-applicable in the SDLA-312 workbook but carries no system-level validation activity; it is discharged through your SDLA certificate. The component-scheme article on fuzzing, load and penetration testing follows the same logic, and the SDLA article on verification and validation covers the lifecycle side.

Myth 3: the lab tests every layout

A scalable system can be certified for a family of layouts, and suppliers sometimes expect each layout on the bench. SSA-300 draws a different line: test-based validations run on the reference system, and analyses cover every layout in scope. The workbook's independent-test flag is the natural correlate of that rule, although no SSA document states the link.

The reference layout is the one layout containing every zone, permitted component type, protocol, software item and interface found anywhere in the family; the reference system is its physical instance. Testing it once, per zone, is how one certificate covers the family, and a component type or protocol missing from it is one the lab cannot test.

The other 104 rows: evidence review, per zone

Everything not flagged, apart from FSA-S-RDF-1, is evidence review, the bulk of FSA-S by count. For each applicable row the assessor examines what you provide, typically test results, design documentation and a demonstration where it helps, and records S, N/S or N/E for each zone, N/E marking a row not required at that zone's level. There is no sampling: every row applicable at a zone's level is assessed for that zone, and the report's zone-by-requirement matrix shows every result.

The decision rule in SSA-300, ISASecure_SY.R16, makes the evidence rows as consequential as the tested ones: a zone clears FSA-S at a level only if none of the rows in scope at that level is recorded N/S for that zone. If one is, the zone does not qualify there, and under the award rule, ISASecure_SY.R4, the certifier grants the highest level it does qualify for, up to the maximum you named. Whether the row was lab-tested or evidence-reviewed makes no difference.

Two contrasts with CSA

The component scheme flags 34 rows for independent test; the CSA independent-testing article walks through them. Eleven versus 34 reflects the object, not a lighter evaluation: IEC 62443-3-3 is written for a system, and the eleven rows are exercised in every zone of the reference system where they apply, so bench time scales with zones. CSA evaluates some functional rows per accessible network interface; SSA-311 has no per-interface rule, and the unit of an FSA-S result is the zone. Interfaces matter for the scan instead: VIT-S runs per accessible interface, and an unscanned one needs a justification and mitigating controls in the report.

The second contrast concerns component certificates. Components need not be CSA- or ICSA-certified, and SSA is an initial certification regardless. The only reuse is in the scan: interfaces of a CSA-certified component may be skipped while its VIT-C scan is current per SSA-420 section 6. No FSA-S row, flagged or otherwise, is discharged by a component certificate.

Two accreditations, two roles

Both kinds of test are laboratory activities. A chartered SSA laboratory holds ISO/IEC 17065 for the certification activity and ISO/IEC 17025 with a testing scope covering FSA-S and VIT-S, so the eleven flagged rows and the scan sit under the testing accreditation and the certificate under the certification one. As an ISASecure certification body, we run the eleven flagged tests and the scan ourselves, on the reference system the supplier provides, and take the certification decision separately.

What to prepare

• A complete reference system at the version under evaluation, built to the reference layout: every zone, permitted component type, protocol, software item and external interface, a second instance of any zone whose instances communicate, and redundant pairs where they add protocols.
• Credentials and accounts in every zone at the roles the flagged rows will need, administrative and low-privilege alike, plus any certificates or keys the components expect.
• The architecture diagram of the reference system: system and zone boundaries, components and how they connect, and the protocols that leave the system.
• The accessible network interface list, consistent with the reference system; it sets the scope of the scan, and an omitted interface is one the report must justify.
• Hardening per your own security guide, applied as a customer would; the scan runs against that configuration.
• The essential-function list and the components performing each function, since several FSA-S rows refer to them.
• The fuzz and load evidence from your lifecycle: interface-by-protocol coverage, confirmation of a reference-layout system, and the essential-function monitoring.
• The evidence package for the non-flagged rows, organised by FSA-S identifier and zone, tied to the version under evaluation, with a named contact who can demonstrate on request.

Prepared that way, the lab's hands-on work is a known quantity: eleven rows per zone where they apply, one scan per accessible interface, one reference system. The series index has the rest of the SSA articles.