IEC 62443 for OT Security Leaders on Zones, Conduits and Security Levels

TL;DR: IEC 62443 is a series of standards for securing industrial automation and control systems (IACS), developed by the ISA99 committee of the International Society of Automation (ISA) and adopted by the International Electrotechnical Commission (IEC). It splits duties between asset owners, system integrators, product suppliers and service providers. Zones group assets with a shared security need, conduits control the paths between them, and security levels set a target for each zone.

What is IEC 62443?

IEC 62443 is a series of standards for securing industrial automation and control systems (IACS). According to the International Society of Automation (ISA), the series defines requirements and processes for implementing and maintaining electronically secure IACS. It is a family of standards and technical reports, not a single document, and each part is aimed at a different party in the life of a control system.

Who wrote it

The series was developed by the ISA99 committee and adopted by the International Electrotechnical Commission (IEC). ISA set up ISA99 in 2002 to protect the equipment and operations behind U.S. critical infrastructure. This is why you will see the name written as ISA/IEC 62443. In our reading, a security leader can treat the ISA and IEC editions as one body of work when talking to suppliers.

Where it applies

The standards were originally designed for the industrial process sector and later adapted for building automation, medical devices and transportation. ISA's list of sectors also includes electric power generation and distribution, and process industries such as chemicals and oil and gas.

In 2021, the IEC recognized the series as a horizontal standard, which means it applies across many industries. ISA also says its lifecycle coverage applies to all automation and control systems, not only industrial. A hospital's building controls fall inside that scope just as a refinery's do.

Who it speaks to

ISA describes shared responsibility as an essential building block of automation cybersecurity. The requirements are split across asset owners (end users), automation product suppliers, integrators who build and maintain control system solutions and their components, and service suppliers. The main parts listed by ISA show how that split works.

The ideas this guide covers next come from inside the series. Security zones and conduits were introduced in ISA/IEC 62443-1-1, and security levels are set out in Part 3-3. For other terms, see the glossary.

A practical first step: ask each OT supplier and integrator which part of the series they claim to meet. Then check that claim against the table above.

Who the standard expects to act: asset owner, system integrator and product supplier

The ISA material names the same three parties in slightly different words. The certificate program page says asset owners, system integrators and suppliers rely on the standards. The standards bundle page describes a common framework for asset owners, product suppliers and service providers. In our reading, the system integrator is the most visible kind of service provider, so the two lists describe one division of labor.

That division follows the part structure covered in the overview above. Two part titles assign a role directly: one security program part is written for asset owners and another for service providers. The product parts on secure development and component requirements belong to suppliers. In our reading, the system parts on risk assessment and security levels are shared ground where the owner and the integrator meet.

The bundle also holds two technical reports that sit close to the owner's daily work: Part 2-2 on an IACS security protection scheme and Part 2-3 on patch management. IACS here means industrial automation and control systems. We think patching is where the owner's duty runs longest, because it lasts as long as the plant does.

A plant example

Each party picks up and puts down its share at a different point.

The gaps open at the handoffs. A supplier can ship a controller that supports strong authentication, and the integrator can leave it switched off. An integrator can document a conduit, and the maintenance team can later bypass it with a temporary laptop connection.

The bundle frames the series as a risk-based approach throughout their lifecycle. For a security leader, that turns into three checks you can run on paper:

• Supplier contracts ask for evidence of the development process, not only a product datasheet.
• Integrator statements of work name a target security level for each zone and require a handover pack.
• Your own security program names who owns patching for each zone once the integrator leaves.

For how OT duties sit inside the wider security function, see what a CISO does.

How zones and conduits divide a control network

What follows is our plain-language reading of zones and conduits. The formal wording lives in Part 1-1, the terminology part mentioned earlier, which ISA lists as ISA-62443-1-1-2007, Security for industrial automation and control systems, Part 1-1: Terminology, concepts, and models. Check the definitions there before you write them into policy.

Zones: groups that share a security need

A zone, in our reading, is a set of assets you protect to the same standard because they face similar risk and serve a similar function. Location helps, but it does not decide membership.

The working test is short. If a compromise of one asset would expose the others in the group, and they need the same controls, they belong together.

Conduits: the paths you control

A conduit is the communication path between zones, together with the controls on it. That covers the firewall, the protocols allowed through, the remote access gateway and the rules for who may use each one. A conduit is a deliberate choice. Traffic that crosses a zone boundary without one is a finding.

A worked example

The conduits in this model are few and narrow:

• Enterprise to DMZ: one firewall, allowing historian reads and patch downloads.
• DMZ to supervisory: a second firewall. Vendor sessions end at the jump host and are recorded.
• Supervisory to basic control: industrial protocols only, from known engineering workstations.
• Safety to supervisory: status data out, no inbound writes.

The model also shows what is not allowed: no direct path from an office laptop to a PLC, and no vendor session that skips the jump host. Most audit findings we see described in plant reviews start with one of those two gaps; treat that as our impression, not a measured rate.

Why the split matters

The series sets out to help asset owners determine the level of security required to meet their unique business and risk needs. We think zones are where that decision becomes workable: you set a target for each zone and each conduit, rather than one target for the whole plant. Security levels, the subject of Part 3-3 noted earlier, then attach to those units.

One practical step: draw the first zone map from captured network traffic, not from the architecture diagram. The diagram shows what was intended. The capture shows what is actually crossing.

What security levels mean for systems and components

A security level is a statement about how hard a zone should be to attack, and how hard it actually is. Part 3-3 states what a whole system must do. Part 4-2 states what each component must contribute. The two are written to match, so you can trace a zone's goal down to one device.

Target and capability

The level for each zone is set during risk assessment. ISA describes Part 3-2 as giving a basis for countermeasures by aligning the zone's target security level with the security level capabilities set out in Part 3-3. The target reflects that zone's risk, which ISA says depends on threats, their likelihood, inherent vulnerabilities and consequences.

How 4-2 reaches the device

Part 4-2 sets technical requirements for four component types: embedded devices, network components, host components and software applications. It is based on the system requirements of Part 3-3. It defines what a component must do to mitigate threats for a given security level without the help of compensating countermeasures.

That last clause is the practical part. A component rated at a level is meant to meet it by itself. If it falls short, the gap has to be closed elsewhere in the zone or conduit, and someone has to own that control.

Process sits in a separate part. Part 4-1, published February 2018, covers how a product is built securely. Part 4-2 covers what the finished product can do.

One zone, three readings

Take the zone in the water-plant example that holds the treatment controllers. The table below shows how its level moves from goal to delivery.

In our reading, the gap between capability and achieved is where most of the risk sits. A controller can support the target level while running with the relevant settings left off. An audit that checks only product claims will not find this.

How IEC 62443 pairs with NIST SP 800-82

The two documents answer different questions. NIST Special Publication (SP) 800-82 Rev. 3, from the National Institute of Standards and Technology (NIST), explains how to secure operational technology (OT). The IEC 62443 series sets requirements that named parties can be held to. In our reading, a program gets the most value by treating the first as shared reference material and the second as contract language.

NIST builds its guide around threats and fixes. It identifies typical threats and vulnerabilities and recommends safeguards and countermeasures. It also adds alignment with the Cybersecurity Framework (CSF), which helps when the enterprise program already reports against the CSF.

Its definition of OT is wide. The examples include building automation, transportation and physical access control systems, so facilities teams can use it too.

A working split

1. Give the OT team SP 800-82 as baseline reading. Use its overlay, which covers low-impact, moderate-impact and high-impact OT systems, as a starting point for control selection.
2. Write procurement and service terms that cite IEC 62443 parts by number: the development lifecycle part for suppliers, the component part for devices, and the service provider part for integrators and maintainers.
3. Keep one mapping sheet. Tag each control you adopt from the NIST overlay with the IEC 62443 requirement that a supplier or integrator must show.
4. Budget for the IEC parts you actually cite. Buy the service provider part separately if you rely on it, since the bundle leaves it out.
5. Diary the Revision 4 comment deadline and review your mapping once the final version lands.

We think NIST for guidance, IEC 62443 for obligations is the simplest way to explain the split to a board or a buyer.

NIST SP 800-82 is being revised again

Rev. 3 is still the final version of the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-82. A fourth revision is in draft. In our reading, for any team that maps IEC 62443 requirements to NIST controls, the gap between those two documents now matters more than usual.

The dates

Rev. 3 went final on 09/28/23 and supersedes Rev. 2, dated 06/03/2015. The pre-draft call for comments opened on 01/22/26 with comments due February 23, 2026, and NIST marked it obsoleted on September 21, 2026. The initial public draft is dated 09/21/26, and its comment period runs through November 30, 2026.

What the draft changes

The draft is restructured around the NIST Cybersecurity Framework (CSF) 2.0. The old risk management section is reorganized around the CSF Govern Function. It also expands guidance on implementing controls, including asset management and network monitoring and detection. A new architecture section covers protecting system management functions and applying zero trust principles.

Coverage widens to building automation and control systems, water and wastewater systems, food and agriculture, freight rail, maritime vessels, and Industrial Internet of Things (IIoT) and cloud convergence.

The pre-draft also proposed moving the OT overlay, Appendix F in Rev. 3, into its own document. It proposed moving the appendices on threats, security organizations and security tools to web resources. In the public draft, Appendix F covers adoption of the NIST Risk Management Framework (RMF).

Before you map controls to a draft

• Pin the version. Record Rev. 3 or Rev. 4 draft against every mapping row. A citation to a section number is ambiguous without it.
• Recheck appendix references. In our reading, any internal document that cites Appendix F for overlay baselines will point at different content under the draft.
• Find where the overlay lives. If your zone baselines lean on it, confirm whether it still sits in the main document or has moved to a separate one.
• Match the CSF version. Mappings built against the older CSF structure will need a pass to line up with CSF 2.0 and the Govern Function.
• Treat the draft as provisional. We think it is sensible to hold audit and contract language at Rev. 3 until the final is out. Use the draft for gap planning only.
• Decide whether to comment.

Other guides on regulatory change are listed at /guides.

What a sitting security leader can do in the first quarter

The steps below are our own view of a workable first quarter. They assume the earlier sections of this guide are familiar and turn them into tasks a security leader can assign this week.

1. Name your role at each site

Write one line per site stating whether your organization acts as asset owner, system integrator or product supplier there. Many companies hold more than one role. A manufacturer can own and run its plants and also ship controllers to customers.

In our reading, most early confusion comes from treating the whole company as one role. Each role pulls in different parts of the standard, so the site list decides which parts each team reads first.

2. Inventory zones and conduits

Start with a drawing of what exists, not a target design. For each zone, record the assets, the owner and the security level you think it needs. For each conduit, record the zones it joins and the traffic it carries.

A single remote access path for a vendor is a conduit and belongs on the list. Gaps in the drawing are findings in their own right.

3. Write part numbers into supplier contracts

A clause that only says a supplier must comply with IEC 62443 is hard to test. Name the specific part and, where it applies, the security level you expect. Then state what evidence the supplier hands over and when it must do so. Procurement and legal teams can check this kind of clause against a delivery.

4. Keep people credentials and product schemes apart

Each certificate requires a course and an exam, and Certificate 1 must come first (ISA). The Expert designation is awarded once a person holds all four (ISA). ISA states that these certificates do not need renewal (ISA).

These certificates describe what a person has learned. A certificate held by an engineer does not certify a product or a system. When a supplier cites certification, ask whether it covers a person, a product or a system, and ask for the document.

5. Report to the board in plain terms

Boards respond to coverage and exceptions more than to standard clause numbers, in our reading. Report how many sites have a named role, how many zones and conduits are documented, and how many supplier contracts now name a part. List the exceptions and who owns each one.

The board oversight glossary entry covers the governance side. For a wider plan around these steps, see the first 90 days guide.

What this guide does not cover

This guide does not reproduce the requirement text of any IEC 62443 part or the formal definitions of each security level. It does not cover the details of product or system certification schemes, or sector-specific regulations that may cite the series. It is not legal advice: check contract clauses and compliance claims with your own legal and procurement teams. For the rules and the record behind it, see SEC Cybersecurity Disclosure Rules for CISOs: Item 1.05, Item 106 and Item 1C Explained.