IEC 62443-1-x: the words everyone argues about

Two people stood next to a 33 kV switchgear room at a 220 MW solar plant last autumn, both holding the same audit checklist, both fluent in the same standard, and both completely talking past each other. The certification body's lead auditor said the inverter SCADA "needed SL 3." The integrator's project manager replied, calmly, "we're already SL 3 — the components are certified." The plant's OT engineer, who had to live with whatever they agreed, asked the only question that mattered: "SL 3 of what? Target, achieved or capability? For which zone?"

That is the conversation IEC TS 62443-1-1:2009 was written to prevent. It usually fails to prevent it — not because the standard is bad, but because almost nobody on a real site has actually read it. They've read a vendor white paper that quoted it, a NIS2 mapping table that paraphrased it, or a slide deck that confused it with IEC 62443-3-3. The vocabulary then drifts, the audit grinds, and the asset owner pays for the misunderstanding.

This post is a slow, deliberate walk through the Part 1 documents of the ISA/IEC 62443 series — the foundation group. These are the documents that define what every other part of the series means by IACS, zone, conduit, security level, foundational requirement, essential function, asset owner, integrator and so on. If you've already read my walkthroughs on IEC 62443-2-x , IEC 62443-3-2 and 3-3 or IEC 62443-4-1 and 4-2 , this is the post that explains why those other posts spend so much time being careful about wording.

TL;DR

IEC 62443-1-x is the foundation group of the IEC 62443 series. The only document in this group that is presently a published IEC deliverable on the IEC webstore as a standalone text is IEC TS 62443-1-1:2009 (a Technical Specification, edition 1.0, dating from July 2009) and the newer IEC TS 62443-1-5:2023 (Technical Specification on security profiles). Parts 1-2 (master glossary), 1-3 (system security conformance metrics) and 1-4 (IACS security lifecycle and use cases) are still under development by ISA99 / IEC TC65 WG10 — they are referenced throughout the series but you cannot, today, buy them as finished documents. That fact alone resolves a surprising number of workshop arguments. Everything below explains the rest.

1. The series map — where 1-x sits and which other parts depend on it

The IEC 62443 series is organised, formally, into four document groups. The ISA99 committee — co-publishing with IEC TC65/WG10 — describes them as:

General (1-x): the terminology, the reference model, the conceptual scaffolding. This is where IEC 62443-1-1 lives.
Policies and procedures (2-x): what an asset owner organisation has to do to run a programme. IEC 62443-2-1:2024 is the live anchor here; 2-3, 2-4 and the upcoming 2-2 (currently IEC PAS 62443-2-2:2025) flesh it out.
System (3-x): technical system-level requirements. IEC 62443-3-2 is the risk-assessment / zoning standard, IEC 62443-3-3 is the catalogue of system requirements tied to the seven foundational requirements.
Component (4-x): secure development lifecycle for product suppliers (IEC 62443-4-1:2018) and component-level technical requirements (IEC 62443-4-2:2019).

A more recent fifth group, Profiles (6-x and the planned 5-x family), was added once IEC formally designated the series as a horizontal standard in 2021 — meaning vertical-industry committees should reference 62443 rather than write their own. That horizontal designation is why IEC TS 62443-1-5:2023 exists: it specifies the scheme by which sector-specific profiles get written and accepted.

Every later document in the series points back to IEC 62443-1-1 for definitions. When IEC 62443-3-3 writes "SR 1.1 Human user identification and authentication … shall be capable of … Security Level 2", the word "Security Level" is not defined there. It is defined in 1-1. When IEC 62443-2-1:2024 talks about an "asset owner" and a "service provider," those roles are defined in 1-1. When IEC 62443-4-2 rates a component at SL-C 2 for FR3, the meaning of foundational requirement, capability, level and component all trace back to 1-1. The whole series hangs from this hook.

That has two practical consequences. First — if you are designing a programme today, you must own and read IEC TS 62443-1-1:2009. Not summaries of it. The actual PDF from the IEC webstore, publication 7029 . Second — you must accept that the document is sixteen years old and the second edition is still being written. Some of the language has moved on (the series talks about "service providers" and "automation solutions" with more precision now), but the definitions of zones, conduits, SL-T/SL-A/SL-C and the seven FRs in 1-1 remain the canonical ones until the second edition lands.

2. IACS, ICS, OT, ICS-cybersecurity — what the standard actually says

This is the first thing people get wrong, and the first thing IEC 62443-1-1 defines.

IACS — Industrial Automation and Control System. This is the 62443 term of art. IEC TS 62443-1-1:2009 defines IACS broadly: a collection of personnel, hardware, software and policies involved in the operation of an industrial process and that can affect or influence its safe, secure and reliable operation. Crucially, personnel and policies are inside the boundary of an IACS. It is not "the network." It is not "the controllers." It is the operating socio-technical system. IEC 62443-2-1:2024 reinforces this — its scope explicitly inherits "the broad definition and scope of what constitutes an IACS as described in IEC TS 62443-1-1."

ICS — Industrial Control System. A narrower term. Generally used to denote the control technology subset — PLCs, DCSs, SCADA, RTUs, HMIs, the engineering workstations and the industrial network that ties them together. In the older IEC TR 62443-3-1:2009, the language used was "ICS" because the term predates the IACS-centric reframing. In modern 62443 documents the preferred umbrella term is IACS, with ICS appearing as a near-synonym in references to the control technology layer.

OT — Operational Technology. Not an IEC 62443 term. OT is the term used by NIST SP 800-82 Rev. 3 (September 2023) , whose title is "Guide to Operational Technology (OT) Security." NIST defines OT as "programmable systems and devices that interact with the physical environment (or manage devices that interact with the physical environment)." Revision 3 widened the scope from the older "ICS" framing of revisions 1 and 2 because building automation, transportation, physical access control and environment monitoring did not fit comfortably under "industrial." OT is the superset of ICS and the closest external term to IACS, but OT does not include personnel and procedures — IACS does.

ICS-cybersecurity / OT-cybersecurity / IACS security. Used interchangeably in practice. Internally to 62443 they are all "IACS cybersecurity."

The argument this resolves: at the audit I mentioned, the question "is the engineering laptop part of the system?" was disputed. The integrator argued no — it's IT, not an inverter. The asset owner argued yes — it programmes the inverters. The standard agrees with the asset owner. Under IEC 62443-1-1, the engineering laptop is part of the IACS because it influences safe, secure and reliable operation. The label on its asset tag does not exempt it.

In renewable-energy work specifically, this matters constantly. A solar plant's IACS includes the inverter SCADA, the meteorological-station data path, the protection relays in the 33 kV switchgear, the BESS battery management system, the network gear at the substation, the engineering laptops the O&M team plug in monthly and the OEM's remote-support VPN. None of those can be argued out of scope on the grounds that they are "just IT" or "just safety."

3. The reference model (Levels 0-5) and how it relates to Purdue

IEC TS 62443-1-1:2009 lays out a hierarchical reference model used throughout the series. It is informed by the Purdue Enterprise Reference Architecture (PERA) from Purdue University's PLAIC programme, but it is not identical to it. The 62443 reference model defines functional levels — abstract bands — that describe where activities sit in the automation hierarchy.

The levels, as used across the series:

Level 0 — Process. The physical equipment under control: turbines, transformers, inverters, valves, motors, the actual equipment doing work.
Level 1 — Basic control. Sensors, actuators, controllers (PLCs, IEDs, drive controllers, BMS controllers). Real-time, deterministic.
Level 2 — Area / supervisory control. HMIs, local SCADA front-ends, plant historians' acquisition layer. Operator-facing, still real-time-adjacent.
Level 3 — Site / operations control. Plant-level systems: site historian, MES-equivalents, engineering workstations, plant-wide SCADA. Still inside the IACS.
Level 3.5 — DMZ. The industrial demilitarised zone. Brokered data exchange between operations and the corporate enterprise. Not present in the original Purdue model; added in industrial-cybersecurity practice and treated by 62443 as a zone boundary.
Level 4 — Site business planning and logistics. ERP, MES proper, business systems at the site level.
Level 5 — Enterprise. Corporate IT.

IEC 62443-1-1 is careful about one point that almost everyone gets wrong: levels are functional, not topological. Two devices on the same physical VLAN can sit at different reference-model levels. A PLC at Level 1 can be in the same room as a historian at Level 3. The reference model tells you what the device does, not where its Ethernet cable terminates.

The relationship with Purdue is therefore "compatible, not identical." Purdue gave us the hierarchical metaphor. 62443 added security-zone reasoning on top — zones do not have to follow Purdue levels, although in most well-designed plants they end up doing so for very good reasons.

Why this matters for renewable plants: a modern solar site rarely fits the textbook Purdue diagram. Inverter manufacturers push cloud-connected telemetry directly out of Level 1 devices. BESS systems often arrive with their own walled-garden cloud at "Level 3-ish" without ever transiting a plant historian. Wind turbines connect through OEM remote-support tunnels that bridge Levels 1 and 5 and pretend they don't. IEC 62443-1-1 lets you describe these architectures honestly — by zone and conduit, with explicit reference-model levels for each function — without forcing a clean Purdue picture that has never matched reality.

4. Zones and conduits — and what counts as a zone boundary

The single most consequential pair of definitions in IEC TS 62443-1-1:2009:

A security zone is a grouping of logical or physical assets that share common security requirements.
A conduit is a logical grouping of communication channels — sharing common security requirements — that connects two or more zones.

Three things follow that catch people out.

First — zones group by security requirement, not by topology or function alone. A zone is whatever set of assets you can defensibly argue needs the same protection, the same trust, the same monitoring, the same access regime. Two physically separated wind-turbine arrays at different voltages can be one zone if they share security requirements. A single substation control building can contain three zones (relay protection, station SCADA, telecom gateway) if those functions warrant different protection levels. The rule of thumb I use on audits: if two assets would, on this site's risk register, ever justify different controls — they are not in the same zone.

Second — conduits are not "the firewall." A conduit is a logical construct: the set of communication channels with shared security needs that crosses a zone boundary. The firewall, switch, data diode or VPN concentrator is a component of the conduit, not the conduit itself. This is why IEC 62443-3-3 requirements apply to conduits as well as zones: a conduit has SL targets, capabilities and an achieved level of its own.

Third — "trust zone" is not the same as "security zone." A trust zone (in the IT zero-trust sense) is a boundary at which identity and policy are re-evaluated. A 62443 security zone is a boundary at which security requirements change. They overlap but are not synonymous. Saying "we've zero-trusted the OT network so we don't need zones" is a category error. The 62443 zone definition still applies; zero trust is one possible means of enforcing the conduit between two zones.

A practical zone-boundary checklist for a hybrid renewable site:

Where does the cyber-physical risk profile change? (e.g. moving from inverter control to battery thermal management to grid protection)
Where does the population of users / vendors / service providers change?
Where do regulatory or contractual obligations differ (e.g. grid-code-mandated systems vs. owner-operated systems)?
Where does the consequence of compromise change in kind (revenue loss vs. safety vs. grid stability)?

Each affirmative answer is a candidate zone boundary. Each is, by IEC 62443-1-1, the basis for a conduit.

This is the input that IEC 62443-3-2 consumes when it asks for a partitioned system under consideration (SuC) with documented zones and conduits. The reasoning lives in 1-1; the methodology lives in 3-2; the control catalogue applied to each zone and conduit lives in 3-3.

5. Security Levels — SL-T, SL-A, SL-C, and the often-confused SL 1-4 numeric scale

This is the section that, if I were writing this post for one person only, would be the entire post.

IEC TS 62443-1-1:2009 defines a Security Level as a measure of confidence that an IACS is free from vulnerabilities and functions in the intended manner. It then defines four numeric bands:

SL 1 — protection against casual or coincidental violation.
SL 2 — protection against intentional violation using simple means with low resources, generic skills and low motivation.
SL 3 — protection against intentional violation using sophisticated means with moderate resources, IACS-specific skills and moderate motivation.
SL 4 — protection against intentional violation using sophisticated means with extended resources, IACS-specific skills and high motivation.

These four levels describe threat actor capability. They do not, on their own, describe a plant, a product, a zone or a control.

The next step is where everyone goes wrong. The series defines three types of Security Level, and the numeric scale (1-4) applies to each:

SL-T (Target) — the security level a particular zone or conduit needs to achieve based on its risk assessment. SL-T is selected, on a per-zone, per-FR basis, by the asset owner in the context of IEC 62443-3-2 . The output of risk assessment is an SL-T vector — seven numbers, one per foundational requirement — for each zone and each conduit.
SL-C (Capability) — the security level a component or system is capable of meeting when properly configured and integrated. SL-C is what a product supplier declares about a device, tested against IEC 62443-4-2 for components or IEC 62443-3-3 for systems. A certified PLC might be SL-C 2 across all seven FRs, or SL-C 3 for FR1 and SL-C 2 for everything else. The certificate carries the vector.
SL-A (Achieved) — the security level the as-built, as-operated zone or conduit actually delivers in service. SL-A is measured (or estimated) after design, integration, commissioning and operational handover. It is, in practice, what your audit evidence is supposed to prove.

The chain that the standard wants you to walk is therefore: SL-T (from risk) → choose components / system with sufficient SL-C → design and operate to deliver SL-A ≥ SL-T. If SL-A falls short of SL-T, you must either accept residual risk, apply compensating countermeasures, or change the design.

This is why the auditor and the integrator were arguing past each other in the opening scene. The integrator said "we're SL 3" meaning SL-C 3 for the components they shipped. The auditor said "we need SL 3" meaning SL-T 3 for the zone. Neither had measured SL-A. A component with SL-C 3 dropped into a zone with SL-T 3 does not automatically produce SL-A 3 — that depends on configuration, integration, the surrounding compensating countermeasures, and whether the operational practices (covered in IEC 62443-2-1:2024 ) actually sustain the capability.

Three further traps the vocabulary still doesn't fully resolve:

SL is per foundational requirement, not a single scalar. Saying "we're SL 2" without a vector across FR1-FR7 is, strictly, not a 62443 statement. The standard expects a tuple. In practice many programmes report a single dominant value plus exceptions; that's defensible if the exceptions are listed.
IACS-wide SL vs zone SL. There is no such thing as an "IACS-wide SL" in IEC 62443-1-1. SLs apply to zones and conduits. An IACS is a collection of zones, each with its own SL-T vector. A single-number SL for an entire plant is a marketing artefact.
Maturity level (ML 1-4) is not Security Level. Maturity Levels appear in IEC 62443-2-4 (service-provider requirements) and IEC TS 62443-6-1:2024 (the evaluation methodology for 2-4). ML measures the maturity of a process. SL measures the security level of a zone, conduit, system or component. They are different scales for different things and are not interchangeable.

6. The seven Foundational Requirements (FR1-FR7)

IEC TS 62443-1-1:2009 defines seven foundational requirements. They are the columns of the matrix that the rest of the series fills in.

FR1 — Identification and Authentication Control (IAC). Who or what is requesting action, and have they proven it?
FR2 — Use Control (UC). Are they permitted to do the requested action?
FR3 — System Integrity (SI). Is the integrity of code, data and configuration maintained against intentional and unintentional change?
FR4 — Data Confidentiality (DC). Is information at rest and in transit protected from disclosure where required?
FR5 — Restricted Data Flow (RDF). Are data flows partitioned along zone and conduit boundaries?
FR6 — Timely Response to Events (TRE). Are security-relevant events detected, logged, alerted and responded to in time?
FR7 — Resource Availability (RA). Are essential functions kept available under stress, attack or degradation?

Two important things about the FRs that the vocabulary still trips people on.

FRs are not controls. They are objectives. IEC 62443-3-3 decomposes them into System Requirements (SRs) and Requirement Enhancements (REs), and IEC 62443-4-2 decomposes them again into Component Requirements (CRs). The phrase "we are compliant with FR3" is meaningless on its own — what is meaningful is "we meet SRs 3.1 through 3.9 at SL-C 2 in zone X, with REs for 3.4 and 3.8 applied." If a vendor's data sheet just says "compliant with FR3" with no SR / CR detail and no SL vector, treat that as marketing copy.

The ordering of FRs is not a priority order. FR1 is not "more important" than FR7. In OT, the opposite is often true: FR7 (resource availability) and FR3 (system integrity) frequently outrank FR4 (data confidentiality) in the risk register. The FRs are an enumeration, not a ranking.

The seven FRs are also the dimensions of every SL vector. When an integrator hands you a IEC 62443-3-3 compliance matrix for a system, it should be a 7-column grid keyed to FR1 through FR7 with an SL-C value in each cell. When the asset owner derives SL-T from IEC 62443-3-2, the output is the same shape. The reason for matching shapes is so SL-C and SL-T can be compared component-by-component.

7. Roles — asset owner, system integrator, product supplier, service provider

IEC 62443-1-1 introduces the role taxonomy that the rest of the series operationalises. Subsequent ISA99 work and the ISAGCA Quick Start Guide sharpen these into four principal roles:

Asset owner. The organisation accountable for the IACS in operation. In renewables this is the IPP, the utility, the asset-management company — whoever bears operational and regulatory accountability for the plant. Asset-owner-facing requirements live primarily in IEC 62443-2-1:2024 .
Product supplier. The organisation that designs, develops and supports a product — a component or a system — used in the IACS. Product suppliers are addressed by IEC 62443-4-1:2018 (development-process requirements) and IEC 62443-4-2:2019 (component-level technical requirements) .
System integrator. The organisation that takes products from suppliers and assembles them into an automation solution for an asset owner. Integrators are addressed by IEC 62443-2-4:2023 (security programme requirements for IACS service providers) in their integration role, and by IEC 62443-3-2 and 3-3 where they execute the design and verification on behalf of the asset owner.
Service provider. The organisation that operates, maintains, monitors or otherwise services the IACS after handover. IEC 62443-2-4 covers them too — explicitly distinguishing between integration service providers and maintenance service providers.

The maintenance-service-provider role is the one that's most often invisible in renewable contracts and the one that causes the most pain at year-three audits. The OEM that ships you the turbines is a product supplier. The EPC who built the wind farm is a system integrator. The O&M contractor who comes on site every quarter — and the OEM remote-support team behind a VPN tunnel — is a maintenance service provider, and IEC 62443-2-4 requirements apply to them. If your O&M contract is silent on cybersecurity capability requirements, you've shifted the maturity rating of your programme down. That is an IEC 62443-2-1 problem caused by a vocabulary problem from 1-1.

The argument this vocabulary resolves: when "the vendor" is doing remote support on a Sunday night to recover an inverter, is that a product supplier action or a service provider action? The answer matters because the requirement sets are different. Under IEC 62443-1-1 it is a service-provider action (they are performing operational work on the as-built solution), and your contract should reflect 2-4 capability requirements.

8. Essential functions and compensating countermeasures

Two more IEC 62443-1-1 terms that everyone uses sloppily.

Essential function. A function whose loss of operation, or operation in a degraded state, could cause unacceptable consequence to safety, integrity or availability. In a solar plant, essential functions include: protection tripping at the 33 kV / HV interface, BESS thermal runaway shutdown, primary frequency response (if the site provides ancillary services), and the safety-related controls of any high-voltage switchgear. Essential function is not the same as important function. The bar is "loss is unacceptable," not "loss is inconvenient." IEC 62443-3-3 explicitly says certain SRs apply more strictly where essential functions are at stake — for example, requirements around denial-of-service tolerance lean heavily on the essential-function concept.

The practical consequence: when you draw the zone diagram for IEC 62443-3-2 , every essential function must end up identified and traceable to a zone. SL-T for that zone is then influenced by the consequence of compromise of that essential function. A zone that hosts only "important" functions can have a lower SL-T than one hosting essential functions.

Compensating countermeasure. A control applied because the inherent control cannot be implemented or is impractical. The standard's logic is: if you cannot meet an SR directly inside a zone, you can apply a compensating countermeasure elsewhere (often in the surrounding conduit, or by procedural means) provided you can argue the residual risk is equivalent. Compensating countermeasures are not "we skipped it because it was hard." They are documented, justified and traceable. A reasonable example: a legacy inverter controller that cannot enforce strong human-user authentication directly (FR1 / SR 1.1) can be compensated by a jump host inside the conduit, plus an admin-procedure that proves which named human used which session — provided that compensation is documented, tested and reviewed at the frequency the security programme requires.

The argument this resolves: when a procurement team writes "the system shall comply with IEC 62443-3-3 SL 2 across all FRs without exceptions," they have written a procurement requirement that may be impossible to satisfy with the field equipment that physically exists. The standard expects exceptions, expects compensating countermeasures, and expects them to be argued on paper. Buying as if compensating countermeasures were a sign of weakness rather than a normal output of design is itself a misreading of IEC 62443-1-1.

9. The security lifecycle (from 1-4) — assess, design, implement, maintain

IEC TR 62443-1-4 — IACS security lifecycle and use cases — is a Technical Report, currently still in development at the ISA99 / IEC TC65 WG10 level. Drafts have circulated within the committee since around 2013. It is intended to provide a detailed description of the underlying lifecycle that the rest of the series assumes, with worked use cases. It is not, as of writing, a finished IEC deliverable on the IEC webstore . What is published — and widely cited — is the ISAGCA Security Lifecycles whitepaper by ISA's Global Cybersecurity Alliance, which captures the same conceptual content pending the formal TR.

The lifecycle the series uses has four broad phases:

Assess. Risk assessment, definition of the SuC, zoning and conduit partitioning, derivation of SL-T per zone and conduit per FR. This is the home of IEC 62443-3-2 and the entry point for any new project or major modification. IEC 62443-2-1:2024 makes assess-phase activities a programme requirement for asset owners.
Design and implement. Selection of products and integrators with adequate SL-C against SL-T, design of compensating countermeasures, factory acceptance test (FAT) and site acceptance test (SAT) including cybersecurity test cases, commissioning. IEC 62443-3-3 is the design-verification reference; IEC 62443-4-2 is the component-selection reference; IEC 62443-2-4 is the integrator capability reference.
Operate and maintain. Patch management, account hygiene, monitoring, incident response, periodic re-assessment, supply-chain controls for maintenance service providers. IEC 62443-2-1:2024 is the operating-phase reference. IEC TR 62443-2-3:2015 covers patch management.
Decommission. Secure handling of credentials, configurations, decommissioned assets, residual data. Often the most neglected phase. The maintenance documentation says "decommission per OEM instructions" and the OEM instructions are silent on cybersecurity.

The lifecycle in 1-4 and ISAGCA's whitepaper is not linear. It is the intersection of three lifecycles: the product lifecycle (owned by product suppliers), the automation-solution lifecycle (owned by integrators) and the operations lifecycle (owned by asset owners and service providers). Where they intersect is where contracts, evidence and handovers live. That's why renewable-energy plant cybersecurity is so contract-driven: the lifecycle model in 1-4 is the only way to map who has to prove what to whom at which milestone.

The argument this resolves: "we did IEC 62443-3-2 at the design phase, so we're compliant." No — 3-2 is one activity in the assess phase. The lifecycle continues for the next twenty years. A zoning document from 2024 is stale by 2028 unless re-validated. The lifecycle framing in 1-4 is what forces that continual re-validation into the contract.

10. Metrics (1-3) — what "compliance metric" attempts and why it is hard

IEC 62443-1-3 — System security conformance metrics (sometimes written as "compliance metrics" in older committee correspondence; the published title uses conformance) — is under development as a Technical Report. Its objective: define a methodology to derive quantitative metrics from the process and technical requirements that the rest of the series specifies. In plain terms — turn "comply with 3-3 SR 1.1 at SL-C 2" into a number you can measure, report and trend.

This is harder than it sounds, and the reasons it's hard are worth being honest about:

Most 62443 requirements are capability statements, not measurements. "The system shall be capable of human-user identification and authentication" is a binary at first glance, but capability under different operational conditions is not. Does a capability that requires manual configuration count? Only when configured? Only when audited?
SL is not a metric, it is a level. Turning a level into a metric requires deciding what proportion of requirements at that level must be met, with what evidence, at what frequency. Different organisations have different answers, and the standard is rightly reluctant to mandate one universal answer.
Asset owners want time-series metrics. "How is our 62443 posture trending quarter on quarter?" is a perfectly reasonable executive question. The 62443 framework, born from engineering rather than from information-security management, has historically been better at point-in-time conformance than at time-series telemetry.
IEC 62443-2-2 overlaps. The Protection Scheme (SPS) work in the current IEC PAS 62443-2-2:2025 introduces security programme ratings (SPR) which provide a related but separate measurement framework. The relationship between 1-3 metrics and 2-2 SPRs has been an active area of committee work.

Until 1-3 lands as a published TR, asset owners build their own metrics. Reasonable choices include: percentage of zones with current 3-2 documentation; percentage of components with SL-C ≥ SL-T per FR; percentage of maintenance service providers with documented 2-4 capability; mean time from CVE publication to patch verification; percentage of essential functions with tested fallback procedures. None of those are 62443-mandated, but each is defensible and traceable to a 1-1 concept.

The argument this vocabulary resolves: when management asks "are we 62443 compliant — yes or no?" you can correctly answer "the series doesn't work that way." IEC 62443-1-1 does not define a single binary state of compliance for an IACS. It defines roles, capabilities, levels and zones, each of which can be assessed. A 62443 programme in IEC 62443-2-1 can be conformant. A component can be SL-C certified. A zone can have an SL-A that meets its SL-T. The plant as a whole is the sum of those statements, not a single yes/no. Pretending otherwise is what produces the unfortunate sales pitch "we're 62443 compliant" — which is usually short for "we sell a product that someone certified once."

11. The arguments this vocabulary still doesn't resolve

For all that IEC TS 62443-1-1:2009 settles, plenty of arguments remain genuinely open. Some are about the world having moved on since 2009; some are about gaps the second edition is meant to close; some are about places where the standard is intentionally silent.

Cloud and IIoT. IEC 62443-1-1 was written before "the cloud" was a routine deployment target for industrial telemetry. Where does AWS IoT Core sit on the reference model? Is it Level 3? Level 4? Level 5? Is the OEM's cloud a zone of the IACS at all, given that the asset owner does not run it? The forthcoming IEC TR 62443-1-6 (Application of the ISA/IEC 62443 series to the Industrial Internet of Things) is intended to address exactly this. Until it lands, asset owners deal with it case by case — most commonly by treating the cloud endpoint as a zone owned by a service provider with a defined conduit to the on-site IACS.

Wireless and 5G. Same problem. Wireless links are conduits with peculiar physical-layer threat models. The series broadly accommodates them, but the practical question of whether a 5G slice is a conduit or a zone is unresolved in published text.

Safety-security interaction. IEC 61511 (functional safety) and IEC 62443 (cybersecurity) overlap explicitly at the safety-instrumented system. Where the safety lifecycle and the security lifecycle disagree — for example, on patching of safety PLCs — the standards do not perfectly reconcile. Recent ISAGCA work and IEC TR 63069:2019 provide partial guidance. The argument continues in real audits.

Horizontal designation and sector profiles. The 2021 designation of 62443 as a horizontal standard means vertical-sector committees should reference it rather than redefining its terms. IEC TS 62443-1-5:2023 formalises the scheme for sector profiles. But the content of sector profiles for renewable energy, water, building automation, medical devices and so on is still being written, and the meaning of "SL-T 2" in a hospital differs materially from "SL-T 2" on a wind farm. The vocabulary holds; the calibration differs.

Second edition of 1-1. A second edition has been circulating for committee review since 2021. It will refine some definitions, add ontology-driven precision (the WG5TG3 consistency task group has done substantial work on this) and reflect lessons from the rest of the series. Until it is published, IEC TS 62443-1-1:2009 is the authoritative reference, and there is some risk that conscientious readers find local divergence between the 2009 text and newer parts.

Mandatory or not? IEC 62443 is not, by itself, a law anywhere. The European NIS2 Directive names "European standards and specifications relevant to security of network and information systems" — and IEC 62443 is widely cited as the most-relevant reference for the OT scope, but the directive does not mandate 62443 by document number. Norway, where I work, is transposing NIS2 with similar latitude. The EU Cyber Resilience Act imposes binding cybersecurity essential requirements on products with digital elements; harmonised standards under the CRA will lean heavily on 62443-4-1 and 4-2, but again, document numbers are not in the legal text. For renewable-energy operators in Europe, the practical answer is: 62443 is voluntary by name but functionally required by procurement, insurance, regulator expectation and supply-chain pressure. See my walkthroughs on NIS2 applicability and CRA applicability for the detail.

Red flags in conversation

A short field guide. These are the phrases that, when I hear them in a workshop or an audit, tell me the speaker has not read IEC TS 62443-1-1:2009 recently and probably has not read it at all.

"We're SL 3 compliant." Compliant against what? Target, capability or achieved? For which zone? For which FRs? On what evidence? Without those qualifiers it's a marketing phrase.
"The whole plant is SL 2." There is no plant-wide SL in IEC 62443-1-1. SL applies to zones and conduits.
"OT and IACS are the same thing." They overlap, but OT (per NIST SP 800-82r3) is a broader term and excludes the personnel and process scope that IEC 62443-1-1 includes in IACS. They are not synonyms.
"FR3 is a control we implemented." FR3 is a foundational requirement — an objective. Controls are SRs, REs and CRs underneath it. If someone calls an FR a control they have skipped a level of the standard.
"Our PLC is 62443-certified." Against which part? 4-1? 4-2? At which SL-C? Across which FRs? "62443-certified" is not a specification.
"Zones are just VLANs." Zones are groupings by shared security requirement. VLANs are one possible enforcement mechanism for the conduit between zones. The two concepts are at different levels of abstraction.
"We don't need compensating countermeasures, we're fully compliant." A 62443 design with no documented compensating countermeasures on a real industrial site is almost always wishful thinking, not rigour.
"IEC 62443-1-1 is just definitions, we can skip it." It defines every term the rest of the series rests on. Skipping it is how the audit conversation in this post's opening scene happens.
"The integrator handed over an SL-T document, so we're done." SL-T is the input to design, derived from risk. SL-A is what you must measure post-commissioning and re-measure through the lifecycle. SL-T on its own proves intent, not delivery.
"Maturity level 3 equals security level 3." They are different scales for different objects. ML measures process maturity; SL measures zone, conduit, system or component security.

Each of these red flags points back to a section of IEC 62443-1-1. The remedy is rarely to argue louder; it is to open the document and read the relevant definition together. The vocabulary, once shared, removes about two-thirds of the disagreements that consume audit time.

FAQ

What is IEC 62443-1-1?

IEC TS 62443-1-1:2009 is the foundation Technical Specification of the IEC 62443 series. Published by IEC in July 2009 (edition 1.0), it defines the terminology, concepts and reference models that the rest of the series uses — including IACS, zones, conduits, security levels (SL-T, SL-A, SL-C), the seven foundational requirements (FR1-FR7) and the principal roles (asset owner, product supplier, integrator, service provider). It is available from the IEC webstore as publication 7029 . A second edition has been in committee review at ISA99 / IEC TC65 WG10 since 2021.

What is the difference between SL-T and SL-C?

SL-T (Target) is the security level a particular zone or conduit needs to achieve, derived from risk assessment under IEC 62443-3-2 . SL-T is an asset-owner output: it says "this zone needs SL 3 across these FRs because of the risk profile here." SL-C (Capability) is the security level a component or system is capable of meeting when properly configured. SL-C is a product-supplier output, certified against IEC 62443-4-2 (components) or IEC 62443-3-3 (systems). A component with SL-C 3 dropped into a zone with SL-T 3 does not automatically deliver SL-A (Achieved) 3 — that depends on configuration, integration, compensating countermeasures and operational practices.

Is IEC 62443 mandatory?

By itself, no. IEC 62443 is a voluntary international standards series, not legislation. However, it is referenced or relied upon by a growing list of frameworks that are binding — the EU NIS2 Directive, the EU Cyber Resilience Act, sector regulators and national transpositions in countries including Norway. Procurement contracts, insurance requirements and supply-chain expectations increasingly cite specific parts (commonly IEC 62443-2-1, 3-3, 4-1 and 4-2). The practical answer for an asset owner in critical infrastructure is: not mandatory by name, but very often mandatory by the things that are mandatory. See my posts on NIS2 applicability and CRA applicability for the full chain of reasoning.

Why isn't IEC 62443-1-2 (the master glossary) available?

Because, as of 2025-2026, it is still under development at ISA99 / IEC TC65 WG10. The ISAGCA Structuring the ISA/IEC 62443 Standards writeup notes that 1-2 "is a master glossary of terms and abbreviations used throughout the series" and that the committee intends to deliver it in an online format. Until it is published as a finished IEC deliverable, the authoritative definitions remain those given inside IEC TS 62443-1-1:2009 and inside each numbered part's own definitions clause. Cross-reference with NIST SP 800-82 Rev. 3 is useful for OT/ICS terminology that touches but is not identical to 62443's IACS vocabulary.

How do zones and conduits relate to the Purdue model?

The Purdue Enterprise Reference Architecture (PERA) is a hierarchical functional model — Levels 0 through 5 — that describes where activities sit in an automation hierarchy. IEC 62443-1-1's reference model is informed by Purdue but adds the security concepts of zones and conduits on top. A zone groups assets that share common security requirements; a conduit is the set of communication channels between zones. Zones do not have to align one-to-one with Purdue levels, although in well-designed plants they often do for sensible engineering reasons. The two models are complementary, not competing.

Further reading on this site: the management-system view is in IEC 62443-2-x: what asset owners must prove ; the system-design view is in IEC 62443-3-2 and 3-3: what asset owners and integrators must prove ; the product-supplier view is in IEC 62443-4-1 and 4-2: what OEMs must prove . Read them in any order — but read this one first, because it's the document the others assume you already understand.