Choosing an Architecture Method for IT/OT Convergence With Unpatchable Assets
Aurora Components runs 14 manufacturing plants whose control networks were historically air-gapped at Purdue levels 0 through 3. A corporate program now streams plant telemetry to Azure for predictive maintenance, with a board mandate to have all 14 plants connected within 12 months and a stated goal of reducing unplanned downtime, not producing compliance artifacts. Roughly 300 PLCs are safety-critical: they cannot be rebooted without a plant shutdown costing about USD 180,000 per day and requiring six weeks of notice, so their effective patch latency is six to eighteen months. Three previous security architecture attempts produced documents that nobody used and no architecture repository survives. The enterprise architecture group mandates TOGAF ADM for all architecture work, the security team has proposed SABSA, and an external consultancy is selling zero trust as 'the architecture'. The CISO must settle the method before the first plant design is approved, and the first plant gate is in five weeks.
1. Recommend the architecture approach. Justify it against the decisions this architecture actually has to support, and explain how the competing frameworks should be positioned relative to each other.
Read the worked answer
Start from the decisions, not the frameworks. This architecture has to settle four things: where the IT/OT boundary and its enforcement points sit; which data leaves each plant, in what direction, and through which conduit; what compensating controls substitute for patching on 300 safety-critical PLCs; and who accepts the residual safety and availability risk. Any method that does not produce traceable answers to those four is the wrong method, regardless of its popularity.
Recommendation: TOGAF ADM as the process wrapper, SABSA for the security content, zero trust as a pattern applied selectively, and zone/conduit modeling for the OT domain.
- The enterprise architecture group already mandates TOGAF ADM, and fighting that costs political capital for no architectural gain. Use ADM phases A through H as the engagement lifecycle, and use the Architecture Requirements Specification and Architecture Definition Document as the vehicles for the four decisions above.
- SABSA supplies what TOGAF lacks: a chain from business attribute (plant uptime, personnel safety, product quality) through to security services and controls, layer by layer. This is precisely the traceability the three failed attempts lacked, and it is why those documents were unused: they described controls without connecting them to a business driver a plant manager would fund.
- Zero trust is a design pattern, not a method. Apply it to the IT side, the cloud analytics platform, and identity for engineers and vendors. Do not apply it to the safety instrumented zone; 'never trust, always verify' does not resolve a safety function that must operate when the network is unavailable, and forcing it there will be rejected by the plant engineering authority and should be.
Deliverables tied to gates: a target reference architecture, a pattern library (cell/zone gateway with one-way telemetry egress, remote vendor access broker, OT asset inventory integration), and an architecture decision record per plant. Each of the four decisions produces an ADR with options, rationale, and named acceptor. Publish the pattern library so plant two through fourteen reuse rather than re-litigate, which is the only way to hit a 12-month, 14-plant deadline with a small team.
2. Turn the 'PLCs cannot be rebooted' constraint into architectural requirements and compensating controls. What must the architecture assume, and what would you refuse to accept?
Read the worked answer
Treat patch latency as a design assumption, not a defect. If the realistic patch window is a scheduled shutdown with six weeks of notice, the architecture must remain safe with PLC firmware 6 to 18 months behind. Write that into the requirements as: no security control whose correctness depends on PLC firmware currency; no inbound network path to level 0-2 required for any business function; the safety function must be provable with the network fully down.
Resulting requirements:
- Telemetry egress is one-directional. A data diode or a unidirectional gateway, with protocol break at the boundary, so no session can be initiated from Azure into the plant.
- Conduits are enumerated and each has an owner, an allowed protocol (for example OPC UA with a defined profile), and a documented business purpose. Default deny between zones.
- The historian and DMZ broker terminate sessions; no direct PLC-to-cloud path.
- Asset inventory of OT devices is maintained from passive monitoring, since active scanning can disturb legacy controllers.
Compensating controls, in order of value: network segmentation and conduit control (the highest-value control here, because it removes reachability rather than detecting misuse), protocol-aware deep packet inspection at the conduit, passive anomaly detection on mirrored traffic, vendor-supported virtual patching on the boundary firewall for known PLC vulnerabilities, hardened and monitored engineering workstations (the usual actual attack path), and a controlled remote-access broker with session recording and time-bound approval for vendor support instead of standing VPN access.
What I would refuse: any design that depends on patching PLCs on a business timetable; any inbound path justified only by convenience; and any risk acceptance signed by the program manager rather than by the plant general manager together with the safety authority, because the consequence being accepted is a safety and availability consequence, not an IT one. Also refuse a blanket 'zero trust inside the cell' claim that cannot be demonstrated during a network-down test.
3. The board wants reduced unplanned downtime, not compliance artifacts. How do you make this architecture measurable and durable after the program ends?
Read the worked answer
Baseline first, or the claim is unfalsifiable. Before plant one connects, capture per plant: unplanned downtime hours and cause codes for the prior 12 months, mean time to detect an OT anomaly, count of inbound paths into levels 0-2, count of standing vendor remote-access accounts, and percentage of OT assets with a known owner and firmware version. These become the outcome and control baselines.
Outcome measures that plausibly link to the architecture:
- Reduction in unplanned downtime attributable to predictive maintenance, with fault classification agreed in advance so the credit is not claimed for unrelated causes.
- Mean time from telemetry anomaly to maintenance work order, which is the actual value chain the board is buying.
- Number of inbound paths to level 0-2, target and holding at zero; this is the single cleanest indicator that the boundary is real.
- Percentage of plants built from the reference pattern without a bespoke exception, which predicts both cost and residual risk.
Control measures that prove the boundary still works: quarterly conduit recertification (a conduit with no current business justification is disabled), a network-down test per plant demonstrating the safety function operates and the plant fails safe, and time-bound vendor access with zero standing accounts.
Durability mechanisms: architecture conformance review at each plant gate with a documented waiver route; the pattern library versioned and owned by a named architect; a two-plant pilot with a fitness review that explicitly asks whether the pattern should change before scaling to twelve more; and an annual architecture review that reports the measures above to the same committee that approved the program, so the architecture stays attached to the outcome it was funded for rather than decaying into a document set.