Every industrial facility runs on trust. Trust that a valve opens when it's told to open, that a controller executes the logic it was programmed with, and that a human operator sitting in front of an HMI is seeing what is actually happening on the plant floor. As operational technology becomes more connected to enterprise networks, cloud platforms, and remote vendors, that trust has become harder to guarantee. This is exactly the gap that IEC 62443 security levels were designed to close.

For CISOs, plant managers, and control system engineers, the phrase "security level" often shows up in vendor documentation, risk assessments, and audit reports without much explanation of what it actually means for day-to-day operations. This Blog breaks the concept down in plain terms, connects it to real industrial incidents, and outlines how a structured IEC 62443 gap assessment can turn an abstract standard into a working security program.

What Is IEC 62443, and Why Does It Matter Now

IEC 62443 is an internationally recognized series of standards for securing industrial automation and control systems. Unlike traditional IT security frameworks, it was built specifically around the realities of operational technology: long equipment lifecycles, safety-critical processes, legacy protocols, and environments where a security patch cannot simply be pushed overnight without risking downtime or a safety event.

At the center of the standard sits the idea of security levels, a structured way of describing how much protection a system, zone, or component needs and how much it actually has. Rather than treating cybersecurity as a single pass-or-fail checkbox, IEC 62443 recognizes that a water treatment plant, a pharmaceutical line, and a power substation each carry different risk profiles and therefore need different depths of protection.

This distinction matters more today than ever. Manufacturing, energy, water, and transportation sectors have all seen a sharp rise in targeted intrusions over the past several years, and regulators across multiple regions are increasingly referencing IEC 62443 in compliance frameworks, insurance requirements, and vendor procurement contracts. Understanding security levels is no longer an engineering nicety; it is becoming a board-level conversation.

The Five IEC 62443 Security Levels Explained

IEC 62443 defines five security levels, numbered SL 0 through SL 4. Each level corresponds to the sophistication, resources, and intent of the threat actor that a system is expected to withstand. The levels are cumulative: a system rated at SL 3 is assumed to also meet the requirements of SL 1 and SL 2.

Figure 1: Overview of IEC 62443 Security Levels (SL 0 to SL 4)

Visual representation of escalating protection requirements across the five security levels

It is worth noting what these levels actually measure. They do not describe how "good" a facility's security program looks on paper. They describe the strength of a defined threat actor a zone or system can realistically withstand, which is a much more operationally useful measurement when planning budgets and countermeasures.

Target, Capability, and Achieved Security Levels: Why the Difference Matters

One of the most misunderstood parts of IEC 62443 is that "security level" is not a single number. The standard actually defines three related concepts, and confusing them is one of the most common mistakes organizations make during audits and vendor negotiations.

Target Security Level (SL-T)

This is the security level an organization determines a zone or system should meet, based on a formal risk assessment. It reflects the desired state, not the current one.

Capability Security Level (SL-C)

This describes what a component or system is inherently capable of achieving when configured correctly, based on the vendor's design and documentation. A firewall or PLC might be rated SL-C 3 out of the factory, but that rating only holds if it is deployed and configured as intended.

Achieved Security Level (SL-A)

This is the real-world level a system is actually operating at, right now, given its current configuration, patch status, network segmentation, and compensating controls. SL-A is frequently lower than SL-T, and that gap is exactly what a well-run IEC 62443 gap assessment is designed to uncover.

Security programs fail most often not because organizations lack ambition on paper, but because nobody formally measures the distance between the target and the achieved level. A zone that was designed for SL 3 five years ago can quietly drift down to an effective SL 1 through unpatched systems, unmanaged remote access, or undocumented network changes.

Why Security Levels Matter: Lessons from Real Industrial Incidents

Security levels can feel theoretical until they are placed next to what has actually happened on plant floors and in control rooms. A handful of well-documented industrial cybersecurity events illustrate exactly why this framework exists.

In one widely studied case from the energy sector, attackers gained access to a utility's operational network and were able to manipulate breakers, causing a widescale power outage affecting hundreds of thousands of customers for several hours. Investigators later found that the affected control systems had inadequate network segmentation and weak access controls between IT and OT environments, conditions that would correspond to a low achieved security level despite the criticality of the assets involved.

In another notable incident affecting a safety instrumented system at a petrochemical facility, malware specifically engineered to interact with safety controllers was discovered only because of an unrelated system fault, not because it was detected by security monitoring. The incident demonstrated that safety systems, often assumed to be air-gapped and inherently secure, can carry an achieved security level far below what their criticality demands.

A separate incident at an aluminum and renewable energy producer showed the operational cost of underestimating security levels across IT and OT together. A ransomware event forced the company to switch large parts of its production to manual operation for weeks, with financial impact reaching tens of millions of dollars. The response required rebuilding systems from the ground up, a costly and disruptive way to discover that achieved security levels had fallen behind target requirements.

A smaller-scale but equally instructive case involved a water treatment facility where an operator noticed a brief, unauthorized change to chemical dosing setpoints through remote access software. The incident was caught quickly and caused no harm, but it highlighted how a single remote access point without multi-factor authentication or session monitoring can single-handedly undermine an otherwise well-designed security architecture.

None of these organizations lacked technology budgets or security intent. What they lacked, in each case, was a clear and continuously validated understanding of where their achieved security level actually stood relative to the risk each zone carried.

Conducting an IEC 62443 Gap Assessment

An IEC 62443 gap assessment is the structured process of comparing target security levels against achieved security levels across every zone and conduit in an industrial environment, then identifying the specific technical and procedural gaps that need to be closed.

A thorough gap assessment typically follows these stages:

Figure 2: Core stages of a structured IEC 62443 gap assessment

The value of this process is that it replaces subjective impressions of security with a defensible, evidence-based picture. A plant manager can walk into a budget conversation with a clear statement: this zone needs to operate at SL 3 because a compromise here could halt production for weeks, and today it is operating at an achieved SL 1 because of these specific, named gaps.

Common Challenges Organizations Face When Applying Security Levels

Even organizations that understand the theory behind IEC 62443 often struggle with practical implementation. Some of the most frequent challenges include:

• Legacy equipment that was never designed with cybersecurity requirements in mind and cannot support modern authentication or encryption without costly redesign

• Flat or poorly segmented networks where a compromise in a low-criticality zone can spread laterally into high-consequence areas

• Inconsistent ownership between IT and OT teams, leading to security controls that look reasonable on an IT dashboard but do not reflect actual conditions on the plant floor

• Vendor and third-party remote access that bypasses standard access control policies, often for the sake of maintenance convenience

• A false sense of security created by physical isolation, even when wireless, USB, or engineering laptop access effectively removes that isolation

• Treating security level assessment as a one-time compliance exercise rather than an ongoing measurement that should evolve with the threat landscape and plant changes

Each of these challenges directly widens the gap between target and achieved security levels, often without anyone in the organization realizing it until an incident, an audit, or a near-miss forces the issue into the open.

Practical Recommendations for Strengthening Security Levels

Closing the gap between target and achieved security levels does not require an unlimited budget. It requires discipline, sequencing, and a willingness to treat security levels as a living metric rather than a static label. The following practices consistently produce measurable improvement:

1. Start With Consequence, Not Compliance

Define target security levels based on what would actually happen if a zone were compromised, including safety, environmental, and production impact, rather than defaulting to a uniform level across the entire facility. This keeps investment focused where it matters most.

2. Segment Before You Secure

Network segmentation between zones and conduits is one of the highest-leverage controls available. A well-segmented environment contains an incident within a single zone rather than allowing it to reach systems with a much higher consequence rating.

3. Treat Remote Access as a Named Risk

Every remote access path, whether for vendors, integrators, or internal engineers, should be inventoried, authenticated with multi-factor controls, time-limited, and logged. Remote access has been a contributing factor in a significant share of publicly documented OT incidents.

4. Build a Living Asset Inventory

You cannot assign or measure a security level for an asset you do not know exists. Continuous, passive discovery of devices and communication patterns keeps the inventory accurate as the environment changes.

5. Reassess on a Fixed Cadence

Achieved security levels degrade quietly over time as configurations drift, patches lag, and new devices are added. A recurring gap assessment, at minimum annually and after any major change, keeps SL-A visible rather than assumed.

6. Align Safety and Security Teams

Safety instrumented systems carry some of the highest consequence ratings in any facility. Security levels for these systems should be defined jointly by process safety and cybersecurity teams, not by either group in isolation.

How Shieldworkz Supports Organizations

Shieldworkz works alongside industrial operators, utilities, and manufacturers to translate IEC 62443 security levels from a standard on paper into a measurable, defensible security program. Our approach is built around the practical realities of live operational environments, not generic IT playbooks.

• Comprehensive IEC 62443 gap assessments that map zones, conduits, target security levels, and achieved security levels with clear supporting evidence

• Asset discovery and network visibility services designed for OT environments, using passive methods that do not disrupt live production

• Risk and consequence analysis tailored to each facility's specific processes, safety systems, and regulatory obligations

• Phased, budget-aware remediation roadmaps that prioritize the gaps with the greatest risk reduction impact first

• Ongoing monitoring and advisory support to keep achieved security levels aligned with target levels as the environment evolves

• Hands-on guidance for aligning safety instrumented systems, remote access architecture, and network segmentation with IEC 62443 requirements

Rather than delivering a static report and moving on, Shieldworkz partners with security and engineering teams throughout implementation, helping translate findings into changes that hold up under real operating conditions and future audits.

Conclusion

IEC 62443 security levels give industrial organizations a common language for describing risk, one that connects engineering reality with business consequence. Understanding the difference between target, capability, and achieved security levels, and formally measuring the distance between them, is what separates organizations that discover their gaps during an audit from those that discover them during an incident.

The industrial threat landscape is not slowing down, and the facilities most exposed are rarely the ones with no security program at all. They are the ones whose achieved security level quietly fell behind their target without anyone measuring the gap. A structured, well-documented gap assessment is the most direct way to close that distance before it is tested by an adversary.

Ready to Understand Where Your Facility Really Stands?

Book a free consultation with our OT security experts and get a clear picture of your target versus achieved IEC 62443 security levels, backed by a practical, prioritized roadmap.

Book a Free Consultation with Our Experts

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