The international standard series for securing Industrial Automation and Control Systems, covering asset owners, integrators, and product suppliers.

What is the difference between ISA 62443 and IEC 62443?

They are effectively the same standard; ISA developed it, and IEC published it internationally, so both names refer to the same series.

What are zones and conduits in IEC 62443?

Zones group assets by shared risk; conduits are controlled communication paths that enforce security between zones.

What are IEC 62443 security levels?

Four levels, SL1 to SL4, each describing resistance to a progressively more capable attacker.

Is IEC 62443 mandatory in the UAE?

Not directly. It typically arrives through procurement or as evidence of OT risk maturity. See NESA compliance.

How does IEC 62443 relate to the Purdue model?

The Purdue model provides the architectural layers; IEC 62443s zones and conduits apply security requirements within that structure. See our Purdue model guide.

Can a company be certified to IEC 62443?

Products, development processes, and individuals can each be certified separately, most commonly through the ISASecure scheme.

Does IEC 62443 require penetration testing?

The standard doesnt mandate it directly, though testing is a common way to validate achieved security levels against targets.

IEC 62443 for UAE Industrial Operators: Zones, Conduits and Certification

IEC 62443 is the international standard for securing Industrial Automation and Control Systems, splitting obligations across asset owners, system integrators, and product suppliers. Zones, conduits, and security levels are the core concepts that determine how the standard applies to a specific facility, and UAE operators in energy, water, and manufacturing increasingly encounter it through procurement requirements rather than direct regulation. This guide explains the standard's structure, the zone and conduit model, security levels, and the three distinct certification routes available.

Key Takeaways

Before applying IEC 62443 to a specific facility, these concepts shape everything else.

The standard splits into four groups by audience: General, Policies and Procedures, System, and Component, and most readers only need the group relevant to their role.
Zones group assets by shared risk and function; conduits are the controlled communication paths between them, and this model determines where security requirements actually apply.
Security levels run from SL1 to SL4, and every zone or conduit carries three distinct SL values: target, capability, and achieved.
Certification comes in three genuinely different forms: product certification, process certification for the supplier's development lifecycle, and personnel certification.
UAE relevance comes primarily through procurement and evidence of broader OT risk management expectations, rather than as a standalone legal mandate.

Understanding these fundamentals first makes the standard considerably easier to apply to a real facility rather than treating it as an abstract compliance checkbox.

Applying IEC 62443 in UAE Industrial Environments

UAE operators across energy, water, utilities, and manufacturing increasingly encounter IEC 62443 through procurement rather than direct regulatory mandate, most often when a contract, a parent company policy, or a tender specification asks for alignment with the standard without the buyer necessarily understanding what that alignment actually requires. Our OT security companies in the UAE guide covers the provider landscape UAE operators can draw on for this kind of implementation work.

The standard exists because industrial control systems carry risk profiles fundamentally different from conventional IT, where availability and safety, not confidentiality, drive the priority order, and where a poorly scoped security measure can itself cause the outage or safety event it was meant to prevent. Our Purdue model guide covers the architectural concept that underpins how IEC 62443's zone model gets applied to a real facility in practice.

How the 62443 Series Is Structured

The standard is a series of documents rather than a single publication, and it is organised into four groups by audience rather than by topic alone.

Group	Covers	Primary audience	Why it matters to you
General (1-x)	Terminology, concepts, and models used throughout the series	All readers	Establishes shared vocabulary before engaging with any other part
Policies and Procedures (2-x)	Security programme requirements for asset owners and service providers	Asset owners, plant operators	Defines what an operator's security management system must contain
System (3-x)	Risk assessment, zone and conduit design, system-level technical requirements	System integrators, plant security leads	Where zones, conduits, and target security levels actually get defined
Component (4-x)	Secure development lifecycle and technical requirements for individual products	Product suppliers, procurement teams	Specifies what security capability a purchased device must have

A plant security lead starting from nothing typically reads 62443-3-2 first, since it defines the risk assessment and zone design process everything else in the series depends on, then uses 62443-3-3 to understand system-level requirements at the target security level, and 62443-4-2 when procuring new components to specify what security capability the hardware needs to carry. Our OT security monitoring guide covers the operational detection layer that typically sits on top of whatever zone architecture a facility ultimately implements.

Zones and Conduits Explained

Zones and conduits form the standard's conceptual core, and understanding them properly is worth more than skimming every other part of the series. A zone is a grouping of assets that share a common security requirement, typically determined by risk and function rather than by physical location alone: a facility's safety instrumented systems form one zone, its process control network another, and its corporate-facing business systems a third, each carrying a materially different risk profile and therefore a different target security level.

A conduit is the defined, controlled communication path between two zones, and the standard requires that any communication crossing a zone boundary flow through an explicitly identified conduit rather than an unmanaged connection. This matters because a conduit is where security controls, firewalls, data diodes, and protocol filtering are applied; a zone without a properly enforced conduit boundary is, in practice, not meaningfully separated from whatever sits on the other side, regardless of how the network diagram labels it.

A worked example makes this concrete. Consider a UAE water treatment facility with a safety instrumented system controlling chemical dosing, a supervisory control network monitoring plant-wide operations, and a corporate IT network handling email and business applications. The safety instrumented system sits in its own zone with the highest target security level, since a compromise there carries direct physical safety consequences. The supervisory network forms a second zone, and the corporate network a third, with conduits enforcing strict, monitored, one-directional or tightly filtered communication between them. A vendor requesting remote access for maintenance connects through a conduit specifically designed and monitored for that purpose, not through an open path that happens to reach the safety system indirectly through the supervisory network.

Security Levels and What They Actually Mean

Security levels express how much protection a zone or conduit needs to resist attackers of a given sophistication, and the standard defines four of them.

Security level	Protects against	Attacker profile	Typical application
SL 1	Unintentional or casual misuse	No specific intent, low skill, incidental exposure	General office-adjacent systems with low direct process risk
SL 2	Intentional misuse using simple means	Low resources, generic skills, low motivation	Standard plant control network segments
SL 3	Sophisticated attacks using moderate resources	IACS-specific skills, moderate motivation	Critical process control zones
SL 4	Advanced attacks with extended resources	IACS-specific skills, high motivation, sophisticated tools	Safety instrumented systems, highest-consequence zones

The distinction that causes the most confusion in practice is that every zone or conduit carries three separate SL values, not one. Target security level (SL-T) is the level a risk assessment determines the zone needs, documented by the asset owner following the 62443-3-2 process. Capability security level (SL-C) is what a system or component can natively achieve without additional compensating measures, defined against 62443-3-3 or 62443-4-2 depending on whether it's being assessed at system or component level. Achieved security level (SL-A) is what's actually measured in the operating environment after implementation, and it's the figure an assessment checks against the target. A zone frequently shows an SL-A below its SL-T immediately after commissioning, and closing that gap, either through better-capable components or compensating procedural controls, is the practical work IEC 62443 implementation actually consists of.

Underpinning all of this are seven Foundational Requirements that structure every security level: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. Every specific technical requirement in the standard traces back to one of these seven categories.

Running a Risk Assessment Under 62443

The risk assessment and zone definition process follows a defined sequence under 62443-3-2, and understanding each stage helps set realistic expectations before starting.

System under consideration definition, establishing the boundary of what's actually being assessed.
Initial high-level risk assessment, a first-pass view of risk across the full system before detailed zoning begins.
Partitioning into zones and conduits, grouping assets by function and risk and defining the communication paths between them.
Detailed risk assessment per zone, a more granular assessment once zone boundaries are established.
Target security level assignment, setting SL-T for each zone and conduit based on the detailed assessment.
Gap analysis against current capability, comparing SL-T to what the environment currently achieves.
Countermeasure selection, choosing technical or procedural measures to close the identified gap.

Operators most commonly stall at asset inventory completeness rather than at the technical work itself, since accurately identifying and classifying every asset within a facility, particularly legacy equipment installed decades before this kind of formal risk process existed, is a genuinely time-intensive exercise that gets underestimated at project outset. Our OT vulnerability management guide covers the ongoing discipline this asset inventory work typically feeds into once it's established.

Certification Routes and What Each One Certifies

Buyers frequently ask a supplier for "62443 certification" without specifying which kind, and the confusion is understandable since the standard supports three genuinely different certification types that prove different things.

Product certification, most commonly delivered through the ISASecure scheme, certifies that a specific system or component meets the standard's technical requirements at a stated security level. System Security Assurance certifies an IACS system against 62443-3-3; Component Security Assurance certifies an individual component, such as an embedded device or network device, against 62443-4-2, with the certification explicitly naming the component type and capability level achieved.

Process certification, delivered as Security Development Lifecycle Assurance, certifies not the product itself but the supplier's development process against 62443-4-1, confirming that security was built into the product development lifecycle rather than bolted on afterwards. A product carrying CSA or SSA certification typically also required its supplier to hold or demonstrate SDLA-aligned development practices as part of that certification.

Personnel certification exists separately from both, certifying an individual's competence against the standard rather than any product or process, with named programmes such as exida's Certified Automation Cybersecurity Expert and Specialist credentials available through accredited certification bodies. A buyer asking whether "the team" is 62443 certified is really asking about this third, distinct category, separate entirely from whether the equipment itself carries a product certification.

IEC 62443 and UAE Regulatory Obligations

IEC 62443 is an international standard rather than a UAE legal requirement, and UAE operators typically encounter it as a procurement expectation or a way to demonstrate broader OT risk-management maturity, not as a direct legal mandate with its own enforcement mechanism. Our NESA compliance page covers the federal framework that does carry direct regulatory weight for UAE critical infrastructure operators, and entities pursuing both find genuine practical overlap: NESA's technical control families address many of the same underlying concerns- asset management, access control, incident response- that IEC 62443's zone and conduit model formalises specifically for industrial environments.

Critical national infrastructure operators in sectors like energy and water are the UAE entities most likely to be asked to align with IEC 62443, whether through a parent company's global security policy, an insurer's underwriting requirements, or a specific tender specification. Our critical national infrastructure page and energy sector page cover this sector-specific risk concentration in more depth.

Where to Start if You Operate Industrial Systems

Getting started with IEC 62443 follows a reasonably consistent sequence regardless of sector or facility size.

Build a genuine OT asset inventory, since every downstream step depends on knowing what's actually in the environment.
Define the system under consideration, establishing clear boundaries before attempting zone design.
Run a high-level risk assessment across the full system before committing to detailed zone boundaries.
Draft an initial zone model, grouping assets by shared risk and function.
Identify which parts of the series are relevant to your specific role, asset owner, integrator, or supplier, rather than attempting to absorb the entire series at once.
Decide whether formal certification is genuinely required for your situation, or whether alignment without third-party certification satisfies the actual business driver.

Sequencing realistically, rather than attempting full implementation simultaneously across every zone, tends to produce a more durable outcome than a rushed, parallel effort, and outcomes from any specific implementation approach should be treated as risk-reducing rather than guaranteed.

Don’t Let Cyber Attacks Ruin Your Business

Certified Security Experts: Our CREST and ISO27001 accredited experts have a proven track record of implementing modern security solutions
41 years of experience: We have served 2600+ customers across 20 countries to secure 7M+ users
One Stop Security Shop: You name the service, we’ve got it — a comprehensive suite of security solutions designed to keep your organization safe

Book Your Free Consultation Call Now

UK:

+44 (0)20 3336 7200

KSA:

+966 1351 81844

UAE:

+971 454 01252

Call
UK: +44 (0)20 3336 7200
KSA: +966 1351 81844
UAE: +971 454 01252

Contents