Ask ten people what zero trust means for an industrial plant and you will collect eleven architecture diagrams, most of them with a very confident box labeled “policy engine” sitting in the middle. Ask the same ten what happens when that policy engine meets a protection relay installed in 1998, and the room goes quiet. That silence is the subject of a recent paper by Vincenzo Calabrò, a security official at the Italian Ministry of the Interior, published by ICT Security Magazine as Zero Trust selettivo negli ambienti OT.

cover

It is written in Italian, it runs to about forty pages, and it asks a smaller and more useful question than most of the literature: not which zero trust architecture to buy, but which zero trust capabilities each class of device can realistically carry, and in what order they deserve your money.

I read it with the habits of someone who has spent two decades looking at what remains after things go wrong, and I came away with a fairly clear opinion. Let me walk you through the paper, and then tell you where I think it earns its keep.

In brief

  • Zero trust was built for laptops and SaaS, and it collides with industrial devices that cannot authenticate, host an agent, or tolerate added latency.
  • MATRIX is Vincenzo Calabrò’s six-phase method for deciding which zero trust capabilities each class of industrial asset can realistically carry, and in what order to deploy them.
  • The method’s core artifact is an allocation matrix where each capability is delivered natively, through an intermediary, through a compensating control, or explicitly “not practicable”.
  • Replaying the 2015 Ukrainian grid attack through the matrix shows its decisive moves fall exactly where the framework concentrates identity checks on critical commands.
  • The paper is honest about its limits: it is qualitative, unvalidated on a live facility, and leans on intermediary layers whose maturity varies by vendor.
  • For operators under NIS2, the matrix doubles as an evidence document that records residual risk for every asset that cannot be upgraded.

The air gap retired quietly, and nobody threw a party

For a long time, industrial security rested on a comforting story: the plant network is separate, therefore the plant network is safe. Ai miei tempi that story was even half true. Control systems lived on their own cables, spoke their own protocols, and the only people who touched them wore boots.

Then came predictive maintenance, vendors who need remote access, dashboards for the board, and the cloud. Calabrò describes how each of these multiplied the points of contact between IT and OT, turning systems that were once opaque to an attacker into reachable targets. The convergence is also covered in the magazine’s opening piece of the series, which frames the whole paper.

The evidence that isolation had failed arrived long before the cloud migration. Stuxnet, dissected by Ralph Langner in 2011, showed that malware could cross an isolated perimeter and quietly manipulate the programmable controllers driving a physical process. In December 2015 the Ukrainian power distribution companies were hit in a way that left roughly 225,000 customers without electricity, and the E-ISAC and SANS report remains the reference reconstruction of how it was done. Since then ransomware has joined the party, and the economics of extortion have turned out to be perfectly compatible with state interests when the victim is a fuel pipeline or a utility.

Zero trust is the obvious answer to a world without trustworthy perimeters. John Kindervag coined the model at Forrester in 2010, and NIST later formalized it in SP 800-207: no entity, user, device or service, is trusted merely because of where it sits on the network, and every access request is authenticated, authorized and evaluated dynamically. It works nicely when your estate is laptops and SaaS. The trouble starts when the estate includes things that cannot answer a login prompt.

Why a protection relay will never run your endpoint agent

The paper’s most useful passage, to my mind, is the short one explaining why OT turns the usual security priorities upside down. In IT, confidentiality leads the list. In OT, availability and integrity come first, because an interrupted process can mean damaged machinery, endangered people and a town without power, as described in NIST SP 800-82r3, the revised guide to OT security that Calabrò leans on throughout.

Add the rest of the picture. Latency budgets are tight, so a control that adds delay to the command chain is a malfunction, not a safeguard. Maintenance windows are rare and expensive. Many protocols were designed with no authentication at all, because connectivity was supposed to be the exception. And the devices themselves have no spare memory, processor cycles or power to host an agent, a certificate store or a crypto library. I wrote recently about Windows NT 4.0 turning thirty, and anyone who has walked through an industrial site knows that machines of that generation are not museum pieces there, they are colleagues with a pension plan.

To make this concrete, the paper borrows from research at the Software Engineering Institute of Carnegie Mellon and defines five attributes that describe how well a device can host zero trust capabilities: how dynamically it can be configured, how easily it can be retrofitted, how much room it has in size, weight and power, how much latency it tolerates, and how close it is to ordinary IT. Score a Windows-based HMI and it comes out wide on every axis. Score a legacy intelligent electronic device speaking a proprietary protocol and the profile collapses to a small dot near the center of the radar chart. The same policy cannot apply to both, and pretending otherwise is how you end up with a beautiful architecture and a plant that is still wide open where it matters.

The other piece of vocabulary you need is the Purdue model, the layered view of an industrial network that runs from the physical process at level 0, through controllers and supervisory systems, up to the enterprise network, with an industrial DMZ in between. The paper reminds us that the closer you get to the process, the stricter the real-time and safety constraints, and the less you can borrow from the IT toolbox. The IEC 62443 series turns the same layering into zones and conduits.

Six steps and one table that admits defeat

MATRIX is an acronym for six phases, and the order is the point. It starts with the mission context: before deciding how to protect anything, you reconstruct what the system is for, through the sequences of activities that deliver its purpose, and identify the data, applications, assets and services those sequences depend on. In a power distribution network that means voltage regulation, load management and fault protection, and the consequence that matters most is not a leak of historical data but a manipulated signal reaching a protection relay.

The second phase profiles asset suitability with the five attributes above. The third models threats and attack surface, mapping realistic entry points such as vendor remote access, firmware updates, USB sticks plugged into workstations and tampering during equipment delivery. The fourth, risk and tradeoff, is where OT gets its due: for every candidate control you weigh not only the risk it removes but the damage it can do to availability, safety, performance and cost. A control that adds unacceptable latency, or demands a plant shutdown nobody can schedule, is described in the paper as a new problem rather than a solution. I found that sentence worth the price of admission.

The fifth phase, implementation, produces the artifact that gives the method its name. Rows are classes of assets, columns are capabilities such as identity and multifactor authentication, microsegmentation, continuous authorization, cryptographic protection, device posture checks and centralized logging. Each cell records how the capability will be delivered, and there are only four honest answers: natively on the device, through an intermediary layer that enforces on its behalf, through an external compensating control, or not at all. In the illustrative table of the paper, workstations and SCADA servers are green almost everywhere, modern IEDs sit in the middle, legacy RTUs depend on intermediaries, and field devices at level 0 get nothing beyond segmentation and monitoring from outside.

That last category, the explicit “not practicable”, is what I find most refreshing. Most security roadmaps are written as if every box will eventually be ticked. This one writes down the boxes that will stay empty and forces someone to sign for the residual risk. The sixth and final phase, execution, turns the table into a program with a staged roadmap: baseline first, with an asset inventory, Purdue-style segmentation and basic visibility, then the cheap high-return wins like multifactor authentication and managed remote access, then logical boundaries between peers and posture checks, and only later granular enforcement and optimization. Remote access is a sensible first target. The edge appliances that broker it are the same ones that keep appearing in my reading, as in Weekly Wire #8, where one remote access product line collected five actively exploited zero-days in nine months.

Replaying Ukraine 2015 through the matrix

A framework without a test is a diagram, so Calabrò applies MATRIX three ways. He maps its phases against NIST SP 800-82r3, IEC 62443 and the Italian NIS2 implementing decree, finding no gaps in coverage. He compares it with the five-step process in the Cloud Security Alliance guidance for critical infrastructure and with the SEI work, concluding that its distinctive contribution is the allocation matrix rather than any new control. And he walks through a fictional distribution operator, NovaGrid, with a modern SCADA system sitting next to legacy equipment running a hundred secondary substations over proprietary protocols that nobody plans to replace anytime soon.

The retrospective test is the one I enjoyed most. The author takes the 2015 attack on the Ukrainian grid and lays its documented steps next to the framework. Spear phishing with a macro installed BlackEnergy 3 on corporate workstations, which maps to posture checks and IT/OT segmentation. A long reconnaissance phase harvested credentials in the absence of strong authentication. The attackers then reached the SCADA systems through legitimate remote access credentials and opened breakers by hand from compromised HMIs. They overwrote the firmware of the serial-to-Ethernet converters in the substations, wiped workstations with KillDisk, disabled backup power at the control center, and flooded the call centers with phone traffic, so that customers could not even report the outage.

The decisive moves, remote access with valid credentials and manual commands to the breakers, fall exactly where the implementation phase concentrates continuous authorization and identity checks on critical commands. The most lasting damage, the converter firmware, hit assets that cannot be upgraded, which is precisely the category for which MATRIX prescribes compensating controls and an explicit residual risk entry instead of the illusion of native protection.

What I appreciated is the restraint. The paper does not claim the framework would have stopped the attack, which no qualitative method could honestly claim. It says that applying it would have put the missing controls on the table, in an orderly way, before the attackers did. That is a more modest claim than most vendor decks dare to make, and a more believable one.

Compliance as a by-product, and what still needs proof

The sixth chapter ties the method to the regulatory load that now sits on operators in essential sectors. Under NIS2 and the Italian decree 138/2024, adequate and proportionate risk management measures are a legal obligation, management bodies answer for approving them, and significant incidents must be notified within tight deadlines, with an early warning inside twenty-four hours and a full notification within seventy-two. The paper also mentions the Italian national cybersecurity agency’s baseline measures, and for electricity the sector-specific network code on cross-border flows. Calabrò’s argument is that the allocation matrix doubles as an evidence document: for every asset it records which capabilities were applied, how, and with what residual risk, which is exactly what an auditor or a board will ask for. I have written about the other half of that duty, the moment when incident response becomes a business decision with a legal clock attached, and a documented rationale for every protected and unprotected asset makes that decision much less lonely. The broader audit pressure on organizations that rely on paperwork alone is the theme of my piece on the summer stress test under NIS2 and DORA.

The paper is also honest about its limits, and I would underline three of them. The method is qualitative, so suitability scores and tradeoff weights carry subjectivity, and two analysts without shared scoring criteria could produce different matrices for the same plant. There has been no validation on a real operating facility, only an illustrative scenario and a retrospective reading of a documented incident. And the whole allocation logic leans on intermediary layers that can translate legacy protocols and enforce policy for devices that cannot, a technology whose maturity varies a lot between sectors and vendors. The conclusions list shared scoring criteria, tooling to fill in the matrix, integration with threat intelligence and field validation as the next steps, and I would put the last one first.

Still, it is a rare thing to see a security framework that begins from the plant and not from the product catalog. Manufacturers hit by operations like the one I described in my note on Panzer ransomware and its Italian victims will not be saved by an architecture slide, they will be saved by someone who knows which machines can take multifactor authentication on Monday and which will need a fence, a tap and a very honest line in the risk register. If you run, secure or audit an industrial environment, read the full paper and try to fill in the table for your own site. The cells you cannot fill with anything but “not practicable” are your actual to-do list.

FAQ

What is the MATRIX framework for zero trust in OT environments?

MATRIX is a six-phase method proposed by Vincenzo Calabrò that maps zero trust capabilities to classes of industrial assets according to what each device can technically sustain, so controls are applied selectively rather than uniformly across a plant.

Why can’t standard zero trust controls be applied directly to industrial control systems?

OT environments prioritize availability and safety over confidentiality, and many devices have tight latency budgets, no spare memory or power, and legacy protocols with no authentication, so they cannot host agents, certificate stores, or multi-factor authentication.

Does MATRIX claim it would have stopped the 2015 Ukraine grid attack?

No. The paper claims only that applying the method would have surfaced the missing controls in an orderly way before the attackers did, and that it records residual risk explicitly for assets that cannot be upgraded.