IEC 62443-4-1: Why Secure Development Just Became a Manufacturing Requirement

For most of the last decade, IEC 62443-4-1 was something you heard about from the big automation vendors - the ones with a certificate on the website and a dedicated product security team. For a machine builder writing its own HMI, or a manufacturer running in-house software that talks to a PLC, it sat comfortably in the “nice to have, maybe later” column.

That column is closing. Three pieces of EU legislation are converging on the same question - can you show that the software in your product was developed securely, and that you’ll keep it secure? - and IEC 62443-4-1 is the most widely recognized answer to that question in the industrial world.

1. What IEC 62443-4-1 actually is

IEC 62443 is a family of standards for industrial automation and control system security. Most of it describes how an operator secures a plant, or what technical capabilities a component must have. Part 4-1 is different: it doesn’t describe the product at all. It describes the process a supplier uses to build and maintain it - a secure development lifecycle (SDL).

It’s organized into eight practices:

• Security management - who owns product security, how the team is trained, how the process itself is controlled
• Specification of security requirements - a threat model and security requirements that exist before the code does
• Secure by design - defense in depth, minimal attack surface, security-reviewed architecture
• Secure implementation - coding standards, static analysis, review of every change
• Security verification and validation testing - testing the requirements, fuzzing, vulnerability scanning, penetration testing
• Management of security-related issues - receiving, triaging and fixing vulnerability reports, including ones from outside
• Security update management - delivering, documenting and signing patches in a timely way
• Security guidelines - documentation that tells the integrator and operator how to deploy and run the product securely

Each practice is assessed against a maturity level from 1 (ad hoc) to 4 (continuously improving), so the standard is something you grow into rather than a pass/fail checkbox.

2. The Cyber Resilience Act turns “nice to have” into law

The EU Cyber Resilience Act (CRA) applies to practically every product with digital elements placed on the EU market - including industrial controllers, machine software, HMIs, gateways and the PC applications that drive them. Its first obligations are already live: since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA and the national CSIRT, with an early warning within 24 hours. The full set of requirements applies from 11 December 2027.

Read Annex I of the CRA next to IEC 62443-4-1 and the overlap is hard to miss: security based on a risk assessment, secure-by-default configuration, a software bill of materials, vulnerability handling without delay, a coordinated disclosure policy, security updates delivered separately from feature updates, and documentation for the user. These are the same topics as the eight practices above - the CRA states what has to be true, 62443-4-1 describes how to organize a team so it stays true.

That’s why the European standardization work for the CRA leans so heavily on IEC 62443 for industrial products. Whatever the final harmonized standards are called, a team already working to 62443-4-1 will be mapping existing evidence, not starting from zero. The cost of getting this wrong isn’t theoretical either: breaching the CRA’s essential requirements can mean fines of up to €15m or 2.5% of worldwide turnover, and - more painfully - products that can’t legally be sold in the EU.

3. The Machinery Regulation adds a safety angle

From 20 January 2027, the new EU Machinery Regulation replaces the Machinery Directive. For the first time, its essential health and safety requirements explicitly cover protection against corruption - including malicious attempts from outside - and require safety-related control systems to resist intended and unintended manipulation, with software changes recorded and traceable.

In other words, a cybersecurity weakness in machine software is now a potential safety nonconformity, and it lands on the CE marking. For a machine builder, “we tested it before shipping” won’t be a convincing answer to that requirement. A documented, repeatable development process is.

4. NIS2 pushes it down the supply chain

Even manufacturers that don’t sell software are affected. NIS2 Article 21 requires in-scope entities to manage supply chain security and to ensure security in the acquisition, development and maintenance of their systems, including vulnerability handling and disclosure. In practice, that becomes a purchasing question: what evidence does your supplier have that the software running your line is developed and maintained securely?

We’re already seeing IEC 62443-4-1 alignment - or an ISASecure SDLA or IECEE certificate based on it - appear in RFQs and supplier questionnaires. A supplier who can answer with a process description, an SBOM and a vulnerability-handling policy wins that conversation. One who can only offer a last-year pen test report usually doesn’t.

5. Why a pen test is no longer enough

A one-off security assessment is valuable - it’s often how you find out where you actually stand. But it describes one version of the software on one day. The regulations above all care about the lifecycle: what happens with the next release, the next dependency upgrade, the next CVE in a library you didn’t know you were shipping.

That’s exactly what IEC 62443-4-1 formalizes. In our own security assessments of industrial software, the findings themselves are only half the outcome. The other half is folding static analysis, dependency scanning, native code analysis and SBOM generation into every pull request, so the next release is checked automatically instead of waiting for the next audit.

Where to start

Nobody reaches maturity level 3 in a quarter, and nobody needs to start with a certification audit. The practical path for a manufacturer or machine builder looks like this:

1. Inventory your products with digital elements - including the “small” internal tools that talk to a PLC. Those are usually the least protected.
2. Run a gap assessment against the eight practices, scored honestly against the maturity levels. Most teams find secure implementation and verification are partly there, while security requirements, issue management and user documentation are missing.
3. Automate what can be automated first - SAST, dependency scanning and SBOM generation in CI are cheap, fast to introduce and directly produce the evidence the CRA asks for.
4. Set up vulnerability handling now, not in 2027: a disclosure contact, a triage process and someone who can file a 24-hour report. Under the CRA, that part is already in force.
5. Write down what you do - threat models, security requirements, review records, release notes. In 62443-4-1, an undocumented process is treated the same as a missing one.

The window between “recommended” and “required” is short, and it’s already closing. Teams that start building their secure development process now will meet the 2027 deadlines with evidence they’ve been generating for a year. The rest will be trying to reconstruct it under pressure - which is exactly the kind of work we’d rather help manufacturers avoid.