Industrial control systems were never designed with cyber risk in mind. They were built for uptime, safety, and precision ,often expected to run untouched for fifteen or twenty years. That design philosophy is exactly why IEC 62443 exists. It is the closest thing the industrial world has to a shared language for OT security, giving asset owners, system integrators, and equipment manufacturers a common set of requirements to work from, instead of every plant reinventing its own approach to protecting the systems that keep production, power, and water running.

Before we begin, don’t forget to check out our previous post on “A technical analysis of the fairlife cyber incident” here.

For OT security leaders, plant managers, and CISOs responsible for critical infrastructure, IEC 62443 compliance is no longer a theoretical exercise reserved for the most regulated sectors. Insurance carriers ask about it during renewal. Customers ask about it during vendor assessments. Regulators reference it when shaping sector-specific rules. And increasingly, boards ask about it because they have watched peer organizations lose weeks of production to incidents that a segmented, well-governed environment could have contained. This guide breaks down what the standard actually requires, why those requirements exist, and how to turn them into a workable program rather than a stack of paperwork.

What Is IEC 62443, and Why Does It Exist?

IEC 62443 is a series of international standards focused specifically on securing industrial automation and control systems (IACS) ,the programmable logic controllers, distributed control systems, SCADA platforms, human-machine interfaces, and safety systems that operate manufacturing plants, power grids, water utilities, and other critical infrastructure. Unlike broad IT security frameworks that treat every asset as roughly interchangeable, IEC 62443 was written with the specific realities of operational technology in mind: long equipment lifecycles, safety-

first design priorities, real-time availability requirements, and a mix of modern and decades-old devices coexisting on the same network.

The standard is unusual in that it does not speak to only one audience. It sets requirements for asset owners who operate the plant, for system integrators who design and deploy the control system, and for product suppliers who manufacture the underlying components. That three-sided structure is deliberate: industrial security failures rarely trace back to a single weak link. They usually trace back to a gap in how responsibility was divided between the people who built the system, the people who integrated it, and the people who now operate it every day.

It also helps to understand what IEC 62443 is not. It is not a product you buy, a single certificate you hang on a wall, or a one-time project with a defined end date. It is a lifecycle standard, meaning it expects security to be designed in from the earliest engineering phase, maintained through years of operation, and revisited every time the environment changes ,a new vendor connection, a new remote access path, a control system upgrade. Organizations that treat it as a finite project tend to pass their first audit and then quietly drift out of compliance within eighteen to twenty-four months, simply because nothing was built to sustain the program.

This lifecycle orientation is also why IEC 62443 has become the reference point that insurers, regulators, and large industrial customers increasingly point to, even in sectors where no law explicitly mandates it. When a framework is built around continuous risk management rather than a static checklist, it holds up better under real audit scrutiny ,and it produces a security posture that actually reflects how the plant operates day to day.

Understanding the Structure of IEC 62443

The Four Parts of the Standard

IEC 62443 is organized into four groups of documents, each addressing a different layer of responsibility. Rather than reading as one dense specification, it functions more like a set of building blocks ,general concepts at the top, increasingly specific technical requirements as you move down.

Figure 1: The four parts of IEC 62443, moving from shared terminology to product-level requirements.

Core IEC 62443 Compliance Requirements Organizations Must Meet

Once you move past the terminology, IEC 62443 compliance comes down to a handful of interlocking requirements. Get these right, and the rest of the program ,policies, documentation, audit evidence ,tends to follow naturally. Get them wrong, and no amount of paperwork will hold up under scrutiny.

Security Levels (SL 0–4): Matching Protection to Threat

IEC 62443 does not assume every asset needs the same level of protection. Instead, it defines five Security Levels, ranging from SL 0 (no specific protection required) to SL 4 (protection against a well-resourced, highly motivated adversary using sophisticated means). Each zone in a facility is assigned a target security level (SL-T) based on the consequences of compromise, and the actual, achieved level (SL-A) is measured against that target.

Zones and Conduits: The Backbone of Technical Compliance

A zone is a grouping of assets that share common security requirements ,for example, all the controllers on a single production line, or all the engineering workstations in a control room. A conduit is the pathway through which data moves between zones, and it is where security controls such as firewalls, protocol filtering, and data diodes are applied. This model matters because it replaces a flat, everything-trusts-everything network with a deliberately segmented one, so that a compromise in a lower-trust zone ,say, the business network ,cannot walk unimpeded into a zone controlling physical processes.

Figure 2: A typical zone and conduit model separating enterprise, DMZ, control, safety, and field-level assets.

Defining zones correctly is one of the most consequential decisions in an IEC 62443 program. Draw zone boundaries too broadly, and a single compromised device places an entire plant at risk. Draw them without understanding actual data flows, and the conduits you build will either break legitimate operations or leave undocumented paths wide open. This is precisely where a structured risk assessment, rather than a network diagram exercise, needs to lead the work.

The Seven Foundational Requirements (FRs)

Underneath the security levels sit seven Foundational Requirements ,the technical categories against which every zone's controls are measured. Every specific requirement in the system-level part of the standard traces back to one of these seven.

IEC 62443 Risk Assessment: The Foundation of Compliance

Nearly every audit gap Shieldworkz consultants encounter traces back to the same root cause: the risk assessment was treated as a documentation exercise rather than the technical foundation it is meant to be. IEC 62443 is explicit that target security levels, zone boundaries, and countermeasures should all be derived from risk ,not selected first and justified afterward.

Figure 3: The IEC 62443 risk assessment lifecycle is continuous, not a one-time compliance milestone.

A defensible IEC 62443 risk assessment generally moves through six stages, and each one produces evidence an auditor will expect to see:

• Identify and inventory assets: build and maintain a complete, accurate inventory of controllers, workstations, network devices, and safety systems, including firmware and configuration data.

• Assess vulnerabilities and threats: Evaluate known weaknesses in the environment against realistic threat scenarios relevant to the sector and geography.

• Determine consequence and likelihood: Estimate the operational, safety, financial, and reputational impact of a successful compromise for each asset group.

• Establish target security levels (SL-T): Assign the appropriate SL-T to each zone based on the consequence analysis, not on generic industry defaults.

• Design and apply countermeasures: Select technical and procedural controls mapped to the seven Foundational Requirements to close the gap between SL-A and SL-T.

• Monitor, reassess, and maintain: Revisit the assessment when assets, connectivity, or threat conditions change, rather than waiting for the next scheduled audit.

This is also where organizations most often underestimate effort. A high-level, facility-wide risk assessment establishes priorities, but IEC 62443 expects a more detailed, zone-by-zone assessment before countermeasures are finalized. Skipping straight to technical controls ,buying a firewall or a monitoring platform before this analysis is complete ,routinely leads to spending on the wrong priorities while the highest-consequence gaps remain open.

Real-World Incidents That Show Why These Requirements Matter

IEC 62443's requirements were not written in the abstract. Each one maps to a category of failure that has already caused real operational damage across the industrial sector. A few well-documented incidents illustrate the pattern clearly.

Ukraine's Power Grid, 2015 and 2016

Attackers gained access to Ukrainian electricity distribution companies and, over a period of sustained reconnaissance, learned enough about the control environment to remotely open breakers and cut power to hundreds of thousands of customers. A follow-up attack the next year used purpose-built malware capable of speaking directly to grid protocols. Both incidents point to the same underlying gap that FR 5 and the zone-and-conduit model are designed to close: insufficient segmentation between corporate networks and the systems capable of directly manipulating physical infrastructure.

TRITON/TRISIS, 2017

In an incident targeting a petrochemical facility, attackers deployed malware specifically engineered to reprogram safety instrumented systems ,the last line of defense designed to bring a process to a safe state during a dangerous condition. The attack was ultimately unsuccessful only because of a configuration error in the malware itself. It remains one of the clearest illustrations of why IEC 62443 assigns safety zones the highest target security levels: compromising a safety system does not just risk data or downtime, it risks physical harm.

Norsk Hydro, 2019

A major aluminum producer was hit with ransomware that spread from IT systems into operational environments, forcing several plants into manual operation for an extended period. The company's transparent public response made it one of the most studied industrial ransomware cases, largely because it demonstrated how quickly an IT-originated compromise can cascade into OT when conduit controls and network segmentation are incomplete.

Oldsmar Water Treatment Facility, 2021

An operator noticed a cursor moving on its own and remote access being used to briefly increase the level of sodium hydroxide in the water supply at a Florida water treatment plant. The change was caught and reversed before it reached the public, but the incident became a widely referenced example of what happens when remote access is not tightly governed ,a gap that falls squarely under FR 1 and FR 2, identification, authentication, and use control.

Colonial Pipeline, 2021

A ransomware attack against the company's IT systems led to a voluntary, precautionary shutdown of a major fuel pipeline, disrupting fuel supply across a large region of the United States for several days. Notably, the operational technology itself was not directly compromised ,the shutdown was a business decision made because billing and IT systems were unreliable. It remains one of the most cited examples of why OT and IT security cannot be treated as fully separate problems, and why governance requirements under 62443-2 matter just as much as technical controls.

Across all five incidents, the common thread is not a single missing tool. It is a missing requirement: segmentation, access control, safety-system hardening, or governance that connects IT and OT decision-making. That is exactly the gap IEC 62443 was built to close.

Common Challenges Organizations Face When Pursuing IEC 62443 Compliance

Every organization Shieldworkz works with underestimates at least one of the following challenges during their first serious attempt at compliance:

• Legacy assets that cannot be patched or scanned ,many controllers in active use are ten to twenty-five years old and were never designed to support modern authentication or endpoint agents.

• A cultural divide between IT and OT teams ,security priorities, change-control tolerance, and even basic terminology differ sharply between the two groups, slowing every joint decision.

• Incomplete or outdated asset inventories ,you cannot assign accurate security levels to assets you have not fully identified.

• Zone boundaries drawn around convenience rather than risk ,networks are often segmented by physical location or vendor, not by actual consequence of compromise.

• Limited internal OT security expertise ,most plant engineering teams are not staffed or trained to run a formal risk assessment against an international standard.

• Downtime sensitivity that limits testing ,validating controls often requires maintenance windows that compete directly with production schedules.

• Supplier and integrator gaps ,component-level requirements under 62443-4 depend on vendors who may not yet build to the standard, leaving asset owners to compensate with additional controls.

Best Practices for Achieving and Maintaining IEC 62443 Compliance

Organizations that succeed with IEC 62443 tend to follow a sequence that mirrors the standard's own logic, rather than jumping straight to tools or documentation.

• Start with a complete, living asset inventory. Passive discovery methods that do not disrupt sensitive controllers are essential in environments where active scanning carries operational risk.

• Run the risk assessment before selecting technology. Target security levels and control priorities should come out of consequence analysis, not a vendor's product catalog.

• Design zones and conduits around actual data flows. Map how information genuinely moves between systems before drawing segmentation boundaries on paper.

• Treat SL-T as a business decision, not just a technical one. Involve plant leadership and safety teams when setting target levels for zones tied to physical processes.

• Build governance that spans IT and OT. Shared policies, joint incident response plans, and a common escalation path prevent the coordination failures seen in several of the incidents above.

• Adapt patch management to OT constraints. Where patching is not feasible, compensating controls such as network segmentation and monitoring must fill the gap and be documented as such.

• Build an OT-specific incident response plan. Generic IT playbooks rarely account for safety implications, physical process impact, or the need to keep production running during containment.

• Reassess continuously. New assets, new vendors, and new connectivity should trigger a review ,waiting for the next scheduled audit leaves gaps open far longer than necessary.

How Shieldworkz Supports Organizations

Shieldworkz works alongside OT security leaders, plant managers, and CISOs to turn IEC 62443 requirements into a practical, sequenced program built around each facility's actual risk profile ,not a generic checklist.

• Comprehensive, passive-first asset discovery and inventory tailored to sensitive OT environments

• Structured IEC 62443 risk assessments, including consequence analysis and target security level determination

• Zone and conduit design based on real network traffic and process data flows

• Gap assessments comparing current-state security levels (SL-A) against target levels (SL-T)

• Development of governance frameworks that connect IT and OT security decision-making

• Continuous monitoring and threat detection built for industrial protocols and legacy devices

• OT-specific incident response planning and tabletop exercises

• Workforce training that builds internal OT security capability, not just external dependency

The goal is always the same: a compliance program that holds up under audit scrutiny and, more importantly, actually reduces the operational risk your organization is exposed to every day.

Conclusion

IEC 62443 compliance is not a certificate to obtain once and forget about. It is a structured way of thinking about industrial risk ,one that asks organizations to understand what they have, what could go wrong, how severe the consequences would be, and what level of protection each part of the environment genuinely needs. The incidents that continue to make headlines across manufacturing, energy, and water sectors are not evidence that the standard is too demanding. They are evidence of what happens when its core requirements ,segmentation, access control, governance, and continuous risk assessment ,are left partially implemented.

For OT security leaders and decision-makers under pressure to show measurable progress, the most effective path forward starts with an honest, expert-led assessment of where the organization currently stands. That single step tends to clarify priorities faster than months of internal debate.

Additional resources  

A downloadable report on the Stryker cyber incident here  
Removable media scan solution vendor evaluation and selection checklist here  
IEC 62443-based OT/ICS risk assessment checklist for the food and beverage manufacturing sector here