Very few control-system products ship as a single fixed configuration. The same platform is sold with two controllers or forty, with or without redundant servers or a historian. A certificate tied to one exact build would serve neither the supplier nor the integrator sizing the next project. ISASecure SSA was written with this in mind: a certificate is granted for a system version and for a layout or a family of layouts, and the scheme has a defined way of describing that family, choosing the one configuration the laboratory tests, and analysing the rest.
This article walks through that machinery: the three scalability requirements of SSA-300, ISASecure_SY.R1 to SY.R3; the reference layout and reference system; the split between testing and analysis; the nine categories of technical submission, SY.R7 to SY.R15; and two lists that are often merged, accessible network interfaces and accessible points of entry.
Fixed or scalable: where the family begins
SSA-100 sets four eligibility criteria. The product must be an integrated set of at least two components, each of one of four kinds (a software application, an embedded device, a host device or a network device). One supplier must offer and support it as a whole, even if parts come from other manufacturers. It must be under configuration control and version management. And it must have either a fixed layout or a layout that scales by replicating components, zones or both.
That last criterion is the hook. A fixed-layout product is the simple case: the scalability requirements do not apply, the test system is built to its one layout, and the certificate names it. A scalable product needs a description of what the supplier will sell under the certified version, and SSA-300 provides the format.
Describing a scalable system: SY.R1 to SY.R3
The unit of description is the security zone, which is also the unit of the certified level: every instance of a zone type shares one capability security level (SL-C), and the certificate names each zone with its level. Three requirements build the family from there; a fourth supplies the test bed.
| Concept | Requirement | What the supplier states | Why it matters |
|---|---|---|---|
| Zone specification | ISASecure_SY.R1 | For each zone type: the component types that may reside in it, each with a minimum and maximum quantity; the protocols used inside the zone; the protocols exchanged with other zones; the protocols that leave the system; and the zone's SL-C. SSA-300 lays this out as a seven-column table. | Fixes what a zone may contain and how it communicates, so the evaluation can reason about any instance of it. |
| Layouts in scope | ISASecure_SY.R2 | The minimum and maximum number of instances of each zone type, and whether every combination within those ranges is in scope or only a described subset. A layout counts only if it still carries the components that let each zone meet its SSA-311 rows at the declared level. | Draws the outer edge of the family and rules out configurations that would fall short. |
| Reference layout | ISASecure_SY.R3 | One layout that contains every zone type, every permitted component type in each zone, every protocol and software item found in any in-scope layout, every external interface, and every interface between zones or between instances of a zone: two instances of a zone type where instances communicate, and a redundant pair where redundancy adds protocols. | The single configuration the laboratory tests. |
| Reference system | ISASecure_SY.R15 | A physical build of the reference layout, made available for the evaluation. | Where the eleven laboratory-tested FSA-S rows and the vulnerability scan are run. |
Two points deserve emphasis.
The first is the closing condition on layouts in scope. Scaling down is not free: if the smallest configuration a supplier wants to sell omits the component that delivers a capability required at the zone's level, it is not in scope at that level. The family is bounded by the requirements as much as by the quantities, so the zone specification and the FSA-S row set (48, 76, 106 or 116 rows by zone level) are worked out together.
The second is the role of the protocol columns. The scheme uses the IEC 62443 zone-and-conduit model, and an SSA-303 report's context drawing shows conduits between zones, but no SSA requirement addresses conduits and no conduit is scored or certified. What a conduit would carry is captured in the zone table instead, as the protocols each zone exchanges with its neighbours and with the outside.
Test the reference, analyse the family
The decision rule in SSA-300, ISASecure_SY.R16, splits the evaluation along one line: validations that involve testing are performed on a system built to the reference layout; every other validation is performed across all layouts in scope.
On the testing side sit exactly two activities. The FSA-S rows flagged for independent test, eleven of the 116, are exercised on the reference system. So is the VIT-S vulnerability scan: SSA-420 requires the components connected as the reference layout specifies, the scanner placed in the same zone as its targets, every IP-addressed component scanned, and components with several accessible interfaces scanned one interface at a time. The division of labour mirrors the component scheme's, described in what the lab tests itself.
On the analysis side sit the rest of FSA-S, evaluated zone by zone at each zone's level with a result recorded per zone, and the whole of SDA-S, whose lifecycle artifacts must address the system as a whole and all in-scope layouts; artifacts written per component or per zone are neither required nor sufficient. The supplier's own fuzz and network-load testing belongs here too: the certifier verifies that it ran on a reference-layout system, or that a documented rationale shows equivalent coverage across the layouts, with essential functions monitored. Where each kind of testing falls is the subject of where fuzzing, load and penetration testing live.
SSA does not sample: every zone is assessed against every row applicable at its level, and every IP-addressed component is scanned. The scheme allows two narrow skips, both in the vulnerability scan. Where replicated zones expose identical duplicate interfaces, the duplicate may be skipped provided both zones are present and running during the scan. And where a component holds a CSA certificate, its interfaces may be skipped while its VIT-C scan is current under SSA-420 section 6. Neither is sampling: the same interface simply need not be scanned twice.
The nine submissions: a preparation checklist
The submission requirements of SSA-300 run from SY.R6 to SY.R15; nine of them each name a category of material, and read as a checklist they describe the package a supplier assembles before the evaluation starts.
| # | Requirement | Submission | What to prepare |
|---|---|---|---|
| 1 | SY.R7 | Architecture diagram | The system boundary, each zone boundary inside it, every component with its connections, and every protocol that leaves the system. |
| 2 | SY.R8 | Bill of materials | Every component with its firmware level, operating system and service pack, any virtual-machine layer and the application versions on it; the configuration rules applied to network devices. |
| 3 | SY.R9 | End-user documentation | Everything delivered with, or made available to, a customer who buys the system (printed or online), including the manuals for each component. |
| 4 | SY.R10 | Essential-function list | The supplier's list of the system's essential functions (the safety, control and operator-view functions the scheme treats as essential) and the components that perform each of them. |
| 5 | SY.R11 | Accessible network interfaces | The network connections a customer is meant to use in day-to-day operation and maintenance (see below). |
| 6 | SY.R12 | Accessible points of entry | Every route by which data can reach an essential-function component (see below). |
| 7 | SY.R13 | IP protocols | The IP protocols in use on the essential-function components. |
| 8 | SY.R14 | Intended defensive behaviour | For every protocol the system supports, whether incoming traffic is rate-limited or not; plus a description of any other defensive behaviour that could affect the assessment, such as address blacklisting or automatic failover. |
| 9 | SY.R15 | Reference system | The physical build of the reference layout. For the vulnerability scan, SSA-420 expects it hardened per the supplier's own security guide, as a customer would deploy it. |
Most of these reappear, in structured form, in the SSA-303 report: the architecture diagram as the context drawing and the layouts table (Table 5, in the SY.R1 format); the bill of materials per zone; the accessible network interfaces with their services and ports; the essential-function list beside the FSA-S results; and an annex recording, interface by interface and protocol by protocol, what the supplier's fuzz and load testing covered. A supplier who prepares the nine items in the report's own shape saves a round of rework.
Two lists, two purposes
Items 5 and 6 are often collapsed into one ports-and-interfaces spreadsheet, but they answer different questions.
Accessible network interfaces (SY.R11) define the scan set. This list is about what a customer would actually plug into: the network connections the supplier intends to be used day to day, for operating and maintaining the system, and that can be reached without opening anything up or re-cabling. VIT-S works through this list: each accessible interface of each component is scanned in turn, and any left unscanned must be justified in the report along with the mitigating controls that make the omission acceptable. The same interfaces, crossed with protocols, frame the annex showing the coverage of the supplier's fuzz and load testing.
Accessible points of entry (SY.R12) disclose the attack surface. This list is scoped to the components that perform essential functions and is deliberately wider. It covers every hardware and software route by which data can get into such a component, not only the network ones, and including routes the product ships with switched off. Together with the IP protocols (SY.R13) and the intended defensive behaviour (SY.R14), it discloses the attack surface of the essential-function components for the analysis-side validations.
For the components that perform essential functions, the second list should contain the first, and the difference between them, the entry points that are not accessible network interfaces, is worth explaining in the hardening documentation.
What the certificate says about the family
The certificate is granted for a system version and for the layout or set of layouts, and it names every zone with its SL-C and the ISASecure version applied. Any public listing of the certification must give the system version, the layouts covered (a pointer to a separate document is allowed) and the ISASecure version. For an integrator sizing a project, the question is not whether the product is certified but whether the proposed configuration is inside the certified family, and at which level each zone is certified. For a supplier, the family is a commercial decision made before the evaluation: everything included has to hold up at the declared level, and the reference layout has to contain all of it.
As an ISASecure certification body, we run the eleven flagged FSA-S tests and the VIT-S scan on the reference system the supplier provides and carry out the remaining validations across every layout in scope.
Where to go next
The rest of this series is on the SSA filter of the Insights index. For how the component scheme handles the same testing questions, see what the lab tests itself and where fuzzing, load and penetration testing live.
Frequently asked questions
No. The certificate is granted for a system version and for a layout or a set of layouts. A scalable system is described by zone type, with minimum and maximum quantities of each resident component and of each zone instance, and the certificate covers every layout inside those ranges that the supplier declared in scope.