IEC/ISA 62443: OT Cybersecurity Standard Guide

IEC/ISA 62443 is the international reference standard for the cybersecurity of Industrial Automation and Control Systems (IACS). Where ISO 27001 governs corporate information security, IEC 62443 governs the world of PLCs, RTUs, HMIs, SCADA systems, and safety instrumented systems. It originated in the ISA99 committee and was adopted by the International Electrotechnical Commission through technical committee IEC TC65, which is why it carries the dual ISA/IEC 62443 name. Today it is the framework that integrators, component suppliers, and asset owners use to speak a common language when the goal is not protecting data but protecting a physical process.

This article walks through the anatomy of the standard: what it is and why it is the OT/IACS reference, the map of the parts family, the seven foundational requirements, security levels SL1 to SL4, the zones and conduits model, the certification schemes, and a realistic adoption roadmap. For the specific relationship between IEC 62443 and NIS2 we do not rebuild the mapping here; instead we point to the dedicated analysis of Industry 4.0 and OT cybersecurity under NIS2.

The essentials. IEC/ISA 62443 is not a single document but a family of standards organized into four groups: general, policies and procedures, system, and component. It defines seven foundational requirements (FR1 to FR7), four security levels (SL1 to SL4), and a segmentation model based on zones and conduits. It distinguishes three audiences (asset owner, integrator, and product supplier) and three certification types (product, process, and personnel). Adopting it is a phased project, not a box to tick.

What IEC 62443 Is and Why It Is the OT/IACS Reference

OT environments carry constraints that traditional IT security never anticipated: hardware lifecycles of 15 to 30 years, legacy industrial protocols with no native authentication, availability as the absolute priority, and a minimal tolerance for interruptions that turns patching into a risk operation. IEC 62443 was designed from that reality. Rather than imposing controls conceived for servers and workstations, it starts from the IACS concept, defines a risk model specific to the industrial process, and distributes responsibility across the whole value chain.

That distribution of responsibility is one of its key contributions. The security of an industrial facility does not depend on the operator alone: it also depends on how the supplier developed the PLC (secure development lifecycle) and how the integrator designed and deployed the solution. IEC 62443 formalizes those three roles and assigns each of them distinct parts of the standard, so an asset owner can contractually require components and services that meet verifiable requirements. This is why it has become the reference standard over more generic frameworks, and why regulators and auditors accept it as evidence of technical maturity in critical infrastructure sectors.

Map of the IEC 62443 Family

The numbering follows the 62443-X-Y pattern, where X identifies the group and Y the document within the group. These are the parts worth knowing:

• 62443-1-1 (concepts and models): establishes the terminology, concepts, and models underpinning the whole series. This is where foundational requirements, security levels, and the notion of zones and conduits are defined. It is the conceptual entry point.
• 62443-2-1 (IACS security program): aimed at the asset owner. It defines how to establish and maintain a cybersecurity management system for the IACS environment, the OT equivalent of an ISMS. Its recent revision brought it closer to the policy and control structure common in governance.
• 62443-2-4 (service providers): security program requirements for integrators and maintenance providers. It lets an asset owner assess and require security capabilities from whoever deploys or maintains the facility.
• 62443-3-2 (system risk assessment): defines the methodology to partition the system under consideration into zones and conduits, run the risk assessment, and assign a target security level to each zone. It is the heart of secure design.
• 62443-3-3 (system security requirements): translates the seven foundational requirements into concrete system requirements (SRs) and associates them with security levels SL1 to SL4. It is the technical reference on the integrated system side.
• 62443-4-1 (secure product development): secure development lifecycle requirements for component suppliers. It covers requirements management, secure design, vulnerability management, and product incident response.
• 62443-4-2 (component requirements): technical security requirements for individual components (embedded devices, host, software applications, and network components), also organized by the seven foundational requirements.

The general group also includes supporting documents such as glossaries and metrics, and the policies group covers aspects like patch management in the IACS environment. For most organizations, parts 2-1, 3-2, 3-3, and 4-2 concentrate the operational work. In connected manufacturing environments, this map intersects with the Purdue Model, as detailed in the analysis of critical IoT/OT threats in 2026.

The Seven Foundational Requirements (FR1-FR7)

The entire technical structure of IEC 62443 rests on seven foundational requirements that group the security capabilities expected of a system or component:

1. FR1 - Identification and Authentication Control (IAC): identify and authenticate all users, processes, and devices before granting access.
2. FR2 - Use Control (UC): enforce the assigned privileges once the entity is authenticated, including logging of actions.
3. FR3 - System Integrity (SI): ensure the integrity of the system and its information against unauthorized manipulation.
4. FR4 - Data Confidentiality (DC): protect the confidentiality of information in transit and at rest where appropriate.
5. FR5 - Restricted Data Flow (RDF): segment the system and control communication flows, the conceptual basis of zones and conduits.
6. FR6 - Timely Response to Events (TRE): detect, log, and respond to security incidents within an appropriate timeframe.
7. FR7 - Resource Availability (RA): ensure system availability against degradation or denial of service, the number one priority in OT.

These seven vectors recur in both 62443-3-3 (at the system level) and 62443-4-2 (at the component level), which allows security posture to be reasoned about consistently across the entire architecture.

Security Levels SL1-SL4 and Maturity Levels

IEC 62443 does not demand the same degree of protection everywhere. It defines four graduated security levels scaled to the capability of the adversary you want to defend against:

• SL1: protection against casual or coincidental violation.
• SL2: protection against intentional violation using simple means, low resources, generic skills, and low motivation.
• SL3: protection against intentional violation using sophisticated means, moderate resources, IACS-specific skills, and moderate motivation.
• SL4: protection against intentional violation using sophisticated means, extended resources, IACS-specific skills, and high motivation, the profile of a state actor.

The most important practical distinction is between the target level (SL-T) and the achieved level (SL-A). The SL-T is the protection a zone needs based on risk, and it is set in the 62443-3-2 assessment. The SL-A is the protection the system actually delivers once deployed. There is also the capability level (SL-C), which expresses what a component can offer when configured correctly. The gap between SL-T and SL-A is, quite literally, what an IEC 62443 gap assessment puts on the table. Each zone does not receive a single number but a vector of seven values, one per foundational requirement.

Alongside security levels, the standard uses maturity levels to evaluate processes, especially in 62443-2-4 and 4-1, on a CMMI-inspired scale: ML1 initial (ad hoc), ML2 managed (repeatable), ML3 defined (practiced and documented process), and ML4 improving (measured and continuously improved). SLs measure the protection the technology delivers; MLs measure the robustness of the process that sustains it.

Zones and Conduits Deep Dive

The zones and conduits model is the most recognizable architectural contribution of IEC 62443 and the materialization of requirement FR5. A zone groups assets that share the same security requirements; a conduit groups the authorized communications between zones and is where controls are concentrated: industrial firewalls, detection systems, data diodes, or reinforced authentication.

The 62443-3-2 process follows a clear sequence. First the system under consideration is defined. Then a high-level initial risk assessment is performed. Next the system is partitioned into zones and conduits, separating by criticality and function: the basic control zone is separated from the supervision zone, and safety instrumented systems are always isolated in their own zone because of their role as the last barrier against accidents. A detailed risk assessment is run over each zone and conduit to set the SL-T, and everything is documented in a cybersecurity requirements specification.

This scheme aligns naturally with the Purdue Model: levels translate into zones and the industrial DMZ becomes the mandatory conduit between the corporate and operational domains. The golden rule is that no IT/OT flow should cross non-adjacent levels without passing through that DMZ, where inspection, authentication, and logging live. Reinforcing those boundaries connects with hardening practices adapted to the industrial environment, of the kind used to defend converged networks under Zero Trust architecture.

Certification Schemes

IEC 62443 is certifiable, and its certifications fall into three categories that mirror the three audiences of the standard:

• Product certification: validates that a component or a system meets technical requirements. The best known scheme is ISASecure, run by the ISA Security Compliance Institute, which offers certifications such as CSA for components (based on 62443-4-2), SSA for systems (based on 62443-3-3), and dedicated schemes for IIoT devices. Bodies such as TÜV (Rheinland, SÜD, NORD) and other accredited labs offer equivalent schemes.
• Process certification: validates the robustness of a process against a part of the standard. A supplier certifies its secure development lifecycle with SDLA (based on 62443-4-1), an integrator or service provider certifies against 62443-2-4, and an asset owner can assess its program against 62443-2-1.
• Personnel certification: accredits the individual competence of professionals through recognized training programs and exams, offered by ISA, TÜV, and other organizations.

Certification is not mandatory for NIS2 compliance, but it provides objective evidence to auditors and clients, and it lets you push verifiable requirements down the supply chain. An asset owner can, for instance, require components with 62443-4-2 certification at the security level its zone demands.

A Practical Adoption Roadmap

Adopting IEC 62443 in an organization starting from low maturity is a phased journey, not a single deployment:

1. Governance and scope. Define the IACS scope, appoint an owner, and adopt the program structure of 62443-2-1.
2. Inventory and system under consideration. Discover every OT asset with passive discovery tools such as Claroty, Nozomi Networks, or Dragos, without injecting traffic that could disturb sensitive devices.
3. Zones, conduits, and risk. Apply 62443-3-2 to partition the system and run the risk assessment.
4. Target level per zone. Set the SL-T of each zone through the foundational requirements vector.
5. Gap assessment. Compare the actual state (SL-A) against the target using 62443-3-3 at the system level and 62443-4-2 at the component level.
6. Remediation. Segment, harden, secure vendor remote access with a jump host and MFA, deploy passive monitoring, and require components developed under 62443-4-1 during procurement.
7. Continuous improvement. Patch management in the IACS environment, process maturity uplift, periodic audits, and, where it adds commercial or regulatory value, certification.

The return on this approach is not only defensive. Building security in from design, rather than retrofitting it after deployment, materially reduces total cost of ownership and eases the conversation with authorities, a point that matters especially under the current framework of NIS2 compliance in Spain.

Frequently asked questions

What is the difference between ISA 62443 and IEC 62443?

They are the same standard. The series originated in the ISA99 committee of the International Society of Automation and was adopted by the International Electrotechnical Commission. That is why it is referenced interchangeably as ISA/IEC 62443, ANSI/ISA-62443, or IEC 62443, depending on the body publishing each document. The technical content is shared.

Is IEC 62443 mandatory?

The standard itself is not a law, but it is the technical reference framework that regulators and auditors expect to see in critical infrastructure and manufacturing sectors. NIS2 does not impose a specific framework, yet IEC 62443 has become the most solid way to demonstrate maturity. In some contracts and tenders, meeting specific parts of the standard is a contractual requirement.

How do security levels relate to zones?

Each zone receives a target security level (SL-T) set in the 62443-3-2 risk assessment. That target is not a single number but a vector with one value per foundational requirement. It is then compared with the achieved level (SL-A) delivered by the deployed system, and the difference defines the remediation plan.

Where should a plant that has never applied IEC 62443 start?

With asset inventory and definition of the system under consideration. Without knowing what is connected and how it communicates, it is impossible to partition into zones or assess risk. Passive discovery is the first technical step, followed by segmentation analysis and a gap assessment against 62443-3-3 and 4-2.

Does IEC 62443 replace ISO 27001?

No, they complement each other. ISO 27001 governs information security at the organizational level, while IEC 62443 provides the technical and process detail specific to IACS environments. Many industrial organizations run an ISO 27001 ISMS in IT and apply IEC 62443 in OT, aligning both frameworks.

Related Resources

• Industry 4.0 and OT cybersecurity: NIS2 protection for manufacturing
• IoT/OT cybersecurity: critical threats in 2026
• NIS2 Spain: compliance 2026
• NIS2 audit step by step

OT/ICS Audit and IEC 62443 Gap Assessment with Secra

Secra supports asset owners, integrators, and suppliers in adopting IEC 62443 with an OT-aware approach. We perform non-intrusive OT/ICS audits, definition of zones and conduits, assignment of target security levels, and an IEC 62443 gap assessment that quantifies the distance between each zone's SL-T and its real SL-A. We work with operational sensitivity, respecting the timing and constraints of the plant.

If your organization needs to map its posture against IEC 62443 before a regulator or an attacker does, explore our IoT/OT security audit or contact our team for a no-commitment initial conversation.