IEC 62443-4-1 certification levels: why ISASecure SDLA has none and every requirement must pass

Search for "IEC 62443-4-1 certification levels" and you will find plenty of material about levels: security levels, maturity levels, "level 2" and "level 3" process certificates. Suppliers arrive at an ISASecure SDLA engagement asking which level to aim for and whether a lower one is a sensible first step. The honest answer is that the question has no object. The ISASecure SDLA scheme certifies a development process with no certification level and no maturity level attached, and has since 2018.

This article covers where the expectation comes from, the rule that replaced the levels, what the one remaining per-requirement choice does, and how to read an SDLA report once you stop looking for a score.

The levels that used to exist

The expectation is not baseless. The scheme did carry certification levels before 2018, and their removal is recorded in the revision histories of the ISASecure SDLA documents.

What remains is a certificate that names one or more development organizations and a specific, version-controlled development process, states the ISASecure version it conforms to and an expiry date, and says nothing about a level. Material that describes SDLA certification levels describes the scheme as it stood before 2018.

What replaced them: every applicable row must pass

The replacement rule is short. IEC 62443-4-1 defines eight practices and 47 requirements. ISASecure expands those into 102 assessable rows in its SDLA-312 evaluation workbook, and certification is granted when every row applicable to the declared scope of the development process has been assessed as passed. Not most of them. Not a weighted percentage. Every one.

The distribution shows where the work concentrates: verification and validation testing is the largest practice at 20 rows, security management has 19 and security guidelines 17; secure by design and update management have five each. It does not change the rule. A single applicable row that cannot be shown to pass is a nonconformity, and the certificate waits until it is closed.

"Applicable" is the only scoping the rule allows. A development process declares whether it is applied to components, to systems or to both, and that declaration decides which rows are in scope. Separately, it declares which products it covers, which decides whose artifacts the certifier may examine. Neither declaration creates a lower tier; together they draw the boundary around the process being certified, and everything inside has to pass.

Two classes of nonconformity exist, major and minor, and it is tempting to read them as a grading scale. They are not. They classify a finding, and at recertification they decide what must happen before the certificate is extended. For an initial certification an open finding of either class means a row has not passed, and the process is not yet certifiable.

The one axis that remains: full or readiness

If there is no level, what do suppliers and assessors negotiate per requirement? The evaluation method, of which there are two.

A full evaluation examines the documented process and the artifacts produced by actually executing it, on products the certifier selects from the supplier's list. A readiness evaluation examines the same documented process, but where a requirement calls for proof of execution it accepts evidence of readiness instead: the training, tools and templates that show the organization is equipped to run the activity even if it has not yet done so.

The method is agreed requirement by requirement, and for most rows the two are identical because most rows do not demand execution artifacts. They differ only on the 21 rows where ISASecure makes proof of execution mandatory; the 22 Appendix A activities are always evaluated in full.

What the choice changes is validity. If every requirement passes by full evaluation, the certificate runs to the end of the 36th month after it is granted. If any requirement passes by readiness evaluation, it runs to the end of the 12th month. That 12-month certificate can be extended once the readiness rows have passed a full evaluation, and the extended certificate expires 36 months after the original grant, not after the extension. If that has not happened by month 12, the certificate expires and the organization starts again with a full evaluation of every requirement.

A readiness-based certificate is not a lower grade: every applicable requirement still passed. What it attests on the readiness rows is readiness to execute rather than execution, and the 12-month term is how long the scheme relies on that before it wants to see execution.

A level on a certificate is not an ISASecure level

You may have seen a certificate, a report or a marketing page that attaches a "maturity level" to a supplier's development process. Whatever it is describing, it is not an ISASecure SDLA outcome. None of the documents that define the scheme, from the scheme description and the certification requirements to the certificate rules, the report template and the evaluation workbook, use a maturity level or a certification level, and the certificate format has no line for either.

This article makes no claim about the text of IEC 62443-4-1 itself; the point is about what the scheme certifies, which is a process with no level attached.

Levels do live in the ISASecure family, in the product schemes. A CSA certificate states a capability security level from 1 to 4, as the CSA series explains; an ICSA certificate states a Core or Advanced tier. Those describe the product, not the process behind it, and the SDLA certificate underneath both carries neither. Exactly one row in the SDLA catalogue, DM-4 on addressing security issues, is validated with reference to the product's capability security level, and even there the level belongs to the product, not to the certificate.

How to read an SDLA assessment report

Once you stop looking for a score, the report is easy to read. The scheme's report template, SDLA-303, gives every practice its own results section carrying one outcome, pass or fail, followed by a narrative and a table with three columns: the requirement, the type of evaluation (full or readiness) and the result.

A practice passes only when every one of its requirements has passed, by either method. A requirement passed by readiness evaluation is marked as such beside its result rather than marked down, and the report's summary spells out what any readiness result means for the certificate's term. There is no practice score, no overall percentage and no level: eight pass-or-fail outcomes, one per practice, and a certificate issued only when all eight are pass.

As an ISASecure certification body, this is the shape of every SDLA report we issue: per practice, pass or fail; per requirement, passed and by which method.

What this means for planning

The absence of levels changes preparation in three practical ways.

Treat the catalogue as a checklist, not a ladder. There is no first rung. Every applicable row has to pass on the day, so the starting point is a gap analysis against all 102 rows, scoped to the components-or-systems declaration you intend to make. The practices with the most rows take longest; those with few rows are not optional.

Decide the evaluation method deliberately, per requirement. The choice only bites on the 21 rows where execution artifacts are mandatory, so the question is concrete: for which of those rows can you show that the activity ran, on at least one product, under the process version you are certifying? Where you can, ask for full evaluation. Where you cannot yet, readiness is a legitimate route, with a 12-month term and a 36-month clock that starts at the original grant.

Do not plan around surveillance, because there is none. A 36-month certificate is kept current by a recertification audit before expiry, a 12-month certificate by the extension above. A lapsed certificate is not suspended, withdrawn or reduced; it expires, and the next certification is an initial one. A plan that assumes an annual check-in to fix things later relies on a mechanism the scheme does not have.

Where to go next

The next article in this series takes the full-versus-readiness choice apart row by row, including the 21 rows with mandatory execution artifacts. The whole series is on the SDLA filter of the Insights index. For the product side, where a security level does appear on the certificate and SDLA is the prerequisite underneath it, start with SDLA as the CSA prerequisite.