SDA-IC: the 93 lifecycle requirements checked per IIoT component, and the five ICSA-only practices

An IIoT device is judged on more than its own behaviour. Before the assessor reaches the product, the first thing verified in an ISASecure ICSA evaluation is a certificate the product does not carry: the supplier's ISASecure SDLA certification for the development process. Then comes SDA-IC, the security development artifacts review for the IIoT component, which checks that the certified process actually ran for this device and left the records it should have.

Suppliers who know the CSA version of this stream expect the same review under a different label. It is not: ICSA checks more of the lifecycle per component, brings defect and update management back into the product review, and adds five practices that SDLA certification does not require.

The prerequisite, and the element that names it

SDLA certifies a development process against the eight practices of IEC 62443-4-1, 118 requirements in all, at organisation scope; it says nothing about any particular product. ICSA certifies the product, an IIoT device or gateway at one version and one tier, and requires a valid SDLA certificate covering the process actually used to build it. The scheme comparison in the CSA series explains why both component schemes lean on the process certificate rather than re-auditing the process per product.

ICSA names the dependency explicitly: of its five evaluation elements, the first, SDLPA-IC, is satisfied by citing the SDLA certificate, ahead of the artifact review, the functional assessment, vulnerability testing and the security maintenance audit. The dependency also outlives the evaluation. Holding SDLA certification is a condition of the ICSA certificate remaining valid, and once the first security maintenance audit is done the later ones are normally timed to each SDLA recertification, so the SDLA renewal date matters long after issuance. The supplier elects the timing of that first audit from three options set out in ICSA-301.

"Covering" is literal: an SDLA certificate held elsewhere in the company does not satisfy the prerequisite for a product built outside the certified process. Confirm the coverage before applying.

93 of 118: the same 77, plus 16

Not every SDLA requirement produces something checkable per product; some are obligations that live entirely in the organisation. SDA-IC looks at the ones that leave an artifact behind for every product. The ISASecure ISDLA-312 workbook marks, for each of the 118 requirements, whether a component-level check applies to an IIoT component, and the answer is 93.

Compare the middle and right columns. Every one of the 77 requirements checked per component in CSA is also checked in ICSA; nothing drops out. The 16 ICSA adds exist only for IIoT components, and they push three practices to complete coverage: all 19 security-requirements rows, all 7 secure-design rows and all 19 security-guidelines rows carry a component-level check.

The shape, and where it differs from CSA

Documentation still dominates. Security management, security requirements, secure design and security guidelines together account for 60 of the 93. Each has an instance for this device: the project's security-management records, the requirements and the threat model behind them, the design that answers the threats, and the guidance the customer receives.

Verification is the second pillar, unchanged. The SVV practice contributes 18 of its 20 requirements, exactly as in CSA. The testing evidence lives here, from requirements and abuse-case testing to fuzz and load testing and attack-surface review; the lab reviews the records rather than repeating the tests.

Defect and update management come back. This is the IIoT difference. In CSA one defect-management and two update-management requirements carry a component check; the rest of those practices are organisational obligations discharged by the SDLA certificate. In ICSA the figures are 5 and 4. The scheme is not re-auditing the organisation's vulnerability process; it is asking how this device handles reported defects and receives updates in the field, over its life, which for a product on an untrusted network is the part of the lifecycle a certificate reader most wants evidence of.

Secure implementation is unchanged at 6 of its 13; the rest is verified at organisation level under SDLA.

The 16 IIoT-specific rows

In the workbook these rows carry identifiers ending in ICSA. In plain language, they ask for the following.

The history row is worth a second look: DM-1, DM-4 and SUM-5 are three of the four IEC 62443-4-1 requirements the security maintenance audit examines; the fourth is DM-2, the sorting of incoming reports into applicable and not. The device's field record enters the evaluation here and is revisited at every audit.

The five ICSA-only practices

Eleven of the sixteen add an IIoT-specific artifact to a practice IEC 62443-4-1 already requires. The other five are different in kind: neither the standard nor SDLA certification requires the underlying practice at all. A supplier can hold a spotless SDLA certificate and never have written a word about any of them.

• Compartmentalised design (SDLA-SD-4-ICSA1): the device's internals designed as separated compartments, so that a compromise of one does not become a compromise of all.
• Fail-secure design (SDLA-SD-4-ICSA2): when something fails, the device ends up in a secure state rather than an open one.
• Update-availability and end-of-support notification (SDLA-SUM-2-ICSA): a defined way of telling users that an update exists and, eventually, that the product will no longer be supported.
• Resource-sharing guidance for user-added functions (SDLA-SG-3-ICSA1): guidance for the customer on how anything they add to the device, such as an application they load onto it, may share its processing, memory and communications.
• Cloud-dependency documentation (SDLA-SG-3-ICSA2): a record of the cloud services the device depends on to do its job.

Because the SDLA certificate cannot vouch for these, the assessor works in two steps: is there a documented process for the practice at all, and did it produce its artifact for this device? Suppliers coming from CSA are used to the second question only. Write the process down before the evaluation, not during it.

What stays outside the component review

Two SVV requirements carry no component-level check in ICSA, exactly as in CSA: penetration testing, SVV-4, and the independence of the people performing the tests, SVV-5. Both are examined in the SDLA process audit only. Fuzz and network-load testing are in scope, with coverage recorded per interface and protocol in the assessment report and a rationale for anything not covered; for an IIoT product that list includes the wireless radio and the cloud links, not only the wired port. The testing article in the CSA series covers the division of labour, and it applies to ICSA unchanged.

What to prepare

• Your SDLA certificate, current and confirmed to cover the process used for this product.
• The threat model and security context for this device and version: deployment environment and usage assumptions, the scope boundary and tier claimed, severity scoring, shared internal resources as attack paths, and a rationale for any retired threat.
• Design and review records showing the compartmentalisation and fail-secure decisions, and the reviews behind the requirements and the code.
• Verification records, including fuzz and load-test coverage per interface and protocol, cloud and wireless included.
• The device's defect and update handling: the intake route for third-party component vulnerabilities, the residual-risk threshold, the update and end-of-support notification process, and the history to date.
• Customer guidance: hardening guidance, resource-sharing guidance for user-added functions, and the cloud-dependency documentation.
• Five short process documents for the ICSA-only practices, if they do not already exist.

As an ISASecure certification body for ICSA, we verify the SDLA certificate before any other part of the artifact stream can close, and the five process documents are the next thing we ask for. The rest of the series is at the ICSA filter on the Insights index, and the CSA articles cover the shared ground.