Demystifying IEC 62443: The Essential Framework for OT Security Assessments
As cyber kinetic attacks threaten critical infrastructure, the ISA/IEC 62443 standard provides the definitive roadmap for protecting Industrial Control Systems (ICS). Learn about its core subsections, security importance, and how to secure your manufacturing floor.
Applying IT security practice to an operational technology environment is how you cause the outage you were hired to prevent. A vulnerability scan that is routine on a corporate network can knock a programmable logic controller offline — and in OT, availability is the safety property, not a service-level target.
IEC 62443 exists because that difference needed a framework of its own. It is not an OT-flavoured rewrite of ISO 27001; it is built around the assumption that these systems run for decades, cannot be patched on a monthly cycle, and fail in ways that hurt people rather than balance sheets.
This guide explains how the standard is structured, what zones and conduits and security levels actually mean in practice, how an OT assessment differs methodologically from an IT one, and how to sequence a programme when you cannot simply take production down.
- 01OT inverts the IT priority order: availability and safety first, confidentiality last.
- 02IEC 62443 organises the environment into zones and conduits — segmentation is the core control.
- 03Security Levels 1–4 describe the attacker you are designing against, not a maturity score.
- 04Assessment must be passive-first. Active scanning can disrupt or damage control systems.
- 05The standard splits duties across asset owners, integrators and product suppliers — know which parts apply to you.
Why OT Security Is Not IT Security
The differences are structural rather than cultural, and they explain almost every friction point between IT and OT teams.
| Dimension | IT environment | OT environment |
|---|---|---|
| Priority order | Confidentiality, integrity, availability | Safety, availability, integrity, confidentiality |
| Asset lifespan | 3–5 years | 15–30 years, often longer |
| Patching | Monthly, largely automated | During planned outages, possibly annual |
| Failure consequence | Data loss, financial and reputational | Physical damage, environmental release, injury |
| Protocols | Authenticated and encrypted by default | Often no authentication by design |
| Testing | Active scanning is routine | Active scanning can disrupt or damage devices |
The protocol row deserves emphasis. Many industrial protocols were designed for isolated networks where every participant was trusted by definition, so they carry no authentication whatsoever. A device on the same segment can often issue commands with no credential at all. That is not a vulnerability to patch; it is the design, and the compensating control is segmentation.
How the Standard Is Organised
IEC 62443 is a series rather than a single document, and it splits obligations across three roles. Knowing which parts apply to you saves a great deal of wasted effort.
- Asset owners — operators of the environment. The 62443-2-x parts cover the security programme, policies and patch management.
- System integrators — those designing and commissioning solutions. The 62443-3-x parts cover system-level requirements, risk assessment and zone design.
- Product suppliers — those building the components. The 62443-4-x parts cover secure development lifecycle and technical component requirements.
Most organisations are asset owners and should start with 62443-2-1 and 62443-3-2. If you manufacture industrial products, 62443-4-1 governs your development process — covered in detail in our guide to secure product development.
Zones, Conduits and Why They Matter
The central architectural idea is straightforward. A zone groups assets that share security requirements — a safety instrumented system, a process control network, a plant DMZ. A conduit is the controlled communication path between zones, and it is where you place enforcement.
This matters because it makes the standard tractable in an environment where you cannot secure individual devices. You cannot patch a twenty-year-old controller or add authentication to a protocol that has none. What you can do is control precisely what is permitted to talk to it and inspect that traffic — which is why zone and conduit design, not device hardening, is where the security actually comes from.
The most common finding in our assessments is that zones exist on the architecture diagram but not in the network. A flat plant network where a compromised engineering workstation can reach safety systems directly is the norm, not the exception.
The question that reveals your real posture: from a compromised laptop on the plant floor, what can be reached without crossing an enforced boundary? If the honest answer includes safety instrumented systems or the control network, your zones are documentation rather than architecture — and no amount of device-level hardening compensates.
Security Levels: Design Targets, Not Scores
Security Levels are widely misread as a maturity ladder to climb. They are not. Each level describes the capability of the adversary you are designing to withstand, and you assign a target level per zone based on consequence.
| Level | Designed to resist | Typically applied to |
|---|---|---|
| SL 1 | Casual or accidental misuse | Low-consequence auxiliary systems |
| SL 2 | Intentional attack with simple means and low motivation | General process control networks |
| SL 3 | Sophisticated attack with OT-specific knowledge | Critical process and safety-adjacent zones |
| SL 4 | State-level actors with extended resources | National critical infrastructure |
A well-designed environment will have different target levels in different zones, and pursuing SL 3 everywhere is usually a sign the consequence analysis was never done.
How an OT Assessment Is Actually Run
Methodology is where OT engagements most often go wrong, and where an IT-trained team can cause real harm.
Passive first. Discovery begins with network traffic analysis through a span port or tap — observing rather than probing. This builds an asset inventory and communication baseline without sending a single packet to a control device.
Active testing only where it is safe. Any active work happens against a test bed, a redundant system, or during a planned outage, with the operations team present and a rollback position agreed. Some devices will fall over when scanned; that must be a controlled discovery, not a surprise.
Consequence-driven analysis. Rather than ranking findings by CVSS, an OT assessment works backward from unacceptable outcomes — an uncontrolled release, a safety system bypass, an extended production stoppage — and identifies which paths could produce them. A medium-severity flaw on a path to a safety system outranks a critical on an isolated historian.
A Sequenced Programme
- 01Build an asset inventory passively. Most operators do not have a complete one.
- 02Define zones and conduits against the network as it actually is, not the diagram.
- 03Run a consequence-driven risk assessment and assign target Security Levels per zone.
- 04Close the IT/OT boundary first — most intrusions arrive from the enterprise side.
- 05Control remote and vendor access — a frequent and poorly monitored entry path.
- 06Deploy passive OT monitoring and feed it into a SOC that understands industrial protocols.
- 07Write an OT-specific incident response plan — IT playbooks assume you can isolate a host.
- 08Apply compensating controls where patching is impossible, and document the reasoning.
Step seven is frequently overlooked. In IT, containment often means isolating a machine. In OT, isolating the wrong device can trip a process or disable a safety function — so the response plan needs operations and engineering involved in the decision, not just security.
How Adayptus Helps
- SCADA & ICS Security — passive-first assessment aligned to IEC 62443 zones and conduits.
- IT/OT Security — the convergence boundary where most intrusions originate.
- Critical Infrastructure Security — for operators under regulatory obligation.
- Managed SOC & MDR — monitoring that understands industrial protocols.
- Incident Response & DFIR — OT-aware containment that will not trip a process.
Related reading: IEC 62443-4-1 for product suppliers.
Frequently Asked Questions
Click any question to expand the answer.
QCan we just apply ISO 27001 to our OT environment?
Not on its own. ISO 27001 provides a sound management-system structure, but it assumes an IT context: assets replaced every few years, monthly patching, and confidentiality as the primary concern. OT inverts that — safety and availability come first, equipment runs for decades, and patching may only be possible during planned outages. IEC 62443 addresses those constraints directly, particularly through zone and conduit architecture. Many organisations run both, using ISO 27001 for governance and 62443 for the OT technical framework.
QIs it safe to run a vulnerability scan on OT systems?
Not against live control systems without careful preparation. Many industrial devices have limited network stacks and can crash or behave unpredictably under scanning traffic that a modern server would ignore entirely. Start passively with traffic analysis through a span port or tap, which yields an asset inventory and communication baseline without touching the devices. Reserve active testing for a test bed, a redundant system, or a planned outage with operations present and a rollback position agreed.
QWhat are zones and conduits in IEC 62443?
A zone groups assets sharing common security requirements, such as a safety instrumented system or a process control network. A conduit is the controlled communication path between zones, and it is where enforcement is applied. This structure exists because you often cannot secure individual devices — a twenty-year-old controller cannot be patched and its protocol may have no authentication at all. Controlling precisely what may communicate with it is where the security actually comes from.
QShould we target Security Level 3 everywhere?
No, and doing so usually indicates the consequence analysis was skipped. Security Levels describe the capability of the adversary a zone is designed to withstand, not a maturity score to maximise. Assign target levels per zone based on what happens if that zone is compromised — a safety-adjacent zone may warrant SL 3 while an auxiliary monitoring system is adequately served by SL 1. Uniform targets waste budget on low-consequence areas while under-protecting nothing in particular.
QHow do we secure devices that cannot be patched?
Through compensating controls, which is exactly what the zone and conduit model is for. If a device cannot be patched or hardened, restrict what may communicate with it, inspect that traffic, monitor for anomalous commands, and control the access paths that reach its zone. Document the reasoning, because auditors and regulators will ask why an unpatched device is acceptable — and a documented compensating control is a defensible answer where an unexplained exception is not.
QWhere do most OT intrusions actually begin?
On the enterprise side, then across a poorly controlled IT/OT boundary — or through remote and vendor access paths that were established for maintenance convenience and never properly monitored. Attackers rarely need an exotic industrial exploit when an engineering workstation on a flat network provides direct reach. That is why closing the IT/OT boundary and controlling third-party access deliver more risk reduction than device-level hardening in most environments.
Adayptus Tech Team
Strategic Intelligence Division
Adayptus Consulting is a premier provider of enterprise cybersecurity solutions, specializing in Managed SOC, Penetration Testing, and GRC strategy. Our intelligence division regularly publishes research to help CISOs navigate the evolving threat landscape.
