Fourteen documents carry the IEC 62443 name. An engineer who reads all of them still will not know which ones are theirs, and that is where most industrial cybersecurity programs stall. The technical content is readable. Working out which obligations land on your desk is the hard part.
IEC 62443 is a series of international standards for securing industrial control systems, written by the ISA99 committee of the International Society of Automation (ISA) with the International Electrotechnical Commission (IEC). Its organizing idea is that no single party can secure a plant floor alone, so requirements divide by role. What an asset owner owes differs from what an integrator owes, and both differ from what a device manufacturer owes.
Adoption is moving too. In July 2026 an industry coalition asked US policy makers to treat the standard as the national reference for operational technology (OT) security, arguing that sector-by-sector mandates keep rebuilding controls it already carries.
What IEC 62443 Is, and Why It Was Written
ISA formed the ISA99 committee in 2002 to write cybersecurity standards for industrial control systems. Around 2010 that work merged with IEC Technical Committee 65, and the two bodies have published jointly since.
The series sits on top of the ISO/IEC 27000 information-security standards, then reworks them around one difference. A breach of a business network costs data. A breach of an industrial automation and control system (IACS) can injure someone, release something, or stop a line. Safety and environmental harm sit inside the risk model from page one.
The second structural idea is shared responsibility, which ISA calls a founding principle of the standards. It is why asset owners, product suppliers, integrators and maintenance providers are addressed in separate documents. An IACS here also takes in the people and work processes around the control system, so the scope runs wider than an equipment list.
How the Series Is Organized
The documents fall into four groups, numbered in the second position of every part number. Read that digit and you know the altitude before opening the file.
| Group | What it covers | The parts you will actually open |
|---|---|---|
| 1 – General | Terminology, concepts and models used across the series | 62443-1-1, which also defines the seven foundational requirements |
| 2 – Policies and Procedures | Security programs, patch handling, evaluation of the program itself | 62443-2-1 for asset owners, 62443-2-4 for service providers, 62443-2-3 for patching |
| 3 – System | Risk assessment and the requirements that apply to a whole system | 62443-3-2 for risk assessment and system design, 62443-3-3 for system requirements and security levels |
| 4 – Component | How a product is built, and what the finished product has to do | 62443-4-1 for the development process, 62443-4-2 for component capability |
Edition years matter more here than in most standards work. The parts were written across two decades and revised on their own schedules, so in the ANSI/ISA editions 62443-2-1 was revised in 2024, 62443-3-2 dates from 2020, and 62443-3-3 still carries a 2013 edition. Check the edition before citing a clause in a specification.
Who IEC 62443 Applies To
Nobody is subject to the whole series. You answer to the parts written for the role you play, and that is often more than one role. A manufacturer who writes its own line-control software is an asset owner and a product supplier at once.
| Role | Who this is on a plant floor | Where your obligations live |
|---|---|---|
| Asset owner | The company operating the plant and carrying the risk | 62443-2-1 security program requirements, plus 62443-3-2 when you scope a system |
| Service provider | Integrators who build the solution, maintenance firms who keep it alive | 62443-2-4 security program requirements for service providers |
| Product supplier | Whoever manufactures the controller, switch, firewall or software | 62443-4-1 for how the product is developed, 62443-4-2 for what it can do |
That division of labor carries a commercial consequence teams miss. An asset owner cannot satisfy 62443-2-1 while buying equipment with no security capability behind it, so the requirement travels down the supply chain through procurement language. It is why 62443-4-2 line items now appear in bid packages written by plants that never intend to certify anything themselves.
The Four Ideas That Decide Your Architecture
Security Levels, and Why Yours Is Not One Number
Part 3-3 defines four security levels that tie the strength of your countermeasures to the strength of the adversary. SL 1 covers casual or accidental misuse. Move up and the assumed attacker sharpens, from simple means and low motivation at SL 2, to automation-specific knowledge and moderate resources at SL 3, to that same knowledge backed by extended resources at SL 4.
Almost every summary stops there and leaves out the useful part. A security level is a vector of seven values, one per foundational requirement, written like SL=(3,3,3,1,2,1,3). Where confidentiality carries little weight inside a zone, that element can drop to SL 1, or to SL 0 where no specific requirement applies, while identification and system integrity sit at SL 3. Two plants can both claim SL 3 while protecting entirely different things.
Zones and Conduits
Part 3-2 requires you to partition the system under consideration into zones and conduits. A zone groups assets that share a risk profile. A conduit carries communication between two zones and maps onto the logical network path between them. Each one then needs its own risk assessment and its own target security level.
That partition carries the largest engineering bill in the standard, because it decides where enforcement points sit and what has to be rewired. Our earlier analysis of IEC 62443 zones and conduits covers how microsegmentation keeps it maintainable without a VLAN rebuild every time a device moves.
The Seven Foundational Requirements
Every technical requirement in 62443-3-3 hangs off one of seven categories defined in 62443-1-1. Learn these and the rest of the series stops reading like a foreign language.
The seven foundational requirements
- FR 1 – Identification and authentication control. Know which human, process or device is asking.
- FR 2 – Use control. Once identified, limit what they may do.
- FR 3 – System integrity. Block unauthorized alteration of the system and its data.
- FR 4 – Data confidentiality. Keep information from readers who should not have it.
- FR 5 – Restricted data flow. Segment the network and control what crosses each boundary.
- FR 6 – Timely response to events. Notice a security event while it still matters.
- FR 7 – Resource availability. Keep the control system up and resistant to denial of service.
What Happens When the Equipment Cannot Comply
This provision makes the standard usable on a real plant floor. A requirement may be met by a compensating countermeasure where the equipment cannot support the technical feature, and IEC’s own commentary names legacy equipment as the case it has in mind.
So a brownfield site can reach a target security level without ripping out controllers that have fifteen good years left, provided the compensating control is documented and does the same job. Network-level enforcement usually carries that weight. A device incapable of defending itself can sit behind something that defends it.
How IEC 62443 Lines Up With NIST and NERC CIP
The question underneath most compliance meetings is whether these frameworks compete. They do not, and US federal OT guidance says so about as plainly as a standards document can.
| ISA/IEC 62443 | NIST SP 800-82r3 | NERC CIP | |
|---|---|---|---|
| What it is | Consensus standard | Federal guidance | Federal regulation |
| Binding | Only where a contract, regulator or procurement clause adopts it | Voluntary | Mandatory, with audits and civil penalties |
| Who it reaches | Any industry, by role | OT of every kind, including building and transport systems | Registered owners and operators of the bulk electric system |
| What it gives you | Technical requirements and a design method | Risk management structure and OT-specific practice | A defined obligation and an evidence burden |
NIST Special Publication 800-82 Revision 3, the September 2023 Guide to Operational Technology (OT) Security, thanks ISA in its acknowledgements “for allowing portions of the ISA-62443 Standards to be used in the document.” Its Risk Management Framework tables then map individual tasks to 62443 clauses alongside Cybersecurity Framework references. On patch management, the same document offers NIST SP 800-40 Revision 4, NERC CIP-007 and ISA 62443-2-3 as equivalent starting points.
For energy operators the relationship is practical. NERC CIP tells you what you are answerable for, and 62443 gives you a method for designing the system that satisfies it. Our breakdown of what NERC CIP-015-1 requires shows how closely that monitoring obligation tracks the zone and conduit thinking in part 3-2.
The overlap has become a policy argument. On 23 July 2026 the Operational Technology Cybersecurity Coalition published a position paper titled A Unified Approach to OT Cybersecurity, asking US policy makers to recognize the standard as the sector’s reference. It points at the Transportation Security Administration’s pipeline directives, at a double-reporting burden under NERC CIP, and at the overlapping European NIS2, CER and Cyber Resilience Act requirements. Precedent exists abroad. Standards Australia has adopted 62443 nationally, and Saudi Arabia and Singapore have anchored national OT frameworks to it.
Tatyana Bolton, the coalition’s executive director, framed the operational cost this way. “Every new mandate that duplicates existing controls pulls engineering resources away from actual threat mitigation and toward paperwork.”
What Certification Proves, and What It Does Not
Two conformity assessment routes exist. ISASecure, run by ISA, certifies against named parts through bodies accredited to ISO/IEC 17065, with separate schemes for components under 62443-4-2, systems under 62443-3-3, development practice under 62443-4-1, and whole sites. The IECEE runs a parallel scheme with its own certificates of conformity.
Read what each certificate actually says. A component certificate tells you a device is capable of meeting a set of requirements. It says nothing about how that device is configured in your plant, or about the network around it. Certification is procurement evidence rather than a security posture, and confusing the two is how a certified device ends up on a flat network with default credentials.
What This Means for Hardware and Network Choices
Read from the plant floor, three requirements do most of the work in equipment selection.
- Restricted data flow has to be enforced, never diagrammed. FR 5 turns a zone drawing into an obligation, and that takes a device permitting traffic only when a rule allows it.
- Boundary devices have to read industrial protocols. Modbus, DNP3 and EtherNet/IP carry no native authentication, so filtering on addresses and ports cannot separate a legitimate control command from a hostile one.
- Compensating controls need somewhere to live. Equipment that cannot defend itself has to be defended by the network around it.
Dynics builds toward those three points. ICS360.Defender, the company’s industrial security appliance, applies deep packet inspection to OT protocols, so a boundary decision rests on the content of a command instead of its port number. The OT SDN Controller handles enforcement, with switches passing no traffic unless an explicit rule permits it.
Both are designed and assembled in Ann Arbor, Michigan, on Buy American Act (BAA) compliant hardware, and both support environments that have to meet IEC 62443, NERC CIP and NIST expectations across energy sector operations and industrial manufacturing. Jeff Smith, who represents Dynics on OT cybersecurity at the S4 Conference and the Level Zero OT Cyber Security Conference, makes the argument the brownfield provision already makes. Security that stops production is not security.
Talk to a Dynics Engineer About IEC 62443
Get a direct read on how your OT network maps to IEC 62443 requirements, and where compensating controls can carry the equipment you are not replacing.
Frequently Asked Questions
What is IEC 62443?
A series of fourteen international standards and technical reports covering the cybersecurity of industrial control systems. ISA and IEC publish it jointly, in four groups covering general concepts, policies and procedures, system requirements, and component requirements.
Who does IEC 62443 apply to?
Three roles. Asset owners who operate the plant answer to 62443-2-1, while service providers, meaning integrators and maintenance firms, answer to 62443-2-4. Product suppliers carry two parts, 62443-4-1 for how they build a product and 62443-4-2 for what it can do. Plenty of organizations hold two of the three.
How do I achieve IEC 62443 compliance?
Identify your role and the parts that follow from it. Scope the system under consideration, partition it into zones and conduits under part 3-2, assess risk on each one, then assign target security levels. Parts 3-3 and 4-2 define what has to be true at each level. Where equipment cannot meet a requirement directly, document a compensating countermeasure and the reasoning behind it.
What is the difference between IEC 62443 and NIST CSF?
The NIST Cybersecurity Framework describes outcomes an organization should reach, across every sector and technology. IEC 62443 goes narrower and deeper. It supplies industrial-specific technical requirements, a risk assessment method and a role structure, and NIST SP 800-82 Revision 3 maps its own tasks onto 62443 clauses instead of replacing them.
What is the difference between IEC 62443 and ISO 27001?
ISO 27001 certifies an information security management system, and its risk model is built around information assets. IEC 62443 was written for systems whose failure has physical consequences. Safety and availability therefore outrank confidentiality, though the two remain complementary, since 62443 was developed on top of the ISO/IEC 27000 series.
Is IEC 62443 mandatory?
Not on its own. It becomes binding when a contract, a procurement specification or a national regulator adopts it, and several already have. The EU Cyber Resilience Act takes its technical baseline from 62443-4-1 and 62443-4-2.
What are IEC 62443 security levels?
Four levels defined in part 3-3, matched to the capability of the attacker rather than to a checklist. SL 1 addresses accidental misuse, SL 2 an attacker working with simple means, SL 3 one carrying automation-specific knowledge and moderate resources, and SL 4 that same attacker with extended resources behind them. Each level is recorded as a vector of seven values, one per foundational requirement.
Where to Start
Three questions get you further than reading the series front to back. Which role or roles do you hold, and therefore which parts are yours. Where do today’s zone boundaries fall. And which assets can meet a technical requirement directly, leaving the rest to compensating controls that somebody has to design, install and document. That last question is what turns a standard into a budget.
Sources
- ISA – ISA/IEC 62443 Series of Standards – part numbers, titles and ANSI/ISA edition years
- IEC SyC Smart Energy – IEC 62443 – foundational requirements, the security level vector, zones and conduits, compensating countermeasures
- NIST SP 800-82r3, Guide to Operational Technology (OT) Security – September 2023, including the Risk Management Framework mappings to IEC 62443
- ISASecure – Certification Schemes – which scheme certifies against which part
- Operational Technology Cybersecurity Coalition – A Unified Approach to OT Cybersecurity – 23 July 2026 position paper
