TL;DR: IEC 62443 (written ISA/IEC 62443, because ISA99 and IEC TC65 developed it jointly) is the international standard series for cybersecurity in industrial automation and control systems. It has four groups of parts — 1-x general, 2-x policies and procedures, 3-x system, 4-x component — and it splits the work across three roles: asset owner, system integrator, product supplier. The design method is to divide the plant into zones, define the conduits between them, assign each zone a target security level from SL1 to SL4, then apply the seven foundational requirements. Nobody becomes “62443 compliant” in general. Each role is assessed against its own parts.
Motionwell Automation builds custom machines and modernises control systems in Singapore. Our largest 2026 workstream is retrofit — replacing PLCs, servo drives and VFDs on legacy production machines with current Allen-Bradley, Siemens and Omron platforms. That work is exactly where IEC 62443 stops being an abstraction: a machine that ran for fifteen years with no network port suddenly has an EtherNet/IP switch, a data path to a plant server, and an engineer who wants to dial in from home. This article explains the standard the way a machine builder needs it, and is honest about where our role ends.
What Is the IEC 62443 Industrial Cybersecurity Standard?
IEC 62443 is a series, not a single document. It covers the whole industrial automation and control system (IACS) — PLCs, drives, HMIs, engineering workstations, historians, the networks between them and the people who operate them. It grew out of the ISA99 committee’s work in the mid-2000s and is now maintained jointly with IEC, which is why you see both names on it.
The series is numbered in four groups. The first digit tells you what kind of document it is and, more usefully, who it is written for.
| Group | What it covers | Who it is written for |
|---|---|---|
| 1-x General | Terminology, concepts and models (62443-1-1) | Everyone, as shared vocabulary |
| 2-x Policies and procedures | Asset owner security programme (62443-2-1), patch management (62443-2-3), service provider requirements (62443-2-4) | Plant owners and integrators |
| 3-x System | Risk assessment and system design (62443-3-2), system security requirements and security levels (62443-3-3) | System designers and integrators |
| 4-x Component | Secure development lifecycle (62443-4-1), technical component requirements (62443-4-2) | Product suppliers |
If you build machines, 62443-3-2, 62443-3-3 and 62443-2-4 are the parts that describe your work. If you buy machines, 62443-2-1 describes yours. Reading the wrong part is the most common way engineers conclude the standard is irrelevant to them.
What Are the IEC 62443 Framework Components and Requirements?
Underneath the part numbering sits a small set of ideas that carry most of the weight.
The seven foundational requirements
Every technical requirement in 62443-3-3 and 62443-4-2 rolls up to one of seven foundational requirements. They are worth memorising because they double as a design checklist.
| FR | Name | The question it answers |
|---|---|---|
| FR1 | Identification and authentication control | Who or what is this, and can it prove it? |
| FR2 | Use control | Now that we know who it is, what may it do? |
| FR3 | System integrity | Has the code, configuration or data been altered? |
| FR4 | Data confidentiality | Can anyone read what should stay private? |
| FR5 | Restricted data flow | Does traffic only go where it is supposed to? |
| FR6 | Timely response to events | Would we notice, and could we reconstruct it afterwards? |
| FR7 | Resource availability | Does the process keep running under load or attack? |
Two of the seven do most of the work on a retrofit. FR5 is where a newly networked legacy machine fails on day one, with PLC, drives, HMI and cameras sharing one flat segment and a fresh route to a plant server bolted onto it — the segmentation section below is what unpicking that costs. FR7 is the one that separates OT from IT. In an office, taking a server offline is a reasonable response to a suspected compromise. On a filling line mid-batch, it is a product loss and a deviation report. Availability outranks confidentiality in nearly every plant we work in, which inverts the priority order most IT security training teaches.
Zones, conduits and the system under consideration
You cannot risk-assess a whole factory as one object. 62443-3-2 tells you to define a system under consideration, then partition it into zones — groups of assets that share security requirements — and conduits, which are the controlled paths between zones.
For a single machine, a workable partition usually looks like this: a device zone holding the PLC, drives, safety controller and field I/O on their own switch; an operator zone with the HMI panel and any local PC; a supervisory conduit carrying production data upward to a server or MES; and an occasional maintenance conduit for remote access. Each zone gets its own target security level. The conduits get explicit rules: which protocol, which direction, which port, which account. On retrofit work the maintenance conduit is the one that gets argued over, because it is the path the machine never had before and the one the engineer who wants to dial in from home is actually asking for.
This partition survives contact with reality because it maps to how the machine is built and wired. If you can draw it on the electrical schematic, an operator can also follow it during a fault.
Security levels SL1 to SL4
62443-3-3 defines four security levels by the kind of adversary each one resists.
| Level | Protects against |
|---|---|
| SL1 | Casual or coincidental violation — a wrong cable, a curious operator |
| SL2 | Intentional violation using simple means, low resources, generic skills, low motivation |
| SL3 | Intentional violation using sophisticated means, moderate resources, IACS-specific skills, moderate motivation |
| SL4 | Intentional violation using sophisticated means, extended resources, IACS-specific skills, high motivation |
Three variants of the level matter in a contract. SL-T is the target you set during risk assessment. SL-C is the capability a component or system can provide. SL-A is what the deployed installation actually achieves. Gaps between them are normal — a twenty-year-old drive has no SL-C worth naming — and the standard expects you to close them with compensating controls at the zone boundary rather than by scrapping the drive.
Most general manufacturing lands at SL1 or SL2. SL3 shows up in regulated production and in facilities that already sit inside a critical infrastructure designation. Specifying SL3 for a tray-filling machine because it sounds thorough will cost real money and buy very little.
Who Is Responsible: Asset Owner, Integrator or Product Supplier?
This is the part of IEC 62443 that changes how projects run, and the part most often skipped.
| Role | Who that is | Main parts | What they own |
|---|---|---|---|
| Asset owner | The manufacturer operating the plant | 62443-2-1, 62443-3-2 | Risk acceptance, security programme, zone definitions, patch decisions, account lifecycle |
| System integrator | The machine builder or automation contractor | 62443-2-4, 62443-3-2, 62443-3-3 | Designing the system to the target level, configuration, handover documentation, secure commissioning |
| Product supplier | The PLC, drive, camera or robot manufacturer | 62443-4-1, 62443-4-2 | Component capability, secure development, vulnerability disclosure, patches |
Read the table again and notice what it means for a purchase order. A machine builder cannot deliver an SL-T that the customer never set. A product supplier cannot be blamed for a flat network the integrator was told to build. And an asset owner who buys certified components, drops them into an unsegmented plant network and shares one engineering password across three shifts has not achieved anything, because the requirements that failed were theirs.
Motionwell sits in the middle row. Our scope on a project is the zone design, the conduit rules, the account and role configuration, and a handover pack that lets your team run the machine securely. The components come from Allen-Bradley, Siemens, Omron, Mitsubishi, Beckhoff, Keyence, Cognex, SICK and others, none of them built here, which is why component-level conformance is the supplier’s evidence to produce and not ours to invent. Choosing a partner who can articulate that boundary is one of the questions covered in our guide to choosing an automation system integrator.
How Do You Apply IEC 62443 to a Single Machine?
Four practical problems come up on nearly every project.
Network segmentation on the machine itself
The default build in a lot of workshops is one flat network: PLC, HMI, drives, cameras and a spare port for whoever needs it. It commissions fast and it fails the restricted-data-flow requirement completely.
The alternative costs one managed switch and some thought. Keep the device-level traffic — EtherNet/IP or PROFINET between controller, drives and I/O — on its own segment with no route outward. Put anything that talks upward on a second interface. Modern controllers make this straightforward: a dual-port controller can hold the machine network on one interface and present a single data path on the other. Vision systems are the usual complication, because Keyence and Cognex devices are often configured from a laptop and then left reachable; give them a defined address range and decide deliberately whether that range is visible from outside the machine.
On our QA lab automation project, where a server dispatches tasks to an autonomous mobile robot, a collaborative robot and a vision station, the scheduling server is a zone of its own and every robot conversation is a conduit with a known protocol and account. That structure was a design decision, not an afterthought, and it is why the system could be replicated to other customers without re-litigating the network each time.
Remote access for commissioning and support
Remote access is where good intentions go to die. The pattern to avoid is a cellular router with an always-on tunnel, installed by an integrator, with credentials nobody at the plant holds.
A defensible arrangement has four properties: the connection is initiated from the plant side or explicitly enabled by plant staff, it is off by default, it lands in a defined zone rather than on the machine network at large, and it is logged. A physical key switch on the panel that enables the remote path is crude, cheap and understood by everyone on the floor. It also satisfies FR2 and FR6 better than most software arrangements, because the control is visible.
Write the arrangement into the specification before commissioning, not after. Retrofitting an access policy onto a machine that is already running production is a negotiation, not an engineering task.
Patching a machine that has been validated
In a regulated plant, the blocker is not technical. It’s that the machine carries IQ/OQ/PQ evidence and nobody wants to invalidate it. 62443-2-3 exists for this: it describes how patch information flows from supplier to asset owner and how patch decisions get made in an environment where you cannot simply reboot.
The mechanism that works is impact-scoped change control. For each patch, record what it modifies, whether anything it modifies is covered by a qualification test, and what verification closes the gap. Operating system and driver patches on an HMI PC usually touch no qualified function and need documented verification only. Changes to control logic, recipe handling or electronic records touch qualified functions and require the affected tests re-executed — not the entire qualification package.
Where a patch cannot be applied at all, which happens with obsolete equipment more often than vendors admit, the standard’s answer is compensating controls: tighten the conduit, remove the route, restrict the accounts, increase monitoring. Document that decision as a decision. An unpatched device inside a properly bounded zone is a managed risk; the same device on a flat network is an open one. This thinking runs through the equipment we deliver for pharmaceutical and packaging production, where serialization data from Cognex readers and Domino coders has to reach upstream systems without opening the line to them.
Security is not safety
Machine safety and machine security are different disciplines with different standards, and conflating them produces bad designs. A safety function is engineered to reduce risk of harm from foreseeable failure and misuse; it is assessed against ISO 13849 or IEC 62061 and, for cobots, ISO/TS 15066. IEC 62443 addresses deliberate interference.
They intersect at one point that deserves attention: the integrity of a safety function must not depend on anything reachable from a general-purpose network. Safety controllers and their networks stay in their own zone. Our cobot safety standards guide covers the safety side properly.
What Should You Ask an Equipment Vendor For?
A short procurement list gets you most of the way, and none of it requires the vendor to be certified.
- A network diagram of the delivered machine showing zones, every network interface, and every protocol and port that crosses a boundary.
- A complete account list: default accounts, roles and permissions, and confirmation that no shared hardcoded engineering password ships with the machine.
- The remote access design, in writing, including who holds credentials and how the plant disables the path.
- A component list with firmware versions, so your team can subscribe to supplier vulnerability notices — the practical value of 62443-4-1 to a buyer is that suppliers who follow it actually publish advisories.
- A hardening note covering what was disabled: unused ports, default web servers, discovery services left on by default in some drives and cameras.
- End-of-support dates for the control platform, which is the number that determines your real patching horizon.
If a vendor cannot produce these, the gap is documentation discipline rather than cryptography, and it is the same discipline that produces good electrical schematics. We build this material into every handover package, as described in our special purpose machine design process.
What Does IEC 62443 Certification Actually Involve?
Certification under IEC 62443 is granted per role and per scope, never as a general badge. Product suppliers certify a development process against 62443-4-1 or a specific component against 62443-4-2. Integrators and service providers are assessed against 62443-2-4. Asset owners assess their security programme against 62443-2-1. Schemes operated under IECEE and ISASecure, and audits from established certification bodies, are the usual routes.
Two cautions. First, a certificate has a scope statement, and the scope is the whole story — a component certified at SL2 for a listed set of functions tells you nothing about a system built from it. Second, certification of a supplier does not transfer to your installation. The achieved level of your plant is determined by how the system was designed, configured and operated.
Motionwell is not certified under any IEC 62443 scheme, does not perform assessments, and does not offer security consultancy. We apply the standard’s practices as a control-system integrator: zone and conduit design, network segmentation, account and role separation, documented remote access, hardening notes and firmware records in the handover package. If you need a formal certificate or an independent audit, that is work for an accredited body, and we will say so rather than sell you something adjacent.
Getting Started
If you are specifying a new machine or a control-system retrofit and want security designed in rather than bolted on, bring these to the first conversation:
- The machine or line in question, its current controller, and whether it is already networked
- Where production data has to go — a server, an MES, a serialization system, a spreadsheet on someone’s PC
- Whether the equipment is qualified, and which tests would be affected by a control change
- Your target security level per zone if your organisation has already set one, or a description of your plant network if it has not
- How your team expects remote support to work, including who may authorise it
Send those details to our engineering team and we will come back with a zone and conduit sketch for the machine, the network and account arrangement we would build, and an honest note on any part of the requirement that belongs with your IT organisation or with a certification body instead of with us.