IEC 62443 compliance means aligning your industrial automation and control systems (IACS) with a series of international standards. Those standards cover how you run a security program, how you design your site, and how the products you buy are built. There is no single certificate that makes an operator "IEC 62443 compliant." You build and maintain a risk-based program, set target security levels for each part of your network, and hold suppliers to the product requirements.
This guide is for operators, plant leadership and security owners in oil and gas, energy and other regulated industries. It explains what the standard asks of you, how security levels work, what certification does and does not cover, and where to start.
TL;DR
- IEC 62443 is a series of standards for securing industrial automation and control systems across their lifecycle. It covers asset owners, system integrators and product suppliers.
- It is risk-based, not a checklist. You assess risk first, then divide the environment into zones and conduits and set a target security level for each.
- Certification exists for products, systems and supplier development practices. An asset owner still owns the site-specific design and the ongoing operation.
- Do not copy IT controls into OT unchanged. Adapt them so they do not disrupt operations or safety.
- Start with an asset inventory and a risk assessment, then build the program in phases.
Table of Contents
- What IEC 62443 covers
- Shared responsibility: who owns what
- Understanding security levels
- Zones and conduits: the core design exercise
- Why OT security needs its own approach
- Certification: what it covers and what it does not
- How IEC 62443 relates to NIST and ISO 27001
- Our perspective
- A phased roadmap to IEC 62443 alignment
- How CISOSafe can help
- FAQ
- Sources
What IEC 62443 covers
The series was developed to secure industrial automation and control systems throughout their lifecycle. According to the IEC, it currently includes nine standards, technical reports and technical specifications. The ISA describes it as a horizontal framework that applies across industries, including oil and gas, energy and building automation. In the US it is usually written ISA/IEC 62443, because the International Society of Automation's ISA99 committee develops it jointly with the IEC. That is why "ISA 62443 compliance" and "IEC 62443 compliance" point to the same body of work.
The series addresses both technical and process-related aspects of automation and control security, as Wikipedia's overview notes. In practice, you will work with four groups of documents:
| Group | What it addresses | Who it matters most to |
|---|---|---|
| General (1-x) | Concepts, terminology, models | Everyone |
| Policies and procedures (2-x) | Running a security program, patch management, service provider requirements | Asset owners, service providers |
| System (3-x) | Risk assessment, zones and conduits, system security requirements | Asset owners, system integrators |
| Component (4-x) | Secure development lifecycle, technical requirements for components | Product suppliers |
Four documents come up most often in a compliance project:
- 62443-2-1: the security program. The ISA's 3-3 preview assumes you have already established a security program under this part and that patch management is in place.
- 62443-3-2: security risk assessment and system design. This is the part that requires zones and conduits, per the IEC.
- 62443-3-3: the technical security requirements a system must meet.
- 62443-4-1 and 4-2: secure product development and component requirements, which concern your suppliers more than you.
Shared responsibility: who owns what
Compliance in this series is a shared effort. Product suppliers, system integrators and asset owners each have distinct roles, and the ISA guidance frames the standard as the roadmap for that collaboration, with security built into the product lifecycle rather than added afterward.
For an operator, the practical consequence is this. Buying components from a supplier with a certified development process helps. But the IEC notes that asset owners remain responsible for site-specific security design, including zoning and conduit partitioning, and that this is where many gaps appear. A refinery or pipeline operator cannot outsource that accountability by purchasing a certified controller.
Ask three questions of every vendor and integrator:
- Which parts of the series do your products and processes conform to, and how was that verified?
- Which security level was each component or system assessed against, and for which requirements?
- What do you expect us to configure and maintain after handover?
Write the answers into contracts. That turns the shared responsibility model from an idea into an obligation.
Understanding security levels
The series defines four security levels. As summarized on Wikipedia, they measure confidence that a system is free from vulnerabilities, and each step up represents greater resistance to threat actors. SL1 addresses casual or coincidental violations. SL4 addresses nation-state level campaigns.
| Level | Resists | Typical thinking |
|---|---|---|
| SL1 | Casual or coincidental violation | Basic hygiene for low-consequence zones |
| SL2 | Intentional violation with simple means and low resources | Common baseline for many business-adjacent control zones |
| SL3 | Sophisticated means, moderate resources, IACS-specific skills | Higher-consequence process control |
| SL4 | Sophisticated means, extended resources, state-level capability | Rare, reserved for the highest-consequence functions |
The SL2 to SL4 descriptions above are a paraphrase of the standard's attacker model. Check the wording and the target definitions in the standard itself before you put them in a policy.
Do not aim for SL4 everywhere
The most common mistake is picking the highest level for all systems. The IEC's Smart Energy guidance points out that security levels should be evaluated per technical requirement rather than as a general product label. It also says that pursuing SL4 across the board is often inefficient and unsustainable. A risk-based approach sets target levels in line with the risk profile of each zone or conduit.
A safety instrumented system and a historian that feeds business reporting do not carry the same consequences if compromised. They should not carry the same target.
Zones and conduits: the core design exercise
The IEC explains that the standard is risk-based, not a checklist. You begin with a risk assessment to identify your most valuable assets. Then you group assets into zones, and define the conduits that carry communication between them. Part 3-2 requires this process.
A workable sequence looks like this:
- Inventory the assets. Controllers, HMIs, engineering workstations, historians, network gear, remote access paths and vendor connections.
- Map data flows. Who and what talks to each asset, and over which path.
- Assess consequences. Ask what a compromise of each group does to safety, production, environment and revenue.
- Define zones. Group assets with similar security needs and consequences.
- Define conduits. Treat every path between zones, including vendor remote access, as something to control and monitor.
- Set target security levels. One per zone and conduit, justified by the risk assessment.
- Compare current to target. The gaps become your remediation roadmap.
This exercise is where a vCISO or experienced advisor pays for itself, because it requires both business-risk judgment and control-system knowledge.
Why OT security needs its own approach
IT security habits do not transfer cleanly. Guidance from the ISA99 committee, presented to NIST, states that IT solutions must be adapted in an informed way for control systems. The reason is that general-purpose IT security can have serious unintended consequences in industrial operations. An aggressive vulnerability scan or an automatic patch reboot can stop a process.
The same principle applies to critical infrastructure operations generally. Controls have to respect uptime, safety and physical constraints. For a related example of how operational dependencies shape resilience planning, see this look at critical infrastructure fuel logistics and how it ties continuity decisions to operational requirements.
Practical rules for OT environments:
- Test changes in a staging environment or during planned outages.
- Prefer passive monitoring over active scanning on fragile devices.
- Segment first. Network segmentation often reduces risk without touching the controllers.
- Treat patching as a managed process with vendor approval, not an automatic update.
- Include operations and safety engineers in every decision.
Certification: what it covers and what it does not
People often ask whether they can be "certified" to IEC 62443. The answer depends on what you mean.
ISASecure is a certification scheme that certifies to the ISA/IEC 62443 standards. Assessments are carried out by a network of ISO/IEC 17065 accredited certification bodies, and ISASecure was founded in 2007 as a wholly owned subsidiary of ISA. Its quick start guide describes it as a third-party conformity assessment scheme. Per the ISASecure site, certifications are offered for components, IIoT components, systems and supplier development practices.
Note what is missing: there is no certificate for "an operating plant." For an asset owner, certification is mostly a procurement tool. You can require certified products and suppliers, then show your own conformance through documented risk assessments, zone and conduit designs, program policies and evidence of operation.
Compliance is also not a point-in-time event. The ISA warns that asset owners often treat it as a product purchase rather than an ongoing program that needs configuration, maintenance and monitoring so capabilities do not degrade.
How IEC 62443 relates to NIST and ISO 27001
Most US operators already work with other frameworks, so the question is how they fit together.
- NIST. IEC 62443 gives technical and procedural requirements for IACS. It is often used alongside NIST guidance such as SP 800-82 on OT security, as NIST-hosted material on control system performance goals reflects. The same material names ISA/IEC 62443 among the established practices for identifying and documenting control system risks, next to the NIST Cybersecurity Framework and Risk Management Framework.
- ISO/IEC 27001 and 27002. The ISA Global Cybersecurity Alliance has published a white paper on applying ISO/IEC 27001, 27002 and the 62443 series together in OT environments. It aligns the two through common approaches where feasible and flags where IT and OT differ.
The practical takeaway is to build one management system with a mapped control set rather than three separate compliance projects. A single risk assessment and a single evidence library can feed several frameworks.
Our perspective
We work with regulated organizations in oil and gas, energy, law and healthcare, and the pattern in industrial environments is consistent. Teams treat the standard as a document to satisfy, when it is a way to decide where limited security budget goes.
Three things we would tell any operator starting out:
- Begin with risk, not controls. A risk assessment that ties systems to business and safety consequences makes every later decision defensible to your board, insurers and regulators.
- Set realistic targets. A zone-by-zone target that you can sustain beats an ambitious blanket target that decays within a year.
- Build for reporting. Leadership needs clear visibility into risk without wading through technical detail. Board-ready reporting is part of how we run engagements.
Most mid-market operators do not have a full-time CISO who can carry this work. A virtual CISO supplies strategic leadership, program ownership and framework expertise at a fraction of the cost and time of a full-time hire or a large consultancy, and that is the model we built CISOSafe around.
— vCISO
A phased roadmap to IEC 62443 alignment
Phase 1: Scope and governance (weeks 1 to 4)
Name an executive owner. Define which facilities and systems are in scope. Agree how OT and IT security teams will share decisions. Review existing policies against the program requirements in part 2-1.
Phase 2: Assess (weeks 3 to 10)
Build the asset inventory, map data flows and complete a risk assessment. Document the zones, conduits and target security levels. Identify gaps against current state.
Phase 3: Remediate by priority
Start with the highest-consequence zones and the weakest conduits. Typical early wins include segmentation, tightening remote access, hardening engineering workstations and establishing backup and recovery for control system configurations.
Phase 4: Manage suppliers
Add conformance requirements to procurement. Ask for evidence of secure development practices and certified products where they exist, and define who patches and monitors what.
Phase 5: Operate and improve
Monitor, review, test your incident response plan and reassess when systems or threats change. This phase never ends, and that is the point.
The timelines above are our planning illustrations, not requirements of the standard. Real durations depend on site count, asset volume and the maturity of your documentation.
How CISOSafe can help
If you run operations in Houston or along the Gulf Coast, or anywhere in the US, our virtual CISO, risk assessment, policy and controls, and audit readiness services cover the program work that a standard like this demands: risk assessments, risk roadmaps, policy development, incident response planning and ongoing strategic advisory. Our platform supports assessments across 50+ frameworks, so your IEC 62443 effort can share evidence with the other standards you answer to. To discuss whether your OT scope fits, start at cisosafe.com.
FAQ
Is IEC 62443 mandatory in the US?
The standard is voluntary on its face. It becomes a requirement when a customer, contract, insurer or sector regulator asks for it. Check the obligations that apply to your sector and contracts with counsel before assuming either way.
What are the requirements of IEC 62443?
There is no single list. Requirements are spread across the series: a security program (2-1), risk assessment with zones and conduits (3-2), technical system requirements (3-3) and secure product development and component requirements (4-1 and 4-2). Which ones apply to you depends on whether you are an asset owner, integrator or supplier.
Which security level should we target?
The one your risk assessment supports for each zone or conduit. The IEC guidance warns against applying the highest level to everything. Most organizations end up with different targets across zones.
Can a company be certified to IEC 62443?
Certification schemes such as ISASecure certify products, systems and supplier development practices. An operating site is not certified in the same way. Operators show conformance through documented assessments, designs and operating evidence.
Sources
- ISA/IEC 62443 Series of Standards, ISA
- Understanding IEC 62443, IEC
- IEC 62443, Wikipedia
- IEC 62443, SyC Smart Energy
- ISA-62443-3-3 preview, ISA
- ISA99 presentation to NIST
- ISASecure
- ISASecure Quick Start Guide
- Applying ISO/IEC 27001, 27002 and the 62443 Series, ISAGCA
- National Security Memorandum on Critical Infrastructure Control Systems Performance Goals