Join our Newsletter — 33% off our NHI Course
Home› FAQ› Architecture & Implementation› How does Level 3 (Purdue) work?
Architecture & Implementation

How does Level 3 (Purdue) work?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 18, 2026 Domain: Architecture & Implementation

Level 3 in the Purdue Model is the site operations layer, where supervisory systems, historians, and plant management functions aggregate and coordinate production data. It sits above control equipment and below enterprise IT. Defenders monitor this layer for lateral movement, data tampering, and paths into lower operational levels.

What Level 3 actually does in the Purdue Model

Level 3 is the operations and supervisory layer. It is where plant-level systems aggregate process data, coordinate production, and give operators and plant managers visibility into what the control layer is doing. In practice, it connects real-time operations with planning and reporting functions, so it has to be stable, observable, and tightly separated from both lower control tiers and higher enterprise systems.

A useful way to think about Level 3 is that it is not the place where field control happens, but it is the place where control information becomes operationally meaningful. Historians, supervisory applications, and plant management functions often live here, so the layer becomes a high-value junction for monitoring, reporting, and operational decision-making.

Because Level 3 sits between process control and enterprise IT, design mistakes here can change the security posture of the whole site. For an overview of how this layer fits into the broader OT stack, the OT Security Guide covers the Purdue model, zones and conduits, and the role of segmentation in industrial environments.

Why Level 3 is such an important boundary

Level 3 is often the first place where operational visibility, business reporting, and remote administration meet. That makes it a practical boundary for controlling where data moves, who can see it, and which systems are allowed to influence production-related decisions. If this layer is overexposed, an attacker or careless change can move laterally into more sensitive operational systems or corrupt the data used to make plant decisions.

It is also where historical data, alarm context, and supervisory control information are concentrated, so integrity matters as much as availability. A compromised historian or supervisory host can mislead operators without visibly shutting the plant down, which is one reason defenders treat this layer as a target for stealthy manipulation rather than only obvious disruption.

Level 3 is also where segmentation discipline becomes operationally visible. The Purdue model assumes a clear boundary between site operations and enterprise networks, and that boundary is easiest to defend when traffic flows are intentional, limited, and monitored. NIST SP 800-207 Zero Trust Architecture is useful here because it reinforces the idea that trust should be verified at every boundary, not inherited from network location.

How defenders should think about Level 3 systems

Level 3 is best treated as a monitored operations zone, not a convenience layer for ad hoc access. The main questions are whether supervisory hosts are segregated, whether plant data paths are controlled, and whether changes can be traced back to an authorized source. If the answer to any of those is unclear, the site may still function, but it is functioning with unnecessary exposure.

Most defensive work at this layer is about reducing the blast radius of compromise. That means tightly managing remote administration paths, limiting cross-zone connectivity, and watching for abnormal use of engineering workstations, historians, or supervisory consoles. When defenders model this area as a likely pivot point, they are usually asking whether an intruder could use it to bridge from business systems into lower operational levels.

Good practice also depends on logging and operational context. Level 3 data is often noisy, so defenders need enough telemetry to distinguish routine operator activity from suspicious movement, data tampering, or unexpected access to control-related services. MITRE ATT&CK Enterprise Matrix helps frame those behaviors as lateral movement, credential access, and privilege escalation patterns that can show up before a clear outage occurs.

Risk and Threat Considerations

Level 3 is attractive to attackers because it combines operational visibility with broad connectivity. If this layer is compromised, an adversary may be able to alter process data, impersonate trusted supervisory activity, or use it as a staging point for movement into lower control levels.

Failure mechanism: Weak segmentation, overbroad admin access, or poor host hygiene can let malicious activity blend into normal supervisory traffic, making lateral movement and data tampering harder to detect.

Impact: Operators can lose trust in plant data, supervisory actions can become unreliable, and the compromise can propagate into production-impacting systems below Level 3 or into enterprise systems above it.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST SP 800-53 Rev 5AC-4 — Information Flow EnforcementLevel 3 depends on enforcing boundaries between OT and enterprise flows.
AU-2 — Audit EventsSupervisory hosts and historians need auditable events to spot tampering and movement.
CM-2 — Baseline ConfigurationLevel 3 stability depends on controlled, known-good host and service configurations.
Recommendation — Enforce information-flow restrictions between Level 3 and adjacent zones. Define and log Level 3 events that reveal unauthorized access or data changes. Maintain hardened baselines for supervisory and historian systems.
CIS Controls v8CIS-12 — Network Infrastructure ManagementLevel 3 security relies on managed segmentation and controlled network pathways.
Recommendation — Segment and manage pathways into and out of Level 3.

Practitioner Guidance

What to verify: Confirm which systems actually reside at Level 3, which accounts can administer them, and which network paths allow access to lower control levels. If a system can both aggregate process data and reach deeper OT assets, treat it as a high-priority boundary host.

Common mistake: Teams often secure Level 3 as if it were just another server zone, then allow broad patching, remote support, or data replication paths that collapse the intended Purdue separation. That usually creates the exact pivot route an attacker would want.

Practitioner takeaway: The main job at Level 3 is not to maximize connectivity, it is to preserve trusted supervision while preventing this layer from becoming the easiest bridge across the OT boundary.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org