What is ISASecure SDLA, and what does the certificate actually certify?

If your company builds controllers, software or systems for industrial use and a customer has asked whether your development process is "62443 certified," the scheme they are pointing at is ISASecure SDLA, Security Development Lifecycle Assurance. It is the ISASecure conformance scheme for IEC 62443-4-1, the part of the standard that describes how secure products are built rather than what they must do.

SDLA is also the ISASecure certificate most often described wrongly, usually by attaching it to a product. This article covers what the certificate certifies, what the evaluation looks at, why there is no level, and what you may say afterwards.

The certificate in one sentence

An SDLA certificate says that a named development organisation has a documented secure development lifecycle, at a specific version, that meets every applicable IEC 62443-4-1 requirement in the ISASecure catalogue, and that the organisation has been observed following it.

The certificate names one or more development organisations and one version of the process, held under version control, and states the process versions it applies to. It rests on every applicable requirement passing, not on a score, and it says nothing about any individual product.

A process, not a product

The subject of an SDLA certificate is the way products get built, not any product that came out of it. Two declarations frame it at application.

The first is what the process applies to: components, systems or both. The second is the scope of products the process is used for, which may be all of the supplier's products or a defined subset. The organisational boundary can be company-wide, named divisions, product-line teams or physical sites, and mixed forms are allowed. Because the certificate names the organisations it covers, a site or business unit outside the audited scope is not covered.

This is why SDLA is a prerequisite rather than a product scheme. SDLA has a single evaluation element, SDLPA, and the ISASecure product certifications, CSA for components, ICSA for IIoT components and SSA for systems, each contain that same development-process element. An SDLA certificate satisfies it for every product developed under the certified process, so the process is examined once rather than for each product. What a product certification adds is a review of that product's own artifacts, covered in the SDLA prerequisite article in the CSA series and its ICSA counterpart.

Eight practices, 47 requirements, 102 rows

IEC 62443-4-1 organises secure development into eight practices: security management (SM), the specification of security requirements (SR), secure by design (SD) and secure implementation (SI), then security verification and validation testing (SVV), and security defect management (DM) and security update management (SUM), and finally security guidelines (SG). Across them the standard defines 47 requirements.

Security management is the largest family at 13 requirements; secure implementation is the smallest at two. The ISASecure evaluation workbook, SDLA-312, refines those 47 requirements into 102 assessable rows, splitting a requirement into lettered or numbered sub-rows where it contains several distinct obligations.

The refinement is uneven, and shows where an audit spends its time. Verification and validation testing grows from five requirements to 20 rows, secure implementation from two to 13 (one of those rows, SI-3, is a scoping rule rather than a requirement), and security guidelines from seven to 17. Security update management keeps one row per requirement, and secure by design adds only one.

Two counting notes. The workbook also carries 16 rows that belong only to the ICSA product scheme; they are not SDLA requirements and are not evaluated in an SDLA audit. And the 102 is the full catalogue: which rows apply to a given process depends on whether it is declared for components, systems or both.

What the audit looks at

An SDLA evaluation is a process audit. The scheme prescribes obligations rather than phases: an application declaring the process and its scope, evaluation of every applicable requirement by an agreed method, a report, and a certificate. Perseus's own procedure runs the work as planning, the audit itself, and a separate report-and-decision step, which the diagram below follows.

The audit examines two things. The first is the documented process: for each applicable row, does the written procedure cover what the requirement asks for? The second is evidence of execution. The supplier lists the products under the process for which execution artifacts exist; the certifier chooses which to review. Those artifacts, with observation of the practice in use, show whether the written procedure is followed.

What the audit does not do is test a product. There is no functional security assessment and no vulnerability scan in SDLA; those belong to the product certifications, and so does the option to witness supplier-run vulnerability tests. The testing the standard calls for, fuzzing, network-load testing, penetration testing and the rest, is the supplier's activity; the SDLA audit checks that the process requires it and, through sampled artifacts, that it happens. As an ISASecure certification body, our SDLA work is document review and process audit; no product goes on a test bench.

The certification decision is then taken by someone who did not perform the evaluation, as ISO/IEC 17065 requires.

No levels: every requirement must pass

There is no level of any kind on an ISASecure SDLA certificate. The scheme once had certification levels; they were removed in 2018 when SDLA was aligned with IEC 62443-4-1, and the certificate format no longer carries a level line. No ISASecure SDLA document uses maturity levels either. The rule is binary: every SDLA-312 row applicable to the declared scope must pass, and a practice passes only when all of its rows do.

What the scheme does distinguish is how a requirement was passed. Two evaluation methods exist, agreed per requirement between certifier and supplier. Full evaluation checks the documented process and proof that it has been executed. Readiness evaluation checks the documented process and that the organisation is equipped to run it, with people trained, tools in place and templates ready, before any product has been through that step. The two methods differ only on the 21 rows where execution artifacts are mandatory; on every other row they are identical. When every requirement passes by full evaluation, the certificate runs to the end of the 36th month after grant. If any requirement passes by readiness only, it runs to the end of the 12th month, and it can be extended, once every readiness-passed row has passed a full evaluation within that year, to 36 months counted from the original grant. There is no surveillance in the SDLA scheme; a certificate is kept by a recertification audit before it expires.

What the certificate states

ISASecure prescribes the certificate content: the certificate number and date, the name of the process, the supplier and the development organisation or organisations covered, the ISASecure version conformed to (SDLA 3.0.0, with the errata version in force), the references to IEC 62443-4-1:2018 and ANSI/ISA-62443-4-1-2018, the process-version applicability, the expiry date, the authorised representative, and the identity and licence number of the chartered laboratory that issued it. Wording and placement are prescribed.

Four of those facts must also appear in public status information: the development organisation, the process, the ISASecure version and the expiry date.

What the certificate does not say

An SDLA certificate makes no statement about any specific product or product version. The scheme's symbol rules make this explicit: a certified organisation may describe, in general terms, the kinds of products its certified process is used for, but may not name a particular product or version as built under it. That claim belongs to a product certificate, CSA, ICSA or SSA, which checks the artifacts of the certified process for that product.

A certified organisation uses the ISASecure SDLA mark in text form only, with its certificate number; the graphical ISASecure symbol is reserved for product certifications and does not appear on an SDLA certificate.

For an asset owner reading a supplier's paperwork, that is the practical test: an SDLA certificate says the supplier's process is certified; only a product certificate says a given product came through it.

Where to go next

This article opens a series on SDLA; later pieces go deeper on the absence of levels, full versus readiness evaluation and its 21 rows, the 31 minimum requirements, the testing practice, the process-only rows, defect and update management, security guidelines, and recertification. Browse the set from the SDLA filter on the Insights index.