IEC 62443 Cybersecurity for Industrial Control Systems: Zone and Conduit Architecture in Practice

Last updated October 2026.

Most industrial networks that get breached were not missing a firewall. They had one, usually at the edge of the plant, and behind it a single flat network where an engineering laptop, a historian, three HMIs and every PLC could talk to each other freely. Once an attacker or a piece of ransomware crossed that one boundary, nothing else stood in the way. IEC 62443 is the standards family built to prevent exactly that outcome, by forcing engineers to divide an automation system into zones, control every conduit between them, and justify each decision with a risk assessment rather than a checklist.

In 2026 the standard matters more than it did when this article first appeared. Part 2-1 for asset owners was reissued in 2024, the EU Cyber Resilience Act starts mandatory vulnerability and incident reporting on 11 September 2026, and procurement teams now ask suppliers for IEC 62443 evidence by default. This guide walks the series part by part, explains the zone and conduit method and the three kinds of security level, works one risk assessment through with illustrative numbers, and covers certification and regulatory mapping.

What this covers: the structure of the series and which part applies to whom, the zone and conduit design method, SL-T/SL-C/SL-A and the seven foundational requirements, a worked example, certification routes, failure modes, and a practical rollout checklist.

Context and Background

Industrial automation and control systems (IACS) were designed for availability and determinism long before anyone worried about adversaries. Protocols such as Modbus, PROFINET and EtherNet/IP carry no authentication by default, controllers run for decades, and a patch window may come once a year during a planned shutdown. IT security practice, which assumes frequent patching, endpoint agents and tolerance for reboots, does not transfer cleanly. The ISA99 committee began the work that became IEC 62443 to supply a vocabulary and method suited to this setting, and the International Electrotechnical Commission (IEC) adopts the documents in parallel with ISA.

The series is organised by audience rather than by technology. Part 1 covers concepts and models. Part 2 addresses the programme side: how an asset owner or a service provider runs security as an ongoing activity. Part 3 addresses the system: how to assess risk, design zones and conduits, and specify system requirements. Part 4 addresses the product: how a supplier builds components securely and what technical capabilities those components must expose. The same three roles recur everywhere: asset owner, system integrator or service provider, and product supplier. Many arguments about “compliance” end once everyone agrees which role they are playing.

It helps to place IEC 62443 against its neighbours. NIST SP 800-82 gives ICS-specific guidance but no certifiable requirements. ISO/IEC 27001 certifies an information security management system and says little about control-system availability or safety. NERC CIP is mandatory for the bulk electric system in North America and is regulation, not engineering method. IEC 62443 is the one that is certifiable at the component, system and process level, which is why regulators and customers keep pointing at it. For the European regulatory picture see our comparison of the CRA, NIS2 and IEC 62443 for IoT and OT vendors.

The attacks that justify all this are well documented. The 2021 Colonial Pipeline ransomware incident was an IT-side compromise, yet the operator halted pipeline operations as a precaution because it could not be sure the business network was separated from operational technology (OT). That is the central lesson: the cost of a weak boundary is paid in forced shutdowns, not only in stolen data. Government advisories since then, including joint warnings about state actors pre-positioning in critical infrastructure, have pushed segmentation and monitoring from “good practice” to procurement criteria.

Where the series stands in 2026

Editions matter, because auditors cite them. As verified against the IEC webstore and the standards bodies for this update:

Part	Subject	Current edition
2-1	Security programme for asset owners	Edition 2.0, published 7 August 2024
2-4	Security programme for service providers	Edition 2.0, published 15 December 2023
3-2	Security risk assessment and system design	Edition 1.0, June 2020
3-3	System security requirements and security levels	Edition 1.0, August 2013
4-1	Secure product development lifecycle	Edition 1.0, January 2018
4-2	Technical requirements for components	Edition 1.0, February 2019

Two points deserve attention. The 2024 revision of 2-1 restructured requirements into security programme elements, removed overlap with ISMS standards, and added a maturity model. Parts 3-3, 3-2, 4-1 and 4-2 remain on their original editions; revisions are in committee work, but we did not find a confirmed publication date for any of them, so plan on the current editions and re-check before an audit. The 2023 edition of 2-4 is listed with a stability date of 2027.

The Zone and Conduit Reference Architecture

A zone is a grouping of assets that share the same security requirements; a conduit is a logical grouping of communication channels between zones that share the same security requirements. The method is to partition the system into zones, assign each a target security level, and place controls on every conduit so that the only traffic crossing a boundary is traffic someone approved.

Figure 1: A typical IEC 62443 zone and conduit layout. The IT/OT demilitarised zone (DMZ) is the only path between business systems and control networks, and vendor remote access terminates there rather than inside the control zone.

Figure 1 shows a common shape for a discrete or process plant. Business systems sit at the top, an IT/OT DMZ holds brokers, patch staging and jump hosts, and below it the supervisory, control and field zones narrow progressively. A separate safety zone hosts safety instrumented system (SIS) controllers, because safety functions have their own integrity requirements and must not share fate with the control network. Dotted arrows are conduits that carry managed, narrow flows such as a telemetry feed to cloud analytics.

Why zones are defined by risk, not by the Purdue model

Many teams start from the Purdue reference model, which stacks levels from field devices (Level 0) to the enterprise (Level 4 or 5), and simply draw one zone per level. That is a reasonable first sketch, and the 62443 documents themselves note that the Purdue model is a useful way to think about functional layers. But the standard does not mandate it, and treating it as the answer causes two recurring errors.

The first error is over-grouping. Level 2 may contain a packaging line, a boiler controller and a chemical dosing skid, and these have very different consequences if compromised. Part 3-2 asks you to group assets by shared risk and shared security requirements, which often cuts across Purdue levels. The second error is ignoring non-hierarchical flows. A cloud-connected condition-monitoring gateway, a wireless handheld or a vendor’s remote service channel does not respect level boundaries, so each needs to be modelled as an explicit zone or conduit.

A useful rule of thumb from practice: if two assets would need different security levels, or different people administer them, or one can be taken offline for patching while the other cannot, put them in different zones. If splitting creates more conduits than you can monitor, merge and raise the zone’s level instead. This balance between granularity and operability is where the engineering judgement lies.

What a conduit actually is

A conduit is not a cable or a firewall; it is the set of communication paths between two zones plus the controls applied to them. A conduit from the supervisory zone to the control zone might include OPC UA sessions, an engineering-tool channel and a time-sync flow, and it must be secured for the highest requirement among them. Typical controls are a stateful or application-aware firewall with an explicit allow-list, protocol inspection for industrial protocols, mutual authentication, integrity protection, and logging that feeds a monitoring system. Our comparison of OPC UA and MQTT Sparkplug B is useful when choosing which protocols to allow across a conduit, since OPC UA brings its own certificate-based security and Sparkplug relies on the broker and transport.

Conduits can also be trusted or untrusted. A conduit that crosses a network the asset owner does not control, such as a carrier link or the internet, is treated as untrusted and needs cryptographic protection end to end. A conduit inside a physically controlled cabinet may rely on other measures. Each conduit gets its own identifier and security requirements in the documentation, which makes later audits tractable.

Three kinds of security level

The most common source of confusion in the standard is that “security level” has three meanings, and each answers a different question. All use the same four-point scale, from SL 1 (protection against casual or coincidental violation) through SL 2 (intentional violation using simple means, few resources, generic skills), SL 3 (sophisticated means, moderate resources, IACS-specific skills) and SL 4 (sophisticated means, extended resources, IACS-specific skills). SL 0 denotes no specific requirement.

• SL-T (target) is the level a zone or conduit needs, derived from risk assessment. It is a requirement.
• SL-C (capability) is the level a component or system can reach when correctly configured. It is a property of the product, assessed against Part 4-2 for components and Part 3-3 for systems.
• SL-A (achieved) is the level actually in place in the running installation. It is measured, and it can be lower than SL-C if the product is misconfigured or unpatched.

The engineering task is to close the gap so that SL-A meets or exceeds SL-T for every zone and conduit, using components whose SL-C is sufficient or compensating controls where it is not.

Figure 3: SL-T comes from the Part 3-2 risk assessment, SL-C from component and system capability under Parts 4-2 and 3-3, and SL-A from the operational programme under Parts 2-1 and 2-4. The gap analysis drives either better components or compensating controls.

Security levels are also vectors, not single numbers. Part 3-3 allows a zone to be described by a level for each of the seven foundational requirements, so a zone might need SL 3 for restricted data flow but only SL 2 for data confidentiality. Treat the single number as shorthand for the highest element, and keep the vector in the documentation, since over-specifying everything to the maximum is the fastest way to blow the budget.

From Risk Assessment to Requirements: The Part 3-2 Method

Part 3-2 turns a vague wish to “secure the plant” into a documented design. It defines seven zone and conduit requirements (ZCR 1 to ZCR 7) that run from scoping to sign-off, and the output is a cybersecurity requirements specification (CSRS) that suppliers and integrators can price and build against.

Figure 2: The Part 3-2 workflow. A cheap initial assessment decides whether a detailed assessment is needed for each zone, which keeps effort proportionate to consequence.

The sequence is deliberately two-pass. First, identify the system under consideration (SUC) and its boundary, including every external connection (ZCR 1). Second, run an initial high-level risk assessment that assumes no countermeasures, to establish the worst-case unmitigated cybersecurity risk in terms of safety, environmental, financial and operational consequence (ZCR 2). Third, partition the SUC into zones and conduits, with a separate zone considered for safety systems, temporary connections and wireless where appropriate (ZCR 3). Fourth, compare the initial risk with the owner’s tolerable risk (ZCR 4). Where it exceeds tolerance, a detailed risk assessment follows for the relevant zones and conduits (ZCR 5). The results are documented as requirements, assumptions and constraints (ZCR 6), and the asset owner formally approves them (ZCR 7).

The detailed assessment, step by step

The detailed assessment (ZCR 5) is where most of the engineering effort lands. For each zone and conduit, the team identifies threats, vulnerabilities, likelihood and consequence, then determines the target security level, SL-T. It then selects countermeasures and re-evaluates residual risk. The standard does not prescribe a scoring formula; organisations use their existing enterprise risk matrix so that cyber risk is comparable to other operational risks.

Three practices make this work. First, anchor consequence in physical terms: injury, release, loss of product, regulatory breach, days of lost production. Second, record the threat source assumption explicitly, because an SL-T of 2 is a statement that the defender is not required to withstand an adversary with IACS-specific skills. If that assumption is wrong for your sector, the whole design is wrong. Third, keep conduit risks separate from zone risks; a well-hardened PLC zone connected through a loosely controlled conduit has an effective level equal to the conduit.

A worked example, with illustrative numbers

Consider a mid-sized water treatment plant. The numbers below are illustrative, chosen to show the reasoning, not measured data from any real site. The SUC contains a SCADA server pair, two HMIs, a historian, six PLC cabinets controlling pumps and chlorine dosing, a safety PLC for the chlorine leak shutdown, an engineering workstation, and a vendor remote-support link.

In the initial assessment (ZCR 2) the team scores unmitigated consequence on a 1 to 5 scale for safety, environment and operations, and likelihood on a 1 to 5 scale assuming a motivated attacker with remote access. The dosing PLCs score consequence 5 for safety, since over-dosing chlorine endangers the public, and likelihood 3 because the vendor link and engineering workstation are reachable. Risk is 15 on a 25-point scale. The owner’s tolerable threshold is 8, so ZCR 4 sends the zone to detailed assessment.

Zone	Consequence	Likelihood	Initial risk	Tolerable	SL-T chosen
Dosing control PLCs	5	3	15	8	SL 3
Pumping control PLCs	3	3	9	8	SL 2
Safety PLC	5	2	10	8	SL 3
SCADA and HMI	3	3	9	8	SL 2
Historian and DMZ	2	4	8	8	SL 2
Vendor remote access conduit	4	4	16	8	SL 3

The vendor conduit emerges as the riskiest element despite the vendor’s PLCs being reasonably capable, because it is an authenticated but internet-reachable path to the control zone. The design response is typical: terminate remote access in the DMZ on a hardened jump host, require multi-factor authentication tied to named individuals, record sessions, and allow the vendor into specific devices only during approved windows. Residual risk is then re-scored with the countermeasures assumed, and the team documents which requirements remain open.

The value of this exercise is not the arithmetic, which any consultant can criticise. It is that every SL-T is traceable to a consequence and a threat assumption, so a later change, such as connecting the historian to a cloud analytics service, triggers a defined re-assessment rather than an argument.

Foundational Requirements and the Component Layer

Part 3-3 and Part 4-2 organise technical controls under seven foundational requirements (FRs). The FR model is shared, which is what lets a system requirement from 3-3 map neatly onto a component capability from 4-2.

FR	Name	What it protects against	Example controls
FR 1	Identification and authentication control	Unauthorised users and devices	Unique accounts, MFA, device certificates
FR 2	Use control	Authenticated users overreaching	Role-based access, session lock, audit of privileged use
FR 3	System integrity	Tampering with software or data	Signed firmware, integrity checks, input validation
FR 4	Data confidentiality	Disclosure at rest and in transit	TLS, encrypted credentials, secure erase
FR 5	Restricted data flow	Lateral movement	Zone firewalls, allow-lists, segmentation
FR 6	Timely response to events	Undetected compromise	Logging, time sync, alerting, log protection
FR 7	Resource availability	Denial of service	Rate limiting, redundancy, backup and restore

Part 3-3 breaks these into 51 system requirements (SRs): FR 1 has 13, FR 2 has 12, FR 3 has 9, FR 4 has 3, FR 5 has 4, FR 6 has 2 and FR 7 has 8. Each SR has a base requirement and optional requirement enhancements (REs) that apply progressively at higher security levels. At SL 1 you implement the base requirement; at SL 3 you will typically also implement the first or second enhancement. That layering is why moving a zone from SL 2 to SL 3 increases cost in steps rather than all at once.

FR 5 and FR 7 deserve the most attention in OT

Restricted data flow is the requirement the zone and conduit architecture directly implements, and it is the one that fails most visibly in audits. The common finding is a rule set with “any” entries left over from commissioning. A conduit should have a documented list of permitted source, destination, port and protocol, with deny-by-default behaviour and rule review at least annually.

Resource availability is the OT-specific twist. A security control that triggers a controller restart, or a scanner that sends malformed packets to a legacy PLC, can itself cause the outage the control was supposed to prevent. FR 7 therefore covers not only denial-of-service resistance but also backup, recovery and the ability to operate in a degraded state. In practice this argues for passive monitoring, careful scan windows and tested restore procedures for controllers and engineering project files.

Component requirements under Part 4-2

Part 4-2 defines technical requirements for four component types: embedded devices such as PLCs and drives, host devices such as workstations and servers, network devices such as switches and firewalls, and software applications. Component requirements (CRs) mirror the SRs, with the same FR grouping, and each component is assessed for its SL-C per FR. Where a component cannot meet a requirement, the standard allows compensating countermeasures documented at the system level.

A practical consequence is that you can use a Part 4-2 certificate as a purchasing filter. A drive controller certified to SL 2 for its FR 1 to FR 7 capabilities tells you it can support unique accounts, signed firmware and audit logs, though you still must configure them. That distinction between capability (SL-C) and achieved (SL-A) is the reason a certificate is evidence, not a guarantee.

For legacy components that cannot be certified, a documented compensating architecture is common: place them in a dedicated zone, front them with a protocol-aware firewall, and restrict engineering access to a single controlled path. This is not elegant, but it is how a 20-year-old controller stays in a plant that must meet SL 2 overall. Part 2-1:2024 states the same principle for legacy systems, requiring compensating measures through policy and procedure when technical upgrades are not possible.

Secure development under Part 4-1

Part 4-1 applies to suppliers. It describes a secure development lifecycle across eight practices: security management, specification of security requirements, secure by design, secure implementation, security verification and validation testing, management of security-related issues, security update management, and security guidelines. The process maturity scale runs from level 1 (initial) to level 4 (improving), and a certified supplier is typically assessed at level 3, where the process is defined and repeatable with documented evidence.

For an integrator or asset owner, 4-1 shows up as questions you can ask a supplier: how do they handle vulnerability reports, how long do they commit to supplying security patches, how are third-party libraries tracked, and what hardening guidance do they publish? A supplier who cannot answer these will be difficult to keep at the target SL-A over a 15-year plant life. This is also where the EU Cyber Resilience Act overlaps most strongly, covered below.

Programme, Services and Certification

Technical controls decay without a programme around them. That is the point of the Part 2 documents, and it is why SL-A drifts below SL-T in plants that did everything right at commissioning.

Part 2-1 for asset owners and Part 2-4 for service providers

Part 2-1:2024 specifies what an asset owner’s security programme must contain: policies, roles, risk management, patch and change processes, incident handling, and the management of legacy equipment. Its rewrite organises requirements into security programme elements and adds a maturity model, so an owner can say not only “we have a patch process” but “our patch process is at maturity level 2, with level 3 planned.” It also trims content that duplicated ISO/IEC 27001-style management systems, so organisations that already run an ISMS can reuse it rather than building a parallel one.

Part 2-4:2023 does the equivalent for integrators and maintenance providers. This matters because most OT compromises touch a service provider at some point: a laptop that connects to many customers, a shared remote-access tool, a project file passed by email. Requirements cover how the provider handles credentials, remote sessions, backups of customer configuration, and the hand-over of security documentation. An asset owner can make 2-4 conformance a contract term, and use it to evaluate the integrator rather than only the product.

How certification works

Certification is offered at three levels, and the table summarises what each proves.

Scope	Based on	Typical scheme	What it shows
Supplier process	Part 4-1	ISASecure SDLA, or a TUV or other certification body assessment	The supplier builds and maintains products securely
Component	Parts 4-1 and 4-2	ISASecure CSA or ICSA, or a certification body report	A device meets stated SL-C per foundational requirement
System	Parts 3-3 and 4-1	ISASecure SSA	A defined system configuration meets stated SL-C
Operating facility	Parts 2-1, 2-4, 3-2, 3-3	ISASecure ACSSA, or inspection by a certification body	Programme and installed system match the target

ISASecure, run by the ISA Security Compliance Institute, certifies through independent certification bodies accredited under ISO/IEC 17065. Its CSA programme includes pre-assessment, lifecycle assessment, technical requirements testing, vulnerability analysis and independent penetration testing. Its ICSA programme adapts CSA for industrial IoT components and offers a Core tier based on SL 2 and an Advanced tier based on SL 4. Wikipedia and ISASecure materials describe ACSSA, the facility-level scheme, as a work in progress at the time of the sources; check current status before relying on it in a contract.

Separately, TUV SUD, TUV Nord, TUV Rheinland, SGS-TUV Saar, Bureau Veritas, Intertek and UL operate their own IEC 62443 certification services, and the IECEE has been building a formal certification scheme through its CB framework. The practical advice is to ask the vendor which scheme, which part, which edition, which target SL and which product version the certificate covers. A certificate for firmware 2.1 says little about firmware 3.4.

Figure 4: The 62443 assurance chain. Evidence flows from the supplier’s lifecycle and component certificates, through the integrator’s services and system design, to the owner’s programme and audit, and onward to regulators.

Mapping to the EU CRA and NIS2

Two European regulations are the main reason legal teams now ask about IEC 62443. The Cyber Resilience Act (CRA) entered into force on 11 December 2024. Its mandatory reporting obligations for actively exploited vulnerabilities and severe incidents start on 11 September 2026, with a 24-hour early warning and a 72-hour notification to the authorities, and full application, including CE marking requirements, follows on 11 December 2027. Our note on CRA 24-hour reporting for industrial IoT covers the process side.

A caution on overclaiming. As of the sources checked for this update, harmonised standards that would give a presumption of conformity to the CRA were still in draft, with none cited in the Official Journal. Part 4-1 and Part 4-2 map well onto the CRA’s essential cybersecurity requirements, and a supplier with a 4-1 certified lifecycle starts far ahead on vulnerability handling and security updates. But an IEC 62443 certificate is not, by itself, a CRA declaration of conformity. Treat it as strong evidence, and watch for the harmonised standards.

The NIS2 Directive (Directive (EU) 2022/2555) covers operators in sectors such as energy, water, manufacturing of critical products and digital infrastructure. Article 21 requires “appropriate and proportionate” technical and organisational risk-management measures, and the Directive explicitly cites supply-chain security. National transposition has been uneven, so verify the law in each member state where you operate. IEC 62443 gives asset owners a defensible way to demonstrate Article 21 measures for their OT: Part 3-2 for risk assessment, Part 2-1 for the programme, and Part 2-4 for suppliers. The detailed mapping is in our CRA, NIS2 and IEC 62443 compliance mapping.

Implementing the Architecture

Theory ends where the first firewall change request begins. The following sequence is a pattern that tends to work, offered as engineering judgement and not as a prescription from the standard.

Start from an asset inventory you trust

You cannot partition what you cannot see. Build an inventory of controllers, HMIs, servers, switches, serial gateways and remote-access paths, with firmware versions and owners. Passive network discovery from a SPAN port or tap is safer than active scanning on legacy equipment, and it will almost always reveal connections the documentation omits: a modem on a spare port, a laptop dual-homed to both networks, a vendor VPN nobody remembers. This inventory feeds ZCR 1 and ZCR 3, and it is the most common point where projects stall.

Segment in order of consequence

Do not try to restructure the whole plant in one outage. Put the IT/OT DMZ in place first, because it cuts the largest exposure, then isolate the highest-consequence zones, which are usually safety systems and hazardous process control. Last, subdivide the supervisory and field layers. At each step, run the new conduit in monitor-only mode for a few weeks, review what traffic it saw, and only then enforce the allow-list. This avoids the classic failure of a rule blocking a rare but essential flow, such as a monthly historian backfill.

Identity should follow the same layering. Humans authenticate to the DMZ with multi-factor authentication and reach OT devices through a jump host. Machine-to-machine flows between modern edge services benefit from short-lived workload identity rather than shared secrets; our article on SPIFFE and SPIRE workload identity shows how that works in a zero-trust design, and it maps well to FR 1 for software components in the supervisory and edge layers.

Monitor the conduits

FR 6 requires timely response, which means someone must see events. Passive industrial network monitoring that understands protocols such as Modbus, S7 and CIP can baseline normal flows and alert on a new command, a new device or a program download. Logs should be forwarded to a collector in the DMZ, with synchronised time, so that investigators can reconstruct a sequence. A conduit without monitoring is a conduit you only believe in. For architecture context on how SCADA, historians and IoT platforms divide responsibilities, see our comparison of SCADA, OPC, IoT platforms and historians.

Plan for cryptography that will age

Control equipment outlives cryptographic algorithms. Choosing components whose firmware can be updated, and whose certificates and key lengths can be rotated, protects the SL-A over the long life of the plant. The post-quantum transition adds a further reason to ask suppliers about crypto agility; see our analysis of post-quantum cryptography for OT and IIoT.

Trade-offs, Gotchas, and What Goes Wrong

The standard is rigorous, and rigour has costs. The most common failure is the paper compliance trap: a thick CSRS, a certificate on file, and a plant where the firewall rules are unchanged since commissioning. Auditors who see only documents will pass it; an attacker will not.

Over-segmentation. Dozens of tiny zones look impressive in a diagram and are unmanageable in operation. Every conduit needs rules, monitoring and an owner. If your team cannot review the rule set annually, you have too many.

Under-specifying the threat. Choosing SL 2 because it is the “default” without writing down the adversary assumption is common. For critical infrastructure facing state-level actors, SL 2 may not be defensible, and the assessment should say so.

SL-C confusion. Buying “SL 3 devices” and declaring the zone SL 3 conflates capability with achievement. The configuration, the surrounding conduits and the operating processes determine SL-A. Component certificates also expire in relevance when firmware changes.

Availability versus security. Patching an HMI is easy; patching a PLC that controls a continuous process may need a shutdown that happens annually. Compensating controls such as virtual patching at the conduit are legitimate if documented, but they reduce your margin and should carry an expiry date.

Remote access sprawl. Several vendors each with their own VPN appliance create parallel conduits that bypass the DMZ. Consolidate onto one broker, and make vendor access a Part 2-4 contract requirement.

Edition drift. Cited requirement numbers change between editions, and Parts 3-3 and 4-2 are older than much of what they now govern, including cloud-connected gateways and containerised edge workloads. Interpret the intent, document your reasoning, and avoid claiming conformance to features the edition never addressed.

Cost realism. Certification of a product through a recognised body is a multi-month effort and the cost varies widely by scope and scheme; we do not quote figures here because published numbers vary and we did not find an authoritative source. Ask certification bodies for scoped quotes.

Practical Recommendations

For an asset owner, start with ZCR 1 and ZCR 2 on one system, the one with the highest consequence, and treat it as a pilot. Use the result to calibrate your risk matrix before scaling to the rest of the estate. Specify the target SL per zone in procurement documents, and require suppliers to state SL-C, scheme, edition and product version. Make vendor remote access go through a single audited path.

For a product supplier, certify the lifecycle first (Part 4-1), then certify the flagship component to Part 4-2. This sequence mirrors the evidence regulators will want under the CRA, and the lifecycle certificate makes each later product cheaper to assess. Publish your vulnerability disclosure policy and a support period for security updates.

For an integrator, use Part 2-4 as the structure for your own service security, and bring a repeatable zone and conduit template to each customer, adapted rather than copied.

A short checklist to close out a project:

• Inventory is current and reviewed by a named owner.
• Each zone and conduit has an identifier, an SL-T and a documented threat assumption.
• Every conduit has a deny-by-default rule set, reviewed in the last twelve months.
• Remote access terminates in the DMZ with MFA and session recording.
• Each critical component has an SL-C statement and a patch or compensating-control plan.
• SL-A is measured, with gaps against SL-T recorded and dated.
• Backups of controller logic exist and a restore has been rehearsed.
• Monitoring covers every conduit and alerts reach a staffed process.
• Supplier and integrator contracts reference Parts 2-4 and 4-1.
• Regulatory mapping (CRA, NIS2, sector rules) is documented and re-checked when editions change.

Frequently Asked Questions

What is IEC 62443 in simple terms?

IEC 62443 is a series of international standards for securing industrial automation and control systems. It defines roles for asset owners, integrators and product suppliers, a method for dividing a system into zones and conduits based on risk, seven foundational requirements for technical controls, and four security levels. Parts also cover security programmes and secure product development, and several parts can be certified by independent bodies.

What is the difference between a zone and a conduit?

A zone is a group of assets that share the same security requirements, such as a set of PLCs in a process area. A conduit is the set of communication paths between zones, together with the controls that secure them, such as firewall rules, authentication and logging. The design goal is that all traffic between zones passes through a conduit that has been assessed and documented.

What are SL-T, SL-C and SL-A?

SL-T is the target security level for a zone or conduit, derived from risk assessment. SL-C is the capability level a component or system can provide when properly configured, assessed against Parts 4-2 and 3-3. SL-A is the level actually achieved in the operating installation. The engineering aim is for SL-A to meet or exceed SL-T, and gaps are closed with better components or compensating controls.

Which IEC 62443 parts apply to me?

Asset owners focus on Part 2-1 for the security programme and Part 3-2 for risk assessment and zone design. System integrators and service providers focus on Part 2-4 and Part 3-3. Product suppliers focus on Part 4-1 for lifecycle and Part 4-2 for component requirements. In practice roles overlap, so many organisations need several parts, and contracts should name the parts and editions that apply.

Does IEC 62443 certification satisfy the EU Cyber Resilience Act?

Not automatically. Parts 4-1 and 4-2 align with many CRA essential requirements, especially around secure development, vulnerability handling and security updates, so they provide strong evidence. However, as of the sources checked in 2026, harmonised standards giving a formal presumption of conformity had not yet been cited in the Official Journal. Treat IEC 62443 as supporting evidence and monitor the harmonised standards list.

What security level should I choose?

Choose the level your risk assessment justifies, not a default. SL 2 addresses intentional misuse with simple means and is common for general manufacturing. SL 3 addresses attackers with IACS-specific skills and moderate resources, and is common where consequences affect safety or critical services. SL 4 addresses well-resourced adversaries and is rare. Record the threat assumption alongside the number so reviewers can challenge it.

Further Reading

• CRA, NIS2 and IEC 62443 compliance mapping for IoT and OT vendors
• EU Cyber Resilience Act 24-hour reporting for IIoT
• SPIFFE and SPIRE workload identity for zero-trust architectures
• Post-quantum cryptography for OT and IIoT
• IEC 62443-2-1:2024 on the IEC webstore
• IEC 62443-2-4:2023 on the IEC webstore
• ISASecure certification programmes
• EU Cyber Resilience Act implementation, European Commission

By Riju — about