Zone and conduit modelling is one of the most useful ways to make industrial and operational technology environments easier to understand and protect. For many UK SMEs, the challenge is not a lack of security tools. It is knowing where to start when production systems, legacy equipment, remote support, and business IT all need to work together without creating unnecessary risk.
IEC 62443 uses the idea of zones and conduits to help with that problem. In simple terms, a zone is a group of assets that share similar security needs, and a conduit is the controlled path between zones. The model gives you a structured way to think about who needs access to what, how data should move, and where stronger controls are justified.
This is not about building a perfect diagram for its own sake. For a small manufacturer or other SME with operational technology, the value comes from making sensible decisions that support safety, availability, maintainability, and security at the same time.
What zone and conduit modelling means in practice
In an industrial setting, systems often have very different roles. A production line controller, a historian, an engineering workstation, and a remote support connection do not all need the same level of trust or the same communications. Zone and conduit modelling helps you separate those parts in a way that reflects how the environment really works.
Why segmentation matters in industrial environments
Segmentation means dividing a network or environment into smaller parts so that access can be limited. In operational technology, this matters because a single flat network can let problems spread more widely than they should. If one device is compromised, poorly controlled connections can make it easier for that issue to affect other systems.
Good segmentation also helps with day-to-day operations. It can reduce noise, make troubleshooting easier, and give teams a clearer picture of which systems are critical. The aim is not to isolate everything. The aim is to create sensible boundaries that match business and operational needs.
How zones and conduits differ from standard IT network segmentation
Traditional IT segmentation often focuses on users, devices, and data types. In OT, the picture is more complex because availability and safety may matter as much as confidentiality. Some systems are old, some are vendor-managed, and some cannot be changed frequently without operational impact.
That means zone and conduit modelling is usually more deliberate than standard office network design. You are not just asking where a firewall should sit. You are asking which assets belong together, which communications are essential, and what level of control is proportionate for each connection.
Where UK SMEs typically use this approach
Zone and conduit modelling is relevant wherever industrial equipment, control systems, or other operational technology support the business. For UK SMEs, that often means environments that have grown over time rather than being designed from scratch.
Manufacturing sites with mixed legacy and modern systems
Many manufacturing organisations run a mix of older equipment and newer connected systems. A production line may include legacy controllers, modern monitoring tools, remote maintenance access, and links to business systems such as planning or reporting platforms. These mixed environments are common, and they can be difficult to secure without a clear model of how they fit together.
Zone and conduit modelling helps by showing where older systems can be grouped safely, where modern systems need tighter controls, and where business connectivity should be limited. It gives decision-makers a practical way to discuss risk without needing to redesign the whole site.
Smaller operational technology environments with limited security resources
SMEs rarely have large OT security teams. The people who understand the production process may also be the people who manage the network, support suppliers, or handle maintenance. In that setting, a simple and well-documented model is often more valuable than a highly detailed one that nobody maintains.
The best starting point is usually a model that captures the important boundaries and the most sensitive connections. That gives the business a manageable foundation that can be improved over time.
How to identify sensible zones
A good zone model starts with the assets you already have, not with a theoretical architecture. The question is which systems belong together because they have similar security requirements and operational behaviour.
Grouping assets by function, criticality, and trust level
One practical way to build zones is to group assets by what they do. For example, production control systems may sit in one zone, engineering workstations in another, and business systems in a separate zone. You can then refine those groups by looking at criticality and trust.
Criticality asks how badly the business would be affected if a system failed or was altered. Trust level asks how much confidence you have in the devices, users, and suppliers involved. A zone with highly critical systems and limited trust usually deserves stronger controls than a zone with low-impact monitoring tools.
It is also sensible to consider whether a system is shared by many people, whether it is vendor-supported, and whether it needs direct internet access. Those factors often influence how tightly a zone should be controlled.
Considering safety, availability, and operational dependencies
Industrial environments are shaped by dependencies. A controller may rely on a historian, a maintenance laptop, a time source, or a remote support channel. If those dependencies are not understood, a well-intended security change can disrupt operations.
When defining zones, look at what must stay available for the process to run safely. Some systems may need to be grouped together because they fail together or because they are tightly linked in operation. Others may need separation because a compromise in one area should not affect another.
For SMEs, this is often a balancing exercise. The right answer is usually not the most restrictive one. It is the one that protects the process while remaining realistic to operate.
How to define conduits between zones
Once the zones are clear, the next step is to define the conduits. A conduit is the controlled communication path between zones. In practice, that means deciding what traffic is allowed, who can use it, and under what conditions.
Allowing only the communications that are genuinely needed
A useful rule is to start from business need rather than technical convenience. If a system does not need to talk to another system, do not allow the connection. If it does need to communicate, be specific about the protocol, direction, source, destination, and timing.
This approach reduces unnecessary exposure and makes it easier to spot exceptions. It also helps when troubleshooting, because the expected traffic is documented rather than assumed. For many SMEs, this is one of the biggest benefits of the exercise.
In some cases, a conduit may be simple, such as a one-way reporting link. In others, it may need to support more complex operational traffic. The key is to keep the design as narrow as possible while still supporting the process.
Documenting data flows, remote access, and third-party connections
Remote access deserves particular attention. Suppliers, maintenance providers, and integrators often need occasional access to OT systems, but that access should be tightly controlled and clearly documented. The same applies to any connection between OT and business IT, cloud services, or external monitoring tools.
When documenting conduits, record what the connection is for, who owns it, how it is approved, and how it is monitored. If a third party needs access, note the business reason, the systems involved, and the controls that limit what they can do. This makes the model more useful for operations and for security reviews.
It is also worth noting where data leaves the site. Even if a connection is only used for telemetry, reporting, or support, it still creates a path that should be understood and managed.
Common design choices and trade-offs
There is rarely a perfect zone and conduit design. Most SMEs need to make practical trade-offs between security, resilience, cost, and operational simplicity.
Balancing resilience, maintainability, and operational disruption
A design that is too rigid can make maintenance harder and increase the temptation to bypass controls. A design that is too loose can leave too much trust between systems that should be separated. The right balance depends on how the site operates and how much change it can absorb.
Resilience matters because industrial environments need to keep running. Maintainability matters because controls that are hard to support tend to drift over time. Operational disruption matters because security changes that interfere with production are unlikely to be welcomed or sustained.
For that reason, it is often better to introduce boundaries gradually. Start with the highest-risk connections and the most critical systems, then refine the model as the business gains confidence.
Avoiding overcomplicated designs that are hard to manage
Overengineering is a common problem. If the model becomes too detailed, it can be difficult for engineers and operations staff to use it in practice. That usually leads to stale documentation and weak ownership.
A useful test is whether the people who run the environment can explain the zones and conduits without needing a long briefing. If they cannot, the model may be more complex than it needs to be.
Simple does not mean weak. A clear, well-maintained model with sensible controls is usually more effective than a highly intricate one that nobody trusts or updates.
A practical starting point for SMEs
If you are starting from scratch, do not begin with the standard. Begin with the environment. The goal is to create a working picture that reflects how the site actually operates today.
Using an asset and communication map to begin the exercise
Start by listing the main OT assets, the systems they depend on, and the communications between them. Include controllers, operator stations, engineering laptops, servers, remote access tools, and any links to business IT or external providers.
Then map the flows. Ask what talks to what, why it talks, and whether that communication is essential. This does not need to be a perfect technical diagram. A simple map that captures the important paths is enough to begin with.
Once you have that map, you can start grouping assets into zones and identifying the conduits between them. The process is iterative, so expect to refine it as you learn more about the environment.
Reviewing the model with engineering, operations, and security stakeholders
Zone and conduit modelling works best when it is reviewed by the people who understand the process, the equipment, and the support arrangements. Engineering can explain how systems behave. Operations can explain what must stay available. Security can help assess where trust boundaries should sit.
Bringing those views together usually leads to a more realistic model. It also helps build ownership, which matters if the design is going to be maintained rather than shelved.
For SMEs, this review does not need to be a formal workshop. A structured conversation around the asset map is often enough to uncover the most important issues.
How this supports broader security improvement
Zone and conduit modelling is not an end in itself. It is a practical foundation for better decisions across the rest of the security programme.
Using the model to prioritise controls and reduce exposure
Once you know where the boundaries are, you can decide where to apply stronger controls. That might include tighter access management, more restrictive firewall rules, better monitoring, or stronger supplier controls around remote support.
The model also helps you prioritise. Instead of trying to secure everything at once, you can focus on the zones and conduits that carry the greatest business risk. That is usually a better use of limited time and budget.
It can also support conversations with leadership. A clear model makes it easier to explain why certain controls matter and where investment will have the most value.
Keeping the design under regular review as systems change
Industrial environments change over time. New equipment is added, suppliers change, remote access is introduced, and business systems evolve. If the zone and conduit model is not updated, it quickly becomes less useful.
Build review into normal change management. When a system is added or a connection changes, ask whether the zone model still reflects reality. This keeps the documentation current and helps prevent accidental drift.
Regular review is especially important for SMEs, where the same small team may be responsible for both operations and security. A simple review habit is often enough to keep the model useful.
Bringing it together
Zone and conduit modelling under IEC 62443 gives UK SMEs a practical way to organise industrial security around real operational needs. It helps you separate critical systems, control communications, and make better decisions about where to invest effort.
The most effective models are usually the ones that are clear, proportionate, and easy to maintain. If you can explain the zones, the conduits, and the reasons behind them in plain English, you are probably on the right track.
If you would like help turning an asset list or network diagram into a workable OT security model, speak to a consultant. A short advisory session can often help you identify the most important boundaries and avoid unnecessary complexity.
Frequently asked questions
What is the difference between a zone and a conduit in IEC 62443? A zone is a group of assets with similar security needs. A conduit is the controlled communication path between zones. In practice, zones help you organise the environment, and conduits help you control how those parts connect.
How should a small manufacturer start zone and conduit modelling without overengineering it? Start with a simple asset and communication map. Group systems by function, criticality, and trust, then document only the communications that are genuinely needed. Review the result with engineering and operations staff so the model stays practical.
Comments are closed