IEC 62443 in Plain English
If you work anywhere near industrial control systems, you have probably heard someone say "we should align with 62443." It is the most widely referenced cybersecurity standard for operational technology, but it is also a large family of documents that can feel impenetrable at first. This article explains what the series is, how it is organized, and which parts actually matter to you.
What the series is
ISA/IEC 62443 is a series of international standards for the security of industrial automation and control systems (IACS). It was developed by the ISA99 committee of the International Society of Automation, and is published jointly with the International Electrotechnical Commission (IEC). You will see the same documents published as ANSI/ISA-62443 and as IEC 62443, sometimes with slightly different edition dates.
What makes 62443 different from general IT security standards is its focus. It is written around the realities of control systems: availability and safety come first, equipment lives for decades, patching is constrained, and responsibility is split between the companies that own plants, the companies that integrate and maintain them, and the companies that make the products inside them.
How the documents are organized
The series is split into four groups. The part number tells you which group a document belongs to.
General (62443-1-x) covers concepts, terminology and models that the rest of the series relies on.
Policies and Procedures (62443-2-x) covers the people and process side: how an organization runs a security program and how service providers should behave.
System (62443-3-x) covers requirements for complete control systems, including risk assessment and system-level security capabilities.
Component (62443-4-x) covers requirements for the individual products that make up a system, and for how vendors develop them.
You do not need to read every part. Most organizations need three or four of them, depending on their role.
The key parts and who they are for
62443-2-1: Security program requirements for IACS asset owners. This is the operator's playbook. It describes what an asset owner's OT security program should include, from governance and risk management to access control, event management and continuity. It is the natural reference point for a plant or utility building a program.
62443-2-4: Security program requirements for IACS service providers. This part applies to system integrators and maintenance providers. It sets out the capabilities an asset owner can reasonably expect from the firms that build, commission and support their systems, such as secure remote access practices, patch handling and account management.
62443-3-2: Security risk assessment. This part explains how to break a system into zones and conduits, assess risk for each, and set a target security level. It is where most practical 62443 work begins.
62443-3-3: System security requirements and security levels. This is the catalogue of technical requirements a control system should meet, organized by foundational requirement and graded by security level.
62443-4-1: Secure product development lifecycle requirements. This part is aimed at product vendors. It covers the processes a supplier should follow while building and maintaining products, including threat modelling, secure coding, testing, vulnerability handling and update management.
62443-4-2: Technical security requirements for IACS components. This defines the security capabilities expected of individual components, such as controllers, embedded devices, network devices, host systems and software applications.
Three roles, shared responsibility
62443 is built around three principal roles, and recognizing which one you are makes the series much easier to navigate.
Asset owner. The organization that owns and operates the facility and is accountable for its risk. Asset owners lean most on 2-1, 3-2 and 3-3.
Integrator or service provider. The firm that assembles, configures, commissions or maintains the system on site. Their main reference is 2-4, and they implement much of what 3-3 asks for.
Product supplier. The vendor that makes the controllers, software and network equipment. Their references are 4-1 for how they build products and 4-2 for what those products can do.
The point is that no single party can secure a control system on its own. A well-built product can be installed badly, and a careful integrator cannot add capabilities a product does not have. The series gives each party a clear share of the work and a common language for contracts and procurement.
The seven foundational requirements
Across the system and component parts, technical requirements are grouped under seven foundational requirements (FRs). They are a useful checklist even if you never read the detailed parts.
FR1 Identification and authentication control. Know who and what is connecting, and verify it.
FR2 Use control. Once identified, users and devices can do only what they are authorized to do.
FR3 System integrity. Protect software, configurations and data from unauthorized change.
FR4 Data confidentiality. Protect sensitive information, both in transit and at rest.
FR5 Restricted data flow. Segment the network and control traffic between zones.
FR6 Timely response to events. Log, monitor and respond to security events quickly enough to matter.
FR7 Resource availability. Keep the system running under stress, including denial-of-service conditions, and be able to recover it.
Notice how operational these are. Availability, integrity and controlled data flow sit right alongside the familiar confidentiality concerns.
How to get started
You do not adopt 62443 all at once. A sensible path for an asset owner looks like this:
Build an accurate inventory of control system assets and their communication paths. You cannot zone what you cannot see.
Define zones and conduits for your most critical system first, using 62443-3-2 as the guide.
Set target security levels for each zone based on realistic risk, not aspiration.
Run a gap assessment against 62443-3-3 and the program elements in 62443-2-1 to see where you stand.
Prioritize and plan the fixes that close the biggest risks first, such as remote access, segmentation and account management.
Bring suppliers along by referencing 2-4 and 4-1/4-2 in contracts and purchasing requirements.
Progress is measured in reduced risk, not in pages of compliance documentation. Starting small and doing it properly beats a sweeping program that stalls.
How QBits Networks can help
Our IEC 62443 gap assessments compare your current program and systems against the relevant parts of the series and produce a prioritized, realistic plan. If you are starting from scratch, a passive-first OT security assessment builds the asset and communication picture that every other 62443 step depends on. Tell us what you need through our contact page and we'll scope it with you.