The production line comes to a standstill. Error messages flood the control room, machines switch to emergency stop. Yet it all began with a routine intervention: a critical patch was to be installed on an engineering workstation to pre-empt a vulnerability.
The problem: no one could reliably predict how the decades-old web of software, control systems, and machinery would react to the change. What started as a security measure brought operations to a halt.
This scenario illustrates a core challenge of OT security. While in classic IT, faulty systems can usually be isolated, restarted, or replaced, in production real physical processes hang on the data cables. A careless IT scan or a failed update endangers not just data here, but plant availability – and in the worst case, people. A cyber risk becomes a physical risk.
This is precisely the interface between cybersecurity and safety where IEC 62443 comes in. The standard for Industrial Automation and Control Systems (IACS) demands a consistent rethink from classic IT security specialists.
The guiding question is no longer just: “How do we protect this system from an attack?” It must be: “What happens to the physical process in the event of a compromise, and how do we prevent a single incident from taking down the entire plant?”
The difference between IT and OT
IT security and OT security fundamentally pursue the same goal: protecting systems and processes from unauthorized access, manipulation, and failure. However, the conditions under which this goal must be achieved differ considerably.
Classic IT often works with the CIA model: Confidentiality, Integrity, and Availability. Depending on the use case, these three protection goals can be weighted differently. In many industrial environments, however, Availability and Integrity carry particularly high importance. A system failure can directly cause a production stoppage; manipulation of control data can cause a physical process to run incorrectly or uncontrolled.
Added to this is a dimension not sufficiently visible in the classic CIA view: Safety. A cyberattack on an industrial system can have physical consequences through digital manipulation – for example, damaged machines, hazardous process states, or environmental impacts.
Further differences arise from the technical and operational conditions:
- Long lifecycles: While IT systems are often renewed or fundamentally updated within a few years, industrial plants and their components can be in use for 15, 20, or more years.
- Determinism and real-time requirements: In many automation environments, control and regulation processes must respond within defined time windows. Additional latencies or unexpected load therefore cannot simply be treated as a normal performance problem.
- Limited maintenance windows: A server can often be restarted outside business hours. A continuously running production plant, on the other hand, can sometimes only be interrupted rarely or not at all on short notice.
- Physical consequences: A compromised IT system can cause considerable economic damage. A compromised OT system can, beyond that, directly affect machines, plants, and processes.
This connection is especially relevant for operators of critical infrastructure – more on the topic page Critical infrastructures (KRITIS) – importance and protection.
These very conditions make clear why security measures in OT cannot simply be implemented according to the same rules as in a classic corporate network. The challenge is not to do less security, but to design security measures so that they account for the special requirements of industrial processes.
Why security in OT environments needs different lever
The fundamental goals of security also apply in OT: harden systems, control access, segment networks. The decisive difference lies in the how. What counts as best practice in enterprise IT can create incalculable risks in a production environment.
A simple “copy-paste” of IT concepts onto the factory floor doesn’t work. This shows up in four classic friction points:
Patch management (security vs. availability)
In IT, vulnerabilities are closed through immediate updates. In OT, a single patch drags along an enormous chain of dependencies – from the engineering software to the physical machine. The guiding question is therefore not: “Why is the system still unpatched?” but: “How do we reduce the risk of the vulnerability (e.g. by restricting communication) without creating a new risk?"
Vulnerability scanning (visibility without side effects)
Active network scans are standard in IT. In OT, unexpected traffic alone can crash a decades-old controller. The solution often lies in passive methods: network traffic is only analyzed and “listened to” without actively attacking the assets.
Endpoints & IAM (a PLC is not an office PC)
Modern EDR software or strict least-privilege concepts often fail on historical OT components that have no user management or are resource-constrained. Because the individual asset often cannot be upgraded, the architecture must compensate for the weaknesses – for example through jump hosts or dedicated engineering stations. How secure OT components can already be identified at the procurement stage is shown by the CISA recommendations for selecting secure OT products.
Network segmentation (by process, not by IP)
While classic IT separates its networks by organizational boundaries (guests, development, HR), segmentation in OT must follow the industrial process. The only question that matters: which systems absolutely must communicate with each other for the production line to run?
The consequence: architecture beats individual measures
IT principles do not lose their validity in OT, but they hit technical and physical limits. Cybersecurity must therefore never depend on protecting a single device here. And this is exactly the point where the IEC 62443 series of standards unfolds its greatest strength: it doesn’t just describe isolated controls, it provides the methodical framework to systematically secure plants.
The IEC 62443 approach: from process to precisely fitted protection
How do you decide how much security a decades-old IACS really needs? IEC 62443 answers this question with a clear cut. Instead of copying all best practices from enterprise IT, the standard restructures the problem entirely: the required protection level is consistently derived from the physical risks, functions, and dependencies of the real plant.
The paradigm shift already shows in the guiding question. It no longer reads: “Which controls must we deploy across the board?” But rather: “Which risks threaten this specific process, and what protection level do the involved systems require?”
To answer this question, the security team must understand the process at its core: which plants are truly critical? Which communication paths are absolutely necessary? And above all: what happens to people, machinery, and the environment if a controller fails or is manipulated?
Security as a team sport: shared responsibility
An operator cannot retroactively patch an insecurely developed PLC (Programmable Logic Controller), and a manufacturer cannot control how its component is networked in machine tool manufacturing. IEC 62443 therefore looks at the entire lifecycle and distributes responsibility across three pillars:
- IEC 62443-2-x (Operator): Addresses the organization, security processes, and risk management in ongoing operations. What additional organizational obligations arise from regulation is explained in the article NIS2 Implementation: Obligations and Risks for Businesses; a deeper overview is provided by the topic pageIT Regulation.
- IEC 62443-3-x (System integrator): Focuses on secure integration and system architecture through the responsible integrators (this is where Zones & Conduits come in).
- IEC 62443-4-x (Manufacturer): Requires “security by design” and secure development processes directly at the component level.
Risk-based instead of “security at any price”
In industry, the rule is: maximum security is not automatically the best security. Especially not when it sabotages real-time requirements or availability. A display that merely shows production data requires a fundamentally different protection level than a controller whose failure creates dangerous overpressure in a boiler. The approach ensures that protective measures and budgets take effect exactly where the operational and physical risk is highest.
From risk analysis to architecture
IEC 62443 doesn’t stop at abstract risk analysis but translates it directly into the system architecture. The logic behind it is strictly sequential:
Risk → security requirement → zone → conduit → technical measure
Back to our scenario from the introduction: the engineering workstation whose patch brought the plant to a halt is not just “another PC.” The standard requires evaluating its context: which zone is the workstation in? Via which conduits (communication paths) is it connected to the control systems?
This shifts the focus of IEC 62443 from isolated security tools to a resilient architecture. And that brings us to the most powerful and central concept of the entire standard: Zones & Conduits.
Zones & Conduits: the architectural core of IEC 62443
Back to our engineering workstation: the vulnerability is known, the patch is ready. But before acting, it must be clear what role this system plays in the overall architecture. This is exactly where the central structuring model of IEC 62443 comes in: Zones & Conduits.
The standard doesn’t view an industrial network as a homogeneous block, but breaks it down into controllable segments. The principle is simple, the strategic impact on cyber resilience is immense:
Zones – grouped by risk, not by IT topology
A zone groups assets with comparable security requirements (e.g. all controllers of a specific production line). In classic IT we ask: “Which devices are on the same VLAN?” In OT under IEC 62443, the guiding question is: “Which assets share the same risk profile, and what physical impact does it have if exactly this group is compromised?”
Conduits – the bottleneck of communication:
Zones rarely work in isolation. The communication paths between them are the conduits. A conduit is not simply a firewall, but the logical bracket for all permitted data flows. Here it’s worth questioning: which systems absolutely must talk to each other for the industrial process? With which protocols? In which direction?
The idea resembles the zero-trust principle from classic IT – just consistently applied to physical processes. More on this in the articleZero Trust in Practice: The 10 Basic Rules for Protection that Promotes Resilience.
Containment instead of perimeter protection
A firewall at the transition between the office and production network (perimeter protection) is important, but doesn’t answer a critical question: what happens if the attacker is already inside?
Consider the potential attack path: office network → engineering workstation → conduit → control zone → PLC. Without clean zoning, an attacker who has taken over the workstation can move laterally into the control level unhindered. The Zones & Conduits model establishes a defense-in-depth strategy here. The goal is damage limitation (containment): even if a single asset falls, clear boundaries and strictly limited communication paths are meant to prevent the next zone from being infected.
The chain of insight: from asset to measure
A zone is by definition not yet “secure.” It merely provides the structured foundation for risk analysis. For each zone and each conduit, a target security level is defined: the so-called Target Security Level (SL-T). Only from this are the technical requirements (per IEC 62443-3-3) derived. This creates a clear architecture chain that prevents pure actionism or blind tool purchases:
Assets → zones & conduits → risk analysis → Target Security Level (SL-T) → technical and organizational measures
For our workstation, that means: we define its zone, limit its conduits, assess the risk, and thus determine the necessary protection level. This leads us inevitably to the most important question for decision-makers and security teams: how much security is actually enough in production? The four security levels provide the answer.
Security levels in practice: how much protection does a plant need
With Zones & Conduits, the architecture stands. Now comes the practical question: how much security does a particular segment actually need?
IEC 62443 provides exactly this with the concept of Security Levels (SL). Important upfront: security levels are not simple school grades along the lines of “SL 4 is secure, SL 1 is insecure.” Instead, they describe which attacker profile and which resources a system must withstand.
| Security Level | The protection goal: protection against... |
|---|---|
| SL 0 | No specific security requirements |
| SL 1 | Random or unintentional errors (e.g. the careless employee) |
| SL 2 | Targeted attacks with simple means (e.g. standard malware, opportunistic hackers) |
| SL 3 | Targeted attacks with sophisticated means and OT know-how |
| SL 4 | Highly complex attacks by state actors (APTs) with massive resources |
The decisive question is therefore: “Which level is appropriate for the specific risk of this particular zone?”
More security is not automatically better security
The goal of an OT security strategy is not to armor every zone to SL 4. Maximum protection brings enormous technical and organizational hurdles. If these measures throttle availability or disrupt real-time processes without the risk justifying it, the security measure harms the business. A production plant doesn’t need the same level everywhere.
The trio of security levels: SL-T, SL-C, and SL-A
To manage this risk trade-off in practice, IEC 62443 splits the term “security level” into three essential perspectives:
- SL-T (Target Security Level): the goal. How much security do we need for this zone based on the risk analysis?
- SL-C (Capability Security Level): the hardware capability. What security level does a purchased component (e.g. a PLC) technically bring out of the box?
- SL-A (Achieved Security Level): the reality. What level does the zone actually achieve in the real operation of the overall plant?
This distinction is the biggest lever in practice. An example: the risk analysis calls for an SL-T of 3 for a critical zone. But the installed controller technically only manages an SL-C of 2.
That doesn’t mean the plant has to remain insecure. It only means that the component alone doesn’t reach the goal. The overall architecture must compensate for the shortfall – for example through stricter network segmentation or upstream firewalls – to ultimately achieve an SL-A of 3 for the whole zone. The security level of the individual component is not the security level of the overall system.
What does this mean for our unpatched workstation? Back to our starting scenario: the workstation has a vulnerability, but the patch can’t be applied without endangering the plant. Without IEC 62443, this would get very complicated. With the standard’s methodology, we now ask completely different questions:
- Which zone is the workstation in?
- What target level (SL-T) applies here?
- Does our achieved level (SL-A) fall below the target due to the vulnerability?
- If we can’t apply the patch: how can we shield the system “from the outside” instead (e.g. through stricter firewalls or network separation) to compensate for this weakness and keep the plant secure anyway?
This turns IEC 62443 from a theoretical body of rules into a hands-on tool. It prevents blind actionism and helps prioritize budgets and measures exactly where an attack would cause the greatest physical and economic damage.
From theory to practice: implementing IEC 62443 in existing plants
Securing a historically grown production plant according to IEC 62443 doesn’t start with blindly buying security solutions. The first step is much less spectacular, but essential: creating transparency.
Here’s how the methodical implementation succeeds in practice without endangering ongoing operations:
1. Establish visibility (the asset inventory)
You can only protect what you know. A list of IP addresses isn’t enough for that. It must be captured completely: which controllers, HMIs, and field devices exist? Which firmware is running? What do the communication paths and remote maintenance access points look like? Since active network scans often crash old plants, passive discovery methods are the tool of choice here. Understand first, then secure.
2. Assess risks, don’t just hunt vulnerabilities
A red CVSS score (vulnerability rating) on an isolated workstation is often less critical than a “small” gap on an asset that controls the core process. The decisive metric in OT is always the impact on the physical process: what happens to production, the environment, and the safety of employees in the event of failure or manipulation?
3. Define zones, conduits, and target levels (SL-T)
A historically grown VLAN (Virtual Local Area Network) is not a security zone. The architecture must instead be restructured along functional process boundaries. For each defined zone and each conduit, the required Target Security Level (SL-T) is then set based on risk. The motto: precisely fitted protection instead of a one-size-fits-all approach.
4. Use architectural levers (gap analysis)
Now comes the comparison: does the zone reach the required target level? If an old component can’t be patched, the risk must be compensated architecturally – for example through strict network segmentation, allowlisting, or strict monitoring at the conduit. Not every problem has to be solved directly on the end device. The gap between target and reality is closed through a smart defense-in-depth concept.
5. Unite IT and OT: evolution instead of “big bang”
For the IT security specialist, an unpatched system is an immediate risk; for the OT manager, installing a patch into a validated process is the real risk. Both are right. True cyber resilience therefore requires shared processes and responsibilities.
How companies master this balancing act between regulation and resilience in practice is shown in the recording The Cyber Resilience of Tomorrow: Proactive Instead of Reactive from it-sa Expo&Congress 2025. Watch the recording now!
The pragmatic start: a complete overhaul of the plant overnight is illusory. A pragmatic starting point lies where the risk is highest: at the transitions between office and production networks, or at external remote maintenance access points. The goal of IEC 62443 is not a perfect, one-time snapshot, but a continuous process in which risks are systematically assessed and gradually reduced.
Want to connect directly with OT security professionals and IEC 62443 experts? At the it-sa EXPO & Congress you can expect live talks, hands-on use cases, and direct exchange with exhibitors on industrial cybersecurity. Register as a visitor now!
Conclusion: OT security begins with architecture, not with the patch
Back to our engineering workstation from the beginning: the vulnerability is there, the patch can’t be applied. What is an unsolvable conflict for classic IT merely marks the starting point of the security consideration in the world of IEC 62443.
The guiding question is not dogmatically: “How do we force this patch onto the system?” It is pragmatically: “What risk arises for the industrial process, and how can we contain it through architectural measures (defense in depth)?”
This perspective makes the crucial difference.IEC 62443 doesn’t demand “IT security light.” Rather, it helps translate proven security principles into a context where availability and physical safety come first.
The perspective shift for security teams
Starting from a genuine risk analysis, zones are drawn, communication paths (conduits) are defined, and precisely fitted security levels are derived. This requires a rethink:
- Not every vulnerability has to be solved on the affected end device.
- Not every system needs the maximum protection level.
- What matters is that the overall architecture controls the risk.
This makes IEC 62443 the perfect puzzle piece for companies that already work with frameworks like ISO 27001 at the management level. It builds the bridge from abstract security management down to the shop floor, into the system architecture and operations.
The key insight: OT security doesn’t mean implementing IT security less rigorously. It means aligning it rigorously with the physical reality of the production process. Anyone who internalizes this way of thinking no longer views a factory as a mere collection of computers that need patching. They understand it as a networked, physical automation system in which security is not a burden bolted on afterward, but the foundation for resilient operations.
