What is IEC 62443-2-1?
IEC 62443-2-1 is the part of the IEC 62443 series of standards that specifies the requirements for an asset owner’s security program: the policies and procedures with which the owner and operator of an industrial automation and control system (IACS) protects that system while it is in operation. The current second edition was published on 7 August 2024 under the title Security program requirements for IACS asset owners and replaced the first edition from 2010. Where IEC 62443-3-3 and IEC 62443-4-2 set technical requirements for systems and components, 2-1 deals with the organisation around them: who does what, how changes are controlled, and how you patch, back up and handle incidents.
IEC 62443-2-1 is therefore the “management part” of the series for owners of SCADA, PLC and DCS environments: it does not tell you which firewall to buy, but which security arrangements must exist around your installation.
🧠 What exactly does IEC 62443-2-1 require?
The standard sets requirements for the security program (SP) of the asset owner, the organisation responsible for the assets of the IACS. In the context of the standard, the operator of the IACS is also considered part of the asset owner, for example a company that runs an installation on behalf of its owner. A few principles from the scope matter a great deal in practice:
- Focused on systems in operation - 2-1 is about operating an existing IACS securely. Risk assessment and zoning during design are covered by IEC 62443-3-2, and requirements for integrators and maintenance providers by IEC 62443-2-4.
- Policies and procedures, not technology - the standard does not require every system to have a particular technical function, but it does require policies and procedures for topics such as patching, malware protection and backups.
- Room for legacy systems - an IACS often stays in service for more than twenty years. If software is no longer supported you cannot patch it; the standard then accepts compensating security measures, provided they are documented in your policies.
- Not everything applies everywhere - requirements on wireless networks or remote access drop out if your installation does not have those functions. You determine which requirements apply to your IACS.
- Implementation independent - you choose how to meet a requirement: technically, physically, procedurally or through a combination.
🔄 What changed between the 2010 and 2024 editions?
The first edition (2010) was based on ANSI/ISA-99.02.01-2009 and centred on a Cyber Security Management System (CSMS): a management system that closely resembled an ISMS. Organisations that already had ISO 27001 ended up duplicating much of their work. The second edition was developed by IEC TC 65 together with the US ISA99 committee; ISA released the identical text in January 2025 as ANSI/ISA-62443-2-1-2024.
| Aspect | Edition 1 (2010) | Edition 2 (2024) |
|---|---|---|
| Core concept | Cyber Security Management System (CSMS) | Security program (SP) |
| Structure | Three main categories: risk analysis, addressing risk, monitoring and improving the CSMS | Eight security program elements (SPEs) with numbered requirements |
| Relation to an ISMS | Considerable overlap with ISO 27001 | Duplicated ISMS requirements removed; linked through requirement ORG 1.1 |
| Assessment | No formal level | Maturity model with maturity levels (ML) |
| Cross-references | Limited | Annex A: mapping tables to 2-4, 3-3, 4-2, ISO/IEC 27001 and the NIST CSF |
The European version, EN IEC 62443-2-1:2024, was adopted without changes and is available in the Netherlands through NEN. Conflicting national standards must be withdrawn by 11 September 2027 at the latest.
🧱 What are the eight security program elements?
The core of edition 2 is a set of eight SPEs. Each element contains numbered requirements with their own code, so you can assess them one by one.
| SPE | Element | Code | Example requirements |
|---|---|---|---|
| SPE 1 | Organisational security measures | ORG | ISMS, background checks, roles and responsibilities, awareness training, supply chain security, physical access |
| SPE 2 | Configuration management | CM | Asset inventory baseline, network drawings, configuration settings, change control |
| SPE 3 | Network and communications security | NET | Segmentation from non-IACS zones, segmentation from safety systems, time distribution, wireless, remote access |
| SPE 4 | Component security | COMP | Hardening, dedicated portable media, malware protection, patch management |
| SPE 5 | Protection of data | DATA | Data classification, confidentiality, cryptography and key management, retention, integrity |
| SPE 6 | User access control | USER | Assigning and removing identities, least privilege, MFA, passwords, separation of duties |
| SPE 7 | Event and incident management | EVENT | Detection, reporting, logging, analysis, incident handling, vulnerability handling |
| SPE 8 | System integrity and availability | AVAIL | Continuity management, resource availability, backup and restore |
What stands out is how concrete the requirements are. SPE 3, for example, explicitly calls for network segmentation between the control system and the safety instrumented system, and SPE 5 has a separate requirement for the configuration mode of safety systems. SPE 6 covers the most ground, with nineteen USER 1 requirements ranging from shared passwords to screen locks.
📊 How do maturity levels and profiles work?
Rather than a simple “compliant” or “not compliant”, edition 2 assesses how mature the implementation of each requirement is. The series uses the same four levels as IEC 62443-2-4:
| Level | Name | What it means |
|---|---|---|
| ML1 | Initial | The requirement is met ad hoc, often relying on individual knowledge |
| ML2 | Managed | Documented procedures exist, but are not yet demonstrably applied everywhere |
| ML3 | Defined (practiced) | Procedures are applied repeatably and demonstrably across the organisation |
| ML4 | Improving | The organisation measures effectiveness and improves the procedures continually |
Maturity levels are not the same as security levels (SL 1 to 4). A security level says how well a zone or component technically resists an attacker; a maturity level says how well the process around it is organised. The standard also introduces profiles: selections of requirements, for example for a particular sector or type of installation. This means a water utility need not apply exactly the same set as a refinery.
🔧 How do you set up a security program in line with IEC 62443-2-1?
Annex B of the standard describes how to establish and maintain a security program. In practice, most asset owners follow these steps:
- Establish the mandate and roles - appoint an owner, for example a CISO for the whole, an Information Security Officer for policy and an OSO for day-to-day implementation on the plant floor. The standard prescribes no job titles, but it does require clear roles and responsibilities.
- Map your installation - build an asset inventory of hardware, software and network connections as part of your asset management, including drawings of zones and conduits.
- Assess the risk - carry out a cybersecurity risk assessment in line with IEC 62443-3-2 and embed the outcome in your risk management.
- Determine the applicable requirements - work through the eight SPEs, mark what does not apply and document compensating measures for legacy systems.
- Run a baseline assessment - score the current maturity level per requirement and choose a target. A pragmatic approach is to aim first for ML2 on every applicable requirement and ML3 on the most critical ones.
- Write policies and procedures - build on your existing security policy and Information Security Policy, for example for access management, patching and backups.
- Set requirements for suppliers - translate your program into contract requirements based on 2-4 for integrators and 4-2 for components, and so manage your supply chain risk.
- Monitor, review and improve - combine security monitoring, periodic audits and program reviews (requirement ORG 2.4) in a PDCA cycle, so that findings feed back as a feedback loop.
Typical pitfall: copying an IT procedure one to one. The standard itself points out that in an IACS, availability often outweighs confidentiality. An automatic restart after a patch or an overly strict account lockout can be more dangerous in a control room than the risk it is meant to address.
🔐 Which technical measures belong to the program?
Although 2-1 is a process standard, the program touches on many technical topics that are covered in more depth elsewhere in this knowledge base:
- Access - access control, user-based access control, RBAC and MFA, with a jump server as the controlled route for remote access.
- Network - network segmentation following the zones and conduits model, separating the office network, the process network and safety systems.
- Components - hardening, antivirus or application whitelisting, and a validated patch process.
- Detection and response - logging, a SIEM, incident management and a tested incident response plan.
- Recovery - backups that do not disrupt the process, are tested regularly and are kept on suitable media, as part of business continuity.
🏭 How does IEC 62443-2-1 relate to other standards and legislation?
| Framework | Relation to IEC 62443-2-1 |
|---|---|
| IEC 62443-1-1 | Provides the terminology and IACS model to which 2-1 refers normatively |
| IEC 62443-2-4 | Requirements for service providers; the asset owner uses 2-4 to contract integrators |
| IEC 62443-3-3 and IEC 62443-4-2 | Technical requirements for systems and components that support the SPEs |
| ISO 27001 | Overarching ISMS; 2-1 adds OT-specific requirements without duplication |
| NIST CSF | Annex A maps the 2-1 requirements to the functions of the framework |
| NIS2 and the Dutch Cybersecurity Act | Legal duty of care; 2-1 is a common way to demonstrate it for OT |
In the Netherlands, the Cyberbeveiligingswet (Cybersecurity Act), which implements NIS2, entered into force on 15 August 2026. The act does not prescribe IEC 62443, but it does require appropriate and proportionate measures, risk management and incident reporting. A security program in line with 2-1 helps you demonstrate that compliance for your OT environment. Since 2026, asset owners can also have their program assessed through the ACSSA scheme of ISASecure, announced in June 2025, which evaluates against 2-1 together with 2-4, 3-2 and 3-3.
❓ Frequently asked questions
Is IEC 62443-2-1 mandatory?
IEC 62443-2-1 is a voluntary standard, not a law. In practice, however, regulators, insurers and clients use the standard as a benchmark for good OT security, especially for organisations that fall under NIS2 or the Dutch Cybersecurity Act.
What is the difference between IEC 62443-2-1 and ISO 27001?
ISO 27001 is a management system for information security across the whole organisation, whereas IEC 62443-2-1 sets specific requirements for the security program of industrial automation and control systems. Since the 2024 edition, IEC 62443-2-1 is designed to work alongside an existing ISMS without duplicating management system requirements.
What does CSMS mean in IEC 62443-2-1?
CSMS stands for Cyber Security Management System, the core concept of the first edition of IEC 62443-2-1 from 2010. The 2024 edition speaks of a security program (SP) made up of eight security program elements, and leaves the generic management system requirements to the ISMS.
Who is IEC 62443-2-1 intended for?
IEC 62443-2-1 is intended for asset owners: the owners and operators of industrial installations such as factories, water utilities and grid operators. Integrators and product suppliers use other parts of the series, but they encounter IEC 62443-2-1 through the requirements that asset owners place on them.
Can an organisation be certified against IEC 62443-2-1?
Yes, ISASecure offers inspection and certification for asset owners through its ACSSA scheme, version 1.0 of which took effect in February 2026, assessing IEC 62443-2-1 together with parts 2-4, 3-2 and 3-3. An ACSSA certificate is valid for three years, subject to periodic surveillance. Many organisations also commission a gap analysis against IEC 62443-2-1 without seeking a formal certificate.
How does IEC 62443-2-1 deal with legacy systems?
IEC 62443-2-1 recognises that many installations remain in service for more than twenty years and that old software cannot always be patched or backed up. The standard then allows compensating security measures, such as additional segmentation or stricter access control, as long as they are documented in policies and procedures.
📌 In summary
IEC 62443-2-1 describes the security program with which an asset owner protects its industrial automation and control systems in operation, built from eight security program elements and assessed with maturity levels.
The 2024 edition replaced the old CSMS model with concrete, auditable requirements, aligns with ISO 27001 without duplication and allows compensating measures for legacy systems. It gives you a structured approach, demonstrable compliance, better availability of your processes and clear visibility of risks and responsibilities. Together with IEC 62443-3-2 for risk assessment and IEC 62443-2-4 for suppliers, it forms the basis for structurally embedding cybersecurity in your OT environment and in your wider industrial automation.