What ISASecure SSA certification actually evaluates

If you sell a control system rather than a single controller, a DCS, a SCADA platform, a packaged skid with its own servers and network, and a customer wants it "62443 certified," the scheme that applies is ISASecure SSA, System Security Assurance, built on IEC 62443-3-3.

The certificate in one sentence

An SSA certificate says that a specific control-system product, as offered by one supplier at a specific version and in a specific layout or family of layouts, meets the IEC 62443-3-3 requirements applicable to each of its security zones at the capability security level stated for that zone, that its supplier holds an ISASecure SDLA certificate whose certified process includes this system in its scope going forward, that this system's development artifacts were checked against that certified process, and that every IP-addressed component of the reference system passed a known-vulnerability scan at its zone's level.

The certificate names the system version, the layouts covered, each zone with its level, and the ISASecure version evaluated against.

A system as sold, not an installation

"System" in the SSA documents is shorthand for a product. A submission qualifies on four conditions: an integrated set of more than one component; one supplier sells and supports the whole, even where parts come from other manufacturers; a layout that is fixed or scales by replicating components or zones; and configuration and version control. The components are the four kinds IEC 62443 recognises: software application, host device, network device and embedded device. A safety zone alone can qualify as a system.

The supplier also draws the box: the architecture diagram submitted with the application shows the system boundary, every zone boundary inside it, every component and connection, and every protocol crossing the boundary. That diagram decides what the certificate covers.

A plant-specific build assembled by an integrator or an asset owner is outside SSA unless one supplier offers and supports the whole as a product.

One capability security level per zone

The unit of the level is the security zone: a system is one or more zones, each with its own capability security level, SL-C 1 to 4. The level describes what the product itself can deliver when set up as the supplier documents, before the owner adds any protection around it; the asset owner's target level is a different concept.

The award rule, ISASecure_SY.R4, has two halves: the applicant names the maximum level it wants for each zone, and the certifier assigns each zone the highest level it qualifies for, up to that maximum. A zone can land below what was asked, and one certificate can carry different levels; ISCI's own illustration 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, and the diagram below shows conduits, but no SSA requirement addresses a conduit and the certificate names zones and their levels only.

Four elements, one decision

SDLPA-S, the process certificate. The supplier must hold an ISASecure SDLA certificate when the SSA certificate is issued, with the system inside the certified process's scope. That certificate discharges this element; it certifies the process, not the system.

SDA-S, security development artifacts. The certifier checks that the artifacts the certified process should produce exist for this system, from threat model to security guidelines, and address the whole system and every layout in scope. Only one row, SDLA-DM-4 on residual risk from known issues, varies with the zone's level.

FSA-S, functional security assessment. The IEC 62443-3-3 stream. Every row is recorded for every zone as S, N/S or N/E: supported, not supported, or not evaluated because the zone's level does not require it. Only applicable rows are assessed, so one requirement's result can differ across zones.

VIT-S, vulnerability identification testing. The laboratory scans every IP-addressed component of the reference system for known vulnerabilities, from inside the component's zone. The pass threshold is set per component by its zone's level, so a mixed-level system has mixed thresholds, and a pass never means zero findings.

The decision rule, ISASecure_SY.R16, requires all four to hold, zone by zone, with tests on the reference system and analyses across all layouts. A chartered SSA laboratory holds ISO/IEC 17065 accreditation for the certification and ISO/IEC 17025 for the FSA-S and VIT-S testing.

The three numbers: 116, 74 and 21

116 functional rows. The FSA-S workbook, ISASecure SSA-311, carries 116 assessable rows that reach every clause of IEC 62443-3-3, 51 system requirements and 49 requirement enhancements; the extra 16 rows come from four base requirements listed item by item. There are no SSA-specific additions.

Applicability grows with the zone's level:

Every requirement enhancement enters at SL 2 or above; a zone at SL 1 faces 48 rows of base requirements and enumerated items. The two lower steps are of similar size, 28 rows then 30, unlike the component scheme.

74 assessable lifecycle rows. SDA-S takes, from the shared IEC 62443-4-1 catalogue in ISASecure SDLA-312, the 74 rows that carry a system-level validation activity: SM 15, SR 13, SD 5, SI 7, SVV 14, DM 1, SUM 2 and SG 17 across the eight practices. These are assessable rows, not a count of requirements, since several requirements span more than one row; the SDLA series shows how one catalogue serves three schemes.

21 vulnerability-testing requirements. VIT-S is specified in ISASecure SSA-420, shared with the component schemes; 21 of its requirements apply to a system: 5 system-specific on tool, configuration, execution and pass criteria, and 16 shared on scanner currency, reporting and fallback.

Test the reference, analyse the family, sample nothing

SSA works with a reference layout containing every zone, component type, protocol, software item and interface found in any in-scope layout; its physical instance is the reference system. Tests run on the reference system, analyses cover every layout in scope, and each layout must still contain the components its zones need.

There is no sampling in SSA: every zone is assessed against every applicable row, every IP-addressed component is scanned, and all 74 lifecycle rows are validated against artifacts covering the whole system and all layouts in scope. The only skips are identical duplicate interfaces between replicated zones, and the interfaces of a CSA-certified component whose VIT-C scan is still current per SSA-420 §6.

What the lab tests itself

The laboratory runs exactly two kinds of test, the VIT-S scan and the 11 FSA-S rows flagged for independent test, both on the reference system. The 11 are cumulative by level, 4 at SL 1, 9 at SL 2 and all 11 from SL 3; the rest of FSA-S is evidence review, zone by zone.

Fuzz, network-load and penetration testing are the supplier's IEC 62443-4-1 activities, not the laboratory's. For fuzz and load testing the certifier checks that it ran on a reference-layout system, what interfaces and protocols it covered, and that essential functions were monitored. Penetration testing, SVV-4, is marked for systems in the lifecycle workbook but has no system-level validation activity and is discharged through the SDLA certificate. Certifier-run robustness testing was withdrawn; the component series explains where each kind of test now lives.

What SSA is not

• A component certificate. A controller, switch, HMI or software package on its own is a CSA object, or ICSA for IIoT devices and gateways. SSA components need not hold either certificate.
• A process certificate. SDLA certifies the development process; it is SSA's prerequisite, not a substitute, and certifies no particular system.
• A site certificate. The plant-specific build described above is ACSSA's territory, not SSA's.

After issue, the certificate has no fixed validity period and no surveillance audit. Under ISASecure SSA-301 it stays in force for the certified version and its updates while the supplier's SDLA certificate covers the system and the system remains in support; an SDLA lapse starts a one-year grace period before withdrawal, and end of support brings withdrawal once the supplier reports it. An upgrade, separated from an update by a version-numbering policy agreed with the laboratory, needs a new certification; so does certifying an existing system to a later ISASecure SSA version or raising a zone's level, neither of which is compulsory and both of which are evaluated as a delta. Earlier evidence may be reused after an impact assessment, but VIT-S is always rerun in full.

Where to go next

Browse the rest of the SSA series from the SSA filter on the Insights index, or step across to the CSA and SDLA series.