The SDLA prerequisite: why ISASecure CSA needs it, and what the SDA-C artifact review adds

Ask a supplier midway through CSA planning what the certification lab will look at first and the answer is usually the product. In practice the first thing verified is a certificate the product does not carry: the supplier's ISASecure SDLA certification for the development process. That raises two questions. Why does a component certificate depend on a process certificate at all? And if the process is already certified, what does CSA add when it reviews development artifacts for the component?

It also answers the question suppliers ask most often about this stream: is there a mandatory-evidence or minimum-requirements list for CSA? No.

Two certificates, two scopes

SDLA, Security Development Lifecycle Assurance, certifies a development process. Its scope is the organisation, or the part of it that develops the products in question, and its yardstick is IEC 62443-4-1. The standard is organised into eight practices: security management, security requirements, secure design, secure implementation, verification and validation testing, defect management, security update management and security guidelines. In the ISASecure evaluation workbook those eight practices expand to 118 requirements. An SDLA certificate says that this process exists, is documented and is followed. It says nothing about any particular product.

CSA, Component Security Assurance, certifies a product: one component, one certified version and its updates, one type, one capability security level, against IEC 62443-4-2. The first article in this series maps the three assessment streams that produce it.

The link between the two is a hard prerequisite. A CSA evaluation requires a valid SDLA certificate covering the component: the component must fall inside the scope of the certified development process. The artifact stream, SDA-C, cannot be closed until that certificate has been verified, and the overall result cannot reach pass without it. It is a gate, not a scoring factor.

The word "covering" carries weight. If the component was developed by a site, business unit or product line that the certified process does not cover, an SDLA certificate held elsewhere in the company does not meet the prerequisite. Confirm the coverage before the evaluation is scheduled, not during it.

Why a product certificate depends on a process certificate

IEC 62443-4-2 defines what a secure component must do; IEC 62443-4-1 defines how one gets built. A product that meets its functional requirements but was developed without threat modelling, security testing or a way of handling reported defects is not much of an assurance. CSA could audit the development process afresh for every product. Instead the scheme delegates that job to SDLA, once, at organisation scope, and lets every product evaluation lean on it.

Because the process is already certified, the CSA assessor does not need to re-establish that the supplier knows how to threat-model, test or handle vulnerabilities, only something narrower: that the certified process actually ran for this component and produced what it should have.

What SDA-C adds: the component-scoped layer

That narrower question is SDA-C, security development artifacts for the component. It is not a second process audit; it checks that the outputs the certified process is supposed to generate exist for this component and this version, and that they hold together.

Not every SDLA requirement translates into something checkable per product. Some describe obligations that live entirely in the organisation, such as how the team is trained or how a reported vulnerability is triaged and fixed; those are discharged by the SDLA certificate. Others produce an artifact for every product that passes through the process: a threat model, a requirements specification, a test report, a hardening guide.

Of the 118 SDLA requirements, 77 carry a component-level artifact verification in a CSA evaluation. The figure and the per-practice split come from the ISASecure SDLA-312 workbook, which marks for each requirement whether a product-level check applies.

Reading the shape of the 77

The documentation practices dominate. Security management, security requirements, secure design and security guidelines together account for 50 of the 77. Each of these practices produces a document set with a component-specific instance: the security management records for this project, the security requirements and the threat model behind them, the design that responds to the threats, and the guidance that tells the customer how to install, harden and operate the product. The threat-modelling requirement alone expands to nine component-level rows.

Verification and validation is the second pillar. The SVV practice contributes 18 of its 20 requirements. This is where the testing evidence lives: security requirements testing, abuse-case and threat-mitigation testing, the search for weaknesses including fuzz and network-load testing, and attack-surface review. The lab does not run these tests; it reviews the records and, for fuzz and load testing, records the coverage per interface. The testing article in this series covers that division of labour in full.

The two SVV requirements without a component-level check, penetration testing, SVV-4, and the independence of the people doing the testing, SVV-5, are examined in the SDLA process audit only.

Defect and update management contribute almost nothing per component. One requirement from defect management, DM-4, and two from update management carry a component-level check. Defect management has 14 requirements in SDLA and update management 7; everything beyond those three checks describes how the organisation handles vulnerabilities and delivers fixes, a process obligation verified once under SDLA.

Secure implementation is a mixed picture. Six of its 13 requirements carry a component check; the rest are verified at organisation level in the SDLA audit.

Is there a mandatory-evidence or minimum-requirements list for CSA?

Suppliers who have been through SDLA know that its scheme rules define two overlays on the 118 requirements: a set of artifacts that must exist for the process certification, and a minimum set of requirements. Both are constructs of the SDLA certification requirements, ISASecure SDLA-300, and both govern the process audit.

CSA defines no equivalent: no shortlist of mandatory CSA artifacts and no reduced requirement set. The evidence expectation is simply the component-specific artifact behind each of the 77 requirements that carry a component-level check. Where your SDLA evidence answered "does the organisation do this," your CSA evidence answers "was this done for this product, and here is the record."

That changes how to organise evidence: not by SDLA overlay, but by component and practice, one folder per artifact family with the version clearly stated.

The link does not end at certification

The SDLA dependency persists after the certificate is issued. If the SDLA certificate stays valid and product maintenance stays under the certified process, certification extends to updates of the certified version, meaning fixes for security problems, bugs, or reliability and usability defects, not new functionality. If the SDLA certification lapses, a one-year grace period runs and then the CSA certificate is withdrawn; if the component leaves supported status, the supplier informs the certifier and the certificate is withdrawn.

An upgrade, a version that adds functionality, needs a new certification, but CSA-301 lets it draw on the prior one through an evidence impact assessment. The supplier describes the modifications and analyses their effect on each SDA-C and FSA-C line item. Where the certifier can judge that impact with confidence, unaffected items carry forward and only the affected ones are re-examined; where it cannot, or, in the functional stream, where security-functionality changes are widespread rather than few and isolated, the element is evaluated in full. Vulnerability identification testing is always re-run in full as a matter of scheme policy.

What to prepare

• Your SDLA certificate, current and confirmed to cover the process used for this component.
• The threat model for this component and version. Not the organisation's template; the instance.
• The security requirements for the component, traceable to the threat model.
• Design and implementation review records: the design that addresses the threats, and the records showing the code was reviewed and analysed.
• Verification and test records, including security requirements testing, abuse-case testing, and the fuzz and load-test coverage per interface and protocol.
• Hardening and user guidance, in the form the customer will receive it. The lab also uses your hardening guidance to configure the vulnerability scan target.

As an ISASecure certification body, we verify the SDLA certificate before any other part of the artifact stream can close, so it is the first document to have in hand. The rest of the series is at the CSA filter on the Insights index.