IEC 62443-4-1: secure product development

This guide explains the eight practices, the four maturity levels and how the standard relates to IEC 62443-4-2 and the Cyber Resilience Act. Using the example of a controller manufacturer, you will see how to get started in six steps. We describe the standard only in our own words, and the examples are invented.

Who IEC 62443-4-1 is for

The standard addresses manufacturers, called "product suppliers" in the series: makers of controllers, gateways, HMI and engineering software, host and network components. Machine builders with their own control or software development often count as well. The first edition was published in 2018 (IEC 62443-4-1:2018, technically identical to ANSI/ISA-62443-4-1-2018).

IEC 62443-4-1 is not a legal obligation. Customers increasingly ask for it in tenders, though, and it is an obvious basis for the duties under Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA). If you first want to place the parts of the series, start with our guide to the IEC 62443 overview.

The eight practices at a glance

A practice is one area of the development process. The table gives the abbreviations under which the standard lists its requirements and the number of requirements per practice.

Practice	Abbreviation	Requirements	What it covers	Typical evidence
1 Security management	SM	13	Process, roles, competence, protected development environment, third-party components, release gate	SDL description, training records, SBOM
2 Specification of security requirements	SR	5	Product security context, threat model, testable requirements	Threat model, requirements list
3 Secure by design	SD	4	Architecture with several layers of defense, design reviews	Security architecture, review records
4 Secure implementation	SI	2	Coding standard, static analysis, code review	Coding standard, analysis reports
5 Security verification and validation testing	SVV	5	Testing of security functions, fuzzing, penetration testing	Test plan and test report
6 Management of security-related issues	DM	6	Receive, assess, fix and disclose reports	PSIRT process, disclosure policy
7 Security update management	SUM	5	Qualify, document and deliver updates authentically	Update concept, release notes
8 Security guidelines	SG	7	Guidance for secure installation, operation and disposal	Hardening guide for users

Three points are often underestimated in practice:

Third-party components. Operating system, crypto libraries and protocol stacks make up a large part of the firmware. They need selection, an inventory and ongoing monitoring, not only your own code.
Release gate. No product and no patch ships while known security issues are open, unless someone has accepted the residual risk deliberately and on record.
User documentation. Without a hardening guide, no integrator can apply the manufacturer's defense-in-depth concept. Practice 8 is therefore part of security, not an afterthought.

Maturity levels: how established the process is

IEC 62443-4-1 describes four maturity levels (ML). In our own words:

ML 1, Initial: The outcome depends on individuals and is hard to predict.
ML 2, Managed: The process is written down and the people involved are trained. It does not yet have to have been applied to a real product.
ML 3, Defined, also Practiced: The process is the same across the organization and has proven itself on at least one product.
ML 4, Improving: You measure how well the process works and show the improvement with metrics.

Maturity is assessed per practice and may differ between practices. Note: the maturity level says how established the process is, not how many requirements you may leave out. Every requirement you declare applicable to a product must be met. Ask the scheme owner which minimum maturity a certification program expects.

How it relates to IEC 62443-4-2

The two manufacturer parts share the work. IEC 62443-4-1 describes the process, IEC 62443-4-2 the technical capabilities of a component per security level, split into software application, embedded device, host device and network device. The level a component can reach is called SL-C (capability security level).

The two interlock: 4-2 assumes that the component was developed under a process in line with 4-1. In turn, the target SL-C becomes a requirement in practice 2, and the tests in practice 5 provide the evidence. Our guide to security levels explains the levels in more detail.

How it relates to the CRA

The CRA does not prescribe a particular standard, but it overlaps with 4-1 in many places. The risk assessment under Art. 13(2) CRA fits practice 2, due diligence for third-party components under Art. 13(5) fits practice 1, and vulnerability handling under Annex I, Part II CRA fits practices 5, 6 and 7. As of 10 November 2026, to our knowledge, no harmonized standard for the CRA has been published in the Official Journal, so a process under 4-1 does not give a presumption of conformity.

Some duties come only from the law, such as reporting under Art. 14 CRA, the SBOM in a machine-readable format and a stated support period. Our guide "CRA and IEC 62443" shows the full mapping. The guides to vulnerability handling under the CRA and to the SBOM, which also places BSI TR-03183-2, go deeper. You will find the text of the regulation on EUR-Lex.

Six steps to a process under 4-1

Set the scope. Which products and versions does the process cover? Which component type under 4-2 is each product?
Record the current state per practice. Go through the eight practices and note what already exists: reviews, test reports, a ticket system for customer reports.
Set the target. Decide the target maturity per practice, the SL-C per component and the route to evidence: self-declaration, process certificate or product certificate.
Prioritize the gaps. Start where customers and the CRA both look: third-party components with an SBOM, vulnerability handling and security updates.
Run it on one product. A process that exists only on paper stays at ML 2. Only a real project shows whether templates and approvals work day to day.
Measure and improve. Trace security defects found in the field back to their cause in the process and adjust it.

Example: a manufacturer of compact controllers

The example is invented. A manufacturer with 60 developers builds compact controllers and a gateway for remote maintenance. A major customer asks in a tender for evidence of a process under IEC 62443-4-1.

Current state: Code reviews and functional tests have been in place for years. There is no threat model, and customer reports about security flaws end up in the general support mailbox.
Target: ML 3 in all practices for the gateway, SL-C 2 under 4-2, a process certificate later on.
First steps: The team creates a threat model for the gateway with data flows and trust boundaries. An SBOM is now produced with every build. A fixed address for security reports and a small PSIRT with a deputy take over the assessment.
After the first release: The release gate checks that all security activities are complete. The hardening guide ships with the product. The controllers follow in the next cycle using the same process.

Common mistakes

Looking only at the technology. 4-1 assesses the process. A secure component without a traceable process does not meet the standard.
Everything at once. A process for all products at the same time overwhelms many teams. Start with one product.
Forgetting third-party code. Vulnerabilities are not only in your own code but also in the libraries you bring in.
Not recording the edition. Note which edition of the standard you apply, and check which one a certification program uses.

Checklist

Products and versions in scope are defined.
Roles and owners in the development process are named.
The edition of the standard and the route to evidence are decided.
Current state and target maturity per practice are documented.
Every product has a threat model.
Third-party components are recorded per version in an SBOM and monitored.
Security reports have a fixed address and a described process.
A release gate stops shipments with open security issues.
Users receive a hardening guide.
The process is reviewed and improved regularly.

IEC 62443-4-1 in Complass

A spreadsheet with 47 rows does not show which evidence belongs to which product version, and templates end up scattered across emails. In Complass you run the process in one place:

IEC 62443 module for manufacturers. Nine phases lead from product goal and maturity level through the eight practices to the component requirements per SL-C.
Catalogs. All 47 practice requirements of 4-1 and the component requirements of 4-2, each with an implementation guide, evidence and industrial examples. 4-2 can be filtered by component type.
Manufacturer templates. Including SDL description, threat model, security test plan, PSIRT process, update concept, hardening guide, SL-C statement and mapping to CRA Annex I.
SBOM and vulnerabilities. SBOM per product version with automatic matching against NVD, KEV, EPSS and EUVD, VEX assessment and vendor advisories in CSAF format.

The texts of the standards are not included, because standards are protected by copyright. Complass explains the requirements in its own words, and you can add excerpts from your licensed edition yourself.

SBOM of a demo company product with components, supplier, purl, license and matched vulnerabilities — SBOM per product version: third-party components and their vulnerabilities at a glance.

Frequently asked questions

Do we need a certificate under IEC 62443-4-1?

Not necessarily. Many manufacturers start with a self-declaration and their own evidence. A process certificate from an independent body, for example in the IECEE scheme or under the ISASecure SDLA program, gives customers additional confidence.

Which maturity level is the right one?

That depends on your customers and the certification program. ML 3 requires that the process has been applied to at least one product. Set the target per practice and give your reasons.

Does 4-1 also apply to pure software?

Yes. The standard covers products for industrial automation, which includes HMI and engineering software. The component type under 4-2 is then software application.

Is a process under 4-1 enough for the CRA?

It covers a lot, but not everything. Reporting under Art. 14 CRA, the stated support period and the conformity assessment come from the law. A good 4-1 process provides most of the building blocks.

In a demo, we show you with the demo company how scattered templates become a traceable development process per product.

Request a demo Try it for 14 days

Not legal advice. This guide gives a general overview and does not replace a case-by-case review. The text of Regulation (EU) 2024/2847 and your licensed edition of the standard are authoritative. Status of standardization: 10 November 2026.

IEC 62443-4-1: secure development for manufacturers