Designing Policy Enforcement for Legacy OT in Manufacturing
Arcadia Manufacturing operates 25 plants, employs 9,000 people, and runs 3,000 OT devices including PLCs, HMIs, historians, and safety systems. IT and OT networks are converging after an acquisition, and vendor engineers remotely support line controllers. OT devices cannot run agents, several run unsupported operating systems, and any disruption can stop a production line for hours. The CISO wants a zero trust architecture that names a policy engine, policy administrator, and policy enforcement points, but plant managers fear downtime more than ransomware. A previous VLAN-based segmentation attempt failed when broadcast traffic from legacy PLCs broke line coordination. The company has an IdP for workforce users, an asset inventory that covers 70% of OT, and no consistent certificate lifecycle for devices. The board asks for a design that improves security without requiring forklift upgrades.
1. Define the logical zero trust components for Arcadia and explain what each must do for OT.
Read the worked answer
Policy engine: the decision point that evaluates access requests using user identity, device identity, OT asset criticality, process context, time, and threat intelligence; it should consume the 70% OT inventory and mark unknown assets as high risk. Policy administrator: establishes or shuts down the communication path by instructing PEPs, issuing short-lived credentials, and logging the decision. PEPs: placed at IT/OT boundaries, in front of remote-access gateways, and at cell or line zones where feasible; they enforce allow-lists and session rules without requiring agents on PLCs. Supporting components: an identity provider for workforce users, a device identity and certificate authority for OT assets, an asset inventory, and a SIEM for OT telemetry.
For OT, the policy engine must treat safety and process continuity as context: a request from a vendor engineer to a PLC during production hours should require sponsor approval and a maintenance window, even if the user has valid credentials. The policy administrator should create a time-bound path through a jump host, not a permanent firewall rule. Reasoning: NIST SP 800-207 separates decision from enforcement; in OT this separation is essential because the PEP may be a network device that cannot run complex logic, and the policy engine must include process context that IT systems do not have.
2. What inputs should the trust algorithm use for OT access, and how should unknown or unmanageable devices be handled?
Read the worked answer
Trust algorithm inputs: user identity and role, strong authentication method, device identity and certificate status, asset criticality and safety classification, known vulnerabilities and patch level, network zone, time and maintenance window, vendor sponsorship, and behavior analytics such as new destination or unusual protocol. For OT devices that cannot authenticate, use network-based identity: MAC, switch port, VLAN, and asset inventory record, combined with a PEP that only allows the device to reach its known controller. Unknown assets should be quarantined in a limited VLAN with no production access, not trusted by default. For devices with no certificate lifecycle, issue certificates where possible; where not, use a compensating control such as an inline PEP and strict allow-lists. The trust algorithm should fail closed for new sessions but preserve existing safety-critical sessions during a policy engine outage.
Reasoning: zero trust in OT cannot rely on agents, so identity must be inferred from multiple weak signals and enforced by the network. Unknown devices are common after acquisitions; treating them as untrusted forces inventory work and prevents shadow access. The algorithm should be explicit about score thresholds and what happens at each threshold, so plant managers can see why a request is denied.
3. How should Arcadia handle vendor remote access and the previous VLAN segmentation failure?
Read the worked answer
Vendor access should go through a brokered remote-access service: the vendor authenticates to the broker with MFA, the broker checks sponsorship, ticket, and maintenance window, then opens a session through a jump host to the specific PLC or HMI. The vendor never gets a network-level tunnel into the OT VLAN. Session recording, command logging, and file-transfer controls should be enabled, and credentials should be vaulted and rotated.
For the previous VLAN failure, do not repeat a broadcast-heavy segmentation design without testing. Use a pilot line or non-production cell to measure broadcast and protocol behavior, then enforce with a PEP that allows required PLC coordination traffic while blocking unnecessary east-west traffic. Use a hybrid approach: VLANs for coarse separation, plus host-based or network-based microsegmentation where supported. Maintain a bypass and rollback path that can restore the prior path in minutes, and schedule changes with plant operations. Success metrics: vendor sessions brokered, standing tunnels removed, unknown OT assets reduced, and zero unplanned line stops during the pilot. Reasoning: the earlier failure was not a reason to abandon segmentation; it was evidence that OT segmentation must be protocol-aware and tested with operations. Vendor access is often the easiest path to reduce remote risk because it can be brokered without touching PLCs.