ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
IEC 62443 certification is asked about far more often than it is understood. There is no single certificate that says an organisation “is IEC 62443 certified”, and any supplier claiming one is describing something narrower than it sounds. The series certifies by role, and knowing which role you occupy tells you which certificate is even available to you.
This guide covers what can be certified, what cannot, how requirements are selected for assessment, and what an asset owner actually gets assessed against.
The series recognises three roles, and IEC 62443 certification follows them.
| Role | Assessed against | What the certificate says |
|---|---|---|
| Asset owner | IEC 62443-2-1 | Your security programme meets the selected requirements at stated maturity levels |
| Service provider | IEC 62443-2-4 | Your integration and maintenance processes meet the requirements |
| Product supplier — process | IEC 62443-4-1 | Your development lifecycle is secure |
| Product supplier — product | IEC 62443-4-2 | This component provides these capabilities |
| System | IEC 62443-3-3 | This automation solution meets these system requirements at a security level |
Those are five different claims. A vendor holding 4-1 has told you how they build software, not what their product can do. A vendor holding 4-2 for one product family has told you nothing about the rest of their catalogue.
Every IEC 62443 certification carries a scope: a named development organisation, a product family, a firmware range, a service line, a site. The certificate’s existence is not the claim — the scope statement is.
The commonest procurement error is accepting a certificate whose scope does not cover the model, version or service you are actually buying. Ask for the scope wording verbatim and record it.
Certification bodies accredited under ISO/IEC 17065 issue these. The best-known industry scheme is ISASecure, developed and maintained by the ISA Security Compliance Institute, which requires its certification bodies to hold ISO/IEC 17065 accreditation and has accredited bodies across the US, Europe and Asia. The IECEE conformity assessment system also operates a programme against the series, and several well-known certification bodies run their own.
Because more than one scheme exists, two certificates against the same part can differ in rigour and in what they cover. That is another reason the scope statement matters more than the logo.
This is where IEC 62443 certification differs most from ISO 27001, and where people are most often surprised.
You are not assessed against all 87 requirements automatically. The requirements to be assessed are selected in one of two ways, and you choose which:
That second route means your assessment scope is genuinely yours — which is powerful, and also means you have to be able to defend it.
Where you judge a requirement not applicable, the standard puts the burden squarely on you. You must justify the exclusion and provide evidence showing specifically how the risk it addresses is otherwise mitigated.
A requirement might legitimately not apply because the IACS contains no such technology — no wireless, no safety system. But “not applicable” with an empty justification column is a finding, not an exclusion, and it is the first thing an assessor filters on.
Asset owner assessment is not simply pass or fail per requirement. Maturity levels form part of the conformance assessment process: you identify whether you meet each requirement and, if so, at what maturity level.
That means an IEC 62443 certification result carries more information than a binary. Two organisations can both “meet” a requirement with one at ML 2 and the other at ML 4, and the difference is real.
The standard names the evidence types it expects to be offered, which is unusually helpful when preparing:
Build your evidence register around those categories and an assessor recognises what you are offering immediately.
The sequence that works, in order:
Step 7 is the one that cannot be shortened. Records showing a process practiced over a period take a period to accumulate, and no amount of documentation substitutes for them.
Certificates are useful, but they answer narrower questions than procurement teams usually assume. Four limits are worth knowing before you rely on one.
It does not tell you the product is secure today. A 4-2 certificate describes capabilities the component can provide when correctly configured. Deployed with default credentials and no logging, that same component delivers very little. Capability is not achievement.
It does not cover versions issued after the assessment. Firmware moves. Assurance that a product family is developed under a secure lifecycle does not establish that the specific version in your cabinet was assessed.
It does not transfer between roles. An integrator holding 2-4 has not told you anything about the products they install, and a product supplier holding 4-1 has not told you their field engineers are screened.
It does not remove your own obligations. Buying certified components does not make your plant conformant. The asset owner requirements are about your programme — your zones, your risk assessment, your patching, your incident response — and no supplier certificate discharges them.
For most operators the value is not the certificate itself. It is that preparing for assessment forces the asset inventory, the zone model and the risk assessment to actually exist, in a form somebody else can read.
Plenty of organisations run a full IEC 62443 certification preparation, reach a defensible maturity position, and never engage a body — because the customer or regulator asking the question was satisfied by the evidence rather than the certificate. That is a legitimate outcome, and it is worth deciding which you are aiming for before you spend anything.
Not in itself. The standard is voluntary. But NIS2 and the EU Cyber Resilience Act both drive organisations toward it, customers increasingly ask for it in procurement, and it is the framework accredited bodies and regulator guidance keep pointing at for operational technology.
No, and treat any claim otherwise with suspicion. Certification requires an accredited body to assess your operating programme. What documentation delivers is the maturity level 2 evidence — the written policies, procedures and training — plus the applicability statement, evidence register and audit records the assessment will ask for.
It depends far more on your starting maturity than on the assessment itself. Organisations with an existing information security management system and a documented plant network often move faster, because much of the management process is already in place. The binding constraint is usually accumulating operating records at maturity level 3, not writing the documents.
No. As an asset owner you are assessed against 2-1. You require evidence from others — 2-4 from your integrators, 4-1 and 4-2 from your product suppliers — rather than being assessed against those parts yourself.
Before thinking about certification at all, do the design work: zones and conduits first, then IEC 62443 security levels. Without those, the applicability statement that drives your assessment scope is guesswork.
If you are unsure which parts of the series apply to you, IEC 62443 parts explained sorts them by role. Understanding how the result is expressed is covered in IEC 62443 maturity levels. The asset owner standard is IEC 62443-2-1:2024.
Our IEC 62443 Toolkit includes the applicability statement pre-loaded with all 87 requirements, the conformity evidence register organised by the evidence types above, the maturity assessment workbook and an internal audit checklist — the four artefacts an IEC 62443 certification assessment asks for first. It will not certify you, and it does not claim to. It gets the paperwork in the shape an assessor expects.
August 26, 2026
August 26, 2026
August 26, 2026
August 26, 2026
August 26, 2026