Purdue model vs ISA-95 is one of the most common points of confusion in industrial architecture, because both use levels numbered from 0 to 4 and both are drawn as stacked layers. In this comparison you will learn what each model was designed for, how their levels map, where they genuinely differ, and how MQTT and a unified namespace change the way data moves between levels without throwing away the security zoning that Purdue-style networks provide.
Where Each Model Comes From
The Purdue Enterprise Reference Architecture was developed at Purdue University in the early 1990s as a general model for computer-integrated manufacturing. In the industrial security world it has become shorthand for a layered network architecture: physical process at the bottom, enterprise IT at the top, and controlled boundaries between them. It is widely used as a reference in OT security programmes and was an influence on the zone-and-conduit approach of ISA/IEC 62443.
ISA-95, also published as IEC 62264, is an integration standard. Its purpose is to define how business systems such as ERP and manufacturing operations systems such as MES exchange information: production schedules, material consumption, equipment capability, quality results. It provides object models, activity models and a functional hierarchy, and it also defines the role-based equipment hierarchy of enterprise, site, area, work center and work unit.
In short: Purdue is mostly used to answer "how should the networks be segmented?", while ISA-95 answers "which functions exist at each level, and what information flows between business and operations?"
How the Levels Line Up
The level numbers match closely enough to be useful and loosely enough to cause arguments.
| Level | Purdue model (network view) | ISA-95 functional hierarchy | Typical systems |
|---|---|---|---|
| 5 | Enterprise network | Not separately defined | Corporate IT, internet-facing services |
| 4 | Business logistics | Business planning and logistics | ERP, planning, email |
| 3.5 | Industrial DMZ | Not defined | Jump hosts, patch servers, data brokers |
| 3 | Site operations | Manufacturing operations management | MES, historian, site SCADA servers |
| 2 | Area supervisory control | Monitoring and supervisory control | HMI, SCADA clients, engineering stations |
| 1 | Basic control | Sensing and manipulating | PLCs, DCS controllers, RTUs |
| 0 | Physical process | The physical process | Sensors, actuators, drives |
Three differences stand out:
- Level 3.5 is a Purdue concept. ISA-95 has no DMZ because it does not model networks. Security practitioners added the industrial DMZ between site operations and enterprise networks to prevent direct traffic between IT and OT.
- Level 5 appears in many Purdue diagrams as a separate enterprise or internet tier. ISA-95 stops at Level 4.
- ISA-95's main contribution is the Level 3 to Level 4 interface, which Purdue diagrams treat as a single firewall boundary.
Purdue Model vs ISA-95: Key Differences
| Aspect | Purdue model | ISA-95 |
|---|---|---|
| Type | Reference architecture | International standard (IEC 62264) |
| Main concern today | Network segmentation and security | System integration and information models |
| Defines data models | No | Yes, for production, quality, maintenance, inventory |
| Defines equipment hierarchy | No | Yes, enterprise to work unit |
| Defines a DMZ | Yes, commonly as Level 3.5 | No |
| Typical audience | OT security, network engineers | MES architects, integrators, operations |
| Relevance to MQTT topic design | Indirect, via where brokers sit | Direct, via the equipment hierarchy |
The practical consequence: when you design MQTT topics, use the ISA-95 equipment hierarchy, which our ISA-95 equipment hierarchy guide explains. When you decide where the broker runs and which connections the firewalls allow, think in Purdue zones.
How MQTT Flattens Communication Across Levels
In a classic Purdue-style plant, data climbs the levels one hop at a time. A PLC is polled by SCADA at Level 2, SCADA feeds the historian at Level 3, the historian is replicated through the DMZ, and ERP eventually sees a summary. Every hop is a point-to-point integration with its own protocol, mapping and failure modes.
A publish-subscribe architecture changes the data flow. With an MQTT broker as a unified namespace, any authorised producer publishes once and any authorised consumer subscribes directly. The MES, the historian, a dashboard and a cloud analytics job all read the same filler telemetry from the same topic. This is what people mean when they say MQTT "flattens the pyramid".
It is important to be precise about what is flattened. The information architecture becomes flat: there is one namespace instead of a chain of copies. The network architecture does not have to: zones, firewalls and the DMZ still exist. MQTT helps here, because clients always open outbound connections to the broker. A gateway at Level 2 can publish to a broker in the DMZ or in the cloud without any inbound port being opened into the control network.
Where to Place the Broker
| Placement | How it works | Considerations |
|---|---|---|
| Level 3 site broker | Gateways publish inside the site; a bridge or consumer forwards upward | Data stays local; you operate the server |
| Level 3.5 DMZ broker | OT clients connect outbound into the DMZ; IT clients connect from above | Clear boundary; neither side connects into the other's zone |
| Cloud broker | Edge gateways connect outbound over TLS to a hosted broker | No server to run; requires outbound internet from a controlled zone |
| Hybrid | Site broker for local consumers, cloud broker for enterprise and cross-site | More components, best resilience and reach |
Our MQTT in the DMZ article covers the DMZ design in depth, including firewall rules. If you choose a cloud MQTT broker, a managed service such as ConnectMQ handles the server side while your firewall only needs to allow outbound TLS from the gateway's zone.
Testing an Outbound Path From an OT Zone
Before committing to a placement, check that a gateway in the intended zone can reach the broker on the right port and that TLS validates. These commands are safe to run from a Linux gateway or jump host; they use the public test broker, so publish nothing sensitive:
# 1. Is outbound TLS on 8883 allowed and does the certificate validate?
openssl s_client -connect broker.connectmq.com:8883 -servername broker.connectmq.com </dev/null 2>/dev/null | grep -E "Verify return code|subject="
# 2. Publish one retained test message over TLS
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i purdue-test-pub-j2 -r -t "connectmq/demo/j2v6/zone-test/level2-gateway" -m "reachable"
# 3. Read it back from another zone
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i purdue-test-sub-j2 -t "connectmq/demo/j2v6/zone-test/#" -v -C 1
A Verify return code: 0 (ok) line confirms that the certificate chain is trusted. If step 1 hangs, a firewall is blocking 8883; if WebSockets are the only option, port 8084 with path /mqtt is an alternative. The free public MQTT broker is fine for this connectivity check; production traffic belongs on a private broker with credentials.
Security Still Matters
A flat namespace makes data easy to reach, so authentication and least privilege matter more, not less:
- Outbound only. Gateways connect out to the broker; never open inbound ports into Levels 0 to 2.
- TLS everywhere. Port 8883 for MQTT over TLS, 8084 for secure WebSockets.
- One identity per client. Issue credentials per gateway and application so each can be revoked independently. On ConnectMQ, client IDs are bound to the issued credentials.
- Separate read and write paths for control. Treat command topics as high risk and keep closed-loop control on the local control network.
- Monitor connections. Watch for unexpected clients and failed logins. ConnectMQ blocks IPs after repeated failed logins and applies flood protection per tenant.
The relationship between the two models is part of the wider IT/OT convergence conversation, and our industrial IoT MQTT guide shows how these pieces fit into a full plant architecture.
Bridge Your Levels With ConnectMQ
Keeping Purdue-style zones while flattening the data flow requires a broker that every zone can reach over outbound TLS. ConnectMQ is a managed MQTT broker with TLS on 8883, secure WebSockets on 8084, per-client credentials and an ISA-95 devices view, available as shared, dedicated or BYOC deployments. Start on the free Serverless plan at app.connectmq.com, no credit card required.
Frequently Asked Questions
Is the Purdue model obsolete?
Its strict one-hop-at-a-time data flow is being replaced by publish-subscribe architectures, but its core idea of segmenting networks into zones with controlled boundaries remains central to OT security.
Does ISA-95 define network security?
No. ISA-95 defines functions, information models and the equipment hierarchy. Network and system security for industrial automation is addressed by the ISA/IEC 62443 series.
Which model should I use for MQTT topic design?
Use the ISA-95 equipment hierarchy for topics, and use Purdue-style zones to decide where the broker runs and which outbound connections are allowed.
Does a unified namespace break the Purdue model?
It changes the data flow, not necessarily the network segmentation. With outbound-only MQTT connections and a broker in the DMZ or cloud, zones and firewalls remain in place.
