The short answer
IEC 62443
IEC 62443 is a series of standards for securing industrial automation and control systems. It splits responsibility among asset owners, integrators, and product suppliers, organizes a system into zones and conduits, and rates protection with security levels 1 through 4 against seven foundational requirements. For most utilities the useful parts are 2-1 for the security program, 3-2 for risk assessment and zoning, and 3-3 for system requirements at a chosen security level.
Key points
- The series is organized by role: asset owner, system integrator, product supplier.
- Security levels 1 to 4 describe the attacker the system must resist, from accidental to well-resourced and persistent.
- Seven foundational requirements define what a zone at a given level must be able to do.
- Parts 3-2 and 3-3 are the working documents for zoning a system and specifying it.
- It is a framework for specification and assessment, not a checklist, and most utilities will target SL 2.
What the series is
IEC 62443 began as ISA-99 and is maintained jointly by the ISA99 committee and IEC Technical Committee 65. It is the one standard series written specifically for industrial automation and control systems, as opposed to IT frameworks adapted to them. Its central ideas are that security is a shared responsibility among the people who own, build, and supply a system; that a system should be divided into zones connected by controlled conduits; and that the amount of protection should be chosen deliberately, by level, rather than applied uniformly.
The documents are purchased, not free, which shapes how they are used. Most practitioners work from a few parts and from the derived guidance published by ISA, government agencies, and vendors. Knowing the structure is what makes that guidance intelligible.
How the series is organized
| Part | Audience | What it covers |
|---|---|---|
| 62443-1-1 | Everyone | Terminology, concepts, and models. Defines zones, conduits, security levels, and the foundational requirements. |
| 62443-2-1 | Asset owner | Requirements for an IACS security program: policies, organization, risk management, and the management system that keeps it alive. |
| 62443-2-4 | Integrator and service provider | Security requirements for the people who design, install, and maintain systems. The part to reference in an integration contract. |
| 62443-3-2 | Asset owner and integrator | Security risk assessment and system design: partitioning the system into zones and conduits and assigning a target security level to each. |
| 62443-3-3 | Asset owner and integrator | System security requirements and security levels. The seven foundational requirements broken into specific requirements and enhancements for each level. |
| 62443-4-1 | Product supplier | Secure product development lifecycle requirements for the vendor. |
| 62443-4-2 | Product supplier | Technical security requirements for individual components: controllers, HMIs, network devices, software. |
Security levels
A security level describes the capability of the adversary the system is meant to resist. The scale is about intent and resources, not about a specific technology.
| Level | Protects against | In practice |
|---|---|---|
| SL 0 | No specific requirement | A zone with nothing worth protecting, which is rare in a control system. |
| SL 1 | Casual or coincidental violation | Mistakes, curious employees, a misconfigured laptop. Basic access control and hygiene. |
| SL 2 | Intentional violation using simple means, low resources, generic skills, low motivation | An opportunistic attacker with public tools. The realistic target for most water and wastewater systems. |
| SL 3 | Intentional violation using sophisticated means, moderate resources, IACS-specific skills, moderate motivation | A capable, targeted attacker. Appropriate for critical zones at large utilities and for systems that have been specifically threatened. |
| SL 4 | Intentional violation using sophisticated means, extended resources, IACS-specific skills, high motivation | A well-resourced, persistent adversary. Rarely a realistic target for an entire system; sometimes chosen for one small critical zone. |
Three flavors of level are used. The target level, SL-T, is what the risk assessment says a zone needs. The capability level, SL-C, is what a component or system can provide when configured correctly. The achieved level, SL-A, is what the installed and operated system actually delivers. The gap between SL-T and SL-A is the work list.
The seven foundational requirements
Part 3-3 defines what a zone at each level must be able to do under seven headings. Each foundational requirement expands into numbered system requirements, with requirement enhancements that apply at higher levels.
- FR 1, Identification and authentication control
- Know who and what is on the system. Unique accounts for people, authenticated devices and software, managed credentials.
- FR 2, Use control
- Once identified, limit what each user, device, and process may do. Roles, least privilege, session control, and the physical keyswitch on a controller.
- FR 3, System integrity
- Prevent unauthorized change and detect it when it happens. Program integrity, firmware validation, malware protection, and change detection.
- FR 4, Data confidentiality
- Protect information that must not be disclosed, in transit and at rest. In a control system this is often credentials and configuration rather than process values.
- FR 5, Restricted data flow
- Segment the system so that data flows only where it is supposed to. This is where zones and conduits are enforced: firewalls, one-way links, and network isolation.
- FR 6, Timely response to events
- Log, monitor, and alert so that an incident is noticed and can be investigated. Audit logs, time synchronization, and someone who reads them.
- FR 7, Resource availability
- Keep the system running under attack or failure. Denial of service resilience, backups, redundancy, and the ability to operate manually.
Read as a list, the seven requirements are also a reasonable outline for a utility security program even without a formal assessment. Nearly every practical control a small utility would put in place maps to one of them.
Zones and conduits
Part 3-2 asks the asset owner to divide the system into zones, groups of assets that share security requirements, and conduits, the communication paths between zones. Each zone gets a target security level from a risk assessment, and each conduit is inventoried with its protocols, direction, and protection. The Purdue model provides the usual starting shape; the zone model is the refinement that says which boundaries actually need enforcement. The zones and conduits page walks through a worked example for a water utility.
How a utility uses it
Very few utilities need to read every part. A practical path uses the series in this order.
- 01Use the concepts in 1-1 to get the vocabulary straight: zones, conduits, security levels, roles. This makes the rest of the guidance readable.
- 02Use 3-2 to inventory assets, draw zones and conduits, and assign a target level to each zone. For most utilities the answer is SL 2 for control zones and SL 1 for less critical ones, with SL 3 considered only for a specific zone that warrants it.
- 03Use 3-3 as the requirements list for each zone at its target level, both to specify new systems and to assess existing ones. The gap analysis is the work plan.
- 04Use 2-1 to build the program around the technical work: policies, responsibilities, training, and the review cycle that keeps the assessment current.
- 05Cite 2-4 in contracts with integrators and service providers, and ask product suppliers about 4-1 and 4-2 conformance when buying components.
Where it fits with other frameworks
The NIST Cybersecurity Framework organizes a program around functions such as identify, protect, detect, respond, and recover, and is technology-neutral. IEC 62443 is the control-system-specific standard that says what protect actually means for a controller network. The two are complementary: many utilities use the NIST framework, or the water sector guidance built on it, for the program and 62443 for the technical requirements. Regulatory requirements, including the risk and resilience assessments under the America's Water Infrastructure Act, do not mandate 62443 but are satisfied more easily by a utility that has done a 3-2 style assessment.
Frequently asked questions
- Do I have to buy the standards to use them?
- To cite specific requirement numbers in a contract or an assessment, yes, the relevant parts should be purchased. To apply the concepts, the freely available quick-start guides and summaries from ISA and the agencies cover zones, conduits, levels, and the foundational requirements well enough to start.
- What security level should a water utility target?
- SL 2 for the control zones is the common answer, meaning the system should resist an opportunistic attacker using public tools. A large utility with a specific threat profile may target SL 3 for its most critical zone. SL 4 across a whole system is neither achievable nor necessary for almost anyone.
- Is 62443 compliance a thing I can claim?
- A system can be assessed against 3-3 at a target level, and a product can be certified against 4-2. Claiming that a utility is 62443 compliant without saying which parts, which zones, and which level is a marketing statement rather than a technical one.
- How does 62443 relate to the Purdue model?
- Purdue is a reference architecture that describes levels of a control hierarchy. 62443 uses it as the starting shape for zoning but does not require it. The zones and conduits model is more flexible and is what 62443 actually assesses.
Related topics
- Zones and ConduitsThe IEC 62443 way to segment a control system: grouping assets into zones with a shared security level, inventorying every conduit between them, and turning the drawing into firewall rules. With a worked water utility example.
- The Purdue ModelThe reference architecture most segmentation designs still start from: what each level contains, where the DMZ goes, and how it maps to a water utility.
- OT Security vs IT SecurityWhy the familiar security priorities invert on a plant floor, and what that changes about patching, scanning, authentication, and incident response.
- Controller HardeningWhat can be locked down on a PLC or RTU: keyswitch and mode, credentials, unused services, access lists, firmware, and the engineering workstation that is the real target.
- Water and Wastewater Utility Threat LandscapeWhat has actually happened at water utilities, what those incidents had in common, and the small number of controls that would have prevented most of them.
- OT Risk AssessmentRanking what could go wrong in a control system and what it would cost: the consequence-first method for utilities, the assets and scenarios to list, likelihood without pretending to know it, the risk matrix, and turning the ranked list into a work plan.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.