The Purdue Model and ISA-95 Explained: A Field Guide to Manufacturing's Five Layers

Spend an hour in a conversation about OT network segmentation or MES rollouts and someone will say "that belongs at Level 3" as if the number is self-explanatory. It usually isn't, unless you've already met the Purdue Model and ISA-95 — the reference architecture that quietly underpins almost every diagram of a modern factory's information flow, from PLC to ERP. This post is the explainer those conversations assume you've already had.

Where the Model Came From

The Purdue Model — formally the Purdue Enterprise Reference Architecture (PERA) — was developed in the early 1990s by Theodore J. Williams and the Industry-Purdue University Consortium for Computer Integrated Manufacturing. Its original job had nothing to do with cybersecurity: it was a way to map the data flows inside a fully computerised manufacturing plant, so engineers designing factory information systems had a shared vocabulary for what belonged where and how information should move between levels.

ISA-95 is the standard that formalised and extended that thinking for industry use. Published by the International Society of Automation as ANSI/ISA-95 (parts 1 through 6) and adopted internationally as IEC 62264, it defines the terminology, data models, and interfaces for integrating enterprise systems (ERP) with control systems (MES, SCADA, PLCs). ISA-95 and IEC 62264 are technically the same standard under two publishing bodies — you'll see both names used interchangeably in vendor documentation. Together, "the Purdue Model" and "ISA-95" get used almost interchangeably on the plant floor, even though one is a conceptual architecture and the other is a formal standard built on top of it.

The Five Levels, Walked From the Floor Up

Level 0 — The physical process. The actual product: metal being stamped, a chemical reaction running, a conveyor moving a part. No computing here, just the physics.

Level 1 — Sensing and actuation. The field devices that touch Level 0 directly — sensors, actuators, drives, valve positioners — talking over the field-level protocols covered in our industrial Ethernet explainer: Modbus, PROFINET, EtherNet/IP, EtherCAT.

Level 2 — Supervisory control. PLCs, DCS controllers, SCADA systems, and local HMIs. This is where real-time control logic lives — the loop that keeps a temperature at setpoint or sequences a robot cell, plus the screens an operator uses to watch and intervene.

Level 3 — Manufacturing operations management. MES, data historians, scheduling, and electronic batch records. This layer turns individual machine events into production-level information: what ran, when, at what rate, with what scrap. It's also where an OEE figure actually gets assembled from raw machine states.

Level 4 — Business planning and logistics. ERP, advanced planning and scheduling, financials. This is where a customer order becomes a production schedule, and where Level 3's output becomes a cost, delivery date, or inventory entry.

The cybersecurity overlay most OT security frameworks use — including IEC 62443, which structures its zones and conduits directly on these boundaries — adds a Level 3.5: a demilitarised zone (DMZ) sitting between the manufacturing zone (Levels 0-3) and the enterprise zone (Level 4), so that no application ever needs a direct path from the business network straight into the control network.

A Worked Example: One Job Order, Five Levels

Take a plant building gearbox housings. A distributor places an order for 500 units. That order lands in Level 4 ERP, which checks inventory and capacity and schedules a production run. The schedule passes down to Level 3, where the MES breaks it into a work order, sequences it against the line's existing queue, and releases it to the shop floor as an electronic routing sheet. At Level 2, the line's SCADA/HMI loads the recipe — spindle speeds, tool offsets, cycle time targets — into the CNC controllers, and the PLCs start executing the machining sequence. At Level 1, sensors on the spindle, coolant system, and part-presence detectors feed real-time state back up, while servo drives execute the actual motion. Level 0 is the housing itself, metal being cut to tolerance.

As the run proceeds, that same data climbs back up: cycle counts and downtime events roll into the MES at Level 3, where they become the OEE and scrap-rate figures a plant manager reviews; completion status rolls into the ERP at Level 4, where it closes out the order and triggers shipping and invoicing. One job order, five layers, moving down as instructions and back up as production data — which is the entire point of the model: it names each handoff so integration between layers can be designed deliberately instead of improvised.

Why the Levels Matter for Security, Not Just Architecture

The model's original purpose was information flow, but it became the default mental map for OT security because its layer boundaries are natural places to put a firewall. Our OT network segmentation guide covers this in depth: IEC 62443's zones and conduits map closely onto Purdue levels, the Level 3.5 DMZ is the standard place to broker any traffic between IT and OT, and a huge share of real-world OT security findings — flat Level 2 networks, unrestricted Level 3-to-4 database links, a historian with an unmanaged direct feed to a cloud dashboard — are really just descriptions of a level boundary nobody enforced.

Where the Clean Hierarchy Breaks Down in 2026

The model describes a strict, layered hierarchy, and modern architectures don't fully respect it anymore. IIoT sensors increasingly stream telemetry straight to a cloud platform, skipping Levels 2 and 3 entirely. The Unified Namespace pattern, built on MQTT and Sparkplug B, deliberately publishes data from any level to any subscriber rather than forcing it up through each layer in sequence. Machine builders expect permanent remote-access VPNs that reach into Level 2. ERP-to-MES integrations open broad, persistent connections across the old Level 3/4 boundary for real-time inventory and scheduling.

None of that makes the model obsolete — it's still the shared vocabulary the industry uses to describe where a system lives and what it's responsible for, and it remains the starting point most IT/OT convergence projects work from. But in 2026 it functions best as a naming and design reference rather than a literal network diagram: the boundaries it describes now need explicit access control and identity verification (the case most OT security vendors now make for layering zero-trust principles on top of Purdue zones) rather than the physical air gaps the original architecture assumed would hold.

Using the Framework in Practice

For most plants, the practical value of ISA-95 isn't philosophical — it's a checklist for two recurring questions. First, when a new system is being specified, which level does it actually belong to, and does its proposed connectivity match that level's normal traffic pattern, or does it quietly reach across a boundary that should have a conduit and a firewall rule instead? Second, when data isn't flowing the way a report expects — an OEE number that doesn't reconcile, a schedule that isn't reaching the floor — the levels are a fast way to localise the break: is this a Level 1/2 problem (a sensor or PLC not reporting), a Level 3 problem (the MES not aggregating correctly), or a Level 3/4 integration problem (ERP and MES disagreeing about a work order)?

If you're new to where these systems sit relative to each other, the Software Defined Factory glossary has standalone entries for ISA-95, SCADA, DCS, MES, and ERP worth bookmarking, and our courses cover IIoT architecture fundamentals in more depth than a single post can.