IEC 62443-3-3 requirements: how ISASecure SSA evaluates all 100 clauses in FSA-S

If you are looking up the requirements of IEC 62443-3-3 because a control system you sell is heading for an ISASecure SSA certificate, the stream to understand is FSA-S, the functional security assessment for systems. It is where the standard is applied clause by clause and zone by zone to the product as sold.

The numbers come from the ISASecure SSA-311 workbook, version 2.2, aligned to IEC 62443-3-3:2013.

The whole standard, and nothing else

IEC 62443-3-3 contains 100 clauses a system can be assessed against: 51 base system requirements, SR 1.1 through SR 7.8, and 49 requirement enhancements that add strength to some of those base requirements at higher security levels. FSA-S covers all 100; there is no subset.

The component scheme, CSA, evaluates IEC 62443-4-2 plus a small group of scheme-wide constraints, the CCSC, which add rows of their own to the component workbook. The system workbook has the equivalent sheet, and it is empty. Every sourced FSA-S row cites a clause of IEC 62443-3-3, so preparing for SSA means preparing for the standard itself. The CSA overview explains the CCSC from the component side.

Why the workbook has 116 rows, not 100

The workbook expands the 100 clauses into 116 assessable rows, organised by the seven foundational requirements.

Identification and authentication control (FR 1, 33 rows) and use control (FR 2, 31 rows) together hold more than half of the set. System integrity (FR 3) has 19, resource availability (FR 7) has 13, restricted data flow (FR 5) has 11, data confidentiality (FR 4) has 6, and timely response to event (FR 6) is the smallest family at 3.

The 16 extra rows come from one editorial decision: four base requirements are written in IEC 62443-3-3 as lettered lists, and SSA-311 gives each item its own row. All four sit in the first two foundational requirements.

Each of the four also keeps its parent row (FSA-S-IAC-5, FSA-S-IAC-9, FSA-S-UC-3 and FSA-S-UC-4), so the arithmetic is 51 base rows plus 16 item rows plus 49 enhancement rows; the items are pieces of existing requirements, so the clause count stays at 100.

From system integrity onward the row count is simply base requirements plus enhancements. Only FR 1 and FR 2 carry split items, nine and seven respectively.

Reading an FSA-S identifier

Every identifier reads FSA-S, then the foundational requirement abbreviation (IAC, UC, SI, DC, RDF, TRE or RA), then the base requirement's number within that family, then an optional dotted suffix for a child row. FSA-S-IAC-9 is SR 1.9; FSA-S-RA-5 is SR 7.5.

The suffix is where readers go wrong. A dotted child can be an enumerated item or a requirement enhancement, and the identifier does not say which. FSA-S-IAC-9.5 is an item of SR 1.9; FSA-S-IAC-9.6 is that requirement's enhancement. The reliable guide is the workbook's source column, which records the IEC 62443-3-3 clause behind 115 of the 116 rows in the standard's own notation for base requirements, lettered items and numbered enhancements. One row, FSA-S-UC-2.1, leaves that cell blank and is placed under SR 2.2 by the workbook's structure alone. The tree view shows the same two-level shape: 51 parents and 65 children, the children being the 16 items and the 49 enhancements together.

Use the SSA-311 form, with the -S- infix, in your evidence: the workbook and the SSA-300 requirement table use it, and it keeps system rows distinct from the component scheme's FSA-C rows.

Scored zone by zone

FSA-S does not produce one result for the system. The unit is the security zone, assessed at the capability security level (SL-C) it is being certified to. A zone at SL 1 is assessed against 48 rows; at SL 2 against 76; at SL 3 against 106; at SL 4 against all 116. The set is cumulative, so each level includes everything below it. No requirement enhancement applies at SL 1, and 37 of the 51 base requirements are already in scope there; the rest enter at SL 2 and SL 3, and everything added at SL 4 is an enhancement.

For each row in each zone the report records one of three results, spelled as the SSA-303 template spells them: S when the zone provides the capability, N/S when it does not, and N/E for a row that sits above the level that zone is being certified to and was therefore left unassessed. The report lays this out as a matrix of zones against the 116 rows. SSA-300 words the pass condition differently: every criterion applicable at the zone's level is found supported or not applicable. The SSA-303 table records that outcome as S on each applicable row. Because the level is awarded per zone, one system can carry different levels on different zones.

Two consequences follow. There is no sampling: every zone, every applicable row. There is no per-interface evaluation: part of the component scheme's functional assessment is scored per accessible network interface and rolled up, but no SSA document does that for a system, and the workbook has no column classifying rows by zone, conduit, interface or component.

Eleven rows the laboratory tests itself

Of the 116 rows, 11 are flagged for validation by independent test. For those the certifier exercises the system itself rather than reviewing evidence; the other 104 are validated without laboratory testing, by documentation review and inspection or by a method left to the certifier. SSA-300 requires test-based validations to run on the reference system; the workbook's independent-test flag is the natural, if unstated, marker of those rows. One row, FSA-S-RDF-1, is marked not applicable in that column.

By foundational requirement the flagged rows fall 5 under FR 1, 4 under FR 2, 1 under FR 3 and 1 under FR 7. Seven of the eleven are enumerated items of the split requirements: FSA-S-IAC-9.1, 9.3, 9.4 and 9.5 under SR 1.9, and FSA-S-UC-3.3, FSA-S-UC-4.3 and FSA-S-UC-4.4 under SR 2.3 and SR 2.4. Two are base requirements, FSA-S-SI-9 and FSA-S-RA-5. The last two enter at SL 3: FSA-S-IAC-3.1, the enhancement of SR 1.3, and FSA-S-UC-2.1, which the workbook places under SR 2.2 by structure since its source cell is blank.

Because the flags follow level applicability, the hands-on count grows with the zone: 4 rows for an SL 1 zone, 9 for SL 2, all 11 from SL 3 upward. The component scheme flags 34 of its rows; the CSA independent-testing article explains that side.

What to prepare

The shape of FSA-S tells you what the evidence has to look like.

• A zone-by-zone answer for every applicable row. For each zone, at the level you are asking for, show which components provide the capability; a row can be supported in one zone and not in another.
• An architecture diagram that draws the boundaries. It has to let the assessor see where the product ends, where each zone begins and ends, what sits in each zone and how it is wired, and which protocols leave the product, together with the maximum capability level you want for each zone.
• Your complete end-user documentation. Many rows concern capabilities the product provides when configured as your own guidance directs; gaps in the guidance become gaps in the evidence.
• The essential-function list and the components performing each function. It feeds the rows that refer to essential functions.
• The reference system, built and reachable. The 11 flagged rows are tested on it, and it must contain every zone, component type, protocol and interface present in any layout the certificate will cover.
• Any user-enforced risk mitigations, written down. The SSA-303 report conditions its conformity statement on them, although its FSA-S table records only S, N/S or N/E.

One caution: components need not hold CSA or ICSA certificates, and holding them does not shrink the FSA-S work, because no component-level functional result is reused in FSA-S; the only reuse the SSA documents provide is on the vulnerability-scan side. As an ISASecure certification body, this is how we scope every FSA-S plan: the full row set for each zone at its level, tests on the reference system, analyses across every layout the certificate will name.

Where to go next

This is the fourth article in the SSA Fundamentals series; its neighbours cover the capability level per zone, the move from SL 2 to SL 3, the vulnerability scan and the SDA-S artifacts. Browse the set from the SSA filter on the Insights index.