IT OT Security Reference Architecture

What is an IT/OT Security Reference Architecture?

An IT/OT Security Reference Architecture is a reusable blueprint that defines how corporate IT and operational technology (OT) are connected securely, by describing zones, secured interfaces, access control and monitoring according to recognised standards. It covers office IT as well as systems such as SCADA, PLC, HMI and industrial networks, and it translates IEC 62443, the Purdue Model and Zero Trust principles into a standard design. Organisations use it as the basis for network drawings, tool selection and policy, so that every plant or site is set up according to the same pattern.

🧠 What makes an architecture a reference architecture?

A reference architecture is not the network drawing of a single plant but a generic pattern that you make concrete for each site. The difference from a solution architecture matters:

A good reference architecture is technology-agnostic: it states that there must be an IDMZ and which traffic may pass through it, but not which brand of firewall you buy. Yet it has to remain executable in your specific environment, with legacy systems that cannot be patched and installations that run for years without interruption.

🧱 Which zones and layers make up the architecture?

Most reference architectures follow the levels of the Purdue Model, also known as the Purdue Enterprise Reference Architecture (PERA), developed at Purdue University in the early 1990s. The model groups systems by function and time scale and, through ISA-95 and IEC 62443, has become the common language for network segmentation.

The core rule is that traffic between enterprise IT and the OT zones does not flow directly but terminates in a service in the IDMZ. NIST SP 800-82 (Revision 3, September 2023) describes exactly this pattern. Where data only needs to flow outwards, a data diode can make the connection physically one-way.

🔧 Which security building blocks belong to it?

The architecture places security layers between the zones. Each building block has a fixed position and a fixed responsibility:

The combination of macro-segmentation (zones) and microsegmentation (within zones) is the heart of segmentation in this architecture. Detection in OT is preferably passive, via a SPAN port or network tap, because active scanning can disrupt older PLCs.

🔄 Which standards and models is the architecture based on?

A security reference architecture rarely invents anything new. It combines existing standards and guidelines into one coherent design:

In January 2026 the UK NCSC and partners, including CISA, Germany’s BSI and the Dutch NCSC, published the Secure connectivity principles for operational technology. Its eight principles map directly onto a reference architecture: balance risk against benefit before connecting, limit exposure, centralise and standardise connections, use standard secure protocols, harden the OT boundary, limit the impact of compromise, log and monitor all connectivity, and establish an isolation plan.

🏭 Why does a reference architecture matter in OT?

• Availability first - the architecture secures the transition between IT and OT without compromising production availability.
• Clear responsibilities - IT and OT teams know who manages which zone and which interface.
• Phased improvement - security upgrades can be carried out per layer or zone, aligned with shutdown windows.
• Repeatability - new sites, acquisitions and projects follow the same pattern, which lowers design and audit costs.
• Demonstrable compliance - the NIS2 Directive and the Dutch Cybersecurity Act, in force since 15 August 2026, require essential and important entities to take appropriate measures for, among other things, network security. The law does not prescribe a specific architecture, but a documented reference architecture is one of the most verifiable pieces of evidence that those measures exist.
• New technology - the architecture provides guidance when integrating remote access, cloud applications and IIoT.

For critical infrastructure such as energy and water, customers and insurers also increasingly set requirements for zoning and remote access. A reference architecture makes those requirements measurable.

🧭 How do you build a reference architecture step by step?

The approach broadly follows the zone and conduit requirements process (ZCR 1 to 7) of IEC 62443-3-2:

1. Define the system under consideration - record which installations, networks and connections are in scope, based on an up-to-date asset inventory.
2. Perform an initial risk assessment - assess the worst case per process: what are the consequences of failure or manipulation for safety, the environment and production?
3. Partition into zones and conduits - group assets with the same function, risk and owner; record every connection between zones as a conduit.
4. Compare with tolerable risk - compare the initial risk of each zone with what the organisation considers acceptable; where it is higher, a detailed assessment follows.
5. Detail the risk assessment per zone and assign a target security level - map threats, vulnerabilities and existing countermeasures and choose an SL-T per zone and conduit: SL 1 protects against casual misuse, SL 2 against intentional attacks with simple means, SL 3 against sophisticated attackers with IACS-specific knowledge and SL 4 against attackers with extensive resources, such as nation-state actors.
6. Document the requirements - describe the measures, assumptions and constraints per zone and conduit and translate them into standard building blocks.
7. Obtain owner approval and keep it current - the asset owner approves the result; after that, review the architecture after major changes, new threats or new standards, and in practice at least once a year.

Typical values in practice: the IDMZ and site operations zones are often assigned SL 2, process control of critical installations SL 2 to 3, and safety systems their own zone with the strictest conduits. Firewall rules between IT and OT are set to deny-by-default, with only named ports to named systems in the IDMZ.

🔐 Which design principles make the architecture strong?

• Defense in Depth - several independent layers of defence per zone, so that a single mistake does not leave a door open.
• Traceable communication paths - every connection between IT and OT is documented, has an owner and is logged.
• Separated update processes - patch management runs through a patch server in the IDMZ, tested per zone and scheduled in maintenance windows.
• Containment - good segmentation limits the impact of incidents; an infected office network must not take production down with it.
• Isolation as an emergency measure - the architecture determines in advance how OT is disconnected from IT during an incident and how long production can keep running.

In this way the architecture reduces the risk of ransomware, espionage, sabotage and insider threats. Many OT incidents start in the office network; the IDMZ and strict conduits prevent such an attack from reaching process control.

❓ Frequently asked questions

Is an IT/OT Security Reference Architecture mandatory?

An IT/OT Security Reference Architecture is not literally mandatory as a document anywhere. NIS2 and the Dutch Cybersecurity Act do require appropriate measures for network security and risk management. A documented reference architecture is a practical way to make those measures demonstrable.

What is the difference between a reference architecture and the Purdue Model?

The Purdue Model is a structure of levels from 0 to 5 and says little about concrete security. An IT/OT Security Reference Architecture uses those levels as a basis and adds zones, conduits, security levels, building blocks and design rules. The reference architecture is therefore the executable security design on top of the Purdue Model.

Does Zero Trust fit into an OT reference architecture?

Zero Trust fits into an OT reference architecture, but usually as a complement to zoning rather than a replacement. Users and third parties are verified at every session, while older PLCs and field devices that do not support authentication stay inside a protected zone. This combines Zero Trust at the edges with classic segmentation in the process layer.

Which security levels does an IT/OT reference architecture use?

An IT/OT reference architecture usually uses the security levels from IEC 62443, from SL 1 to SL 4. A target level (SL-T) is set per zone based on a risk assessment, and the chosen building blocks must achieve that level. In many industrial environments the target is SL 2 or SL 3.

How often should you review a reference architecture?

You review an IT/OT Security Reference Architecture after major changes to installations, when new threats or standards appear, and otherwise at least annually. The architecture only stays valuable if it matches reality. An up-to-date asset inventory and network monitoring help you quickly find gaps between design and practice.

Who owns the IT/OT Security Reference Architecture?

The owner of an IT/OT Security Reference Architecture is usually a central architecture or security function, with shared responsibility for IT and OT. The local OT administrator translates the model to their own installation and reports deviations back. Without one clear owner, the design quickly fragments from site to site.

📌 In summary

An IT/OT Security Reference Architecture is the reusable blueprint that uses zones, conduits, an IDMZ, access control and monitoring to define how corporate IT and OT work together securely.

The architecture builds on the Purdue Model, IEC 62443, NIST SP 800-82 and Zero Trust and makes security repeatable across sites. It helps organisations build resilient networks, demonstrate compliance with NIS2 and the Cybersecurity Act, and limit the impact of incidents, without sacrificing production availability.