What Is ISA/IEC 62443?
ISA/IEC 62443 is a series of standards, technical specifications, and technical reports that define how to secure industrial automation and control systems (IACS) against cyber threats. It is developed by the ISA99 committee of the International Society of Automation (ISA) and published jointly with the International Electrotechnical Commission (IEC), which is why it appears as both ISA-62443 and IEC 62443.
In IEC 62443, an IACS includes not only control hardware and software, such as PLCs, distributed control systems, SCADA, HMIs, and safety systems, but also the people, policies, and procedures that operate and maintain them. "Security" means preventing unauthorized access, unwanted interference (intentional or not), and the disclosure of confidential information, so that the system keeps operating safely and reliably.
The overall objective is to reduce the risk that cyber incidents compromise the safety, availability, and integrity of industrial operations. Three features set IEC 62443 apart from general IT security frameworks:
- It is written for OT. Requirements account for availability, safety, real-time performance, and long-lived legacy equipment.
- It assigns responsibilities by role. Asset owners, service providers, and product suppliers each have their own requirements.
- It is measurable. Security levels (SL 1–4) and maturity levels make requirements testable and certifiable.
The series is also written "ISA 62443" or "IEC62443", and sometimes, incorrectly, "ISO 62443". It is not an ISO standard, although organizations often use it alongside ISO/IEC 27001. The ISA99 committee began publishing guidance in the mid-2000s, and the series' foundational concepts document (62443-1-1) was first published in 2007. In 2021, the IEC designated the series a horizontal standard, meaning it applies across every industry sector that uses IACS rather than to a single industry.
Why Is IEC 62443 Important for OT Cybersecurity?
IEC 62443 is important because it is the principal international standard written specifically for industrial control systems, where availability and safety come before confidentiality. It gives asset owners, integrators, and suppliers a shared, measurable way to define, build, and verify OT security, and it is increasingly referenced in regulation and procurement.
As OT environments connect to enterprise networks, remote access, IIoT devices, and the cloud through IT/OT convergence, cyber incidents can directly affect production, equipment, and safety. IEC 62443 matters for five reasons:
- It addresses OT's real constraints. General IT frameworks assume systems can be patched, rebooted, and scanned freely. IEC 62443 is built around continuous operation, legacy equipment, and safety.
- It creates a common language across the supply chain. Zones and conduits, security levels, and foundational requirements let an asset owner specify what it needs, an integrator design to it, and a supplier certify a product against it.
- It is risk-based. Effort is proportional to risk: a safety-critical zone gets stronger controls than an office printer network.
- It is verifiable. Products and development processes can be independently certified, for example under ISASecure or the IECEE CB Scheme, which gives buyers evidence rather than marketing claims.
- Regulation increasingly points to it. In the EU, the Cyber Resilience Act's reporting obligations for manufacturers have applied since September 11, 2026, and its full requirements apply from December 11, 2027; European harmonized versions of IEC 62443 parts are being developed to support conformity. Many organizations also use IEC 62443 as the technical reference for the risk-management measures required by NIS2.
For manufacturers preparing for the new EU rules, see our guide to the Cyber Resilience Act for manufacturers.
ISA/IEC 62443 Industrial Cybersecurity Standards: An Overview of the Series
The ISA/IEC 62443 series is organized into four main groups: General, Policies and Procedures, System, and Component. A newer fifth group covers evaluation methodology. Each document is one of the following types:
- International Standard (IS): normative requirements that can be assessed and certified.
- Technical Specification (TS) or Publicly Available Specification (PAS): requirements or methods that are still maturing toward a full standard.
- Technical Report (TR): informative guidance.
About a dozen documents have been published, and several more are in development. ISA and IEC sometimes publish the same part in different years, so one document can carry two designations, for example ANSI/ISA-62443-4-2-2018 and IEC 62443-4-2:2019.
1. General (IEC 62443-1-x)
This group explains the concepts, terminology, and models used across the series.
| Document | Title | Type and current edition |
|---|---|---|
| 62443-1-1 | Terminology, concepts and models | IEC TS 62443-1-1:2009 (first published by ISA in 2007) |
| 62443-1-2 | Master glossary of terms and abbreviations | In development |
| 62443-1-3 | System security conformance metrics | In development |
| 62443-1-4 | IACS security lifecycle and use cases | In development |
| 62443-1-5 | Scheme for IEC 62443 security profiles | IEC TS 62443-1-5:2023 |
2. Policies and Procedures (IEC 62443-2-x)
This group covers the security program: the policies, procedures, and organizational requirements for operating and servicing IACS securely.
| Document | Title | Type and current edition |
|---|---|---|
| 62443-2-1 | Security program requirements for IACS asset owners | IEC 62443-2-1:2024 (Edition 2); ANSI/ISA-62443-2-1-2024 |
| 62443-2-2 | IACS security protection scheme | IEC PAS 62443-2-2:2025; ISA-TR62443-2-2-2025 |
| 62443-2-3 | Patch management in the IACS environment | IEC TR 62443-2-3:2015 |
| 62443-2-4 | Security program requirements for IACS service providers | IEC 62443-2-4:2023 (Edition 2) |
3. System (IEC 62443-3-x)
This group defines security requirements and risk assessment for the control system as a whole.
| Document | Title | Type and current edition |
|---|---|---|
| 62443-3-1 | Security technologies for IACS | IEC TR 62443-3-1:2009 |
| 62443-3-2 | Security risk assessment for system design | IEC 62443-3-2:2020 |
| 62443-3-3 | System security requirements and security levels | IEC 62443-3-3:2013 |
Component (IEC 62443-4-x)
This group sets requirements for the suppliers that develop IACS products.
| Document | Title | Type and current edition |
|---|---|---|
| 62443-4-1 | Secure product development lifecycle requirements | IEC 62443-4-1:2018 |
| 62443-4-2 | Technical security requirements for IACS components | IEC 62443-4-2:2019 |
IEC 62443-4-2 applies to four component types: software applications, embedded devices, host devices, and network devices.
5. Evaluation (IEC 62443-6-x)
| Document | Title | Type and current edition |
|---|---|---|
| 62443-6-1 | Security evaluation methodology for IEC 62443-2-4 | IEC TS 62443-6-1:2024 |
Which IEC 62443 Parts Apply to You?
Most organizations do not need every document. The parts that matter depend on your role:
| Role | Who it is | Primary parts | What you demonstrate |
|---|---|---|---|
| Asset owner | The organization that owns and operates the industrial system, such as a manufacturer or utility | 2-1, 3-2, 3-3 (2-3 for patching) | A security program, a risk assessment, and target security levels for each zone |
| Service provider | System integrators and maintenance service providers | 2-4, 3-2, 3-3 | Secure integration and maintenance practices |
| Product supplier | Manufacturers of control systems and components | 4-1, 4-2, 3-3 | A secure development lifecycle and product security capabilities |
Industries That Use IEC 62443
Because it is a horizontal standard, IEC 62443 applies to any industry that uses IACS, whether a business operates in energy, water treatment, manufacturing, or any other field. Common adopters include:
- Oil and gas
- Renewables and green energy
- Energy and utilities, including power generation, transmission, and water and wastewater treatment
- Manufacturing, including semiconductor and automotive production
- Electrical and electronic equipment
- Transportation, building automation, and medical devices
Key Protection Principles of the IEC 62443 OT Security Standard
IEC 62443 runs to hundreds of pages across its parts, but six principles recur throughout the series and form the foundation of any implementation.
1. Establish Zones and Conduits
A zone is a group of physical or logical assets that share common security requirements. A conduit is a group of communication channels that connects two or more zones and shares common security requirements. Every IACS asset must belong to a zone, and all communication between zones must pass through a defined conduit.
Zones and conduits put network segmentation on a risk-based footing. Many organizations draw their first zones along the levels of the Purdue model (enterprise, site operations, supervisory control, basic control), but IEC 62443 does not require this. Zones are defined by the shared security requirements identified in the risk assessment. A safety instrumented system, for example, usually gets its own zone even when it sits at the same Purdue level as the control system it protects.
2. Implement Defense-in-Depth
A single countermeasure or technology is rarely enough to meet cybersecurity objectives. IEC 62443 applies defense-in-depth: multiple layers of countermeasures, so that if one fails, another still protects the system. For example, intrusion detection systems can detect attacks that get past firewalls, and network isolation can stop malware from spreading.
3. Apply Risk Assessment (IEC 62443-3-2)
Risk analysis based on likelihood and consequence has long been used to manage risks to production infrastructure, people, and the environment. IEC 62443-3-2 extends it to cybersecurity with a method for assessing IACS cyber risk that also drives the division of the system into zones and conduits. It sets out seven zone and conduit requirements (ZCRs):
- Identify the system under consideration (SuC), including its boundary and access points.
- Perform an initial cybersecurity risk assessment.
- Partition the system into zones and conduits.
- Compare the initial risk with the organization's tolerable risk.
- Perform a detailed risk assessment for zones and conduits whose risk is not tolerable, and set target security levels.
- Document the cybersecurity requirements, assumptions, and constraints.
- Obtain asset owner approval.
4. Apply the Principle of Least Privilege
Users, whether people, software, or devices, receive only the permissions they need to perform their tasks. Least privilege prevents unnecessary access to data and functions, and it blocks or slows an attacker who has compromised an account.
5. Meet the Seven Foundational Requirements (FRs)
ISA/IEC 62443-3-3 (for systems) and IEC 62443-4-2 (for components) organize technical security requirements under seven foundational requirements:
| FR | Name | What it requires |
|---|---|---|
| FR1 | Identification and Authentication Control (IAC) | Identify and authenticate all users (people, software processes, and devices) before allowing access |
| FR2 | Use Control (UC) | Enforce the privileges assigned to authenticated users and monitor their use |
| FR3 | System Integrity (SI) | Protect the integrity of the IACS against unauthorized manipulation, including malicious code |
| FR4 | Data Confidentiality (DC) | Protect the confidentiality of information on communication channels and in data repositories, for example through encryption |
| FR5 | Restricted Data Flow (RDF) | Segment the control system through zones and conduits to limit unnecessary data flow |
| FR6 | Timely Response to Events (TRE) | Respond to security violations by notifying the proper authority, reporting the evidence, and taking timely corrective action |
| FR7 | Resource Availability (RA) | Ensure the availability of the control system against degradation or denial of essential services |
Each FR is broken down into system requirements (SRs) in IEC 62443-3-3 and component requirements (CRs) in IEC 62443-4-2, with requirement enhancements that apply at higher security levels.
6. Define Target Security Levels (SL 1–4)
Security levels express how capable an attacker a zone, conduit, or component is designed to resist. IEC 62443 defines four:
| Security level | Protects against |
|---|---|
| SL 1 | Casual or coincidental violation, such as accidental misuse |
| SL 2 | Intentional violation using simple means, with low resources, generic skills, and low motivation |
| SL 3 | Intentional violation using sophisticated means, with moderate resources, IACS-specific skills, and moderate motivation |
| SL 4 | Intentional violation using sophisticated means, with extended resources, IACS-specific skills, and high motivation |
Security levels are used in three ways. The target security level (SL-T) is set for each zone and conduit during risk assessment. The capability security level (SL-C) is what a product or system can achieve when properly configured. The achieved security level (SL-A) is what is actually in place. Implementation is the work of closing the gap between SL-A and SL-T.
The Challenges of Implementing ISA/IEC 62443
Challenge 1: Securing Management Support
The first hurdle in implementing ISA/IEC 62443 is making the business case clearly enough to gain management support.
To secure that support, organizations need to understand which systems, subsystems, and product components are critical to OT/ICS operations and security. Without that understanding, it is difficult to explain the potential consequences of cyber threats to management, or to answer questions such as:
- What are the potential threats?
- What could be the impact on the business?
- What losses could result from an attack?
- What would compensating cybersecurity measures cost?
Without answers to these questions, it is hard to win management's participation and commitment, and without management support, IEC 62443 implementations rarely succeed.
Challenge 2: The Specificity of the OT Domain
In OT, availability comes first, and many systems are fragile. Applying security requirements without regard for operations can itself cause downtime, so organizations must balance availability against security and choose solutions designed for OT. Three situations are especially common:
- OT systems run on outdated equipment. Many older OT/ICS endpoints perform critical operations on production lines but run unsupported operating systems or applications, so new vulnerabilities cannot be fixed. Because these systems must stay operational, owners often choose not to patch at all. Compensating controls such as application lockdown and virtual patching are needed instead.
- IT tools need connectivity that OT does not have. Many security products depend on internet access for updates and management, which does not fit isolated manufacturing networks. A common example: how do you update antivirus engines and malware patterns in an offline environment?
- Original equipment may not allow software installation. OEM restrictions and warranty terms often prohibit installing third-party software, which makes on-device threat detection and incident response difficult.
These constraints call for solutions that fit real OT conditions, and for security vendors that can support both security improvement and compliance.
Challenge 3: Visibility Alone Is Not Protection
Knowing what needs protection (asset discovery) and what risks exist (vulnerabilities and threats) is the starting point of any IT or OT security program. Many OT visibility solutions have emerged as a result, but visibility alone does not meet the standard's requirements.
IEC 62443 also expects organizations to prevent, detect, contain, and recover from incidents. That requires fingerprinting devices and segmenting them according to data flow, location, criticality, trust level, ownership, or other business logic, while making sure that segmentation does not interfere with daily operations, safety, or response capabilities.
Organizations should therefore integrate endpoint and network defenses to achieve true defense-in-depth: OT micro-segmentation that extends visibility across all assets, a zero trust approach that verifies every identity and device, default-deny (allow-list) policies, least privilege, and continuous monitoring with real-time response.
IEC 62443 Compliance Checklist: What Should Organizations Prepare?
To prepare for IEC 62443, an asset owner should secure management sponsorship, build a complete asset inventory, define zones and conduits, assess risk and set target security levels, run a gap analysis against IEC 62443-3-3, implement controls in phases, and sustain the program through patch management, supplier requirements, incident response, and continuous monitoring.
A note on terminology: there is no single "IEC 62443 certificate" for an entire organization. Conformance is demonstrated part by part and role by role. Product suppliers certify development processes against 4-1 and products against 4-2 or 3-3; service providers can be assessed against 2-4; and asset owners usually demonstrate conformance with 2-1, 3-2, and 3-3 through internal or third-party assessments and documented evidence.
| # | Step | What to prepare | IEC 62443 reference | Evidence |
|---|---|---|---|---|
| 1 | Secure sponsorship and define scope | Business case, executive sponsor, program owner, and the scope of the system under consideration | 2-1; 3-2 (ZCR 1) | Approved charter and scope statement |
| 2 | Build an asset inventory | Every IACS asset, including standalone and air-gapped systems: hardware, OS, firmware, software, and network connections | 2-1; 3-2 | Current asset register |
| 3 | Map data flows and define zones and conduits | Network diagrams, a communication matrix, and the zone and conduit model | 3-2 (ZCR 3) | Zone and conduit diagram |
| 4 | Assess risk and set target security levels | Threat scenarios, consequences, tolerable risk, and an SL-T for each zone and conduit | 3-2 (ZCR 2, 4, 5) | Risk register and SL-T assignments |
| 5 | Run a gap analysis | Compare current controls with the 3-3 system requirements for each SL-T | 3-3 | Gap report and estimated SL-A |
| 6 | Implement controls in phases | Segmentation, access control, endpoint hardening, malware protection, and monitoring, with compensating controls for legacy systems | 3-3; 4-2 | Implementation plan and records |
| 7 | Manage patches and vulnerabilities | A patch evaluation process, with virtual patching where patches cannot be applied | 2-3; 2-1 | Patch and exception records |
| 8 | Set supplier and integrator requirements | Require 4-1/4-2 certified products and 2-4 aligned service providers in procurement | 2-4; 4-1; 4-2 | Procurement requirements and supplier evidence |
| 9 | Prepare incident response and recovery | An incident response plan, backups of control logic and configurations, and joint IT/OT exercises | 2-1; 3-3 (FR6, FR7) | Tested plans and exercise reports |
| 10 | Monitor, review, and improve | Continuous monitoring, periodic reassessment, and management review | 2-1 | Audit records and program metrics |
Use a phased approach. Start with the zones whose risk most exceeds tolerance, typically safety systems, conduits that reach the internet or IT networks, and legacy assets that cannot be patched, then expand according to available resources rather than trying to meet every requirement at once.
How TXOne Networks Supports ISA/IEC 62443 Implementation
The ISA/IEC 62443 series provides a framework for implementing industrial cybersecurity best practices step by step and improving continuously. This applies to control systems in manufacturing, process plants, utilities (electricity, gas, and water), and pipeline and oil production and distribution facilities. The requirements can seem daunting, but business leaders can turn them into a clear roadmap. Start with a risk analysis that shows the gap between the organization's current state and the standard, identify weak or non-compliant areas, and address them through process changes, new technologies, and employee training, phased to the resources available.
TXOne Networks' own secure development lifecycle is certified to IEC 62443-4-1 by SGS (April 2026), so the products protecting your environment are built under the same standard you are implementing. Read about TXOne's IEC 62443-4-1 certification.
IEC 62443-3-3 describes the security functions an OT/ICS system should implement. TXOne's OT zero trust solutions help organizations meet those requirements across endpoints, networks, and inspection workflows while keeping operations available:
| TXOne solution | What it does | Foundational requirements supported |
|---|---|---|
| Portable Inspector | Installation-free malware scanning from a USB port for Windows and Linux systems, including legacy and air-gapped assets. Collects asset information with every scan; the Pro model adds AES-256 hardware-encrypted storage for safe file transfer | FR3 System Integrity; supports the asset inventory needed for risk assessment (3-2) |
| Stellar Protect and StellarOne | Prevention-first endpoint protection for Windows 2000 through Windows 11: application lockdown, operation lockdown, USB device control, and CPSDR behavioral anomaly detection, managed from one console | FR2 Use Control, FR3 System Integrity, FR6 Timely Response to Events |
| EdgeIPS and EdgeFire | OT-native intrusion prevention and next-generation firewalling that enforce zones and conduits, with deep inspection of 180+ industrial protocols, AI-assisted allow-list policies, virtual patching, and fail-safe hardware bypass | FR5 Restricted Data Flow, FR3 System Integrity, FR6 Timely Response to Events, FR7 Resource Availability |
| SenninOne | Unified governance across Edge, Stellar, and Element: asset-centric threat detection, VSAR vulnerability scoring, approval workflows, and SIEM integration | FR6 Timely Response to Events; supports the program management and evidence requirements of 2-1 |
Mappings are indicative. Actual conformance depends on configuration and on the target security level of each zone.
For more depth, download the white paper Securing Digital Manufacturing: The Essence of ISA/IEC 62443 Implementation. TXOne Networks' OT/ICS security experts and technologies help maintain the availability, stability, and security of critical infrastructure and manufacturing, and our solutions help organizations meet ISA/IEC 62443 requirements in step with their cybersecurity roadmap. Explore TXOne's ISA/IEC 62443 compliance solutions.
ISA/IEC 62443 FAQs
What is IEC 62443?
IEC 62443, also published as ISA/IEC 62443, is a series of international standards for securing industrial automation and control systems (IACS) in OT environments such as manufacturing plants, energy facilities, utilities, and transportation systems. It defines requirements for asset owners, service providers, and product suppliers, using concepts such as zones and conduits, seven foundational requirements, and security levels. It is not an ISO standard, although it is sometimes called "ISO 62443."
Why is IEC 62443 important for OT cybersecurity?
IEC 62443 is important because it is the principal international standard written specifically for industrial control systems, where availability and safety come before confidentiality. As OT connects to IT networks, remote access, and the cloud, cyber incidents can cause downtime, equipment damage, or safety hazards. IEC 62443 gives organizations a risk-based, measurable way to secure these systems, and it is widely used to support compliance with regulations such as NIS2 and the EU Cyber Resilience Act.
What industries use the IEC 62443 industrial cybersecurity standard?
IEC 62443 is a horizontal standard, so it applies to any industry that uses industrial automation and control systems. Common adopters include manufacturing, semiconductors, oil and gas, energy and power, renewables, water and wastewater utilities, transportation, building automation, and manufacturers of medical devices and electrical equipment. These industries depend on OT systems where availability and safety are top priorities.
What are zones and conduits in IEC 62443?
A zone is a group of physical or logical assets that share common security requirements, such as the controllers on one production line or a safety system. A conduit is a group of communication channels connecting two or more zones. Every asset belongs to a zone, and all traffic between zones passes through a defined conduit, so organizations can limit unnecessary communication, contain threats, and apply controls in proportion to each zone's risk.
What are the IEC 62443 security levels?
IEC 62443 defines four security levels. SL 1 protects against casual or coincidental violation. SL 2 protects against intentional attacks using simple means and low resources. SL 3 protects against sophisticated attacks with moderate resources and IACS-specific skills. SL 4 protects against sophisticated attacks with extended resources and high motivation. Organizations set a target security level (SL-T) for each zone and conduit based on risk.
What are the 7 foundational requirements of IEC 62443?
The seven foundational requirements are FR1 Identification and Authentication Control, FR2 Use Control, FR3 System Integrity, FR4 Data Confidentiality, FR5 Restricted Data Flow, FR6 Timely Response to Events, and FR7 Resource Availability. IEC 62443-3-3 breaks them down into system requirements and IEC 62443-4-2 into component requirements, with stricter requirement enhancements at higher security levels.
What is the difference between IEC 62443-4-1 and IEC 62443-4-2?
IEC 62443-4-1 covers the process: it sets secure product development lifecycle requirements for suppliers, such as threat modeling, secure coding, security testing, and vulnerability handling. IEC 62443-4-2 covers the product: it sets the technical security capabilities an IACS component must have, such as authentication, integrity protection, and audit logging. Under the ISASecure scheme, a supplier needs SDLA certification (4-1) before it can obtain CSA product certification (4-2).
Is IEC 62443 certification mandatory?
No. IEC 62443 is a voluntary international standard, so certification is not mandatory in itself. It becomes a requirement in practice when customers, sector regulators, or contracts specify it, which is increasingly common in critical infrastructure and industrial equipment procurement. Products and development processes can be certified through schemes such as ISASecure and the IECEE CB Scheme, while asset owners usually demonstrate conformance through assessments and documented evidence.
How can organizations start implementing IEC 62443?
Start by understanding your current OT environment: build an asset inventory, map communication paths, and define zones and conduits. Then assess risk, set target security levels, and run a gap analysis against the requirements of IEC 62443-3-3. Implement controls in phases, beginning with the most critical systems, and require suppliers and integrators to meet IEC 62443-4-1, 4-2, and 2-4 in procurement.
Tags
