Purdue Model for Identity: What Breaks Below Level 3
The Purdue model splits OT networks into levels 0–5 plus an IDMZ. Here's what identity and access look like at each level, and why IT patterns break.
In this post
The Purdue model is a reference architecture that divides an industrial network into levels, from the physical process at Level 0 up to enterprise IT at Level 5, with an industrial DMZ (often called Level 3.5) between operations and business systems. Security teams use it to decide what may talk to what, and it’s just as useful for deciding who may log in where.
I say this a lot: the identity playbook that works in IT tends to fall apart below Purdue Level 3. This post explains why, level by level. If you’re newer to the space, start with what OT security is and come back.
What is the Purdue model?
The model comes from the Purdue Enterprise Reference Architecture, developed at Purdue University in the early 1990s, and it was later carried into the ISA-95 standard for integrating enterprise and control systems. It was never designed as a security architecture. It was a way to describe how manufacturing systems fit together. Security people adopted it because its layers map neatly onto trust boundaries.
It’s worth being honest about its limits. Real plants aren’t this tidy, and cloud-connected sensors, remote analytics and IIoT gateways skip levels all the time. IEC 62443 doesn’t require Purdue; it uses zones and conduits instead. Still, almost every OT conversation I’m in uses Purdue levels as shorthand, so it’s the right frame to explain identity with.
Purdue model levels 0 through 5
| Level | Name | What lives there | Typical identity reality |
|---|---|---|---|
| 5 | Enterprise network | Corporate IT, email, cloud apps, corporate identity provider | Full IT identity: SSO, MFA, IGA, PAM |
| 4 | Site business planning and logistics | ERP, site IT, business-side reporting | Still IT identity, joined to the corporate directory |
| 3.5 | Industrial DMZ (IDMZ) | Remote access gateways, jump hosts, data brokers, patch and AV staging, historian replicas | The identity checkpoint: brokered access, MFA, session control |
| 3 | Site operations and control | Historians, OT domain controllers, engineering servers, MES functions, OT patch servers | A separate OT directory, a small set of admins, service accounts everywhere |
| 2 | Area supervisory control | HMIs, SCADA servers, engineering workstations, alarm servers | Shared operator accounts, role-based HMI logins, engineering software with its own users |
| 1 | Basic control | PLCs, RTUs, DCS controllers, safety controllers | Device passwords if any, often shared or default; vendor tools as the “identity” |
| 0 | Physical process | Sensors, actuators, drives, valves, motors | No identity at all. Whoever can send the signal is authorized |
Safety instrumented systems are often drawn as their own zone alongside Levels 1 and 2. From an identity standpoint, treat anything that can change safety logic as the most privileged access in the plant.
The IDMZ: where IT identity should stop
Level 3.5 exists so that nothing on the enterprise side talks directly to anything in operations. Traffic terminates in the IDMZ and a separate connection continues on the other side. Data flows up through brokers or replicas. People come down through jump hosts or a remote access gateway.
That makes the IDMZ the natural home for most of the identity controls IT people are used to:
- Strong, phishing-resistant MFA for anyone crossing into operations, employees and vendors alike.
- A brokered remote access path so vendors and engineers never get a raw VPN onto the control network. This is privileged access management applied to OT: approval, credential injection, session recording, and time-boxed access.
- Just-in-time access for engineering and vendor sessions, so the default state is no access and every session has a reason attached.
- No domain trust that carries IT credentials past it. If an attacker owns the corporate directory, the IDMZ should be the end of the road, not a speed bump.
What this usually looks like: Picture a vendor support VPN the controls team set up years ago, terminating on a firewall that drops the user straight onto the Level 2 control network. The IT diagram shows a tidy Level 3.5; the vendor’s laptop has never heard of it. The first fix isn’t a new IDMZ build. It’s moving that VPN’s landing point to a jump host in the DMZ and removing the direct route, so there’s at least one place to authenticate, approve and record.
What identity looks like at Levels 3, 2 and 1
Level 3: a small, separate OT identity world
Level 3 is where an OT identity program can look the most like IT, with one big difference: it should be its own world. Most mature sites run a dedicated OT Active Directory forest here, with no trust to the corporate forest, or a carefully constrained one. Administrators have separate OT accounts. Group policy is tuned for operational systems, not for laptops.
Level 3 is also where non-human identities pile up. Historians collect from SCADA servers, OPC servers bridge protocols, backup and patch services touch everything below. Each has a service account, and many of those were created during commissioning by an integrator who has since moved on. I’d inventory these before anything else at this level, because they’re the accounts most likely to have broad rights and passwords that never change.
Level 2: shared consoles and shift work
Level 2 is the operator’s world, and it’s where IT identity habits do the most damage if you copy them blindly.
Control rooms run on shifts, and HMIs are often logged in to a role (“Operator, Unit 2”) rather than a person. That isn’t negligence. An operator who needs to acknowledge an alarm right now can’t wait for a login, a push notification or an unlock. Engineering workstations are different: they can change control logic, so they deserve individual accounts, strong authentication at login, and recorded sessions. The art is telling those two apart and treating them differently.
Level 1: devices that don’t know who you are
At Level 1, the “identity” is often whoever has the vendor’s engineering software and network reach to the controller. Many PLCs support a password, some support role-based access, and newer ones support certificates and secure protocols. Plenty of installed equipment supports none of that, or has a password that’s shared across the whole fleet. Some controllers still rely on a physical key switch to move between run and program mode, which is, honestly, one of the better access controls in the building.
You won’t fix Level 1 identity by touching Level 1 much. You fix it by controlling who can get to the engineering workstation and the network path to the controller.
Why IT identity patterns break down in Levels 0–2
Here are the specific IT habits that run into trouble, and what tends to work instead.
| IT pattern | Why it breaks below Level 3 | What tends to work instead |
|---|---|---|
| One directory everywhere | Ties plant availability to the corporate domain, and turns an IT compromise into an OT one | Separate OT directory at Level 3; separate admin identities |
| SSO to everything | Many OT applications and devices can’t federate, and an IdP outage can’t be allowed to stop operations | Local or OT-directory authentication, with SSO only up to the IDMZ |
| MFA prompts at every login | Delays operators during alarms; phones are often banned from control rooms | MFA at the IDMZ, remote access gateway and engineering workstations; physical security in the control room |
| Aggressive lockout and timeouts | Can lock an operator out of a running process | Alerting on failed attempts instead of lockout on operator consoles; lockout where it’s safe |
| Endpoint agents for identity and EDR | Often unsupported by the control system vendor, and can void support | Passive network monitoring, application allowlisting where the vendor certifies it, controls at the boundary |
| Monthly patching and rapid password rotation | Changes need outages, vendor approval and management of change | Rotation where supported, compensating controls and monitoring where not, and changes scheduled with operations |
| Removing shared accounts | Some are operationally necessary | Know them, scope them, pair them with physical controls and logging |
None of this means you give up on least privilege below Level 3. It means you move enforcement to the places that can carry it: the IDMZ, the jump host, the engineering workstation and the network path. That’s the same logic behind Zero Trust, applied honestly to devices that can’t verify anything themselves.
Where it tends to go wrong: Say a site extends corporate SSO and MFA to the Level 2 engineering workstations as part of a domain consolidation. Then the WAN link to the cloud IdP drops on a night shift, and the engineers can’t log in to the station they need to fix the very problem in front of them. The usual outcome is a hastily created local admin account that never goes away, which leaves the site worse off than before. Keep the IdP dependency at the IDMZ and use local authentication with break-glass procedures inside.
There’s one more thing that breaks: the assumption that an outage is just an inconvenience. In IT, a misconfigured access policy produces tickets. In OT, it can leave an operator unable to act on a running process. A control system outage is a safety event, not a ticket, and every identity decision below Level 3 should be reviewed with that in mind.
How to use the Purdue model for identity design
If you’re building or reviewing OT access, here’s the sequence I’d follow:
- Draw the real map, not the reference one. Find every path between levels, including vendor modems, cloud connectors and “temporary” remote tools.
- Make the IDMZ the only way in. Every human crossing from Level 4 or the internet into Level 3 or below goes through a brokered, authenticated, recorded path.
- Separate the directories. OT identities live in an OT directory with no inherited trust from IT.
- Classify accounts by level and consequence. Engineering and safety-system access gets the strictest treatment. Operator console access gets the most operational flexibility.
- Inventory the non-human identities at Level 3. Service accounts, integration credentials and machine certificates, each with an owner. (On the certificate side, certificate lifecycle management applies here too, with longer change windows.)
- Agree the failure modes with operations. For every control, decide what happens when it fails, and make sure the answer isn’t “operators can’t see the process.”
My advice: Run step 6 as a workshop, not a document review. I’d put an operations lead, a controls engineer and whoever owns the firewalls in a room with the real network drawing, and walk each control with one question: if this fails at 2am, what does the operator see? The answers usually move a few controls up a level, and they earn you the operational buy-in you’ll need later.
The short answer
The Purdue model is a map of an industrial network, from physical process to enterprise IT. For identity, it’s most useful as a guide to where each kind of control belongs. Full IT identity works at Levels 4 and 5. The IDMZ is where strong authentication, brokered remote access and session control should concentrate. Below Level 3, identity becomes a mix of a separate OT directory, carefully scoped shared accounts, and protection of the paths to devices that can’t authenticate anyone.
If you take one thing from this: stop trying to push IT identity down to Level 1, and start making the IDMZ do the work. More posts on this live in the OT security hub.