ISA/IEC 62443 Standards for Industrial Cybersecurity
If I had to boil ISA/IEC 62443 down to one point, it’s this: I use it to decide what to protect, where to place controls, and what to ask for when I buy or upgrade OT equipment.
This standard series covers industrial control systems from the top down: company security program, system design, device features, and supplier development process. In the U.S., I’m looking at ANSI/ISA-62443, and the parts that matter most usually map to three roles: asset owners, system integrators, and product suppliers.
Here’s the short version:
- 62443-2-1: how I set up and improve a security program
- 62443-2-4: what I expect from service providers and integrators
- 62443-3-3: what the system needs to do
- 62443-4-1: how suppliers build products
- 62443-4-2: what each device should support
A few ideas do most of the work:
- Zones group assets with similar security needs
- Conduits control traffic between those groups
- FR1–FR7 define the core security function areas
- SL1–SL4 set the target level of protection by risk
That matters because OT is not IT. In many plants, uptime and safety come first. And many industrial protocols still need extra controls at the network boundary. For example, Modbus often needs more conduit-level control, while OPC UA includes more built-in security functions.
I also use 62443 as a buying checklist. Before equipment lands on site, I want clear answers to four questions:
- Which zone will it go in?
- What Security Level does that zone need?
- Can the device support that target on its own?
- If not, can the system design make up for the gap?
Take a look at the ISA/IEC 62443 Series of Standards
sbb-itb-501186b
Quick comparison
| Part | Who I use it for | Main question it answers |
|---|---|---|
| 62443-2-1 | Asset owners | Do I have the right security program in place? |
| 62443-2-4 | Integrators/service providers | What should I require from outside providers? |
| 62443-3-3 | System teams | What controls must the IACS system meet? |
| 62443-4-1 | Product suppliers | Was the product built through a secure development process? |
| 62443-4-2 | Buyers/engineers | Does the device have the security features I need? |
One update stands out: ANSI/ISA-62443-2-1-2024 replaced the 2010 edition and adds a maturity model for program performance. So if I’m planning a project in 2026, I’m not just checking device features. I’m also checking whether my process, vendors, and network layout line up with the target zone and Security Level.
That’s the core idea of the article: use ISA/IEC 62443 as a plain, risk-based way to map systems, devices, and protocol paths to the controls they need.
How the ISA/IEC 62443 Series Is Organized
ISA/IEC 62443 Standards: Roles, Parts & Requirements at a Glance
Once you’ve identified the threats, the next move is to map IEC 62443 to the right scope, role, and requirement set. The series is split into four parts: General, Policies and Procedures, System, and Component. Each part narrows the focus, moving from broad concepts to device-level requirements. That structure makes it much easier to connect each requirement to the right job and the right part of the IACS.
The Four Groups and the Three Primary Roles
Three main roles show up across the series: asset owners, system integrators, and product suppliers. Asset owners run and maintain the IACS. System integrators design and deploy those systems by combining parts from multiple vendors. Product suppliers build the hardware and software that the system depends on.
Each role lines up with different parts of IEC 62443 and different duties.
| Role | Primary Focus | Key Standards |
|---|---|---|
| Asset Owner | Security program, operations, and protocol security | IEC 62443-2-1, IEC 62443-3-3 |
| System Integrator | Secure integration, service delivery, and segmentation | IEC 62443-2-4, IEC 62443-3-3 |
| Product Supplier | Secure product development and device capabilities | IEC 62443-4-1, IEC 62443-4-2 |
IEC 62443 treats security as a risk-based tradeoff, including safety and environmental consequences.
Key Parts to Know First
IEC 62443-1-1 is the starting point. It defines the terms, concepts, and models used across the full series.
IEC 62443-2-1 is the main standard for asset owners. It covers how to set up, put in place, and improve an organization-wide security program. ANSI/ISA-62443-2-1-2024 replaced the 2010 edition and adds a maturity model for security-program performance. IEC 62443-2-4 works alongside it by setting requirements for IACS service providers, including system integrators and maintenance providers.
At the system level, IEC 62443-3-3 lays out the technical security requirements for the IACS as a whole and ties them straight to Security Levels. At the component level, IEC 62443-4-1 covers the secure development lifecycle for manufacturers, while IEC 62443-4-2 spells out the technical security capabilities required for individual devices such as PLCs, switches, and sensors. Together, those two standards connect device capabilities to the system-level goals defined in 3-3.
With that structure clear, the next step is applying its core security concepts to OT network design.
Core Security Concepts: Zones, Conduits, Foundational Requirements, and Security Levels
Zones, conduits, foundational requirements, and security levels are the ideas that make ISA/IEC 62443 usable in day-to-day OT design. The model starts by grouping OT assets, then it maps the right level of protection to each group.
Zones and Conduits in Industrial Network Design
A zone is a group of assets with similar security needs. In plain terms, zones split OT assets into groups based on shared security needs, while conduits control the protocol traffic that moves between those groups.
A conduit is the controlled communication path between zones. It sets the rules for how traffic crosses a boundary and which controls apply there. That matters in mixed-vendor OT environments, where systems often need to work together without relying on one vendor’s stack.
Once zones and conduits are defined, the next step is to assign the right security level to each one.
FR1 to FR7 and SL1 to SL4
The seven Foundational Requirements (FRs) define the core security functions.
Security Levels (SLs) define the target strength of protection for each zone. They tie controls to risk and impact. Put simply, security levels help determine how much control a zone needs based on what happens if that zone fails. Higher target security levels call for stronger controls.
Apply protection in proportion to each zone’s risk.
Those targets then drive the system-level and device-level requirements in the next stage of implementation.
Defense in Depth and Least Privilege for OT
Defense in depth means using multiple layers of protection so one failure does not expose the entire system. In OT, layered segmentation and access control help stop a weak protocol connection from turning into a path across the whole system. In ISA/IEC 62443, this approach is supported by dividing the environment into zones and conduits and applying controls at each boundary.
Least privilege means giving users, devices, and processes only the access they need to do their jobs.
Because 62443 is vendor-neutral, these controls can support secure interoperability across industrial protocols. That is why 62443 can be applied to protocols, devices, and system boundaries without depending on one vendor stack.
Applying ISA/IEC 62443 to Systems, Devices, and Industrial Protocols
The ideas from the previous section - zones, conduits, foundational requirements, and security levels - start to matter when you map them to actual equipment and actual networks. IEC 62443-3-3 and IEC 62443-4-2 handle that step. One deals with system-level expectations. The other focuses on what each component needs to support. Start with the system, then check whether each device can back up the controls that system requires.
IEC 62443-3-3 at the System Level
IEC 62443-3-3 sets system-level controls based on security goals for an IACS environment. Asset owners can pick technologies that fit the plant without changing the required security outcome. Those controls should be applied at each zone boundary and conduit.
In plain terms, that means shaping controls around how each zone and conduit is actually used. Remote access, OT-to-enterprise connections, and other critical communication paths need protection that fits their risk. The tools can vary by architecture, but the target stays the same.
That system view only holds up if the components can support it.
IEC 62443-4-2 for Components and Device Capabilities
While 62443-3-3 looks at the system, IEC 62443-4-2 looks at the security capabilities built into individual components and devices. That makes it useful when reviewing PLCs, HMIs, gateways, sensors, and other industrial equipment for new builds or upgrades.
The main question for buyers and engineers is simple: what security functions must the device provide, and what must the system boundary handle instead? A device with stronger built-in functions is easier to place in a protected OT design. Older devices can still remain in service when segmentation, access control, and other zone- and conduit-level controls make up for missing device features.
The next step is to see how those capabilities perform across the actual protocol paths between devices.
Protocol and Interoperability Considerations
ISA/IEC 62443 applies across legacy and modern protocols. The key is to match security controls to the protocol in use, because not every protocol comes with the same built-in protections. Interoperability only helps if the protocol path can be controlled at the boundary.
For example, Modbus has limited built-in security, so more of the protection has to happen at the conduit level through segmentation and tightly controlled access paths. OPC UA, on the other hand, includes built-in security features that teams can use directly. Remote access needs the same level of discipline. Any maintenance path that reaches OT assets should be treated as a controlled conduit, with protections that fit the risk.
That risk-based approach shapes how teams deal with legacy protocols, interoperability, and where controls should sit. Use those requirements as a checklist when buying, upgrading, and integrating equipment.
Using ISA/IEC 62443 in Equipment Selection, Upgrades, and Project Planning
What to Check When Buying or Upgrading Equipment
Once system requirements are set, use them to screen purchases and upgrades. If you're reviewing a PLC, HMI, drive, gateway, switch, or similar device for an IACS setting, check whether it supports the technical capabilities listed in IEC 62443-4-2:
- Identification and authentication control
- Use control
- System integrity
- Resource availability
For older equipment, the big issue is simple: can the full architecture still meet the target Security Level for that zone? If yes, document that call. If not, the upgrade may need more than a device swap.
Use ANSI/ISA-62443-2-1 to judge how well the equipment fits your security program and maturity targets. When you talk with vendors, ask for documentation that maps to the program elements and maturity levels. That tells you a lot more about long-term fit than a basic feature list.
Match the Security Level to the zone's risk.
Where Electrical Equipment Sourcing Fits Into Cybersecurity Planning
Procurement is where 62443 stops being a design document and turns into a buying rule. For U.S. teams sourcing breakers, transformers, switchgear, and related hardware through Electrical Trader, ISA/IEC 62443 should be treated as a procurement requirement, not a nice-to-have.
Before a component ships to the site, the team should already know where it will go, which zone it belongs to, what Security Level that zone requires, and whether the device fits that placement. That's the difference between a clean rollout and a last-minute scramble.
Used equipment needs extra review before it enters a segmented OT network.
Conclusion: Key ISA/IEC 62443 Points for OT Projects
At that stage, the standard moves from specification to project execution. ISA/IEC 62443 gives U.S. industrial teams a structured, risk-based framework that covers every layer, from the organization down to individual components, through zones, conduits, Foundational Requirements (FR1–FR7), Security Levels (SL 1–SL 4), IEC 62443-3-3, and IEC 62443-4-2.
The goal is straightforward: buy and integrate equipment that fits the zone, conduit, and Security Level it must support.
FAQs
How do I choose the right Security Level for a zone?
Start with a risk assessment under ISA/IEC 62443-3-2. First, identify your critical assets and group them into functional zones. Then assess risk across four areas:
- personnel safety
- financial loss
- business interruption
- environmental impact
Use the estimated impact and likelihood of threats to rank those zones by priority. From there, choose a Security Level from SL 0 to SL 4 that matches how your operation works and what it needs to protect.
Can legacy OT devices still fit a 62443-based design?
Yes. Legacy operational technology devices can fit a 62443-based design through compensating network-level controls.
Many older devices don't have built-in encryption or authentication. So the fix usually happens around them, not inside them. That means placing them in secure zones and protecting access with firewalls or VPNs.
You can also use tactics like virtual patching to shield aging hardware without reboots or risky software updates.
Which 62443 parts matter most when buying equipment?
Focus on equipment that lines up with:
- ISA/IEC 62443-4-1 for secure product development
- ISA/IEC 62443-3-2 for system integration and zone/conduit segmentation
- ISA/IEC 62443-3-3 for technical security requirements and protection levels
Taken together, these standards help show that the equipment can support a secure, resilient operational environment.
