What is IEC 62443-2-4?
IEC 62443-2-4 is the part of the IEC 62443 series that specifies which security processes a service provider must be able to offer when it integrates or maintains an industrial automation and control system (IACS). The standard therefore does not target products but the work of system integrators, maintenance contractors and their subcontractors in industrial automation. An asset owner uses IEC 62443-2-4 to state in contracts what it may expect from those parties, and a service provider uses it to set up its own security programme and have it certified. The current version is edition 2.0, published in December 2023.
🧠 What exactly does IEC 62443-2-4 cover?
IEC 62443-2-4 describes the security programme (Security Program, SP) of an IACS service provider: the combination of policies, procedures, practices and personnel through which it assures security and cybersecurity during the integration and maintenance of an Automation Solution. That is the concrete, customer-specific installation of a control system, such as a DCS or SCADA system with its associated safety functions.
Three principles determine how you should read the standard:
- Capabilities, not project obligations - a requirement means the service provider can deliver a measure when the asset owner asks for it. Not every requirement has to be applied in every project.
- Processes, not technology - the requirements concern how the service provider works. Edition 2 explicitly reworded requirements that could be read as technical product features into requirements on the use and configuration of technical capabilities. Technical requirements for systems and components are in IEC 62443-3-3 and IEC 62443-4-2.
- Profiles - because not every requirement fits every sector, the standard allows industry groups to create a profile: a selected subset of requirements for a specific environment.
The requirements sit in normative Annex A as one large table. Each requirement has an ID (for example SP.07.xx), a functional area, topic and subtopic, a column for required documentation and a rationale. Every requirement is either a Base Requirement (BR) or a Requirement Enhancement (RE) that strengthens a base requirement. The IEC also ships the table as a CSV file, so you can filter it and copy it into a procurement specification.
🧱 Who is IEC 62443-2-4 intended for?
The standard distinguishes four roles around an installation:
| Role | What does this party do? | Relevant standard |
|---|---|---|
| Asset owner | Owns and operates the installation and sets the requirements | IEC 62443-2-1, IEC 62443-3-2 |
| Integration service provider | Design, installation, configuration, testing, commissioning and handover; often called integrator or Main Automation Contractor (MAC) | IEC 62443-2-4 |
| Maintenance service provider | Support after handover, such as account management, monitoring, patching and security assessments | IEC 62443-2-4 |
| Product supplier | Manufacturer of hardware and software, for example an OEM or control system vendor | IEC 62443-4-1, IEC 62443-4-2 |
In practice, many companies play several roles. A control system vendor supplies products (4-1/4-2), builds the installation as integrator (2-4) and then signs a service contract for remote maintenance (also 2-4). A machine builder that commissions its machine at the customer’s site and supports it through Remote Access also acts as a service provider in the sense of IEC 62443-2-4 at that point.
🔧 Which twelve functional areas does the standard define?
Annex A groups the requirements into twelve functional areas. Together they cover the entire lifecycle, from staffing the project team to backup and recovery:
| Code | Functional area | Example requirements |
|---|---|---|
| SP.01 | Solution staffing | Security training and screening of project staff, appointing a security lead |
| SP.02 | Assurance | Demonstrating that the installation’s security policy is actually enforced, for example through hardening guidelines and security testing during FAT and SAT |
| SP.03 | Architecture | Network design with zones and conduits, network segmentation, protocol filtering and firewalls |
| SP.04 | Wireless | Secure design and management of wireless links, such as WirelessHART |
| SP.05 | SIS | Protecting the safety instrumented system against unintended or unauthorised changes |
| SP.06 | Configuration management | Configuration management, asset inventory and change management |
| SP.07 | Remote access | Controlled remote access, for example via a Jump Server with MFA |
| SP.08 | Event management | Logging, monitoring and support for incident response |
| SP.09 | Account management | Access control, personal user accounts and password policy |
| SP.10 | Malware protection | Use of anti-malware software or allowlisting and keeping malware definitions up to date |
| SP.11 | Patch management | Testing, approving and deploying patches in line with patch management |
| SP.12 | Backup/restore | Backup and restore of configurations, programs and system images, including restore tests |
For the asset owner this structure works as a checklist: you can quickly see which areas a supplier can demonstrably handle and where the contract needs additional agreements.
📈 How does the IEC 62443-2-4 maturity model work?
IEC 62443-2-4 measures not only whether a service provider meets a requirement, but also how mature that process is. The maturity model is derived from CMMI for Services (CMMI-SVC) and has four levels:
| Level | Name | What it means in practice |
|---|---|---|
| ML 1 | Initial | The service provider can deliver the capability, but ad hoc and often without a documented way of working |
| ML 2 | Managed | Written policies and procedures exist; the provider can demonstrably manage how the capability is delivered |
| ML 3 | Defined | The documented processes are applied repeatably across the organisation, with evidence from projects |
| ML 4 | Improving | Processes are measured and continuously improved based on those measurements |
Two points are often misunderstood. First, a maturity level is unrelated to a security level: the former describes how mature a process is, the latter how resilient a zone or component is. Second, a certificate often states different levels for different parts. Published integrator certificates commonly show ML 2, sometimes with ML 3 for a subset of the requirements. So always look at the scope and the assessment report, not just the number.
🕰️ How did IEC 62443-2-4 come about?
IEC 62443-2-4 has a notably Dutch background. It was prepared by IEC technical committee TC 65 in collaboration with the WIB, the International Instrument Users’ Association. The WIB was founded in the Netherlands in 1963 by process companies including Shell, AKU (later AKZO), DSM, Hoogovens and Unilever under the Dutch name Werkgroep voor Instrument Beoordeling, and is based in The Hague.
| Year | Milestone |
|---|---|
| 2010 | WIB publishes the report Process Control Domain – Security Requirements for Vendors (M 2784-X-10), followed by version 2 later that year |
| 2011 | Shell requires conformance with the WIB requirements from suppliers of process control systems from 1 January |
| 2015 | First edition of IEC 62443-2-4, based on the WIB document |
| 2017 | Amendment 1; adopted by ISA in 2018 as ANSI/ISA-62443-2-4-2018 |
| 2023 | Edition 2.0 (December): editorial clarifications, no significant technical changes |
| 2024 | European adoption as EN IEC 62443-2-4:2024 and publication of the evaluation method IEC TS 62443-6-1 (March) |
IEC TS 62443-6-1 gave assessors and certification bodies a uniform method for establishing conformity with 2-4, so that assessments are repeatable and comparable.
🧭 How do you apply IEC 62443-2-4 in an OT project?
For an asset owner commissioning a new installation or signing a maintenance contract, this approach works well:
- Define your own framework first - set up your security programme in line with IEC 62443-2-1 and carry out a risk assessment according to IEC 62443-3-2. This yields zones, conduits and the target security level.
- Select the relevant requirements - pick the requirements from Annex A that fit the project, or use an existing industry profile. A maintenance contract mainly calls for SP.06 to SP.12; a new-build project for all twelve areas.
- Include them in the procurement specification - refer to specific requirement IDs and ask for the maturity level. This makes tenders comparable.
- Assess the supplier - ask for a 2-4 certificate with its assessment report, or run your own audit using IEC TS 62443-6-1 as a guide.
- Verify during the project - have security measures demonstrated during FAT and SAT, and require documentation at handover: network drawings, asset inventory, account overview, backups and hardening reports.
- Secure the maintenance phase - agree how patches, malware protection, the use of portable media such as USB sticks, remote access and incident reporting are handled for as long as the system is in operation.
In the Netherlands this has become more relevant since the Cybersecurity Act (Cyberbeveiligingswet) entered into force on 15 August 2026. Like NIS2, it requires essential and important entities to manage supply chain risks. IEC 62443-2-4 turns that into auditable requirements for OT service providers, alongside general supplier security and Third Party Risk Management. The Cyber Resilience Act covers products with digital elements but not the services of an integrator, so 2-4 remains the standard of choice there. Referencing a recognised standard also makes compliance easier to demonstrate to regulators.
❓ Frequently asked questions
Is IEC 62443-2-4 mandatory?
IEC 62443-2-4 is a voluntary international standard, not a law. It becomes binding as soon as an asset owner includes it in a contract or procurement specification. Because the Dutch Cybersecurity Act and NIS2 require supply chain security, more and more asset owners use IEC 62443-2-4 as a contractual requirement for OT service providers.
What is the difference between IEC 62443-2-4 and IEC 62443-2-1?
IEC 62443-2-1 describes the security programme of the asset owner, the organisation that owns and operates the installation. IEC 62443-2-4 describes the security programme of the service provider that integrates or maintains the installation. The two standards fit together: the asset owner sets the requirements, and the service provider must be able to deliver them.
What is the difference between IEC 62443-2-4 and IEC 62443-4-1?
IEC 62443-4-1 sets requirements for the development process of a product supplier, such as a manufacturer of PLCs or SCADA software. IEC 62443-2-4 covers the services around a specific installation: design, integration, commissioning and maintenance. A supplier that both makes products and delivers projects deals with both standards.
Can an integrator be certified to IEC 62443-2-4?
An integrator or maintenance provider can have its security programme certified by an accredited certification body, often within the IECEE scheme. The certificate states the assessed functional areas and the maturity level achieved, for example ML 2 or ML 3. An IEC 62443-2-4 certificate says something about the service provider’s processes, not about the security of one specific installation.
Which maturity level should I require from a service provider?
For most OT projects, IEC 62443-2-4 maturity level 2 is a realistic minimum, because it requires documented policies and procedures. For critical installations, such as essential processes under the Dutch Cybersecurity Act, ML 3 is more appropriate, because the service provider must then show that its processes are applied repeatably in every project. The level you choose should follow from your own risk assessment.
What changed in edition 2 of IEC 62443-2-4?
Edition 2.0 of IEC 62443-2-4 appeared in December 2023 and replaced the 2015 edition with its 2017 Amendment 1. According to the IEC, the new edition mainly contains editorial clarifications and no significant technical changes. The main clarification is that requirements now clearly concern the use and configuration of technical capabilities, not the capabilities themselves.
📌 In summary
IEC 62443-2-4 defines which security processes an integrator or maintenance provider must be able to deliver, organised into twelve functional areas and assessed against four maturity levels. The standard grew out of the user-driven work of the Dutch-founded WIB, has been available as edition 2.0 since December 2023 and, together with IEC 62443-2-1, IEC 62443-3-3 and IEC 62443-4-1, forms the basis for demonstrably secure OT installations across the whole lifecycle. For asset owners it is the instrument for turning supply chain security under the Cybersecurity Act into concrete contract terms.