IEC 62443 compliance means running your industrial automation and control systems against an internationally recognised security programme, not just installing firewalls. For asset owners, that programme centres on four parts: 2-1 for governance, 3-2 for risk assessment and zoning, 3-3 for system requirements, and 2-4 for holding service providers to account. The immediate next step is straightforward: define your System under Consideration and start the CRS-driven risk assessment before you touch a single control.
TL;DR:
- Asset owners must define their system boundaries accurately, conduct thorough risk assessments, and develop a detailed cybersecurity requirements specification before implementing controls.
- The most critical parts of IEC 62443 for asset owners are governance (Part 2-1), service provider requirements (Part 2-4), risk assessment and zone design (Part 3-2), and security level mapping (Part 3-3).
- Implementing segmentation with monitored, controlled conduits that respect operational availability is essential to meet targeted security levels without disrupting production.
- Ongoing supplier vetting, documented governance, and maintaining an evidence pack are vital for sustained compliance and effective audits.
- Costs and timelines depend heavily on environment size, scope, and existing documentation, but phased work with measurable risk reduction ensures better stakeholder engagement.
Table of Contents
- What is IEC 62443 compliance and who does it apply to?
- How the IEC 62443 series is structured and which parts matter most
- Security levels and the seven foundational requirements explained
- A practical implementation roadmap for asset owners
- Risk assessment, zones and conduits, and building the CRS
- Technical controls that meet target security levels in practice
- Governance and managing service providers under Parts 2-1 and 2-4
- Certification options: ISASecure, ACSSA, and choosing a certification body
- How IEC 62443 fits with ISO 27001, NIST CSF, and NIS2
- Timelines, costs, and building the business case
- How Re-Solution supports OT teams through IEC 62443 implementation
- Lessons from delivering compliance projects
- Get practical help implementing your IEC 62443 programme
- Where to go for the standards themselves
- Sources
- FAQ
What is IEC 62443 compliance and who does it apply to?
IEC 62443 is maintained jointly by IEC Technical Committee 65 Working Group 10 and the International Society of Automation, which built the series specifically for industrial automation and control systems (IACS) rather than adapting IT security frameworks after the fact. That distinction matters more than most compliance guides admit.
The standard addresses three separate actors, and confusing them is one of the most common early mistakes. Asset owners operate the plant, refinery, or production line and carry ultimate accountability for security outcomes. Service providers integrate, maintain, or monitor those systems on the asset owner’s behalf. Product suppliers design and build the PLCs, HMIs, and controllers that go into the environment. Each has its own set of parts to work against, and a compliant programme requires all three to meet their defined responsibilities in parallel. A perfectly hardened PLC from a Part 4-1 compliant supplier still fails if the integrator ignores Part 2-4 requirements during commissioning.
OT security also inverts the usual IT priority order. Where IT defaults to confidentiality first, OT puts availability and safety ahead of everything else. A control that would be routine in an office network, forcing a password reset mid-shift or rebooting a device for a patch, can shut down a production line or, worse, interfere with a safety interlock. Every control decision under IEC 62443 gets filtered through that lens first.
How the IEC 62443 series is structured and which parts matter most
The series runs across four groups: General (concepts and terminology), Policies and Procedures (organisational requirements), System (technical architecture requirements), and Component (product-level requirements). Most of that structure is background reading. For an asset owner building a working programme, four parts do the actual work.
Part 2-1 sets out the Cybersecurity Management System (CSMS): the governance backbone, policies, and organisational accountability that everything else sits on. Part 2-4 governs service provider requirements, meaning the standards your integrators and maintenance contractors must meet. Part 3-2 covers risk assessment and the zone/conduit segmentation model. Part 3-3 defines system security requirements mapped against security levels. Sitting alongside these for product suppliers, Part 4-1 covers secure product development lifecycle requirements, worth knowing even as an asset owner because it tells you what to demand from vendors during procurement.
Practical implementation guidance consistently identifies 2-1, 2-4, 3-2, and 3-3 as the nucleus of an asset-owner programme, with everything else supporting that core.
Prioritisation differs by environment. Greenfield sites can build zones and conduits into the design from day one, which is far cheaper than retrofitting. Brownfield sites need a risk-led sequencing plan, tackling the highest-consequence zones first rather than the easiest. Multi-site fleets benefit from a template CRS built once and adapted per site, rather than reinventing the risk assessment at every location.
Security levels and the seven foundational requirements explained
Security Levels (SLs) run from SL 0 (no specific protection) to SL 4 (protection against sophisticated attackers with extended resources and specialist knowledge). Each zone in your architecture gets a Target Security Level (SL-T), set by weighing the consequence of compromise against the threat capability you reasonably expect to face there. A safety-critical zone controlling a chemical reactor warrants a higher SL-T than a building management subsystem on the same site, even though both sit inside the same plant.
Underneath the SLs sit seven Foundational Requirements (FRs), and every technical control you deploy maps back to one of them:
- Identification and authentication control — verifying who or what is accessing a device or system
- Use control — enforcing authorised actions once access is granted
- System integrity — protecting against unauthorised modification
- Data confidentiality — protecting information from unauthorised disclosure
- Restricted data flow — segmentation between zones and conduits
- Timely response to events — detection, logging, and alerting
- Resource availability — ensuring systems remain available under stress or attack
Selecting an SL for a zone is not a paperwork exercise. It should follow directly from the risk assessment: what happens if this zone is compromised, and who is realistically capable of doing it? A zone protecting a boiler safety system deserves a materially different SL-T conversation than a printer sitting on the plant’s guest Wi-Fi.
A practical implementation roadmap for asset owners
Compliance work goes wrong most often when teams jump straight to buying firewalls before they know what they are protecting. A staged approach avoids that.
- Scope the System under Consideration (SuC). Define physical and logical boundaries before anything else. Getting this wrong invalidates every later risk decision.
- Establish the governance baseline. Stand up (or formalise) your Part 2-1 CSMS, with named owners for policy, incident response, and supplier oversight.
- Run the risk assessment. Identify assets, threats, and consequences per Part 3-2, and produce a documented, defensible output rather than a gut-feel ranking.
- Design zones and conduits. Group assets by function and required SL-T, then define the conduits (and their controls) connecting them.
- Write the Cybersecurity Requirements Specification (CRS). This becomes the single document that drives procurement, integrator briefs, and design reviews.
- Implement controls against Part 3-3 requirements, phased to avoid taking down live production.
- Validate, gather evidence, and prepare for surveillance, whether that is an internal audit cycle or a formal certification assessment.
Deliverables to bank at each stage:
- A full asset inventory, including firmware versions and network paths, not just a spreadsheet of hostnames
- A signed-off CRS document, versioned and tied to specific zones
- A segmentation design showing conduits, firewalls, and data flow direction
- Supplier assessment records against Part 2-4 for every integrator and maintenance contractor
- An evidence pack: logs, configuration snapshots, and change records ready for an auditor
Phasing matters as much as sequencing. Spreading segmentation work across maintenance windows over several months protects uptime and spreads cost across budget cycles, rather than forcing a single disruptive cutover that finance and operations both resist.
Risk assessment, zones and conduits, and building the CRS
Scoping the SuC sounds simple until you try it. The most common pitfall is drawing the boundary around a convenient organisational chart (say, “the manufacturing division”) rather than the actual physical and logical system. A better boundary follows the process: everything from a specific sensor through to the historian database that logs its readings, including every network hop in between.
Zone and conduit models group assets that share a function and a risk profile. A typical plant might separate the safety instrumented system into its own zone with the highest SL-T, isolate the process control network into a second zone, and place enterprise-facing systems like MES or ERP integration into a third, lower-SL zone with a tightly controlled conduit back into the process network. NIST’s OT security guidance reinforces this same logic for devices such as PLCs and HMIs, treating them as distinct risk categories from standard IT endpoints.
The Cybersecurity Requirements Specification is where all of this becomes actionable. A well-written CRS states the target SL for each zone, the specific technical requirements that follow from it, and the acceptance criteria an integrator must meet before sign-off. It is the document you hand a vendor during procurement, and the document an auditor will ask for first. Skipping it, or writing a vague version, is the single biggest reason implementation projects drift over budget: without a CRS, every supplier interprets “secure” differently.
Technical controls that meet target security levels in practice
Segmentation is usually the first control asset owners reach for, and rightly so, but it has to respect OT availability constraints. Well-designed segmentation uses conduits with defined, monitored data flows rather than flat networks where a compromised HMI can reach the safety system directly.
Identity and authentication controls need adapting for OT hardware. PLCs and older HMIs often lack native multi-factor authentication, so controls typically move to the network layer: 802.1X-based device authentication, certificate-based trust for IIoT sensors, and strict access control lists at the conduit boundary.
Patch and change control is where safety and security genuinely conflict. A patch that closes a vulnerability might also require a safety re-certification review before it can go live, and that review can take months. The practical answer is a documented compensating control (tighter monitoring or segmentation) while the patch works through the safety change process, rather than leaving the vulnerability open indefinitely or forcing an unsafe rushed patch.
Monitoring and logging round out the picture: OT-aware intrusion detection, centralised log collection, and an incident response plan written for control-system consequences, not generic IT playbooks.
Governance and managing service providers under Parts 2-1 and 2-4
A CSMS under Part 2-1 needs to document policy ownership, incident response roles, risk acceptance authority, and how often the programme gets reviewed. Vague ownership is the most common governance failure: if nobody specifically owns supplier oversight, nobody checks it.
Part 2-4 gives you the leverage to hold integrators and maintenance contractors accountable. Before signing a contract, request evidence of their own security practices: how they manage remote access into your environment, how they handle credentials for shared accounts, and what patching discipline they follow on their own tooling.
A basic service-provider assessment checklist should cover:
- Documented remote access procedures and session logging
- Personnel vetting and role-based access controls on their side
- Incident notification timelines written into the contract, not left implicit
- Evidence of their own Part 4-1 alignment if they also supply products
Surveillance shouldn’t stop at signature. Build periodic reassessment into the contract renewal cycle, not just the initial onboarding.
Certification options: ISASecure, ACSSA, and choosing a certification body
Two very different certification questions come up, and mixing them causes confusion. Product and system certification (ISASecure-style schemes) validates that a specific device or system was engineered against Part 4-1 or 3-3 requirements. ACSSA, introduced as an asset-owner-focused certification programme, assesses your operational security posture directly rather than a vendor’s product.
ACSSA evidence typically includes your CSMS documentation, risk assessment records, the CRS itself, segmentation evidence, and supplier assessment records under Part 2-4. Preparing that evidence pack before engaging an assessor makes the process considerably less disruptive; scrambling to produce documentation during an assessment window rarely ends well.
Choosing a Certification Body means checking accreditation against national accreditation infrastructure (UKAS in the UK, for example) and confirming the CB has genuine IACS assessment experience, not just general information security auditing. Ask about surveillance audit frequency upfront: most schemes require periodic reassessment, not a one-time pass.
How IEC 62443 fits with ISO 27001, NIST CSF, and NIS2
IEC 62443 supplies the technical depth that governance frameworks like ISO 27001 don’t provide for OT. ISO 27001 gives you the management system wrapper; IEC 62443 tells you specifically what a zone, conduit, or PLC needs to satisfy. Organisations running both typically map their ISO 27001 Statement of Applicability controls directly against Part 3-3 requirements to avoid duplicating evidence collection.
NIST CSF and 62443 overlap conceptually (both use function-based categorisation) but 62443 is more prescriptive for OT-specific technical controls. NIST’s own OT guidance treats 62443 as a complementary source rather than a competitor.
For NIS2 and UK regulatory expectations under NCSC guidance, alignment with 62443 demonstrates a credible, internationally recognised security baseline, but it is not a legal substitute for whatever your specific national regulator requires. Build your evidence package so it can be relabelled against multiple frameworks without redoing the underlying work: the same CRS and risk assessment evidence should satisfy an ISO 27001 auditor and a regulatory inspector alike.
Timelines, costs, and building the business case
Timeline expectations vary sharply by scope. A single zone within one facility might reach a defensible baseline in a few months. A full single-site programme, covering governance, risk assessment, and segmentation, typically takes under two years. Multi-site fleets extend well beyond that, often running as a rolling multi-year programme rather than a fixed project.
Cost drivers worth flagging to finance early:
- Asset inventory and discovery effort, which scales with how undocumented the existing environment is
- Segmentation project costs, including new switching hardware and firewall rules
- Device upgrades or replacements for equipment that cannot meet baseline authentication requirements
- Ongoing managed service or monitoring costs to sustain the programme post-implementation
- Certification body fees if pursuing ACSSA or product-level conformity assessment
Pro Tip: Translate every proposed control into annualised risk reduction, not just a cost line. Boards fund risk reduction; they resist funding “compliance” as an abstract line item.
IEC 62443 deliberately stays methodology-neutral on financial justification, which means asset owners have to do that translation themselves. Rising cyber threat intelligence volumes give a useful backdrop for that conversation: threat scale is increasing, and quantifying exposure in financial terms tends to secure sustained funding across multiple budget cycles rather than a single approval that dries up the following year.
How Re-Solution supports OT teams through IEC 62443 implementation
An engineering firm working with Re-Solution deployed Cisco ISE to bring device authentication and network access control up to the standard required for its compliance programme, giving the security team visibility over exactly what was connecting to its OT network for the first time.
A compact checklist drawn from the roadmap above, useful as a starting self-assessment:
- Has the SuC been formally scoped and documented?
- Does a CRS exist, and is it version-controlled against current zones?
- Are segmentation designs implemented, or still on paper?
- Have all service provider contracts been checked against Part 2-4 requirements?
- Is monitoring in place across every defined conduit?
- Is an evidence pack being maintained continuously, rather than assembled reactively before an audit?
Engaging a managed service makes sense once the governance and CRS work is done but ongoing monitoring, patch coordination, and supplier oversight need sustained resourcing your internal team doesn’t have spare capacity for.
Lessons from delivering compliance projects
The biggest failure mode in IEC 62443 work isn’t technical. It’s governance drift: a project starts with cross-functional buy-in, then six months in, only the security team is still showing up to steering meetings while operations and finance quietly disengage.
Phasing work around planned maintenance windows, rather than forcing a big-bang cutover, keeps operations engaged because it protects their production targets. And presenting progress in financial terms, quarterly risk-reduction figures rather than a list of completed tickets, keeps finance and the board bought in for the multi-year horizon these programmes actually need. The standard gives you the technical map. Holding the room together for eighteen months is the harder job.
— Jacob
Get practical help implementing your IEC 62443 programme
Building an IEC 62443 programme in-house means finding the time to run a proper risk assessment, write a defensible CRS, and hold every integrator to Part 2-4 standards, on top of your existing workload. Re-Solution’s network and compliance audits give asset owners a starting risk baseline without pulling internal engineers off day-to-day operations, and the Cisco ISE deployment referenced above shows the same team behind identity and access control work that directly supports Part 3-3 requirements.
Beyond audits, Re-Solution’s Network as a Service model and managed IT services cover the ongoing monitoring and supplier coordination that keeps a programme compliant after the initial project ends, rather than letting evidence collection lapse the moment the auditor leaves. For teams still mapping out segmentation and infrastructure changes ahead of a CRS, the network infrastructure planning guide is a useful starting reference. If you want a clear view of where your current environment stands against IEC 62443 expectations, get in touch to book a network audit and start the conversation with a concrete baseline rather than a guess.
Where to go for the standards themselves
Consult ISA’s IEC 62443 series page for the official standards text and part numbering. NIST SP 800-82 gives OT-specific complementary guidance. For certification bodies and ACSSA details, start with the IEC 62443 overview on Wikipedia, then verify accreditation through your national accreditation body before engaging any assessor. Procurement teams checking supplier evidence may also find industrial capability statements and digital calibration certificate practices useful reference points for supplier QA expectations.
Sources
- ISA/IEC 62443 Series of Standards
- IEC 62443 — Wikipedia
- IEC 62443 Implementation plan (Denexus)
- Statista — Cyber threat intelligence topic
FAQ
What is the difference between ISO 27001 and IEC 62443?
ISO 27001 is a general information security management system standard, while IEC 62443 is written specifically for industrial automation and control systems, providing the technical depth on zones, conduits, and device-level requirements that ISO 27001 does not cover.
Is IEC 62443 compliance worth it?
For any organisation running industrial control systems, alignment with IEC 62443 provides a structured, internationally recognised way to reduce operational risk and satisfy the technical evidence regulators and insurers increasingly expect, even where formal certification isn’t pursued.
How much does IEC 62443 certification cost?
Costs vary widely by scope, from asset inventory and segmentation projects through to certification body fees for schemes like ACSSA, and are best built into a multi-year budget rather than treated as a single upfront figure.
What are the security levels in IEC 62443?
Security Levels run from SL 0 (no specific protection) to SL 4 (protection against sophisticated, well-resourced attackers), with each zone assigned a Target Security Level based on the consequence of compromise and the realistic threat capability it faces.
Recommended
- Cybersecurity compliance basics: 2026 guide for IT teams
- Network infrastructure checklist: optimise compliance
- Network assurance for IT teams: a practical guide
- Guide to infrastructure lifecycle: 2026 edition
