IEC 62443-2-4: The Complete 2026 Service Provider Guide

IEC 62443-2-4 is the part of the IEC 62443 series that sets security program requirements for the companies that integrate and maintain your automation systems: system integrators, vendor service teams and maintenance contractors. It does not certify a product or your plant. It defines the security capabilities a service provider can offer an asset owner, and maturity levels for rating each of those capabilities.

For an asset owner, that makes it a procurement tool. Instead of a vague “follow good security practice” clause, you can name the edition, pick the requirements that apply to a project, set a minimum maturity level and ask for evidence. The current international edition is Edition 2.0, published in December 2023.

This guide covers who the standard applies to, what it asks of providers, how ML1 to ML4 work, how providers are evaluated and certified, and how to write it into contracts. For where it sits among the other parts, see our guide to the IEC 62443 parts.

Who IEC 62443-2-4 applies to

The standard is written for IACS service providers, meaning integration and maintenance service providers working on an Automation Solution. In plain terms, an Automation Solution is the control system as actually installed and configured at your site, including its supporting hardware and software. It often contains components from several suppliers.

Typical in-scope providers include:

• System integrators that design, configure, install and commission control systems.
• Automation vendors’ service organizations that maintain their installed base.
• Maintenance contractors and remote support providers working on live systems.
• Equipment builders when they commission and support packaged systems on your site.

It sits alongside the other roles in the series. IEC 62443-2-1 covers the asset owner’s own security program, IEC 62443-3-3 covers system security requirements, and IEC 62443-4-1 and 4-2 cover product suppliers. Nothing stops an asset owner from holding its in-house engineering team to the same requirements, and doing so keeps internal and external work to one yardstick.

What the standard asks of service providers

The requirements describe capabilities, not technical settings. The IEC abstract notes they are mainly related to policy, procedure, practice and personnel. Together, the capabilities a provider offers form its Security Program, which it should be able to describe and demonstrate to you.

The requirements are grouped into functional areas. Typical topics include:

• Solution architecture and hardening of the systems the provider delivers.
• Secure remote access for vendor support.
• Account and user management, including removal of default and shared accounts.
• Event logging and handover of security-relevant records.
• Malware protection and patch handling for the components they support.
• Backup and restore of configurations and data.
• Staffing: training, background checks and competence of the people sent to site.

These are general topic descriptions, not the standard’s formal headings. The standard also links some requirements to the technical capabilities in IEC 62443-3-3 and 4-2, and it accepts that legacy systems with weak technical security can be addressed through risk mitigation.

Two design features matter for buyers. First, the standard allows profiles that select a subset of requirements, so not every capability applies to every project. Second, it is not a configuration baseline. The specific settings for your site still come from your own risk assessment and target security levels.

IEC 62443-2-4 editions: 2023, 2024 and 2018

The current IEC version is IEC 62443-2-4:2023, Edition 2.0, published on 15 December 2023. It replaces the 2015 edition and its 2017 amendment. The foreword describes it as a technical revision with editorial updates and clarifications, but no significant technical changes.

Two other versions appear in contracts and certificates:

• EN IEC 62443-2-4:2024 is the European adoption of the 2023 edition.
• ANSI/ISA-62443-2-4-2018 is still ISA’s US version, based on the 2015 IEC text and its 2017 amendment.

Because the versions differ in date and wording, write the exact one into your contract. If a provider’s certificate references the 2015 edition, ask how and when they plan to move to the 2023 text.

Maturity levels ML1 to ML4 in practice

Each requirement is assessed at a maturity level, so a provider claims a capability “at ML2” or “at ML3” rather than simply complying. The four levels are ML1 Initial, ML2 Managed, ML3 Defined (Practiced) and ML4 Improving. The table shows what each means on site and what you should ask for.

Maturity level	What it means in practice	Evidence an asset owner should request
ML1 Initial	The service is delivered ad hoc. Documentation is missing or partial, and results depend on which engineer turns up.	Treat as no assurance. Ask for a dated plan to reach ML2 or ML3 for the requirements you selected.
ML2 Managed	Written policies and procedures exist, staff have the expertise or training to follow them, and the process can be repeated.	Current procedures, named responsible roles, and training records for the staff assigned to your site.
ML3 Defined (Practiced)	The process is repeatable across the provider’s organization and has actually been performed, with records to prove it.	Redacted records from real projects: completed hardening checklists, remote session logs, patch qualification records, restore test results. A certificate showing ML3 for those requirements.
ML4 Improving	The provider measures how well the process works and shows continuous improvement based on those measures.	Process metrics and trend reports, plus corrective actions taken after audits, incidents or missed targets.

In our view, ML3 is a sensible contractual floor at high-consequence sites for remote access, account management, patching and backup. It is the first level that calls for evidence the process has actually been practiced. ML2 shows written procedures and trained staff, which is not the same as proof of execution.

Read certificates closely. Some published certificates claim ML3 only for a defined subset of requirements and ML2 for the rest, and scope may be limited to one business unit, site or service line.

How IEC 62443-2-4 maturity levels differ from security levels

Maturity levels measure how well a provider’s processes are defined and practiced. Security levels (SL 1 to SL 4) measure how well a system or component resists attack, and they come from IEC 62443-3-3 and 4-2. A provider at ML3 can still deliver a system that misses your target security level if the design is wrong, so you need both.

How IEC 62443-2-4 is evaluated and certified

IEC TS 62443-6-1:2024, published in March 2024, sets out an evaluation methodology for 2-4. Its aim is repeatable, reproducible results, and it is written for first-party (self), second-party (customer) and third-party (certification body) assessment. For an asset owner, that means you can audit a provider against a recognized method instead of inventing your own checklist.

Third-party routes include:

• Provider certificates. Certification bodies issue 2-4 certificates to service organizations, and some appear as IECEE certificates under the Industrial Cyber Security Capability Scheme (OD-2061). Check the edition, scope, maturity level per requirement set, and expiry or surveillance dates.
• ISASecure ACSSA. The ISASecure ACSSA program evaluates an operating IACS against IEC 62443-2-1, 2-4, 3-2 and 3-3, with the asset owner as the applicant. Version 1.0.0 took effect on 17 February 2026.

ACSSA is not a standalone service provider certificate. The provider’s work is evaluated as part of your system. ISASecure states that a maintenance provider holding a suitable 2-4 certification at ML3 can supply evidence for the applicable requirements, though additional evidence may still be required for the system under evaluation.

All of these routes are voluntary. No certificate replaces your own oversight of what happens on your network.

How to write IEC 62443-2-4 into contracts

“The contractor shall comply with IEC 62443” gives you very little to enforce. Nobody can say which requirements apply, at what maturity, or in which phase. A workable clause set looks like this:

1. Name the edition. For example, IEC 62443-2-4:2023 or its EN adoption, rather than an undated reference.
2. Select the requirements. Attach a profile or requirements matrix showing which capabilities apply to integration and which to maintenance.
3. Set minimum maturity. State the ML per requirement, for example ML3 for remote access and patch handling and ML2 elsewhere.
4. Define deliverables. Make security documentation part of acceptance: hardening records, account lists, network drawings, and backup and restore test results.
5. Flow requirements down. Subcontractors and remote support partners must meet the same requirements.
6. Require notification. Set timelines for reporting security incidents, vulnerabilities found during service, and loss or downgrade of certification.
7. Keep audit rights. Reserve the right to assess the provider using the IEC TS 62443-6-1 method, on site or remotely.

Our post on third-party risk contract clauses covers the general drafting of audit, notification and termination terms.

Evidence and questions for an IEC 62443-2-4 service provider

Before award, and again at renewal, ask for evidence rather than declarations:

• The certificate and full scope statement, or the latest assessment summary if the provider is not certified.
• The provider’s Security Program description and the procedures behind each requirement you selected.
• Redacted records from recent projects showing those procedures in use.
• Training and background-check records for the people assigned to your site.
• A sample handover package from a comparable project.

Then ask direct questions:

• Which of our selected requirements are inside your certificate scope, and at what maturity level?
• Who will actually do the work: employees, subcontractors or both?
• How do you connect remotely, who approves sessions, and how are sessions logged and closed?
• How do you qualify patches and anti-malware updates before applying them to our systems?
• What happens when you find an unsupported or vulnerable system during a visit?
• How are engineering laptops and removable media checked before they touch our network?
• When did you last test a restore from backup, and can we see the record?

In our experience, remote access is where provider practices vary most. Our guide to OT secure remote access lists the controls to expect before you approve a vendor connection.

If you need the documented layer for this work, the IEC 62443 Toolkit ($149) includes 117 editable templates (82 Word, 35 Excel) in 16 sections, and its coverage includes service providers and supply chain under 2-4. It is written against IEC 62443-2-1:2024 for asset owners and service providers. It cannot certify anyone; your team still has to run the processes and keep the records.

IEC 62443-2-4 FAQs

Is IEC 62443-2-4 certification mandatory?

No. Certification is voluntary. It typically becomes binding on a provider when a customer writes it into a contract or tender, which is why the drafting steps above matter.

What maturity level should we require from an integrator?

As a rule of thumb, for critical sites require ML3 for remote access, account management, patching, and backup and restore, and accept ML2 for lower-risk requirements. Treat ML4 as a differentiator rather than a minimum, since it requires measured, continuous improvement.

What is the difference between 2-1 and 2-4?

IEC 62443-2-1 covers the asset owner’s own security program, organized into security program elements. Part 2-4 covers the capabilities a service provider brings to your site. Your 2-1 program should define what you require from providers, and 2-4 gives you the vocabulary to state it.

Can we assess a provider ourselves?

Yes. IEC TS 62443-6-1:2024 supports second-party assessment, so an asset owner can run its own evaluation of a provider. Keep it proportionate: a desk review of procedures and records for most providers, and an on-site or witnessed assessment for those with privileged or remote access to critical systems.