IEC 62443 Certification for Product Makers: What's Involved

IEC 62443 is a series of standards on security for industrial automation and control systems (IACS) ^[1][2]. For a company that makes components such as controllers, devices, embedded software or network equipment, "IEC 62443 certification" usually means one or both of two things: certification of your development process against IEC 62443-4-1, or of a product against IEC 62443-4-2 ^[1][2][3][4].

This page explains that product-maker path: what each part covers, what security levels mean, how certification schemes work, what evidence your team will need, and how it relates to the EU Cyber Resilience Act. It’s part of our product security standards hub. We don’t reproduce the standards. Buy them from IEC or your national standards body.

Looking for a personal IEC 62443 credential for an individual engineer? That’s a separate training and certificate route. This page covers product and process certification only.

Two parts, two kinds of certification

The seven foundational requirements in 4-2 are identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability ^[2].

The two fit together. In ISASecure’s CSA scheme, for example, a supplier must pass a development lifecycle process assessment, on which an SDLA certification is granted; suppliers may already hold SDLA or apply for both in parallel ^[3]. Check your chosen scheme’s rules. The IEC 62443-4-1 vs 4-2 comparison goes into the differences in detail.

Security levels and "SL 2"

IEC 62443-4-2 defines requirements for a component’s capability security level, written SL-C ^[2]. That’s the level the component is capable of, not the target level for a particular site (SL-T) or the level a deployed system achieves (SL-A), which 4-2 treats as out of scope ^[2].

Searches for "IEC 62443-4-2 SL2" are about this capability level. Which level you seek certification for should come from your customers' requirements and your threat model, not from marketing.

How certification works

IEC doesn’t issue certificates itself. Certification is done by certification bodies operating under a scheme. One established scheme for product makers is ISASecure:

• SDLA (Security Development Lifecycle Assurance) assesses development lifecycle processes of suppliers of control system products against ISA/IEC 62443-4-1. SDLA version 3.0.0 has been effective since 16 June 2020 ^[4].
• CSA (Component Security Assurance) covers software applications, embedded devices, host devices and network devices as defined by ISA/IEC 62443-4-2. CSA version 1.0.0 has been effective since 28 August 2019 ^[3].

Other schemes and certification bodies exist. Before you choose one, check:

• which parts and versions of IEC 62443 it issues certificates against;
• whether its certificates are recognized by the customers and markets you sell to;
• who the accredited certification bodies are, and whether they test the product or only review documents;
• what happens to the certificate when you ship a new firmware version.

The evidence a product team must produce

Our original summary of the kinds of evidence product teams may need to prepare. It’s a planning aid. Your scheme’s documents are the authority. ISASecure’s CSA, for example, examines development artifacts, the component’s security capabilities and vulnerability identification testing ^[3].

Much of this overlaps with what the CRA asks for anyway: a vulnerability-handling process, security testing, user information and update mechanisms ^[5]. See our guide to setting up a PSIRT for the vulnerability-handling side.

How it relates to the Cyber Resilience Act

Under the CRA, products that conform to harmonised standards cited for the CRA benefit from a presumption of conformity with the essential requirements those standards cover, once the standards' references are published in the Official Journal ^[5][6]. Status as of 2026-11-10:

• The Commission adopted standardisation request M/606 for 41 standards supporting the CRA, horizontal and product-specific, prioritising the important and critical product categories in Annexes III and IV ^[6].
• The Commission’s Cyber Resilience Act implementation timeline lists first standardisation deliverables for Q3 2026 and more for 30 October 2027 ^[7].
• We didn’t find a harmonised standard for the CRA listed on the Commission’s Cyber Resilience Act standardisation page (last updated 31 July 2026) ^[6]. Check the Official Journal and the European standardisation organisations' Cyber Resilience Act site before relying on any standard for presumption of conformity.

So an IEC 62443 certificate is evidence you can use in your Cyber Resilience Act technical documentation, but on its own it isn’t proof of Cyber Resilience Act conformity. Which product class you’re in also matters, because important and critical products have stricter conformity assessment routes ^[5]. See our Cyber Resilience Act guide.

For wireless products, the separate EN 18031 standards under the Radio Equipment Directive are covered in EN 18031 and the RED delegated act.

Where to start

1. Ask your top EU and US customers which parts of IEC 62443, and which security level, they expect.
2. Run a gap assessment of your development process against 4-1 first.
3. Pick one product to take through 4-2, and decide the capability level from its threat model.
4. Choose a scheme and certification body, and read their current scheme documents.
5. Map the evidence to your Cyber Resilience Act technical documentation so you build it once.

If you need outside help with the engineering side, our guide to evaluating firmware development companies covers what to ask.

Spotted an error? Report it to our corrections log. Read our editorial methodology.