Most readers of an ISASecure SSA certificate did not commission it: the asset owner meets it in a tender response, the integrator has to design around it. This article is for those two readers.
What the certificate states
An SSA certificate is granted to a control-system product as one supplier sells it: a named system, at a stated version, in a stated layout or a defined family of layouts (a pointer to a separate layout document is allowed). It is not granted to a plant or a site, and a system assembled for one customer is outside SSA unless one supplier offers and supports it as a whole. The certificate also carries the ISASecure certification version; ISASecure SSA 4.0.0 is the version referenced by the SSA documents this article draws on (2019 to 2022). ISCI lists certified systems, subject to the supplier's permission.
At the heart of the certificate, each security zone is named with the capability security level it was certified to, SL-C 1 to 4. Two rules decide those levels:
- The level describes capability. It states what the zone provides when the product is configured as its documentation says, without compensating countermeasures. It is not your site's target level, which comes from your own risk assessment; matching the two is your job.
- The supplier names a maximum; the certifier awards what qualifies. The applicant states the highest level it wants per zone and is awarded the highest level the zone qualifies for, up to that maximum. A zone can land below what was asked, and one certificate can carry different levels; ISCI's own example has two zones at SL-C 1 and a safety zone at SL-C 2.
The scheme uses the IEC 62443 zone and conduit model, but only zones are scored and named on the certificate; no SSA requirement addresses conduits.
Which components sit in each zone, which interfaces were scanned, what you must add around the system: that is in the assessment report, written to the structure of ISCI's sample report SSA-303 (available on request). Ask the supplier for it.
The report: ten sections and an annex
| Section | Title | What a reader finds there |
|---|---|---|
| 1 | Management Summary | The zone and level table, whether the system is scalable, the four assessment activities, and the conformity statement with its conditions |
| 2 | Purpose and Scope | The target of evaluation restated, the same zone and level table, and pointers to the three results sections |
| 3 | Technical Summary | Table 1, the evaluation summary: system identity, the SDLA certificate relied on, the user-enforced mitigations, and the per-zone and per-component results |
| 4 | Required User Enforced Risk Mitigations | The user-side measures the supplier relies on, organised by host group |
| 5 | Project Management | Roles, the list of specifications the evaluation was performed against (Table 2), and the documents the client supplied and the assessor generated |
| 6 | Target of Evaluation | The context drawing, the layouts assessed (Table 5), a bill of materials per zone, and the accessible network interfaces with their services and ports |
| 7 | Results of FSA-S | The zone-by-requirement matrix (Table 6), the essential-function list, and the statement about the reference system |
| 8 | Results of SDL assessments | The SDLA certificate relied on, the per-requirement SDA-S results (Table 7), and the scope of the supplier's fuzz and load testing |
| 9 | Results of VIT-S | Scan configuration, scanner version and plugin cut-off date, per-device finding counts by risk factor (Table 8), then each finding with its disposition |
| 10 | Status of the document | Revision history and release signatures |
| Annex | Supplier Protocol Robustness Testing | Interface by interface: internal or external, which protocols were fuzz-tested and load-tested, and where no tool existed |
As an ISASecure certification body, Perseus writes its SSA assessment reports to this structure.
Start with Table 1
Section 3 carries the one table to read first. Table 1 identifies the system, names the SDLA certificate relied on, lists the required user-enforced risk mitigations, then gives each zone's SDA-S and FSA-S result with its level and each component's VIT-S result with its zone's level and scan date. Two notes under it flag that SDA-S depends on the zone level through one requirement only, SDLA-DM-4, and that a VIT-S pass depends on both severity and the zone's level.
The conditional conformity statement
The management summary states conformity conditionally, on two things: the supplier's documented assumptions about the deployment environment, and the measures it relies on the user to put in place. The report calls the latter required user-enforced risk mitigations and gives them their own section; each entry names a protective measure the supplier relies on and the host group it must run on.
Read that section as obligations. For an integrator it is design input: the architecture must supply what the list calls for, or the certified capability is not delivered. For an asset owner it is procurement and operations input: the listed measures must be bought, deployed and kept running.
One caution. SSA-303 conditions the conformity statement on the mitigations; its FSA-S table records only S, N/S and N/E, and the documents held do not say whether a mitigation is what made a row "supported". Treat the mitigations as conditions on the whole statement, not on individual rows.
Reading the per-zone results
Section 7 holds the FSA-S matrix, Table 6: one row per IEC 62443-3-3 requirement row on the SSA-311 list, one column per zone, one result per cell. S records that the zone provides the capability, N/S that it does not, and N/E that the row was skipped because it does not apply at the level that zone was assessed for. An N/E is not a gap: the row set grows cumulatively with the level, 48 rows at SL-C 1, 76 at SL-C 2, 106 at SL-C 3 and all 116 at SL-C 4, so N/E cells thin out towards higher-level zones.
The same section lists the essential functions the supplier declared, those that keep the process safe and running, and the supplier names which components perform each. The list drives the requirement rows that concern essential functions and the pass criterion of the supplier's fuzz and load tests; if a function you depend on is missing, ask why.
Tests were run on the reference system, a physical instance of the layout that contains everything found anywhere in the certified family; analyses cover every layout in scope. Table 5 in Section 6 lists those layouts: check that yours is among them, or inside the minimum and maximum quantities it defines.
The lifecycle evidence
Section 8 has two halves. SDLPA-S cites the supplier's ISASecure SDLA certificate, which attests that the development process meets IEC 62443-4-1: a certificate for the process, not for this system. SDA-S ties the two together: Table 7 records, per IEC 62443-4-1 requirement under its eight practices, whether the artifacts the certified process should have produced exist for this system and its layouts.
Subsection 8.2.2 and the annex cover the supplier's protocol robustness testing, interface by interface. These are supplier activities the certifier verified for reference-layout use, protocol coverage and essential-function monitoring, not tests the laboratory ran; the CSA article on fuzzing, load and penetration testing covers the same division for components.
The scan results
Section 9 holds the scan record; the pass criterion is applied per component using its zone's level, as a cumulative ratchet: at SL-C 1 every critical finding must be addressed, at SL-C 2 high findings as well, at SL-C 3 medium findings too, at SL-C 4 every finding. Addressed means corrected or documented as not relevant, so a mixed-level system has mixed thresholds and a pass never means zero findings. Also look for two things: an accessible interface left unscanned must be justified, with mitigating controls described, and a CSA-certified component's interfaces may have been skipped where its VIT-C scan was still current per section 6 of SSA-420.
After the certificate is issued
An SSA certificate has no fixed validity period and no surveillance audit. Under SSA-301, ISCI's maintenance document, its life is tied to the supplier's SDLA certification instead: the supplier must hold an ISASecure SDLA certificate covering the system when the SSA certificate is issued, and the certificate then covers the certified version and its updates, fixes rather than new features, for as long as that certification is held with the system in scope and the system remains in support. If the SDLA certification lapses or drops the system, a one-year grace period runs and the certificate is then withdrawn; when the supplier reports that the system has left support, it is withdrawn on that notice. At each SDLA recertification, every three years, the certificate is amended to list the supported update versions; that cycle, not a validity period, explains the "three years" sometimes quoted for SSA.
Update or upgrade is decided by a version-numbering policy the laboratory and supplier agree. An upgrade needs a new certification: prior SDA-S and FSA-S evidence may be reused where an evidence impact assessment supports it, but VIT-S is always rerun in full. Raising a zone's level is a delta: the FSA-S rows that enter at the new level, the level-dependent SDA-S row, SDLA-DM-4, and a VIT-S pass at the new level. So check that the certificate lists your version, that the supplier's SDLA certificate is current and that the system is in support.
How this differs from a CSA certificate
A CSA certificate names one component at one capability security level; an SSA certificate names an assembled product with a level per zone. The components inside need no CSA or ICSA certificates, and the only reuse is the VIT-C skip described above; no functional results carry over into FSA-S. The CSA hub article explains what a component certificate covers.
Where to go next
The rest of this series is on the SSA filter of the Insights index; the CSA series is under the CSA filter.
Frequently asked questions
No. SSA certifies a control-system product as sold by one supplier, at a stated version and in a stated layout or family of layouts. It says nothing about a particular installation. A system assembled for one site by an integrator or by the asset owner is outside SSA unless a single supplier offers and supports it as a whole; that site-specific case belongs to the asset-owner program, not to SSA.