What is OT architecture?
OT architecture is the description of the structure and coherence of all systems, networks, data flows and security measures that measure, control and monitor a physical process, from the sensor in the field to the link with business systems. It covers SCADA systems, PLCs, sensors, actuators, industrial networks and monitoring tools, and the way they connect to IT systems. A good architecture defines which system belongs at which level, which traffic may flow between levels and how the installation stays available and secure over a lifetime that is often twenty years or more.
OT architecture ensures reliable, safe and manageable process automation, from the field layer up to management level.
π§± What are the components of an OT architecture?
Every OT environment, whether a wastewater treatment plant, a food factory or an electrical substation, is built from a similar set of building blocks:
| Component | Function | Examples |
|---|---|---|
| Field devices | Measuring and switching in the process | Sensors, actuators, valves, variable frequency drives |
| Control | Local control and logic | PLC, RTU, DCS controllers, IED |
| Safety systems | Bringing the process to a safe state | SIS, safety PLC |
| Supervision and operation | Visualisation, alarming, operator control | SCADA, HMI |
| Operational systems | Production management and process data | MES, historian, engineering workstations |
| Networks and protocols | Communication between layers | fieldbuses, ProfiNET, Modbus, IP, OPC UA |
| Edge and IIoT | Local processing and access to data | edge devices, MQTT, Unified Namespace |
| Security infrastructure | Separating, controlling access, detecting | firewalls, IDMZ, jump server, IDS |
An architecture describes not only these components but above all their relationships: who talks to whom, over which protocol, how often and under whose management.
Recording this explicitly serves a practical purpose: standardising components and networks, letting installations grow in a manageable way, safeguarding safety and availability, promoting interoperability between vendors and systems, and preparing the installation for innovation.
π How does the Purdue model divide an OT architecture into layers?
The most common structure is the Purdue Model, developed at Purdue University in the early 1990s and later the basis for ISA-95 (IEC 62264) and the reference model in IEC 62443-1-1. Each level has its own function and timescale:
| Level | Function | Typical systems | Timescale |
|---|---|---|---|
| 5 | Enterprise | Email, central IT, cloud analytics | Months to days |
| 4 | Business planning and logistics | ERP, planning, office network | Weeks to days |
| 3.5 | Controlled IT/OT transition | IDMZ, historian replica, patch server | n/a |
| 3 | Site operations | MES, historian, engineering | Days to minutes |
| 2 | Supervisory control | SCADA, HMI, alarm servers | Seconds |
| 1 | Basic control | PLC, RTU, DCS controllers, SIS | Milliseconds to seconds |
| 0 | Physical process | Sensors, actuators, motors | Continuous |
Levels 0 to 3 together form the manufacturing or OT zone, levels 4 and 5 the enterprise zone. Level 3.5 is not part of the original model; it emerged from security practice and was worked out in, among others, Converged Plantwide Ethernet by Cisco and Rockwell Automation. The principle is simple: there is no direct connection from the office to production.
A good OT architecture defines which components, protocols and security measures apply at each level.
π How do you secure an OT architecture?
Security is not a layer added on top of the architecture but a design principle (Security by Design). The IEC 62443 series of standards provides the usual framework. The key building blocks:
| Measure | Explanation |
|---|---|
| Zones and conduits | Group systems with similar security requirements into zones and let traffic flow only through controlled conduits, as described in IEC 62443-3-2 |
| Security levels | Assign each zone a target level SL-T, from SL 1 (unintentional error) to SL 4 (well-resourced attacker) |
| Network segmentation | Separate field, control, SCADA and IT using firewalls and VLANs |
| IDMZ and data diode | Let data reach IT through an intermediate zone or a one-way connection |
| Remote access | Vendors and administrators only through a jump server with MFA and logging |
| Patch management | Safe and controlled updating of firmware and software, after testing |
| Lifecycle Management | Versioning, documentation and end-of-life policy for OT components |
| Monitoring and detection | Passive network monitoring for abnormal behaviour or unauthorised access |
Together these measures form defence in depth: if one layer fails, the next one still stops the attacker.
π What is the difference between IT and OT architecture?
| Feature | IT architecture | OT architecture |
|---|---|---|
| Purpose | Information processing, supporting users | Process control, physical execution |
| Priority | Often confidentiality first | Safety and availability first, then integrity, then confidentiality |
| Lifespan | 3β5 years | 15β25 years or longer |
| Frequency of change | High (monthly patches) | Low (planned shutdowns, validation) |
| Timing requirements | Delay is a nuisance | Deterministic, milliseconds can matter |
| Interfaces | User applications, web services | Sensors, actuators, machine protocols |
For the wider comparison see Differences Between IT and OT. OT convergence calls for an architecture that connects both worlds technically and in terms of policy, without subordinating the requirements of process control to those of IT.
π§ How do you draw up an OT architecture in practice?
In September 2025, CISA, the FBI, the UK NCSC, the Dutch NCSC and four other partners jointly published the guidance Creating and Maintaining a Definitive View of Your OT Architecture. It sets out five principles that work well as a step-by-step plan:
- Define the process - who maintains the architecture overview, how often is it updated and who may see it? An outdated overview creates a false sense of security.
- Establish an OT security programme - embedded in your management system, with clear ownership of OT risk.
- Identify and categorise assets - through an asset inventory and passive monitoring, recording criticality, firmware version and owner for each asset.
- Document all connectivity - map the data flows between levels and watch especially for traffic that skips levels, such as a PLC with a direct cloud connection.
- Understand third-party risk - vendors with remote access, cloud platforms and integrators (supply chain risk).
The design follows: defining zones and conduits, assigning security levels based on a risk assessment and setting up the IDMZ. In January 2026 the UK NCSC, again with partners including the Dutch NCSC, followed up with guidance containing eight principles for secure OT connectivity, such as limiting exposure, hardening boundaries and logging.
Dutch context. Since 15 August 2026 the Dutch Cybersecurity Act (Cyberbeveiligingswet) and the Cybersecurity Decree apply. The duty of care also covers OT systems needed to deliver the service, such as the SCADA systems and PLCs of a drinking water company or grid operator. An up-to-date architecture overview is no longer optional: without it you cannot assess risks or quickly contain incidents. For manufacturers of products with digital elements, the Cyber Resilience Act adds further requirements.
π§ Which trends are changing the classic OT architecture?
The Purdue model assumes that data flows neatly upwards from layer to layer. Modern architectures deviate from that:
- Edge computing and the cloud - data sometimes goes straight from level 1 or 2 to a cloud platform. That calls for strict conduits and outbound-only connections.
- Unified Namespace - a central, event-driven data bus over MQTT instead of point-to-point links per layer.
- NAMUR Open Architecture - a second, one-way channel next to the existing control system for monitoring and optimisation.
- Virtualisation - SCADA servers and sometimes even soft PLCs run on virtualised hardware.
- Zero Trust - even within a zone, nothing is trusted blindly any more.
A reference architecture that combines these developments with classic segmentation is the IT OT Security Reference Architecture. It makes applications such as IIoT and Predictive Maintenance possible without exposing process control.
β Frequently asked questions
Is the Purdue model still useful for OT architecture?
Yes, the Purdue model remains the common language for classifying and segmenting OT systems by function. You do need to supplement it with zones and conduits from IEC 62443 and with rules for edge and cloud connections that skip levels.
What is the difference between OT architecture and network segmentation?
OT architecture describes the whole of systems, data flows, management and security in an industrial environment. Network segmentation is one measure within that architecture: dividing the network into shielded parts.
Which standard do you use to design a secure OT architecture?
The most important standard is IEC 62443, in particular part 3-2 for zones, conduits and risk assessment and part 3-3 for system requirements per security level. NIST SP 800-82 Rev. 3 from September 2023 adds practical OT architecture examples.
How often should an OT architecture overview be updated?
An OT architecture overview should be updated with every change to assets, connections or suppliers, and also be reviewed periodically. The international guidance of September 2025 speaks of a definitive record that must be kept continuously up to date.
Who is responsible for the OT architecture?
Responsibility usually lies with an OT architect or OT security engineer, working with process automation, IT and the owner of the installation. Under the Dutch Cybersecurity Act, the organisationβs management board remains ultimately accountable for the duty of care, including for OT.
Does a safety instrumented system (SIS) belong in the same zone as the PLC?
A SIS sits functionally at level 1 of the Purdue model, but a good OT architecture treats it as a separate safety zone. That way the safety system keeps working independently, even if process control is compromised.
π In summary
OT architecture is the blueprint for reliable, safe and future-proof industrial systems.
The Purdue model provides the layers, IEC 62443 the zones, conduits and security levels, and an up-to-date architecture overview forms the basis for risk assessment and the duty of care under the Dutch Cybersecurity Act. By bringing structure to control, networks and security, OT becomes manageable as a whole, also in conjunction with IT.
See also OTArchitect.nl
