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 controller platforms that are still supported, still patched by their maker, and still stocked locally, since a machine hardened on a platform whose vendor has stopped issuing fixes is hardened only until the next disclosure. 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: which OT cybersecurity requirement belongs to which role, and what changes on the machine itself.
What Is the IEC 62443 Industrial Cybersecurity Standard?
IEC 62443 is a series. 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 a quick way to conclude the standard is irrelevant to you when it is not.
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, and what unpicking that costs is set out in the segmentation section below. 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, so the drive stays where it is.
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 controllers, drives, cameras and network devices on a machine are bought in and none of them are built here, which is why component-level conformance under 62443-4-2 is the product supplier’s evidence to produce, never an integrator’s to invent. The practical consequence for a specification is that an SL-T written against a machine cannot be met by a component datasheet alone: ask the builder for the zone design and the account model, and ask each device maker for its own conformance claim, because nobody can hand you both. 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.
Separate device-level control traffic from plant and service access using the network architecture defined for the zones. Check the controller’s port design: two physical ports may share an internal switch, while independent interfaces can support separate networks. Use the required routing and firewall controls at the conduit, permit named services and test that blocked paths remain blocked. Include cameras and engineering laptops in that design so commissioning access has an owner and an operating policy after handover.
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, 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 remote-access arrangement gives plant staff control over when a session is enabled, routes it to a defined service zone and records the session. A panel key switch can provide a local enable signal. Combine it with named accounts, authentication, role-based permissions, connection limits and logs that the asset owner can review. Validate those controls against the selected IEC 62443 requirements, including use control and response to events.
Write the arrangement into the specification before commissioning. Retrofitting an access policy onto a machine that is already running production is a negotiation.
Patching a machine that has been validated
For qualified equipment, assess the patch through change control: affected functions, supplier information, test coverage, backup and rollback, then the release decision. IEC 62443-2-3 addresses patch information and its use by suppliers and asset owners, supporting a planned update with the required validation evidence. Where the machine creates regulated electronic records, the Part 11 questions for machine buyers help define which records and controls the change assessment must cover.
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, well short of 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. The same thinking applies in pharmaceutical and packaging production, where serialization data from code readers and 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.
A SCADA cutover changes platform and access configuration. SCADA upgrade access review includes user, interface and recovery tests alongside archive verification.
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, 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.
What Motionwell brings to a project is the integrator’s share of that work: zone and conduit design, network segmentation, account and role separation, documented remote access, hardening notes and firmware records in the handover package. A formal certificate or an independent audit is issued by an accredited body under one of those schemes, and the scope statement printed on it is what your own assessment will later be read against.
What Should You Bring to the First Conversation?
If you are specifying a new machine or a control-system retrofit and want security designed in, bring these five things:
- 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 a note naming any part of the requirement that belongs with your IT organisation or with a certification body.