Mattias Pilroth
OT security architecture
I arrived at security architecture through operations. That origin determines what I treat as demonstrated and what I treat as assumed.
The consequence question
A plant run by a control system can be driven by that control system.
Security work reduces the opportunity to acquire that authority and limits the cost when compromise succeeds: vulnerabilities removed, access governed, boundaries maintained, and recovery prepared. That work is required, it does real work, and it is what the discipline is organised around.
It leaves a separate question, and not because the work is done badly. What can the plant be driven to if it is not enough, and does anything stand between that and a consequence the operator cannot accept? A programme executed perfectly still does not answer it. Across most operational technology, no standard lifecycle deliverable requires the answer.
Where everything a compromise can reach is recoverable and an acceptable loss, no separate answer is owed, and the programme is the correct instrument for it. Where it is not, something else has to stand between that reach and the outcome, and the programme does not supply it.
The two are not the same question. One is a programme: broad, continuous, maintained, and attested through evidence that controls are present and operating. The other is a demonstration: bounded around a named outcome, and capable of being shown wrong. A compliance programme answers the first. No accumulation of control attestations closes the second.
The second question is narrower than it sounds. State the outcome that must not occur. Identify the pathways by which one compromised authority can reach it. Establish that something the same authority cannot also defeat stands in the way. Test the bound, and repeat when the plant or an assumption supporting it changes.
Where a site relies on a credited safety instrumented function, the question has a specific form: whether one authority can both create the demand on that function and defeat it.
Demonstrated, assumed, or ruled out. No required review determines which.
The work
Argument
Keeping the commands in the right hands is one question, answered by a programme attested for presence and maintained continuously. Establishing what the plant can be driven to is another, and across most operational technology no standard lifecycle deliverable requires the answer. Where compliance governs, it governs correctly. What it cannot establish is that an unacceptable outcome is bounded.
Where one configuration authority can create the demand and defeat the credited safety function in the same causal sequence, that function is not an independent protection layer against that cause. Its credit cannot be discounted into the scenario. Against that specific cause, it is lost, not reduced.
Context
OT environments appear static. Their slow rate of deliberate change follows from how they were validated, funded and operated, while their actual condition continues to move. Security strategies that ignore those constraints will be overridden by them.
OT systems do not hold their commissioning state. They drift silently, without producing signals that demand correction. Security controls inherit the operational conditions on which they depend; their presence does not establish that those conditions still hold.
About
My background runs from field automation engineering and EPCM project delivery in oil and gas and petrochemicals, through six and a half years of operational responsibility for the full OT estate at a SEVESO-classified chlorovinyl production facility, to enterprise OT security architecture across 14 chemical manufacturing sites in 8 European countries. It includes work with control and safety instrumented systems under the IEC 61511 lifecycle, and with the network, identity and platform infrastructure that carries authority across the IT and OT boundary.
Contact: mattias@pilroth.com