ISA/IEC 62443 for Plant Leaders: What It Requires, Who Does What, and How Each Industry Uses It

The request usually arrives in one line. Corporate IT, a customer audit or an insurance renewal says the plant needs to be “62443 compliant”, and an engineering manager is handed a standard they have never read. One practitioner’s advice to someone in exactly that position, posted on r/OTSecurity this October, was blunt: “If i were you, I’d be asking a whole lot of questions right now.”

They are the right questions, because the short answers surprise people:

• No law requires a plant to adopt ISA/IEC 62443.
• No certification scheme covers a whole plant.
• Whoever does the work, the plant stays accountable for the result.

ISA/IEC 62443 is best understood as a contract language and a shared vocabulary. It gives a plant, its integrators and its suppliers the words to agree on what “secure enough” means for each part of a control system, and to prove it. It is not a certificate to hang on the wall.

Joltek’s founder, Vladimir Romanov, has assessed plant networks, servers and segmentation, often flagging how networks were configured: VLANs, NAT and the boundaries between them. Vladimir has also architected networks to 62443-based guidelines set by IT departments. This guide is written from that seat: the plant’s.

It covers, as of October 2026:

• what 62443 is, and which of its fourteen current documents matter to whom;
• whether it is mandatory, and the regulatory dates that reach plants and machine builders in 2026 and 2027;
• who does what among owners, integrators, maintainers and suppliers;
• zones, conduits and security levels, explained correctly, and what they look like in a brownfield plant;
• what can be certified, what a certificate is worth, and what to demand in contracts;
• how each industry uses it, how it fits with NIST, ISO 27001, NERC CIP and IEC 61511, what it costs, and where to start.

A note on independence: Joltek holds no 62443 certification and sells none. It assesses plant networks, designs architectures and runs integration projects.

What is ISA/IEC 62443, in plain terms?

ISA/IEC 62443 is a series of standards for securing industrial automation and control systems across their whole life: the plant’s security program, the risk assessment that sets targets for each zone, how integrators and maintainers work, and how products are built. It is a shared vocabulary for owners, integrators and suppliers, not a product or a certificate.

Why industrial systems needed their own standard

Corporate IT security has had its frameworks for decades. They fit a plant badly, for reasons anyone who has run a plant can list:

• Availability comes first. A production line that stops is the incident, whatever the cause. The 2024 edition of 62443-2-1 says it plainly: “in an IACS, availability may have a higher priority than confidentiality.”
• Safety is in the loop. A compromised controller can hurt people, not just leak data.
• Assets run for decades. Controllers, HMIs and drives commonly outlive the operating systems and protocols they were designed around.
• Change is expensive. Many systems cannot be patched, rebooted or scanned on a schedule without a production window and, in regulated plants, revalidation.

The standard’s authors also warned against the most common shortcut. In the words of 62443-2-1: “a frequent mistake is to deal with cybersecurity one system at a time.” The point of the series is to treat the control system, the people who run it and the companies that build and service it as one program.

Where it came from

The work began in 2002, when the International Society of Automation formed the ISA99 committee. Its first face-to-face meeting, in Chicago on 22 October 2002, drew almost 60 people. Committee co-chair Eric Cosman has written of joining to represent the American Chemistry Council’s chemical-sector cybersecurity program, which had decided not to write sector-specific standards. ISA made the same choice: instead of asking each of its standards groups to bolt on security, it created one “horizontal” series that every sector could use.

The first document, ISA-99.00.01, was published in 2007. Around 2010 the ISA documents were renumbered ISA-62443 to align with the International Electrotechnical Commission (IEC), whose technical committee TC 65 adopts them in parallel through working group 10. ISA develops the parts as American National Standards; IEC publishes them internationally; the two editions are identical apart from their front matter. One exception is part 2-4, which was developed at IEC with the International Instrumentation Users Association (WIB) and then adopted by ISA. In 2021, IEC designated the series a horizontal standard. IEC described horizontal standards as “technology independent”, standards that “can be applied across many technical areas.” ISA99 is co-chaired today by Johan Nye and Eric Cosman.

Two details matter later in this guide. First, IEC itself certifies no one; every IEC 62443 document says that conformity is assessed by independent certification bodies. Second, ISA notes that physical security, while important, “is not specifically addressed in this series.”

How the series is organized

The documents sit in four groups, plus a newer set of evaluation methods:

Group	What it covers	Parts in force
1 General	Concepts, terminology, security profiles, industrial IoT	1-1, 1-5, 1-6
2 Policies and procedures	The asset owner’s security program, security protection schemes, patch management, service providers	2-1, 2-2, 2-3, 2-4
3 System	Security technologies, risk assessment for system design, system requirements and security levels	3-1, 3-2, 3-3
4 Component	Secure product development lifecycle, component technical requirements	4-1, 4-2
6 Evaluation methods	How assessors evaluate service providers and components	6-1, 6-2

One word to settle early: IACS, for industrial automation and control system. In 62443-2-1:2024 and 62443-2-4:2023, an IACS is the combination of the automation solution and “the organizational measures necessary for its design, deployment, operation, and maintenance.” It includes people, policies and procedures, not only equipment. That definition is why a plant cannot buy its way to 62443 with certified products alone.

62443 also gets confused with the Purdue model and ISA-95. The levels describe what systems do, from field devices up to enterprise planning. Zones in 62443 describe how assets are grouped for security. The two usually overlap in a real plant, but they are not the same thing. For the functional model, see ISA-95 in practice.

Why does 62443 matter to a plant in 2026?

Because attacks, regulators and buyers have all reached the plant floor. Field data finds poor segmentation and stolen remote-access credentials behind most incidents, EU law now reaches machines and components, and procurement teams ask for 62443 evidence. A plant that speaks the language can specify, buy and audit security instead of guessing.

The attacks reached the plant floor

The clearest picture of what goes wrong comes from the firms that respond to incidents. Dragos, an OT security company, published its 2026 Year in Review in February 2026, drawing on its own incident response, penetration testing and assessment work. It does not state sample sizes in its summary, so treat the figures as one vendor’s field data:

• “81 percent of assessments identified poor IT/OT segmentation.”
• “73 percent of all-time IR cases involved compromised VPN or jumphost credentials.”
• “Only 46 percent of assessments found adequate OT network monitoring deployed.”
• Ransomware groups affected 3,300 industrial organizations in 2025, and “Manufacturing accounted for more than two-thirds of victims.”

Each of those findings maps onto something 62443 organizes:

• segmentation is the zones and conduits model, and foundational requirement 5, restricted data flow;
• remote-access credentials are covered by the identification, authentication and use-control requirements, and by the secure remote access elements of 62443-2-1;
• monitoring is foundational requirement 6, timely response to events.

When an incident does happen, recovery depends on the backups, approved versions and procedures the program put in place beforehand. See a PLC ransomware recovery runbook.

The regulators reached the machines

Two pieces of EU product law changed the conversation for anyone who builds, buys or exports equipment:

• The Cyber Resilience Act (Regulation 2024/2847). Its reporting obligations have applied since 11 September 2026. Manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents within 24 hours, with follow-ups at 72 hours and 14 days. That duty covers products already on the EU market. The rest of the regulation applies from 11 December 2027.
• The Machinery Regulation (2023/1230), which applies from 20 January 2027. Its essential requirements now include “protection against corruption” (Annex III, section 1.1.9). They also require that control systems withstand “reasonably foreseeable malicious attempts from third parties leading to a hazardous situation” (section 1.2.1).

Neither text names 62443. But 62443 is the vocabulary the European standards bodies are using to write the technical standards behind them, as the section on frameworks explains.

North American agencies are pointing the same way without legislation. In January 2025, CISA and eleven partner agencies from the United States, Canada, Australia, the EU, Germany, the Netherlands, New Zealand and the United Kingdom published Secure by Demand guidance for OT buyers. It says: “Buyers should look for manufacturers that demonstrate their adoption of Secure by Design and International Society of Automation (ISA) 62443 standards.” CISA’s Cross-Sector Cybersecurity Performance Goals 2.0, released in December 2025, note that all its goals “map to corresponding controls” in NIST CSF or ISA/IEC 62443. NIST’s own OT security guide, SP 800-82, references 62443 throughout.

Governance and evidence pay off

The surveys that measure program maturity point at governance, not at any one technology. In the SANS Institute’s 2024 survey of more than 530 practitioners, 72 percent of organizations mapped their control systems to a recognized framework, with NIST CSF the most common at 45 percent and 62443 “also widely used”. More telling: “If a CISO owns the governance, 82% of ICS programs follow industry standards, compared to only 42% if there are no corporate-wide policies for ICS.” In SANS’s 2025 survey of 330 respondents, sites under mandatory compliance had similar incident rates to their peers but “~50% fewer financial losses and safety impacts”. That is a correlation, and it is not specific to 62443, but it is the best available evidence that structured programs change outcomes.

What the vocabulary buys a plant

The practical value of 62443 is precision. “Make the new line secure” cannot be bought, tested or audited. A plant can buy, test and audit a requirements specification that sets a target security level for the packaging zone, defines the conduit to the site network, names the accounts to be changed at handover, and lists the tests to run at the site acceptance test. Owners, integrators, suppliers, auditors and insurers can all read the same document the same way. That is the case for 62443 in one paragraph, and it is why this guide treats the standard as a contract language rather than a badge.

Is ISA/IEC 62443 mandatory?

No law requires a plant to adopt ISA/IEC 62443. It becomes binding through contracts, through class rules for new ships, and as one optional route to the EU Cyber Resilience Act. Most regimes, including NERC CIP, NIS2, US pipeline rules and Australia’s SOCI rules, use their own requirements; 62443 is how many plants meet them.

What “mandatory” means here

62443 is a voluntary consensus standard. It becomes binding in one of three ways:

• a law or regulation adopts it by reference;
• a regulator or class society writes it into its rules;
• a customer or corporate program writes it into a contract or policy.

Research for this guide found no law, in the US, Canada, the EU, the UK, Australia or Singapore, that names 62443 as the required standard for an industrial plant.

Instrument	Names 62443?	What it requires	Who it touches
IACS UR E27 Rev.1 (ship equipment)	Yes. Based on selected requirements of 62443-3-3; cites 62443-4-1 clauses	Security capabilities for on-board systems; secure development by suppliers	Ships contracted for construction from 1 July 2024; equipment suppliers
IACS UR E26 Rev.1 (ship level)	No, but uses zones and conduits and the same role split	Cyber resilience of the ship as a whole	Shipyards, owners, class societies
EU Cyber Resilience Act	No	Essential cybersecurity requirements and reporting for products with digital elements; presumption of conformity via cited harmonised standards	Manufacturers, importers, distributors selling into the EU
EU Machinery Regulation	No	Protection against corruption; resistance to malicious attempts that could create hazards	Machine builders, and anyone placing machinery on the EU market
EU NIS2 Directive	No	“Appropriate and proportionate” measures, considering “relevant European and international standards”	Essential and important entities, including many manufacturers
NERC CIP	No	Mandatory requirements for the bulk electric system	Registered electric utilities
TSA pipeline directives, API Std 1164	No (NIST CSF basis)	Pipeline security programs	US pipeline operators
AWWA guidance, EPA actions	No	Risk and resilience assessments	US water utilities
Australia SOCI risk management rules	No	Risk management programs	Australian critical infrastructure
CISA Secure by Demand, CPG 2.0	Recommends and maps	Buyer guidance and performance goals	US critical infrastructure and OT buyers

The calendar that matters from 2026 to 2028

Date	What happens	Why a plant should care
1 Jul 2024	IACS UR E26 and E27 Rev.1 apply to ships contracted from this date	The first rule that writes 62443 requirements into mandatory equipment approval
13 Jan 2025	CISA and partners publish Secure by Demand for OT	Buyers told to look for 62443 adoption; aligns with security level 3 of 62443-4-2 and 3-3
Dec 2025	CISA Cross-Sector Performance Goals 2.0	Goals map to NIST CSF or 62443
11 Jun 2026	CRA provisions on conformity assessment bodies apply	Notified bodies begin to be designated
11 Sep 2026	CRA reporting obligations apply	Manufacturers must report exploited vulnerabilities and severe incidents, including for products already sold
21 Sep 2026	NIST SP 800-82 Rev. 4 draft published (comments to 30 Nov 2026)	The draft keeps its references to 62443
Late 2026 to 2027	CENELEC amendments to EN IEC 62443-4-1 and 4-2, and OT product profiles, in development	The likely harmonised-standard route for the CRA; nothing cited yet
20 Jan 2027	EU Machinery Regulation applies	Cyber-related essential requirements for machinery
11 Dec 2027	CRA applies in full	Essential requirements, conformity assessment and CE marking for products with digital elements
2028	Forecast publication of 62443-4-1 edition 2 and 2-4 edition 3	Supplier and integrator requirements will move

One date in that table is often misquoted. The original Machinery Regulation text gave 14 January 2027; a corrigendum published in July 2023 changed it to 20 January 2027.

Where it is effectively mandatory

Ships. IACS UR E27 states that its requirements “are based on the selected requirements in IEC 62443-3-3.” Its supplier development clauses cite 62443-4-1 by clause number. It applies to ships contracted for construction on or after 1 July 2024, which covers:

• passenger ships on international voyages;
• cargo ships of 500 gross tonnage and above on international voyages;
• high-speed craft and mobile offshore drilling units above that size.

Its companion, UR E26, uses the same zones-and-conduits method and the same split of roles between shipyard, supplier and owner, but never names the standard.

EU product law, optionally. Under the CRA, products that conform to harmonised standards cited in the Official Journal are presumed to meet the essential requirements. CENELEC is preparing those standards from EN IEC 62443-4-1 and 4-2, but CEN and CENELEC are explicit that “EN IEC 62443-based hENs are only an option.” A manufacturer may choose another route.

Contracts and corporate programs. For most manufacturers, this is where 62443 really becomes mandatory: a customer’s supplier requirements, a parent company’s OT security standard, or a project specification. Research for this guide found no published insurer or automotive manufacturer document that requires 62443 certification from plant suppliers. Customers and insurers do increasingly ask for evidence, and the vocabulary they ask in is usually 62443’s.

North America in particular

In the United States, sector regulators have built their own regimes:

• NERC CIP for the bulk electric system;
• TSA security directives for pipelines, alongside API Std 1164;
• risk and resilience assessments for water utilities under America’s Water Infrastructure Act.

None adopts 62443. The Chemical Facility Anti-Terrorism Standards program, a regime that covered chemical plants, lapsed when Congress let its statutory authority expire on 28 July 2023.

In Canada, Bill C-8, An Act respecting cyber security, received royal assent in June 2026. Its Critical Cyber Systems Protection Act targets designated operators in finance, telecommunications, energy and transportation. It will come into force in phases, and Public Safety Canada’s announcement names no technical standard. The Canadian Standards Association has adopted individual parts of the series as national standards, including CSA IEC 62443-4-2.

Which parts of 62443 matter, and to whom?

Fourteen documents are current, but most plants need four or five. Asset owners start with 2-1, the security program, and 3-2, the risk assessment. Integrators and maintainers use 2-4, system suppliers 3-3, and component makers 4-1 and 4-2. Several parts listed online, including 1-2, 1-3, 1-4 and 2-5, were never published.

The fourteen current documents (as of October 2026)

IEC labels each document by type. An International Standard (IS) carries requirements. A Technical Specification (TS) is closer to a standard but less settled. A Technical Report (TR) and a Publicly Available Specification (PAS) are guidance.

Part	Title (short)	Type and current IEC edition	Who it is for
1-1	Terminology, concepts and models	TS, 2009 (an International Standard reissue is in drafting, forecast end of 2027)	Everyone
1-5	Scheme for security profiles	TS, 2023	Sector bodies and standards writers
1-6	Applying the series to the industrial internet of things	PAS, December 2025	Asset owners, service providers
2-1	Security program requirements for asset owners	IS, edition 2, August 2024	Asset owners
2-2	IACS security protection scheme	PAS, March 2025	Asset owners, service providers, suppliers
2-3	Patch management	TR, 2015	Asset owners, suppliers
2-4	Security program requirements for service providers	IS, edition 2, December 2023	Integrators, maintenance providers
3-1	Security technologies	TR, 2009	Reference (dated as a technology survey)
3-2	Security risk assessment for system design	IS, 2020	Asset owners with integrators
3-3	System security requirements and security levels	IS, 2013	System suppliers, integrators, owners specifying
4-1	Secure product development lifecycle	IS, 2018 (edition 2 forecast 2028)	Product suppliers
4-2	Technical security requirements for components	IS, 2019	Component suppliers
6-1	Evaluation method for 62443-2-4	TS, 2024	Assessors, service providers
6-2	Evaluation method for 62443-4-2	TS, 2025	Assessors, component suppliers

Parts you will see listed that do not exist

Many explainers, and NIST SP 800-82 Rev. 3’s own appendix, list parts 1-2 (master glossary), 1-3 (conformance metrics), 1-4 (lifecycle and use cases) and 2-5 (implementation guidance for asset owners). None of them has been published by IEC or ISA, and buyers go looking for them. In May 2026, one engineer on r/OTSecurity asked where to buy those four parts. The reply was short: “If they aren’t on the ISA website, they aren’t published.”

What changed since 2023

Much of what ranks in search results describes the series as it stood before 2023. The changes that matter to a plant:

• 62443-2-1:2024 replaced the 2010 edition and is now about half its length (189 pages against 338). It organizes requirements into eight security program elements:

  • organizational security measures;
  • configuration management;
  • network and communications security;
  • component security;
  • protection of data;
  • user access control;
  • event and incident management;
  • system integrity and availability.

  It has 87 numbered requirements by Joltek’s count of the contents, and adds a maturity model. It was rewritten “to eliminate duplication of an information security management system”, so it assumes an ISO 27001-style management system exists or runs alongside, and covers what is specific to control systems. It also accepts that for most legacy systems the program “addresses only a subset” of the requirements, with compensating measures.

• 62443-2-4:2023 is a second edition that “does not contain significant technical changes.” Its main clarification is that some requirements are about how service providers use and configure technical capabilities, not about building them.

• PAS 62443-2-2:2025 introduces a “security protection scheme” and security protection ratings for a plant in operation.

• PAS 62443-1-6:2025 covers industrial IoT, including zero trust architecture.

• TS 62443-6-1 and 6-2 give assessors evaluation methods for service providers and components.

Which parts to read, by role

Role	Read first	Read next	Keep as reference
Asset owner	1-1, 2-1, 3-2	3-3 (to specify), 2-4 (to contract)	2-3, 2-2
Integration service provider	2-4, 3-2	3-3	2-3, 1-1
Maintenance service provider	2-4	2-3	2-1 (to fit the owner’s program)
Product supplier (components)	4-1, 4-2	6-2	2-3
Product supplier (systems)	4-1, 3-3	4-2	2-3
Machine builder or OEM	4-1, 4-2, 2-4 (as integrator)	3-3	2-3

Practitioners converge on a reading order for owners. One r/OTSecurity reply in September 2026 summed it up: “Just read 62443-1-1 then -2-1 then -3-2 and then 3-3.”

What it costs to read

The standards are not free, and the price is the first question many readers ask. At IEC list prices in October 2026, single-user electronic copies cost:

Part	CHF
2-1:2024	405
2-4:2023	405
3-2:2020	260
3-3:2013	380
4-1:2018	335
4-2:2019	405
Six core parts	2,190
All fourteen current documents	4,800

ISA sells identical editions. ISA members can read most ISA standards free online, but ISA notes that this does not apply to standards that are identical IEC adoptions, which covers most of the 62443 series. The free routes are:

• ISAGCA’s quick start guide and white papers;
• IEC’s free previews, which show each part’s contents, scope and introduction;
• NIST SP 800-82, which maps much of the series.

Who does what under 62443?

The standard names four roles: asset owner, integration service provider, maintenance service provider and product supplier. Responsibilities can be delegated, but accountability for the control system stays with the asset owner. The hand-offs that matter most are the cybersecurity requirements specification, approved by the owner before anything is built, and credentials changed at handover.

Four roles, and why a role is not a company

The series defines four principal roles. The descriptions below follow the wording ISA’s Global Cybersecurity Alliance (ISAGCA) uses in its published guides.

Role	What it does	Parts that apply most
Asset owner	Accountable and responsible for the control system; also its operator	2-1 (security program), 3-2 (risk assessment), 2-3 (patching); specifies with 3-3
Integration service provider	Designs, installs, configures, tests, commissions and hands over the automation solution; may help partition it into zones and conduits and run the risk assessment	2-4, 3-2, 3-3
Maintenance service provider	Supports the automation solution after handover	2-4, 2-3
Product supplier	Makes and supports hardware and software: control systems, embedded devices, host devices, network devices and software applications	4-1, 4-2, 3-3

The most useful sentence in ISAGCA’s lifecycle paper is about what these roles are not: “Roles are not the same as organizations. An organization can have multiple roles, and the responsibilities of a role can be split between multiple organizations.”

Plants live that sentence every day. A machine builder designs and builds its own control panel as a product supplier, commissions it on site as an integration service provider, and later offers remote support as a maintenance service provider: one company, three roles, three sets of obligations. ISAGCA calls this out directly: “It is also not uncommon that a Product Supplier organization has the Product Supplier role, the Integration Service Provider role and portions of the Maintenance Service Provider role.” A plant engineering group that builds its own systems holds the owner and integrator roles at once.

That is why the paper puts one task squarely on the plant: “The Asset Owner must determine and document the actual roles and responsibilities used for their organization and IACS Product Suppliers and Service Providers.” If a project cannot say, in writing, who is acting in which role, nobody can say who owes what.

Accountability does not move

ISAGCA’s wording is unambiguous: “while all or part of the responsibilities in a role can be delegated to other organizations, the accountability for the IACS must remain with the Asset Owner organization.” The 2024 edition of 62443-2-1 says the same thing in standards language: the asset owner “is ultimately accountable for the secure operation of an IACS”.

That sentence should change how a plant reads every integrator proposal. An integrator can design to a target security level, configure the firewalls and test the result. It cannot own the risk, because it does not own the process, the consequences or the decision about what risk is tolerable.

The same line runs inside the owner’s own organization. Vladimir has architected plant networks to 62443-based guidelines written by IT departments. Guidelines like these are a good start: they set reference architectures, naming and policy. But they cannot see a plant’s process, the consequence of losing a particular line, or the 15-year-old controller that cannot run modern authentication. The 3-2 risk assessment asks for exactly that knowledge, and only plant engineering and operations have it. The guidelines come from the corporation; the system under consideration, its essential functions and its tolerable risk have to come from the plant.

Who does what, phase by phase

ISAGCA’s Security Lifecycles in the ISA/IEC 62443 Series (October 2020) walks through the automation solution’s life phase by phase. The table below condenses it. The paper predates the 2023 and 2024 editions of 2-4 and 2-1, but the division of work still holds.

Phase	Asset owner	Integration service provider	Maintenance service provider	Product supplier	What changes hands
Specify (3-2, ZCR 1 to 3)	Accountable, responsible	Consulted			System boundary, zone and conduit drawing, target security level per zone
Design (ZCR 4 to 7)	Accountable, approves	Responsible		Consulted	Cybersecurity requirements specification
Implement	Accountable; owns operational procedures	Responsible for technical measures	Responsible for maintenance procedures		Configured system
Verify and validate	Accountable	Responsible	Responsible		Test reports; formal handover; credentials changed
Operate	Accountable, responsible				Re-assessment, incident response
Maintain	Accountable		Responsible	Responsible for product updates	Change management, patching
Decommission	Accountable, approves		Responsible		Purged data, retired assets

Two hand-offs in that table decide most outcomes.

The cybersecurity requirements specification (CRS). It is the output of the design work in 62443-3-2. It contains:

• the system description;
• zone and conduit drawings;
• the target security level for each zone and conduit;
• operating and threat assumptions;
• the organization’s policies;
• tolerable risk;
• regulatory requirements.

ISAGCA states that it “must be approved by the Asset Owner before the Implementation Phase can start.” ISAGCA’s quick start guide adds that the CRS “does not have to be a standalone document.” In most projects it becomes the security section of the functional specification and the request for proposal. If it is not written and approved before the purchase order, there is nothing to test against at the factory or site acceptance test.

Handover. ISAGCA’s lifecycle paper says the owner “Must change credentials (accounts, passwords, keys) before putting the IACS into operation.” It reads like housekeeping. It is not. Accounts and remote paths left over from commissioning are exactly what attackers use: Dragos’s 2026 field data, from its own incident response work, found compromised VPN or jump-host credentials in 73 percent of the cases it has handled.

The parties a plant actually deals with

The four roles map onto the organizations a plant manager meets every week, usually imperfectly.

Party	Role in 62443 terms	What they owe the plant	What gets misunderstood
Plant engineering and operations	Asset owner (operations)	Process knowledge, procedures, acceptance, change control	That the integrator “does the 62443”, and that security ends at handover
Corporate IT and the CISO	Asset owner (governance)	Security program, risk method, incident response, funding	That an IT playbook runs unchanged on a production line
Machine builders and OEMs	Product supplier; often integrator and maintainer too	Hardening guides, patch information, vulnerability handling; from 2027, EU product-law obligations for machines placed on the EU market	That “62443 ready” means anything without a certificate and its scope
System integrators	Integration service provider	The CRS, secure integration, test evidence, a clean handover	That integration equals compliance
Product suppliers	Product supplier	Certified development process and products, update policy, end-of-support dates	That a component certificate covers the plant’s configuration
Certification bodies	Assessors, outside the four roles	Independent assessment of a defined scope	That every certificate means the same thing
Insurers and auditors	Outside the standard	Questionnaires and audits	That 62443 evidence earns automatic credit; no published insurer requirement was found
Regulators and class societies	Compliance authority	Outcome rules and acceptance	That “62443 compliant” is accepted as proof without review

Governance is where these lines usually fail. In the SANS Institute’s 2024 survey of more than 530 professionals, 82 percent of control system programs followed industry standards when a CISO owned governance, against 42 percent where there was no corporate-wide policy for control systems. The standard does not require any particular org chart. It requires that someone owns the program and that everyone else knows it.

For how plants select and manage the firms that fill these roles, see working with systems integrators. Joltek’s own work usually sits across these lines: assessing what a plant has, designing the architecture, and helping the owner write requirements its integrators and suppliers can be held to.

How do zones, conduits and security levels work?

Zones group assets that share security needs; conduits are the controlled paths between them. A risk assessment sets a target security level for each zone and conduit, from SL 1 to SL 4, across seven requirement areas. Products are certified for a capability level; what the plant actually achieves is checked after commissioning.

Zones and conduits

The definitions, as ISAGCA reproduces them from the standards:

• A zone is a “collection of entities that represents partitioning of a System under Consideration on the basis of their functional, logical, and physical (including location) relationship.” A zone has a clear border, and its policy is enforced both at the edge and inside it.
• A conduit is a “logical grouping of communication channels, between or connecting two or more zones, that share common security requirements.”

Two consequences follow. First, every asset in the system under consideration belongs to a zone or a conduit; nothing is left unassigned. Second, a zone is a security concept, not a network technology. A VLAN can implement part of a zone, but a VLAN on its own separates broadcast traffic, not trust. If routing between VLANs is open, two VLANs are effectively one zone. That distinction is among the most common findings in the plant network assessments Vladimir has carried out: VLANs drawn as boundaries on paper, with nothing enforcing policy between them.

62443-3-2 also names five kinds of asset that should be separated from the rest when zones are drawn:

• business assets from control assets;
• safety-related assets;
• temporarily connected devices, such as engineering laptops;
• wireless devices;
• devices connected through external networks.

For how this is done on a live plant without stopping production, see OT network segmentation for brownfield plants. For one vendor’s switching and segmentation options, see Stratix and segmentation.

The risk assessment, step by step

62443-3-2 lays out seven steps, with 32 numbered requirements between them. It does not prescribe a scoring method. The plant uses its own risk matrix, consistent with how the rest of the organization measures risk, and the standard’s informative annex shows example matrices.

Step	Title in 62443-3-2	What it does
ZCR 1	Identify the system under consideration	Draw the boundary and list every access point
ZCR 2	Initial cybersecurity risk assessment	A coarse, worst-case view of consequence and likelihood
ZCR 3	Partition into zones and conduits	Group assets; separate the five classes above
ZCR 4	Risk comparison	If initial risk exceeds tolerable risk, go to the detailed assessment
ZCR 5	Detailed cybersecurity risk assessment	Per zone and conduit: threats, vulnerabilities, consequences, likelihood, target security level, existing and additional countermeasures, residual risk (13 sub-steps)
ZCR 6	Document requirements, assumptions and constraints	Produces the cybersecurity requirements specification, zone and conduit drawings, and the threat and operating assumptions
ZCR 7	Asset owner approval	The owner signs off; the integrator cannot self-approve

Security levels

A security level describes the kind of attacker a zone or conduit should withstand. The definitions, as ISAGCA presents them:

Level	Protection against	Means	Resources	Skills	Motivation
SL 1	Casual or coincidental violation
SL 2	Intentional violation	Simple	Low	Generic	Low
SL 3	Intentional violation	Sophisticated	Moderate	IACS-specific	Moderate
SL 4	Intentional violation	Sophisticated	Extended	IACS-specific	High

A security level is not one number. It is a vector with one value for each of the seven foundational requirements:

FR	Name	In plain terms	System requirements in 62443-3-3
FR 1	Identification and authentication control	Who and what is connecting	13
FR 2	Use control	What they are allowed to do	12
FR 3	System integrity	Stopping unauthorized changes to software, data and configuration	9
FR 4	Data confidentiality	Keeping information private where that matters	3
FR 5	Restricted data flow	Segmentation and controlled paths between zones	4
FR 6	Timely response to events	Logging, monitoring and response	2
FR 7	Resource availability	Keeping the system running and recoverable	8

62443-3-3 contains 51 system requirements in all. Requirement enhancements raise the bar from one level to the next. An IEC committee page gives example vectors, such as SL = (3, 3, 3, 1, 2, 1, 3): strong protection of access, use and integrity, low emphasis on confidentiality. An element can be set to SL 1, or left without a target, where a property such as confidentiality is not an objective for that zone.

SL-T, SL-C and SL-A

Three different security levels appear in the series, and confusing them causes most of the misunderstandings about certification:

Type	Meaning	Who produces it	Where it is used
SL-T (target)	The level a zone or conduit needs	The asset owner, through the 62443-3-2 risk assessment	Recorded in the CRS; used to select products and countermeasures
SL-C (capability)	What a system or component can provide when properly configured, without extra countermeasures	Suppliers, under 62443-3-3 (systems) and 62443-4-2 (components)	Product certificates state SL-C
SL-A (achieved)	The actual level of the solution once commissioned and running	Measured after commissioning	Audits, re-assessments, the plant’s real exposure

The sequence is simple to state:

1. The owner sets SL-T per zone.
2. The integrator selects systems and components whose SL-C meets the target, or adds compensating countermeasures where it does not.
3. SL-A is what is true in the plant afterwards.

62443-4-2 states that SL-T and SL-A “are out of scope” for a component. A certified SL-C says nothing, on its own, about the SL-A of the plant.

Security levels are not maturity levels

The series also uses maturity levels, and they measure something else entirely:

	Security level (SL)	Maturity level (ML)
Measures	Strength of technical protection against a defined attacker	How well processes are defined and practiced
Scale	SL 1 to SL 4, per foundational requirement	ML 1 Initial, ML 2 Managed, ML 3 Defined, ML 4 Improving
Applies to	A zone, conduit, system or component	A security program, a service provider, a development process
Where defined	3-2, 3-3, 4-2	2-1, 2-2, 2-4, 4-1

The maturity model is based on CMMI, with its levels 4 and 5 combined into one. A supplier’s development process certified at ML 3 tells a buyer how the supplier works. It says nothing about the security level of any particular product.

Three ways plants misapply security levels

1. One level for the whole site. It feels simpler, and it is wrong. One r/OTSecurity commenter put it in October 2025: “A site should never all be sl-t:3.” Targets belong to zones and conduits, set from the consequence of losing what is inside them.
2. A level per industry. Some ranking explainers assign SL 3 to food and beverage or pharma and SL 4 to energy and water. The standard does not work that way. A water utility’s administrative network and a food plant’s ammonia refrigeration controls can have very different consequences from what their industry label suggests.
3. A level chosen from what the equipment supports. The target comes from risk, not from the capability of the controller that happens to be installed. When an installed device’s SL-C falls short of the zone’s SL-T, the answer is a compensating countermeasure at the zone boundary, or a replacement plan, not a lower target.

A worked example

The table below is illustrative, not a recommendation for any real plant. It shows how a mid-sized food or consumer goods plant might come out of a 3-2 assessment. Every number would come from that plant’s own risk matrix and tolerable-risk decisions. Vectors run FR 1 to FR 7.

Zone or conduit	What is in it	Consequence if compromised	Illustrative SL-T vector	Reasoning
Packaging line zone	Line PLCs, HMIs, drives, vision	Line stoppage, product waste	(2, 2, 2, 1, 2, 1, 2)	Production impact, low confidentiality need
Process cell zone	Batch controllers, recipe management	Off-spec product, food safety risk	(2, 2, 3, 1, 2, 2, 2)	Integrity of recipes and set points matters most
Safety system zone	Safety controllers, burner management	Harm to people and equipment	(3, 3, 3, 1, 3, 2, 3)	Separated per ZCR 3.3; highest integrity and isolation
Utilities zone	Boilers, compressors, refrigeration	Site-wide outage, hazardous releases	(2, 2, 2, 1, 2, 1, 3)	Availability carries the most weight
Site operations zone	SCADA servers, historian, engineering workstations	Loss of visibility; a path to every line	(3, 3, 2, 2, 3, 2, 2)	Concentrates access to everything below
Enterprise conduit (through the industrial DMZ)	Data to ERP and reporting; patch and antivirus feeds	A route in from business IT	(3, 3, 2, 2, 3, 2, 2)	The main boundary between business and control
Vendor remote-access conduit	OEM and integrator support sessions	Direct access to controllers	(3, 3, 2, 2, 3, 3, 2)	The path behind most incident cases in field data

What does 62443 look like in a brownfield plant?

It starts with what is there: an asset inventory, accurate network drawings, and a risk assessment that groups old and new equipment into zones. Legacy controllers that cannot meet modern requirements get compensating countermeasures at the zone boundary. Segmentation, remote access and credentials usually come first, because assessments keep finding the same gaps.

What assessments usually find

Most plants were not designed to 62443. Their networks grew line by line, project by project, each integrator leaving its own conventions behind. In the plant network, server and segmentation assessments Vladimir has carried out, the findings that recur are less about missing products than about configuration:

• Flat networks. One large network where any device can reach any controller, often bridged straight to the office network.
• VLANs treated as security boundaries. VLANs exist and are drawn neatly, but routing between them is open, so they separate broadcast traffic and nothing else.
• NAT standing in for segmentation. Network address translation hides addresses and solves IP conflicts between machines, but it does not decide which traffic is allowed. It is not a conduit.
• Shared credentials. The same accounts and passwords across HMIs, engineering stations and controllers, often unchanged since commissioning.
• Undocumented remote access. Vendor modems, remote access boxes and VPN accounts that nobody on site can list completely.

Each of these maps directly onto the standard:

• the first three are foundational requirement 5 (restricted data flow) and the zone and conduit design;
• the fourth is foundational requirements 1 and 2;
• the fifth is the secure remote access elements of 62443-2-1.

Fixing them does not require new controllers. It requires deciding where the boundaries are, then enforcing them.

Legacy equipment and compensating countermeasures

The standard was written knowing that plants run old equipment. 62443-3-3 includes compensating countermeasures as a recognized constraint, and 62443-4-2 does the same for components. 62443-2-1:2024 says that for most legacy systems the security program “addresses only a subset” of the requirements.

Practitioners are blunt about the scale of the problem. When an r/PLC thread in July 2026 claimed most modern PLCs already conform to 62443, one reply came back: “SLCs don’t and they still run 70% of the worlds infrastructure.” The figure is a forum comment, not data, but the point is real: plants will run unsupportable controllers for years.

Common compensating countermeasures for legacy controllers include:

• placing them in their own zone, whose conduit is the control point: a firewall that allows only the specific industrial protocols and hosts the line needs;
• routing engineering access through a hardened jump host in the site operations zone, rather than from laptops on the plant floor;
• monitoring the conduit for changes and unexpected traffic;
• keeping tested backups and approved program versions, so a compromised controller can be restored.

A pharmaceutical practitioner described the same pattern for validated plants, where changing a system triggers revalidation: “No changes that alter the device or system without a recert … You separate obsolete and unpatchable into Zones.”

A brownfield sequence

Step	What happens	Why in this order
1. Inventory and drawings	List controllers, HMIs, servers, switches and remote access paths; draw the network as it is	Nothing else can be assessed without it. See OT asset inventory
2. System under consideration	Choose the boundary and the essential functions	Keeps the first assessment finite
3. Initial risk assessment	Rank consequences per area	Shows where the first money goes
4. The enterprise boundary	Build or fix the industrial DMZ between business and control networks	Removes the broadest path in
5. Remote access	One controlled conduit for vendors and integrators, logged and time-limited	The path field data ties to most incidents. See controlled remote access
6. Zones inside the plant	Enforce boundaries between lines, utilities and safety systems	Contains incidents to one area
7. Accounts and credentials	Remove shared and default accounts; change integrator credentials	Cheap, and closes common entry points
8. Monitoring, backup and change control	Watch the conduits; keep approved versions of controller programs	Detects drift and enables recovery. See PLC version control in practice

The order matters because the cure can cost more than the disease if it is done carelessly. One practitioner warned that some security fixes they had seen were “significantly more expensive, caused more cumulative downtime” than the risks they addressed. Segmentation on a live plant is a phased program with planned outage windows, not a weekend cut-over.

Two related guides go deeper: designing a plant network for a small or mid-sized manufacturer, and the risk of unmanaged switches on production networks.

What can be certified to 62443, and what is a certificate worth?

Products, control systems, supplier development processes and integrators can be certified, through ISASecure, the IECEE scheme or bodies such as TÜV and exida. Since February 2026 a specified control system and its owner’s program can be certified too. No scheme certifies a whole plant, and a product certificate proves capability, not the plant’s achieved security.

What can be certified, and how

Subject	Can it be certified?	Standard	Main routes
A component (PLC, switch, HMI software, gateway)	Yes	4-2, plus the supplier’s 4-1 process	ISASecure CSA; IECEE CB scheme; TÜV, exida and others
A control system product	Yes	3-3, plus 4-1	ISASecure SSA; IECEE
A supplier’s development process	Yes	4-1	ISASecure SDLA; IECEE; TÜV and others
An integrator or maintenance provider	Yes	2-4 (evaluated with 6-1)	IECEE; exida, TÜV and others
A specified control system and its owner’s program	Yes, since 17 February 2026	2-1, 2-4, 3-2, 3-3	ISASecure ACSSA, a three-year certificate
A whole plant or company	No		No scheme exists
A person	Training certificates only		ISA’s certificate program; no IEC person certification

ISASecure and IECEE

Two schemes dominate.

ISASecure is run by the ISA Security Compliance Institute, a subsidiary of ISA, and has certified products and development practices since 2010. Its certification bodies must be accredited to ISO/IEC 17065. Those listed in October 2026 were:

• BYHON;
• the Control System Security Center (Japan);
• exida;
• Palindrome Technologies;
• Perseus;
• TÜV SÜD PSB;
• TÜV Rheinland;
• UL Solutions.

Its schemes are:

• CSA for components;
• ICSA for industrial IoT devices;
• SSA for systems;
• SDLA for development processes;
• ACSSA, since February 2026, for an asset owner’s specified control system.

A sixth scheme, for high-criticality components, is expected in early 2027.

IECEE is IEC’s own conformity assessment system. Its industrial cyber security program issues certificates through national certification bodies under the operational document OD-2061. It covers 3-3, 4-1, 4-2 and 2-4, and IECEE added 2-1:2024 in October 2024. Many suppliers also hold certificates issued directly by TÜV, exida or similar bodies outside either scheme.

What the public lists show

ISASecure publishes opt-in lists of certified products and organizations. A count of those lists on 23 October 2026 found:

• 97 component entries from 33 suppliers. 56 are current CSA certificates: 36 at capability level 1, 17 at level 2 and 3 at level 3, with none at level 4. The other 40 are legacy certificates under the older EDSA scheme.
• 10 system entries, all at level 1, from ABB, Emerson, GE Vernova, Honeywell, Schneider Electric, Valmet and Yokogawa.
• 51 development organizations certified under SDLA. 22 were listed in 2026 alone.

Several of the largest automation suppliers do not appear on those lists, including Siemens, Rockwell Automation, Mitsubishi Electric, Omron, Beckhoff and WAGO. That does not mean they are uncertified. They use other routes; Rockwell Automation, for example, announced in 2018 that TÜV Rheinland had certified its development process to 62443-4-1. The ISASecure lists therefore undercount the market, and no single public register covers every certificate.

No ACSSA certificate had been listed as of 23 October 2026. The first certification body accredited for the scheme, Perseus, was announced on 9 June 2026.

How to read a certificate

Before a certificate goes into a purchase decision, check:

• The subject. The exact product, model and firmware or software versions covered. A certificate for one version does not cover the next by default.
• The standard and edition. 4-1, 4-2, 3-3 or 2-4, and which edition.
• The level. For products, the SL-C, ideally per foundational requirement. For processes and providers, the maturity level.
• The scope. For systems, which zones and configurations were assessed.
• The issuer. The certification body, its accreditation and the scheme.
• Dates and conditions. Issue and expiry, surveillance, and the conditions attached. Most product certificates assume the supplier’s security guide and hardening instructions are followed: SL-C is what a product can provide “when properly configured.”

When certificates disappoint

Practitioners report certificates that do not hold up in the field. One r/OTSecurity commenter described an argument “with an OEM over their 4-2 certified product” that failed a simple network scan. Another noted how many certified suppliers have “no asset inventory in place”, a gap the commenter said is “specifically spelled out as a requirement.” A third described an accreditor who refused to let a product be marketed at the security level its makers claimed, and was right. These are anecdotes, not data. The lesson for a buyer is still clear: a certificate narrows the question, it does not answer it. Test what was delivered.

Certificates for people

ISA’s certificate program covers four courses with exams:

• Fundamentals Specialist (IC32);
• Risk Assessment Specialist (IC33);
• Design Specialist (IC34);
• Maintenance Specialist (IC37).

Completing all four earns the Expert certificate. Self-paced courses list at USD 2,160 per seat, and ISA states that renewal is not required.

These are training certificates, not certifications of competence in the conformity-assessment sense, and their value is debated. One commenter who said they had written part of the standard put it this way: “I honestly wouldn’t pay for the certifications myself. A lot of employers will pay for the certifications once you’re on board.” For a plant team, the fundamentals course is most useful as a way to give engineering, IT and purchasing a shared vocabulary.

How does 62443 apply across industries?

Regulated and safety-heavy sectors borrow 62443 into their own rules: ship classification, rail, offshore oil and gas, and process safety through IEC 61511. Power, water and US pipelines run their own regimes. General manufacturing adopts it voluntarily, driven by corporate programs and, from 2027, by EU machinery and product law. Security levels follow risk, not industry. For the regulators, standards and control stacks of each industry, see Joltek’s guide to how automation differs from one industry to the next.

Sector	Is 62443 in the rule?	How it is used	Who drives it	What is different
Maritime (new ships)	Yes in UR E27; E26 uses the method	Equipment approval, supplier development process, ship zone diagrams	Class societies	The shipbuilding contract date decides scope
Rail	Yes in CLC/TS 50701	Risk assessment, security level vectors	Operators, standards bodies	Long asset life and a safety-case culture
Offshore oil and gas	Yes in industry guidelines	Program and project method	Operators	Remote, high-consequence, safety-system heavy
US pipelines	No	Procurement, supplier assurance	TSA	NIST CSF-based directives
Electric power	No (NERC CIP)	Product procurement, supplier assurance	FERC and NERC	A compliance regime already exists
Chemicals and process	Through IEC 61511	Security of safety instrumented systems	Functional safety owners	The safety team already has a way in
Water and wastewater	No	Rare, voluntary	EPA, Congress	Small utilities, thin budgets
Pharma and life sciences	No	Voluntary, shaped by validation	Quality and validation	Every change can trigger revalidation
Food, beverage and discrete	No	Corporate programs; supplier requirements	Corporate policy, customers	Many sites, mixed vintages, OEM remote access
Semiconductor	SEMI E187 is separate	Equipment baseline	Fabs	Supply-chain driven
Building automation	No	Product certification	Suppliers	Many devices, many owners
Nuclear	No (IEC 62645 family)	Reference	Nuclear regulators	A separate standards family

Maritime

Ships are where 62443 comes closest to mandatory. The International Association of Classification Societies withdrew its first 2022 versions of UR E26 and E27 before they took effect and issued revision 1 in 2023. Both apply to ships contracted for construction on or after 1 July 2024. E27’s equipment requirements are “based on the selected requirements in IEC 62443-3-3”, and its secure development section cites 62443-4-1 clause by clause. E26 sets the ship-level requirements:

• a zones-and-conduits diagram;
• a cyber security design description;
• an asset inventory;
• test procedures.

The shipyard acts as the integrator until delivery, and the class society reviews and surveys.

Rail

The European technical specification CLC/TS 50701 adapts 62443 to railway applications and says it is based on or derived from the series. An international successor, IEC 63452, was at or near final approval in 2026. Rail operators and suppliers also endorsed the Europe’s Rail Cybersecurity Specification in March 2025. Rail’s long asset life and safety-case culture make 62443’s lifecycle approach a natural fit.

Offshore oil and gas, and pipelines

Offshore operators led some of the earliest practical guidance. DNV-RP-G108, published in 2017, came out of a joint industry project with Shell Norge, Statoil (now Equinor), Woodside and Lundin Norway, alongside Siemens, Honeywell, ABB, Emerson and Kongsberg Maritime. Woodside’s engineering lead said at the time: “Aligning our Operational Technology cyber security approach to IEC 62443 enables us to learn from and contribute to industry knowledge and capability.” The Norwegian industry guideline Offshore Norge 104, revised again in June 2026, uses 62443-2-1 requirement identifiers.

US pipelines are different. The TSA’s security directives and API Std 1164 (third edition, 2021) rest on NIST CSF rather than 62443.

Electric power

NERC CIP is mandatory and enforceable for the North American bulk electric system, and it is not 62443. A 2024 white paper from ISAGCA, the Utilities Technology Council and Cumulys mapped the two. It concluded that, “with few exceptions, the technical cybersecurity capabilities needed to comply with NERC CIP are substantially supported by the existing ISA/IEC 62443 product cybersecurity standards”, while listing the CIP requirements 62443 does not meet. The paper describes itself as an interpretation, “not a product of the ISA99 committee.” In practice, utilities use 62443 certificates in procurement and supplier assurance, under CIP’s supply chain requirements, and IEC 62351 for the security of power system protocols.

Chemicals and process industries

Process plants have a door into 62443 that other sectors lack: functional safety. The 2016 edition of IEC 61511, the process-sector safety instrumented systems standard, added security risk assessment requirements for the safety system. ISA-TR84.00.09-2024 gives guidance on integrating cybersecurity across the safety lifecycle, and IEC TR 63069:2019 explains how to apply IEC 61508 and 62443 together. 62443-3-2 itself calls for safety-related assets to be placed in their own zones.

The US chemical-security regime CFATS no longer applies; its statutory authority lapsed in July 2023. For many process plants, the safety team’s existing discipline of hazard analysis, independent layers of protection and management of change is the easiest place to anchor a 62443 program. For how that separation plays out at a chemical plant, from the SIS architecture to the lessons of TRITON, see our guide to chemical plant automation.

Water and wastewater

Water utilities in the US work under America’s Water Infrastructure Act, EPA guidance and AWWA’s cybersecurity guidance, none of which adopts 62443. Most utilities are small, with thin budgets and few dedicated staff. 62443 concepts, especially zones and conduits and secure remote access, still apply. But the frameworks utilities are measured against are NIST-based.

Pharmaceutical and life sciences

No pharmaceutical regulation names 62443. FDA’s 21 CFR 211.68 requires that only authorized personnel can change computerized systems and that backups are protected. EU GMP Annex 11, under revision, sets change control expectations. What makes pharma different is validation: a change to a validated system can trigger revalidation. That pushes plants toward the zone-based approach the practitioner quoted above described, isolating “obsolete and unpatchable” systems rather than changing them.

Food, beverage and discrete manufacturing

General manufacturing has no sector rule. Adoption is driven by corporate security programs and customer requirements and, for machines sold into Europe, by the CRA and Machinery Regulation. Most such plants share a profile:

• many sites of mixed vintage;
• acquired plants with their own conventions;
• machine builders who keep remote access to their equipment;
• short changeover windows;
• thin OT security staffing.

The most useful public example is Campari Group, presented in an ISAGCA webinar in May 2024. The spirits company noted that it “does not operate in a regulated sector” but uses international standards as the reference for its program: ISO 27000 for IT, NIST and 62443 for OT. Its approach:

1. a 62443-2-1 assessment on a pilot plant;
2. a risk assessment combining a business impact analysis (ISO 22317) with 62443-3-2, to set zones and target levels;
3. a reference design drawn from seven “typical” plants;
4. a plant-by-plant roll-out.

For a multi-site food or consumer goods manufacturer, that pattern of pilot, template and roll-out is the practical one.

The business case is the obstacle. A discrete machine builder on r/PLC was told plainly in 2024 that certification “only helps if your customers care”, and that without a regulatory requirement it is “a business decision” driven by whether customers demand it or will pay for it.

Semiconductor, building automation and nuclear

• Semiconductor fabs use SEMI E187 and E188 for equipment cybersecurity. These are separate standards, though a revision of E187 aims at closer alignment with 62443.
• Building automation suppliers are among the most active certificate holders. Johnson Controls, Honeywell, Carrier and Trane all appear on ISASecure’s lists.
• Nuclear plants follow IEC 62645 and related standards, which build on ISO 27001 and IAEA guidance and seek “better consistency” with 62443 where relevant.

What actually changes from one industry to the next

The method stays the same; the inputs change:

• Consequence scoring. Harm to people, environmental release, product safety and recall, regulatory exposure and lost production weigh differently in each sector.
• The safety interface. Process and energy plants must integrate with functional safety; many discrete plants have simpler machine safety systems.
• Change control. Validated pharma systems and certified rail or marine equipment cannot change freely; general manufacturing has more room.
• Who pays. Regulated sectors budget for compliance; general manufacturers need a customer, an insurer or an incident to justify the spend.

None of that changes the core rule: security levels come from the risk in each zone, not from the industry label on the plant.

What should a plant demand from integrators, OEMs and suppliers?

Ask for evidence matched to the question: a 4-1 certificate for how a supplier builds products, 4-2 or 3-3 for what a product can do, and 2-4 for how an integrator works. Write the requirements specification, security acceptance tests, hardening guides, patch information and credential handover into the contract, because unwritten requirements do not happen.

Match the evidence to the question

Question the plant is asking	Evidence to ask for	What to check
How does this supplier build and patch products?	A 4-1 certificate (ISASecure SDLA, IECEE or another body)	Maturity level, scope of sites and product lines, expiry
What can this product do?	A 4-2 certificate (components) or 3-3 certificate (systems)	SL-C per foundational requirement, exact versions, conditions
How does this integrator or maintainer work?	A 2-4 certificate or assessment	Maturity level, which functional areas were in scope
Will the delivered system meet our targets?	The approved CRS, plus factory and site acceptance test evidence	Tests mapped to each zone’s SL-T
How will vulnerabilities and updates be handled?	Security update policy, advisory process, support period	For products sold in the EU, the CRA’s reporting duty and support period obligations
Is a specific site system certified?	An ACSSA certificate	Rare so far; check the scope

For integrator and maintenance work, 62443-2-4 lists the functional areas a plant can put into a contract. The first edition identified them as SP.01 to SP.12:

• solution staffing;
• assurance;
• architecture;
• wireless;
• safety instrumented systems;
• configuration management;
• remote access;
• event management;
• account management;
• malware protection;
• patch management;
• backup and restore.

What to write into the contract

Practitioners know how this works. In an r/PLC thread in May 2026 about how machine builders track security advisories, one commenter wrote: “If it’s not requirement in the contract documents … it doesn’t happen.” Another added that “after FAT and final signoff the machine is their equipment.” Security requirements belong in the documents that drive the project:

• The CRS, or a security section of the functional specification, as a contractual deliverable, with the applicable parts and the SL-T per zone and conduit.
• Hardening to the supplier’s security guide, with exceptions documented and approved.
• Account and credential lists, and their change at handover.
• Remote access only through the plant’s own controlled conduit, never through equipment-specific modems or boxes.
• Patch and vulnerability notification obligations for the support period.
• Documentation: as-built zone and conduit drawings, the asset inventory, backups and approved program versions.
• Security tests at the factory and site acceptance tests.
• For products sold into the EU: evidence of how the manufacturer meets the CRA. From December 2027 that includes a software bill of materials in its technical documentation.

For the broader contract language, see systems integrator scope of work.

Security tests at FAT and SAT

ISAGCA’s lifecycle guidance lists the kinds of tests that belong in verification:

• vulnerability scans;
• penetration tests;
• intrusion detection tests;
• access control tests.

In plant terms, a security acceptance test checks that:

• accounts and roles match the specification, and default accounts are gone;
• unused ports and services are disabled;
• firewall rules match the conduit design, and nothing else passes;
• remote access works only through the approved path;
• events reach the plant’s logging and monitoring;
• backups restore, and the restored system runs;
• every commissioning credential has been changed.

Scans on live production systems need care and a plan. Run them at the factory acceptance test where possible. See factory acceptance testing for plant controls.

“62443 ready” and other claims

Marketing claims run ahead of certificates. A machine builder on r/PLC asked in 2024 how to market machines as “IEC 62443 Ready”, and was told the easiest mechanism would be a firewall in front of the controls. Another reply was that “there’s an entire certification program you need to follow and complete an audit of to be able to market a product as 62443 compliant.” For a buyer, the test is simple. Ask which part, which level, certified by whom, for which versions, and under what conditions. A claim that cannot answer those questions is not evidence.

What CISA tells buyers to ask for

CISA’s Secure by Demand guide for OT, written with eleven partner agencies, lists twelve security elements buyers should look for in products:

• configuration management;
• logging in the baseline product;
• open standards;
• ownership;
• protection of data;
• secure by default;
• secure communications;
• secure controls;
• strong authentication;
• threat modeling;
• vulnerability management;
• upgrade and patch tooling.

The guide aligns them with security level 3 of 62443-4-2 and 3-3. It is free, and it works as a checklist for any request for proposal. Plants that want an independent party to hold suppliers to those requirements during a project can use an owner’s engineer.

How does 62443 fit with NIST, ISO 27001, NERC CIP, IEC 61511 and the CRA?

They complement each other. NIST SP 800-82 references 62443 throughout, 62443-2-1 assumes an ISO 27001-style management system, NERC CIP is a separate mandatory regime that 62443 products can support, IEC 61511 requires a security risk assessment for safety systems, and the CRA points to 62443-based standards as one way to show conformity.

Framework	What it is	Mandatory?	Relationship to 62443
NIST SP 800-82 Rev. 3 (2023)	US guide to OT security	No (free guidance)	Thanks ISA for allowing use of 62443 material; maps tasks to 62443-2-1 requirements; points to 3-2 for risk and 2-3 for patching. The Rev. 4 draft (September 2026) keeps those references
NIST CSF 2.0 (2024)	Enterprise cybersecurity framework	No	The CSF 2.0 document does not name 62443; 62443-2-1:2024 includes its own cross-reference to the CSF
ISO/IEC 27001:2022	Information security management system, certifiable at company level	No	62443-2-1:2024 was written to avoid duplicating an ISMS; its annex cross-references ISO 27001 (2013 edition)
ISO/IEC 27019:2024	Security controls for energy utilities	No	IEC notes it can be used with 62443
NERC CIP	Rules for the bulk electric system	Yes, for registered entities	Separate regime; 62443 products “substantially support” its technical capabilities, with exceptions
IEC 61511	Functional safety for process safety systems	Adopted by regulators in many jurisdictions	The 2016 edition requires a security risk assessment of the safety system; ISA-TR84.00.09 bridges to 62443
EU Cyber Resilience Act	Product law for products with digital elements	Yes, for products on the EU market	Does not name 62443; 62443-based harmonised standards are in preparation as one route
EU Machinery Regulation	Product law for machinery	Yes, from 20 January 2027	Does not name 62443; cyber-related essential requirements in Annex III
EU NIS2	Obligations for essential and important entities	Yes, through national law	Does not name 62443; refers to relevant international standards
CISA CPG 2.0	Voluntary performance goals	No	Goals map to NIST CSF or 62443

“62443 vs NIST” is the wrong question

Search for “IEC 62443 vs NIST” and the first results are machine-generated “mapping” pages that claim overlap percentages with no stated method. The real relationship is simpler:

• NIST CSF describes what an organization’s cybersecurity program should achieve;
• NIST SP 800-82 explains how to apply it to OT, citing 62443 throughout;
• 62443 supplies the detailed requirements and the shared vocabulary for owners, integrators and suppliers.

Most mature programs use NIST CSF or ISO 27001 at the enterprise level and 62443 for the plant, its projects and its suppliers. A plant does not have to choose. Neither does 62443 replace NERC CIP, NIS2 or any other mandatory regime. It is often the clearest way to meet them.

Where the Cyber Resilience Act stands

As of mid-October 2026, no harmonised standard under the CRA had been cited in the Official Journal. CENELEC is drafting amendments to EN IEC 62443-4-1 and 4-2, along with six OT product “profiles” built using the method in 62443-1-5. The 4-2 amendment adds:

• requirement enhancements for the CRA’s essential requirements;
• rationales for each enhancement;
• applicability criteria;
• evaluation artifacts based on 62443-6-2.

Exida, whose staff co-chair the IEC team working on 4-1, wrote in June 2026: “Compliance with today’s IEC 62443 standard is NOT sufficient evidence to claim conformity to the CRA regulation.”

The CRA asks for more than any current 62443 part covers, including vulnerability reporting within 24 hours, a support period of at least five years in most cases, and documentation of software components. For a plant that buys machines and components, the practical consequence arrives in purchasing: from December 2027, suppliers selling into the EU must carry CE marking that includes cybersecurity, and their reporting duties already apply.

For one vendor-specific view of how NIS2 and 62443 evidence fit together, see NIS2 and IEC 62443 evidence for backup and change tools.

What does 62443 cost?

The six core documents cost about CHF 2,190 and ISA courses list at about USD 2,160 each. Product and process certification is quoted per project; one consultancy estimates EUR 15,000 to 50,000 per certificate. A plant program has no reliable public price, and the largest budget is usually remediation: segmentation, remote access and unsupportable equipment.

Item	Figure	Source and status
The six core documents	CHF 2,190 (all fourteen: CHF 4,800)	IEC list prices, October 2026
ISA certificate courses	USD 2,160 list per self-paced seat; four courses for the Expert certificate	ISA, October 2026; practitioners report discounts through membership and promotions
ISASecure scheme fees	CSA USD 1,200 per component per year; SDLA USD 1,500 per year; ACSSA certification body registration USD 3,000 per three-year certificate	ISASecure; scheme fees only, not the assessor’s fees
Process certification (4-1 or 2-4 at maturity level 2)	EUR 15,000 to 35,000	Secuvi, a consultancy; a rough estimate
Product certification (4-2)	EUR 25,000 to 50,000, on top of a certified 4-1 process	Secuvi; a rough estimate
System or blueprint certification (2-4 or 3-3)	EUR 30,000 to 50,000	Secuvi; a rough estimate
Machine builders’ CRA and Machinery Regulation compliance	More than EUR 1,000,000 per platform architecture	CECIMO and partner associations, in a 2026 request to delay the rules; an advocacy estimate
An asset owner’s whole program	No traceable public figure	Research for this guide found none

Why the program costs more than the paperwork

The documents and the training are the cheap part. The money goes to remediation:

• network redesign and segmentation hardware, installed in planned outage windows;
• a proper remote access conduit;
• monitoring;
• replacing equipment that cannot be protected;
• engineering hours to document what exists.

Australia’s Department of Home Affairs, reviewing cost submissions for its own critical infrastructure rules in 2026, called the estimates “highly variable and often measure-specific” and “not suitable for direct national extrapolation”. That is a fair warning against any single number.

Some ranking pages publish program costs and timelines with no source, such as six- or seven-figure euro ranges and “12 to 24 months”. Ignore them. Under-pricing is the more common failure. One r/OTSecurity commenter described a supplier that costed an eight-month 4-1 and 4-2 certification project for new products at $15,000, then “wondered why we lost money on the project.” That is one person’s account, but the pattern is familiar to anyone who has watched security scoped as paperwork.

How to budget honestly

• Fund the assessment first. The inventory, drawings and high-level risk assessment turn an unknown into a ranked list of zones and gaps.
• Then fund remediation by consequence, zone by zone, starting with the enterprise boundary and remote access.
• Attach security to capital projects. A new line written to a CRS from the start costs far less than retrofitting later.
• Budget for operation, not just the project: monitoring, account reviews, patch windows and re-assessment.

Where should a plant start with 62443?

Start by asking why the request came: a customer, an insurer, a corporate program or a regulation. Then name the accountable owner, build the inventory and network drawings, run a high-level risk assessment, and fix the boundaries everyone already knows about. Write the next project’s security requirements specification to 62443 before buying anything.

Why were you asked?

The trigger decides what evidence is needed:

Trigger	What it usually wants	First move
A customer audit or supplier requirement	Evidence of a security program and specific controls	Ask for their questionnaire or standard, and answer it with 62443 terms
An insurance renewal	Answers on segmentation, remote access, authentication, backups	Document what exists; fix the remote access gaps first
A corporate security program	Alignment with corporate policy and ISMS	Map corporate guidelines to plant zones; agree on who owns what
EU product law (machines or components sold into the EU)	Manufacturer obligations under the CRA and Machinery Regulation	Engage suppliers and product engineering, not just the plant
NIS2 (EU entities)	Appropriate and proportionate measures, with evidence	Use 2-1:2024 to structure the program
An incident	Recovery, then a program	Restore, then assess and segment

The first 90 days

Weeks	Step	Done when
1 to 2	Name the accountable owner, confirm the trigger, choose the first system under consideration	One page, signed by plant leadership and IT
2 to 4	Asset inventory and network drawings	Drawings match what is installed
3 to 6	High-level risk assessment and first zone and conduit map	Zones ranked by consequence
4 to 8	Fix the known boundaries: enterprise to plant, remote access, shared credentials	The broadest paths in are closed or controlled
6 to 10	Write a CRS template and contract clauses for the next project	The next purchase order carries security requirements
8 to 12	Shared vocabulary training for engineering, IT and purchasing	Everyone uses the same words
12	Review, and a funded roadmap by zone	Leadership approves phase two

The first step most plants skip is the inventory, and it is the one everything else depends on. An external OT network assessment can compress the first month: inventory, drawings, findings and a ranked list of zones. For plants whose security questions sit inside a wider question of aging equipment, see a plant systems assessment.

Frequently asked questions

Is ISA/IEC 62443 mandatory?

No law requires a plant to adopt it. ISA/IEC 62443 becomes binding through contracts, through class rules for ships contracted since 1 July 2024 (IACS UR E27), and as one optional route to conformity under the EU Cyber Resilience Act. NIS2, NERC CIP and most national rules do not name it, though many plants use it to show their measures are appropriate.

Can a plant be certified to IEC 62443?

Not as a whole. Since 17 February 2026 the ISASecure ACSSA scheme can certify a specified control system and the asset owner’s program that runs it, against parts 2-1, 2-4, 3-2 and 3-3, for three years. Products, systems, supplier development processes and service providers can also be certified. No scheme certifies an entire plant or company.

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

SL-T is the target security level the risk assessment sets for a zone or conduit. SL-C is the capability a product or system provides when properly configured, which is what product certificates state. SL-A is the level the plant actually achieves once commissioned and running. A certified component does not by itself bring a zone to its target.

Which 62443 parts does an asset owner need?

Start with 62443-2-1:2024, the asset owner’s security program, and 62443-3-2, the risk assessment that sets zones, conduits and target security levels. Add 62443-3-3 to specify system requirements and 62443-2-4 to set requirements for integrators and maintenance providers. Part 1-1 gives the vocabulary; 4-1 and 4-2 matter mainly when evaluating suppliers.

How much do the 62443 standards cost?

At IEC list prices in October 2026, the six core parts (2-1, 2-4, 3-2, 3-3, 4-1 and 4-2) cost CHF 2,190 for single-user electronic copies, and all fourteen current documents cost CHF 4,800. ISA sells identical editions, and ISA membership does not include free access to them. ISAGCA publishes free overviews, including a quick start guide.

Does IEC 62443 certification satisfy the EU Cyber Resilience Act?

Not on its own, as of October 2026. The CRA grants a presumption of conformity only for harmonised standards cited in the Official Journal, and none had been cited by mid-October. CENELEC is amending EN IEC 62443-4-1 and 4-2 for that purpose. Reporting obligations have applied since 11 September 2026, including for products already on the market.

A contract language, not a certificate

ISA/IEC 62443 does its best work in documents, not on walls:

• in the risk assessment that sets a target for each zone;
• in the requirements specification an integrator builds to;
• in the certificate scopes a buyer reads before signing;
• in the acceptance tests that prove the result.

When owners, integrators and suppliers use the same words in those documents, security becomes something a plant can specify, buy and audit.

None of that moves the accountability. The plant owns the risk, whoever designs the network, writes the code or supplies the hardware.

Joltek works on the plant’s side of that line:

• assessing networks, servers and segmentation;
• designing architectures to 62443 principles;
• helping owners write requirements their integrators and suppliers can be held to.

Start with an OT network assessment, see how Joltek connects plant and enterprise systems, or tell Joltek what you have been asked to do.

Photos: inspection photo by PEO ACWA, via Wikimedia Commons, licensed CC BY 2.0, with a sign and a helmet decal removed; other photos by Valentin Lacoste (Unsplash) and Vjanodic WERSOV (Pexels).