Trending Topics
Trending
Thomas Plank, CEO of Tributech: “Blind trust is exactly what an attacker who manipulates data relies on”
Cyber attacks on critical infrastructure do not need to steal data or disable systems to cause damage. Manipulating a sensor reading or operational command can be enough to disrupt a physical process, a risk that grows as industrial operators connect legacy equipment to cloud platforms and AI systems.
Thomas Plank, CEO of Tributech, argues that organisations must look beyond who can access their networks and establish whether the data and commands flowing between equipment, IT systems and AI models can be trusted. With AI agents increasingly able to change configurations and adjust equipment settings, proving data integrity is becoming both an operational and regulatory concern.
Tributech addresses this through cryptographic data verification and secure remote commands. Its collaboration with IBM is intended to bring these capabilities to industrial organisations globally, combining Tributech’s technology with IBM Consulting’s security expertise. The aim is to help operators protect data across connected environments, including assets communicating over cellular and satellite networks, without having to replace existing infrastructure wholesale.
In this interview, Plank discusses why Zero Trust needs to extend to operational data, how organisations can adopt AI without increasing the risk of physical disruption, and why proving data authenticity is becoming a board-level responsibility.
You argue that the next major threat to critical infrastructure may be the manipulation of operational data rather than the theft of it. What does a realistic attack of this kind actually look like, and why might existing security controls fail to detect it?
Theft takes something from you, but your operation still runs on the truth. Manipulation leaves everything in place and changes what is true. Nothing gets locked, nothing stops, and the plant keeps running on data and commands that are no longer genuine. We’re now seeing the very building blocks for that attack showing up in live environments, with AI making it cheaper to assemble.
Step one is access and patience. Dragos’s 2026 OT Cybersecurity Year in Review describes adversaries moving beyond pre-positioning to actively mapping control loops and learning how a process behaves so they can manipulate it later. It also documents specialisation: Dragos observed one threat group, SYLVANITE, handing off established footholds to another, VOLTZITE, to enable deeper OT intrusion. That’s an operating model built for the long game, not a smash-and-grab.
Step two is AI compressing the work. In May, Dragos published its analysis of an intrusion into a municipal water utility in Monterrey, Mexico, first reported by Gambit Security. Without being asked, the attacker’s commercial AI tools flagged a SCADA gateway as a high-value target and worked out an access path towards the IT/OT boundary. That attempt failed, and Dragos assessed that the AI-built tooling would only have succeeded where basic security measures were missing. Then in August, the NSA, CISA, FBI, DOE and EPA issued an advisory, AA26-231A, describing it as the first US government advisory to state that attackers are using AI-generated scripts against OT. The scripts are disguised as legitimate monitoring tools and are capable of reading and writing PLC memory and logic. They are being used for reconnaissance and capability development against US-based Siemens PLC installations. The agencies warn that AI dramatically reduces the expertise and time needed to build working ICS exploits.
Step three is the manipulation itself, and it doesn’t need to look like an attack. Centrii’s recent GRIDLOCK study models this for battery storage: attackers use the remote, often cloud-based platforms that dispatch battery fleets to manipulate charge and discharge commands. No battery needs to be damaged, and no generation needs to stop. Yet the model finds that compromising around 400 units, roughly 29 per cent of UK battery capacity, could be enough to trigger a cascading blackout. As Centrii’s CEO points out, a battery swinging from full charge to full discharge is exactly what these assets are paid to do, so a malicious command looks like a legitimate one.
Why does it go unnoticed? First, most operators can’t see the layer where it happens. Dragos reports that only around 30 per cent of OT networks have visibility, and 56 per cent can’t see below the IT/OT boundary. Second, even good monitoring answers a different question. Firewalls and identity controls decide whether a connection, device or user is allowed. Detection platforms are built to answer, ‘is something happening on my network?’, not ‘is my data still true?’. They can flag that a write or command took place. But when it comes from a legitimate-looking tool over an authorised channel and the value is plausible, they can’t tell you whether that value is genuine. Many of the most widely used industrial protocols carry no proof of origin or integrity. So almost nothing in a typical OT stack can show that a reading is the one the sensor actually produced, or that a command is the one an operator actually issued.
And even after the event, you may not be able to reconstruct what happened. Last December, attackers reached a Polish heat-and-power plant serving around 50,000 residents through a private mobile network, spent a week on reconnaissance, and then shut down a steam turbine and the water treatment system. The operator first put it down to a contractor’s mistake. CERT Polska’s follow-up report, published in August, says the analysis took more than three months. The attacker had damaged the device it used to get in, and the plant’s own recovery, resetting controllers to factory settings and reloading logic backups, deleting the logs that remained on them. If a loud attack can leave that little evidence, a quiet manipulation designed to look like normal operation could be close to invisible. That’s the version that worries me. The first symptom isn’t an alarm. It’s a decision, or a blackout, based on data and commands nobody can prove are genuine.
AI systems are increasingly being introduced into industrial and critical-infrastructure environments. How does the use of AI change the consequences of a compromised sensor, dataset or operational command compared with traditional IT environments?
In traditional IT, a compromised dataset usually means a breach: sensitive information is exposed, and the cost is financial, legal or reputational. In industrial environments, data drives physical outcomes: safety, equipment, product quality and the environment. And AI’s role is changing. For years it was an advisor. A model predicted a failure or suggested a better setpoint, and an operator decided what to do. Increasingly, models and AI agents write setpoints back to control systems themselves, sometimes every few minutes and without a human approving each change. That changes the consequences in four ways.
First, it removes the human sense-check. An experienced operator might look at an odd reading and say, ‘That can’t be right.’ A model generally can’t tell well-crafted manipulated data from real data. It makes the wrong decision with full confidence, at machine speed. An attacker doesn’t need to touch the AI at all, only the data it reads.
Second, it makes corruption persistent. If manipulated data gets into training or retraining pipelines, the model doesn’t just make one bad decision. It learns a distorted version of reality and carries that forward, long after the original intrusion has been cleaned up. That is very hard to detect after the fact and very hard to unwind.
Third, it creates new ways for a command to be wrong, some of them before any attacker is involved. A hallucinated parameter, a prompt injection hidden in a document or ticket an agent processed, or a command sent to the wrong asset can all end up at a device. In IT, a bad AI output is a wrong answer on a screen. In a closed loop, it’s a valve position.
Fourth, it widens the blast radius. A single compromised sensor in a traditional setup affects one control loop. The same sensor feeding an optimisation model can influence scheduling, maintenance, energy trading or quality decisions across a whole site or fleet.
So, the question for any AI in an operational setting is no longer only ‘is the model good?’ There are two questions. Can I prove the data it learns from and acts on is genuine? And can I prove every command it issues is authorised, unaltered and within engineering limits before it reaches a device? Without both, you are automating trust you haven’t earned.
Zero Trust has largely focused on verifying users, devices and network access. What would it mean in practice to extend that principle to the data and commands moving between IT and OT systems?
Zero Trust has done a good job of asking ‘who are you?’ and ‘should you be on this network?’ What it has mostly not asked is ‘is this piece of data, or this command, exactly what its source produced, and has it been altered on the way?’ Extending Zero Trust to data means treating operational data and every instruction as untrusted until they can be verified.
In practice, that comes down to a few things. Data is cryptographically signed as close to its point of origin as possible, ideally on the device or at the edge. Each signature is tied to a known, verified identity. As the data moves through gateways, brokers, historians and cloud platforms, any system that consumes it can check that signature independently, rather than trusting whichever hop handed it over. Commands going the other way, from IT or cloud back down to the plant, get the same treatment: an instruction is only acted on if it can be shown to come from an authorised source and to be unchanged.
Encrypting the channel isn’t enough on its own, because channel security works hop by hop. TLS or a VPN protects data between two endpoints while the session lasts. But at every gateway and broker along the way, the data is decrypted, often translated between protocols, then re-encrypted and passed on. Whoever controls that hop can see and change it before the next session protects it again. Every individual hop can be properly secured and the data can still arrive altered. Many legacy devices can’t run modern cryptography at all. And a session can’t testify afterwards: six months later, in an audit or an investigation, it offers no evidence of what the data was when it left the source.
What’s needed is proof that travels with the data rather than with the connection. Data should be fingerprinted at the earliest point of integration, in a way every downstream system can verify end to end, however many hops, protocols and networks it has crossed. That proof should also stay verifiable for as long as the data matters. The result is an auditable chain of custody in both directions. Data carries proof from its source to every decision made on it. Commands carry proof from whoever issued them to the asset that executes them. Before a command runs, it is checked: who sent it, that it hasn’t changed on the way, and that it falls within policy and engineering limits. It is then recorded in an audit trail that can’t be repudiated afterwards. None of this replaces network segmentation or identity controls; it closes the gap they leave. Even if an attacker gets inside a trusted zone, they can’t alter verified data without it showing, and a forged or modified command sent through that channel is rejected before it reaches the asset.
This is the problem we work on at Tributech. We notarise operational data as close to its source as possible and keep the proof independently of the systems that carry it. Integrity can then be verified at every stage, from the edge to the AI model, and long after the fact, by the operator or by a third party such as an auditor or investigator.
Legacy OT systems were often designed around very different assumptions about connectivity and security. How can operators modernise these environments and introduce cloud and AI capabilities without effectively creating new attack paths into physical processes?
Most OT assets were designed for a world where the network was the perimeter, and the perimeter was the plant fence. Many of the protocols they use have no built-in authentication or integrity checks at all. Every time we connect those systems to the cloud, to analytics or to AI, we extend a trust model that was never meant to leave the building.
The instinctive response is to wall it off, but walls leak. An air gap rarely stays an air gap, because there’s always a reason someone needs a way back in: remote maintenance, updates, a vendor who needs access. A data diode is genuinely one-way, but the environment around it often isn’t once VPN jump hosts and remote-access tools are added alongside it. Stopping modernisation isn’t realistic either. Many critical assets sit in remote locations where you can’t keep people on site, and the operational benefits of connectivity and AI are too large to forgo.
Operators also can’t simply rip and replace. A turbine controller or a water-treatment PLC can have a service life of 20 or 30 years. So, the approach has to be additive, and I’d stage it: start at the boundary, then extend towards the source.
Start at the boundary. The point where OT data leaves the plant, and where commands come back in, is where risk concentrates and where you can act without touching a single controller. Sign data as it crosses that boundary and verify every command before it’s allowed back through. Everything upstream (cloud platforms, analytics, AI) then works with verifiable data, and every write-back is checked for authenticity and against engineering limits.
Then extend towards the source. The boundary proves what happens after data leaves the plant, not before. So, over time, move verification closer to the asset: onto gateways and edge devices, and ideally into device firmware, so a value is fingerprinted the moment it’s generated. This matters most for remote assets connected over 4G, 5G or satellite. You don’t own that network, so you can’t build a wall around it. Take a remote pumping station or substation that reports over a carrier network and receives setpoint changes back the same way. If someone alters a setpoint in transit, the consequence is physical. This year’s attack on a Polish heat-and-power plant came in through a private mobile network. The most reliable protection is verification that travels with the data and the command.
Two design principles make this safe to introduce into critical operations. First, the integrity layer must never become a new single point of failure. Verification should run in parallel with the operational data flow, so the process keeps running even if the verification channel doesn’t. Second, it should be deployable in the operator’s own environment, so sensitive operational data stays under their control.
Done this way, modernisation can actually reduce risk, because you’re adding a layer of verification the original environment never had.
There is an obvious tension between the speed at which organisations want to deploy AI and the level of assurance required in safety-critical environments. Where should organisations draw the line between experimentation and putting AI in control of operational decisions?
I’d draw the line around consequence and access, not around the technology. A useful way to think about it is three levels.
At the first level, AI advises. It analyses, forecasts and recommends, and a qualified human makes the decision. Organisations should experiment here aggressively. The value is high and the risk is contained, but only if the experiment itself is built properly.
That caveat matters more than most people think. The risk I see most often doesn’t come from a model making a bad decision. It comes from what was opened up to make a pilot work: a new network path into the plant, broad service credentials, write permissions granted ‘temporarily’ because the demo needed them. So before asking what an AI system can do, ask what it has been given access to. Even at the first level, every AI application should have its own identity and read-only access to only the data it needs, with no route to write anything back. Too many industrial AI pilots start outside security’s view, the same way shadow IT always has.
At the second level, AI acts within tight bounds. It adjusts setpoints or schedules within limits engineers have defined, and conventional safety systems remain fully independent. This is where most organisations should be heading in the next few years, but only once they can show four things. The data the model relies on is verifiably authentic. Every command it issues is verified and checked against engineering limits enforced outside the AI. Its actions are logged and attributable. And there’s a tested way to fall back to manual or deterministic control.
At the third level, AI controls decisions where an error could cause physical harm or a safety incident. That requires the same level of assurance we demand of any other safety-critical system. Today, very few organisations can provide that evidence for AI, and that is fine. It’s not a reason to stop. It is a reason to build the assurance first.
The biggest mistake isn’t moving too fast. It’s moving beyond the first level without security on board. A recommendation engine gets wired into an automated workflow, its read access quietly becomes write access, and the security team finds out afterwards, if at all. Security needs to be involved as early as the business, so it can set guardrails rather than be dragged in once decisions are made. Organisations need a deliberate gate at each transition, with security as a party to it, and verified data and verified commands should be conditions for passing it.
If you were responsible for the cybersecurity of a major energy, water or manufacturing operation today, what is the one assumption about the integrity of your operational data that you would want to challenge first?
The assumption that data from inside my network is trustworthy because it comes from inside my network. More broadly, I’d challenge the habit of assuming at all.
We recently ran a tabletop exercise built around a compromise of an OT environment. The phrase we heard more than any other was ‘I assume’. I assume the reading is right. I assume the command came from the control room. I assume nobody has touched the historian. Each assumption sounds reasonable on its own. Together they amount to blind trust, and blind trust is exactly what an attacker who manipulates data relies on.
The industry data says the same. In a Rockwell Automation study published last month, 46 per cent of the industrial organisations surveyed had experienced a cyber incident in the past year, yet 90 per cent were confident they could prevent, contain or recover from one. That gap is what assuming looks like.
Almost every OT environment carries this belief somewhere. If a value arrives from a known device on a segmented network, people assume it’s genuine. But being inside the network says nothing about whether a reading is accurate or unaltered. It only says where it came from, and often not even that reliably.
So, I’d start by assuming compromise and asking my team one question. If our environment were compromised right now, possibly without us knowing, what could we still trust? For our most critical process values and commands, can we prove that what we’re seeing is what the sensor actually measured, and that what reaches the asset is what an operator actually sent? Not ‘do we believe it’ or ‘has anything alerted’, but ‘can we prove it’. In most organisations today, the honest answer is no.
That’s the shift: from assuming to verifying. It doesn’t require boiling the ocean. Start with the handful of data streams and commands that drive safety-relevant or high-value decisions, make them verifiable, and expand from there. Once you can prove your data and commands are genuine, you no longer have to assume. You can act with confidence, and so can everything built on top, including AI.
You might also be interested
About The Author
