Tutorial 02 / 10
QuantLayer AcademyQuantLayer Across the Purdue Model: Industrial IT/OT Trust
Apply trust decisions across industrial zones while respecting legacy equipment, safety boundaries, and the realities of plant operations.
QuantLayer Academy
Platform learning series
In this tutorial · jump to a section
What you will learn
- Describe trust boundaries across representative Purdue levels.
- Choose native, gateway-mediated, or passive evidence appropriately.
- Place enforcement where it respects plant safety and availability.
Start with the zones and conduits
The Purdue Model is a useful way to discuss industrial environments as operational levels: field devices and process equipment at Level 0, controllers at Level 1, supervisory control at Level 2, site operations at Level 3, an industrial DMZ around Level 3.5, and enterprise systems above it. Real plants vary, so treat the model as a map rather than a claim that every network is identical.
Trust architecture should preserve these boundaries. The goal is to understand which identities, devices, and sessions may communicate across which conduits, under what conditions, and with what evidence. A trust layer can coordinate that view without becoming an inline appliance at every level.
Use three evidence attachment patterns
Capable assets may provide native cryptographic identity or attestation. Legacy controllers often cannot run an agent, store a TPM key, or tolerate new traffic. For those systems, a managed gateway can represent the connection and supply evidence about the gateway, operator, and approved route.
Passive monitoring contributes another useful view: observed asset identity, protocol behavior, and communication patterns. Passive evidence should be labeled as observation, not cryptographic proof. Combining these methods gives coverage without pretending that every PLC has the same capabilities.
Trace an engineering access path
Consider an engineer connecting from an enterprise workstation toward a PLC. The approved path may require a verified user and managed workstation, a controlled jump host, and a reviewed conduit through the industrial DMZ. Policy can evaluate the identity, device posture, request, time window, and target before an authorized control allows the session onward.
Make the path explicit: request, evidence, decision, enforcement point, and audit result. The trust plane may coordinate these steps, but the jump host, firewall, remote access gateway, or other integrated control performs the enforcement it supports.
Keep safety and availability in the design
Levels 0 and 1 frequently contain systems where availability and physical safety take priority. Avoid autonomous actions that could interrupt a process. Use monitoring and recommendations first, then place narrowly scoped controls at safer boundaries such as the DMZ or selected gateways after operational review.
Plan for stale telemetry, vendor maintenance, emergency access, and network partitions. Define who can approve an exception, how it expires, how operators can roll back a change, and how the team proves that the plant returned to its expected state.
Adopt in operational stages
Inventory assets and conduits, identify evidence sources, and mark confidence and ownership. Baseline current communication before changing policy. Pilot with a representative site or cell, measure false positives and missed observations, then simulate the proposed boundary actions.
Expand only when the plant team understands the decision and the rollback path. An accurate industrial design distinguishes native attestation, gateway-mediated evidence, passive observation, policy decision, and safe enforcement. That precision is more valuable than drawing every device as equally manageable.
Concept map
Route maintenance through safe conduits
A trusted operator reaches only an approved asset through reviewed industrial boundaries.
Scope the work
Named contractor, work order, target, and time window.
Verify at the gateway
Check identity and managed workstation posture.
Cross the industrial DMZ
Apply the site's approved conduit and operator review.
Keep the PLC isolated
Reach only the authorized historian or service.
Key point: Place enforcement at a supported boundary; do not assume a legacy controller can host an agent.
Model the actual plant before applying Purdue labels
Use site diagrams, firewall rules, switch data, maintenance procedures, and interviews with control engineers to validate where assets and conduits really sit. A historian may exchange data with enterprise systems through a site-specific broker; a safety instrumented system may have a stricter boundary than a simple level diagram suggests. Record the real source and destination, protocol, owner, business purpose, and approved direction for each important flow.
Treat Level 3.5 as a design boundary to examine, not a universal appliance location. Some plants have multiple DMZs, vendor enclaves, remote operations centers, or unidirectional gateways. Preserve those distinctions in policy so a broad label such as OT access does not accidentally grant a contractor reachability to unrelated cells or production lines.
Assign assurance according to what can be observed
A device with a validated hardware key can provide stronger identity evidence than a hostname learned from passive traffic. A gateway can prove which gateway opened a route and which operator authenticated there, while leaving the downstream PLC identity less certain. Passive monitoring can show that a device communicated using a protocol, but normally cannot prove which software state produced the traffic. Keep these assertions separate in the evidence model.
For each attachment method, define which decisions it may support. A passive observation might justify inventory enrichment or analyst review, while a verified operator identity and a managed jump host could support a bounded maintenance session. Avoid silently promoting low-confidence asset matching into an automatic block or allow rule. When the target is uncertain, require a human to confirm the asset and work order.
Rehearse maintenance and recovery with plant operators
Walk through normal vendor maintenance, emergency access, a failed connector, a network partition, and an unexpected control-system alarm. For each scenario, identify the person allowed to approve the action, the boundary where it is enforced, the expected audit record, and the safe recovery procedure. Test during an approved window with operations staff present, using a noncritical representative path before touching a production cell.
Measure whether the planned control preserves process availability, not just whether the policy engine returned the intended decision. Confirm that operators can stop a session, restore a known-good route, and see which exception remains active. An exception should identify its owner, scope, reason, and expiry; when it expires, the system should return to the normal rule and report that transition clearly.
Worked example
A contractor needs scheduled access to a production historian while a PLC remains isolated from direct remote access.
- Place the approved remote session through the managed access gateway and industrial DMZ.
- Validate contractor identity, device posture, work order, and the historian's Purdue level.
- Log the bounded historian session and require the site operator to approve any change that could affect control systems.
Expected outcome: The user reaches only the authorized service through a monitored boundary; the PLC retains its existing safety and control path.
Further reading
- NIST SP 800-82 Rev. 3: Guide to Operational Technology Security
- ISA/IEC 62443 series: Industrial Automation and Control Systems Security
Knowledge check
A legacy PLC has no TPM or agent and must be reached for approved maintenance. What should the architecture show?