Mattias Pilroth | Principal OT Security Architect

Compliance Has a Working Range

Sun, 06 Sep 2026 00:00:00 +0000

A plant that is run by a control system can be driven by that control system. Whatever the plant can be commanded to do, it can be commanded to do by whoever holds the commands, however they came to hold them.

Two obligations follow from that, and they are usually treated as one.

The first is to keep the commands in the right hands: to manage known vulnerabilities as fixes are published for them, to separate what should not be reachable, to govern who holds credentials, and to be able to recover when something fails. This is what the discipline is organised around. It is structured by compliance frameworks, audited on a cycle, and it does real work.

The Control Nobody Argues About

Sun, 06 Sep 2026 00:00:00 +0000

The list of controls required of an industrial operator grows between revisions and does not shorten. Items are added. Items are elaborated. What does not happen is withdrawal because a requirement turned out not to be worth having.

The documents doing the requiring sit at different levels. IEC 62443-3-3 states system security requirements and maps them to capability security levels. It is careful about its own scope: target and achieved levels belong to other parts of the series, and this document states what a system must be capable of rather than what any particular plant should aim at. It is equally careful to say that it specifies functional requirements and leaves how they are met to integrators and suppliers. NIST SP 800-82 Revision 3 wraps risk management guidance around a control overlay and tells the reader explicitly not to treat the document as a checklist, but to assess and tailor. It goes further than that. It contains a section on building an OT cybersecurity business case, with a subsection on the benefits of cybersecurity investment. The NIST Cybersecurity Framework sits higher again, specifying outcomes rather than controls and speaking directly about prioritisation, risk tolerance, available resources, and progression where a cost-benefit analysis supports it.

Independence Cannot Be Discounted

Tue, 01 Sep 2026 00:00:00 +0000

Where a configuration authority can create the initiating demand and defeat the credited safety instrumented function in the same causal sequence, that function is not an independent protection layer against that cause. Its integrity level does not entitle it to partial credit there, and a probability derived from the security measures in place is not a substitute, because it describes a different conditional event. This paper does not establish, for any particular installation, that such an arrangement exists.

Sequenced OT Resilience: A Framework for Consequence-Derived Investment

Thu, 14 May 2026 00:00:00 +0000

This paper specifies the Sequenced OT Resilience (SOR) Framework, an investment and execution model for OT resilience in brownfield industrial environments where change capacity is constrained and consequence varies across zones. The argument for why OT environments require a different investment logic from the one most programs currently use is developed in the companion paper, The Coverage Trap. This document specifies the framework that argument points toward. The SOR Framework is a correction to the investment model, not a replacement for the work already done under existing programs.

SOR Framework: Practitioner Reference

Thu, 14 May 2026 00:00:00 +0000

Framework overview

Four core constructs

Consequence ceiling — The verified architectural condition where unacceptable consequence cannot be reached through a single compromise.
Governed exposure — Every contact point assessed, documented, and owned. Three states: acceptable governed, exception-governed, ungoverned. Completion = zero ungoverned exposure within assessed scope.
Contact boundary — The governed perimeter between zones and external dependencies.
Health baseline — Indicators that confirm the system remains in its assessed state. Each specified to four fields: identity, current value, threshold, owner.

Three operating rules

The Coverage Trap

Sun, 29 Mar 2026 00:00:00 +0000

Most OT security practitioners working in brownfield industrial environments reach the same point. The program is running. Controls are being deployed. Assessments are producing findings. And yet the sense that the fundamental exposures are not being addressed does not go away. Budget cycles close without the structural conditions improving. The same gaps surface in successive assessments. The practitioner inside the environment recognises the mismatch. The institutional structures around the program have no mechanism for surfacing it. The program is active. The exposure is not materially reduced.

Silent Degradation in OT Systems

Sun, 22 Mar 2026 00:00:00 +0000

Long-lifecycle OT systems do not hold their commissioning state.

Sustained operation is not evidence of operational stability.

These systems drift. Configuration diverges from documentation. Temporary changes become permanent. Redundant paths fail one at a time without crossing the threshold that forces escalation. Diagnostic channels decay. Ownership weakens at the interfaces between systems, teams, and vendors. The environment continues to run while its actual condition moves away from the condition operators believe they are maintaining.

Why OT Infrastructure Appears Static

Sun, 22 Feb 2026 00:00:00 +0000

Industrial control systems in chemical plants, refineries, and generating stations appear static to IT and cybersecurity teams. Systems stay in service for decades. Patch levels lag. Legacy platforms outlive vendor support. Change is slow and frequently deferred.

From outside the operating context, this looks irrational. Inside the fence, it is a rational response to consequence, liability, validation limits, and funding mechanics. The inertia follows from the constraints that determine what change the plant can safely absorb.