Walk into any plant floor in 2026 and you’ll see something that should be shocking - but somehow isn’t. The PLC running the line was likely designed in the early 2000s. The protocol it’s speaking was probably standardised in 1979. The HMI looks like Windows 95 had a baby with a calculator. And somewhere in the back office, a tired controls engineer is gluing it all together with VBA and ladder logic - and, probably, hopes and prayers.
And this isn’t a story about technical debt. Technical debt implies a deliberate trade-off - you took a shortcut, you know about it, and you’re planning to fix it. What we have in industrial automation is something stranger and harder to talk about: a kind of institutional fear. We are not stuck on legacy protocols because they are the best tool for the job. We’re stuck on legacy protocols because nobody wants to be the person who broke the line.
And the worst part about all of this is that the caution I’m talking about has fundamentally metastasised into something much worse - it’s become an excuse. And the people paying the price are not the vendors, not the integrators, and not even the engineers - it’s the end users. Operators, technicians, plant managers, and ultimately the customers downstream who deal with the consequences of systems that should have been retired a decade ago.
Let’s first acknowledge the obvious. Industrial environments are not consumer environments. Downtime on a production line can cost thousands of dollars per minute. A botched firmware update can take a refinery offline. Safety-critical systems - the ones keeping fingers attached to hands and chemicals contained in tanks - genuinely cannot tolerate the kind of “move fast and break things” energy that defines other parts of the tech industry.
So when people in industrial automation say “if it works, don’t break it,” there is a real reason behind that instinct. The conservatism was earned, hard, over decades of incidents, recalls, and lawsuits.
But somewhere along the way, that earned caution calcified. It stopped being a principle and started being a posture - and now, we’re no longer asking “is this risk worth taking?” Instead, we’re asking “can we get away with not changing anything?”
And to be clear, the answer to that question, increasingly, is no - because the cost of not changing has stopped being abstract. It is showing up in unpatched vulnerabilities, in integration nightmares, in workforce churn, and in the widening gap between what industrial systems can do and what their users actually need them to do.
Modbus was published in 1979. Let that sit for a second. The protocol underpinning a huge chunk of industrial communication is older than the IBM PC, older than the public internet, and older than most of the engineers running plants today. And it is still, in 2026, one of the default ways two devices talk to each other in countless facilities around the world.
This is not a takedown of Modbus, by the way - it’s a remarkable piece of engineering and the fact that it still works is a testament to how well it was designed. But “still works” is doing a lot of heavy lifting in that sentence. Modbus has no native security, no built-in discovery, no metadata, and no real concept of identity. Yes, there are ways around that - and again, this is not a teardown of Modbus, I think it still has a place in modern plants - it’s just that we have spent forty years building scaffolding around it. VPNs, segmented networks, firewalls, custom translators - all because we cannot bring ourselves to retire it.
Meanwhile, the alternatives have matured. OPC UA offers proper security, semantic modelling, and a real information architecture. MQTT with Sparkplug B gives you a publish-subscribe model that actually fits the way modern industrial data wants to flow - event-driven, contextual, and unified. These are not experimental technologies anymore. They are mature, well-supported, and deployed at scale by organisations that decided the inertia was no longer worth the cost.
The question is not whether the new protocols are good enough. They are. The question is whether the industry is willing to commit to them - and so far, the answer has been “kind of” with a half-shrugged “maybe?” tacked on.
Here’s a disclosure for you - I’m aware that the AI conversation in industrial has gotten exhausting. It is the elephant in every industrial conference room right now, and the discourse has, frustratingly, polarised into two camps.
On one side, vendors selling “AI-driven” everything, often with very little substance behind the marketing. And more on this in a moment - predictably, as a DevRel at FlowFuse, I think FlowFuse is a super notable exception to that statement.
On the other side, a kind of reflexive dismissal - “we don’t need AI, we need reliable automation.”
Both camps are wrong, and they are wrong in ways that reinforce each other. The hype camp gives the dismissive camp a reason to dismiss. The dismissive camp gives the hype camp a reason to keep selling fluff, because there is no real expectation of substance. And the people who would actually benefit from thoughtful AI deployment - predictive maintenance that catches failures before they happen, anomaly detection on noisy sensor streams, agent-driven workflows that handle the routine so humans can focus on the exceptional - are caught in the middle.
Fundamentally, AI is a tool, and like any tool it has appropriate uses and inappropriate ones. Predictive maintenance models trained on historical sensor data are not magic and they are not vaporware - they work, they have been working for years, and the organisations using them well are quietly running their plants more efficiently than the organisations refusing to touch the technology. The same is true of computer vision for quality inspection, of NLP for parsing maintenance logs, and increasingly of agentic systems that can sit alongside human operators and handle the long tail of routine decisions.
Refusing to engage with any of this is not safety. It is abdication. And ultimately, it’s not an abdication that just harms your org.
Here’s the part that doesn’t get said often enough - every conversation about industrial modernisation tends to incorrectly focus on the vendors, the integrators, the standards bodies, and the C-suite. The end users - the people who actually have to use these systems every day - rarely get a seat at the table. And it shows.
Consider for a moment two realities. In one, a technician walks up to an HMI that was designed in the last five years - clean, contextual, surfacing the information that actually matters and hiding the rest. They diagnose an issue in two minutes and move on. In the other, the same technician faces a 1995-era screen with sixty status lights, three nested menus, and documentation that lives in a binder somewhere. The same problem takes them an hour (or more), and they are frustrated and demoralised by the time they fix it.
Multiply that across every shift, every operator, every plant. The cost of bad UX in industrial is enormous, and it is paid in time, in errors, in turnover, and in the steady erosion of institutional knowledge as experienced operators retire and the people replacing them refuse to put up with tooling that feels punishing. We talk about the workforce shortage in industry as if it is purely a recruiting problem, as if we can fix it with some new marketing and some flashy logos. But the reality is that a lot of it is a tooling problem. People do not want to spend their careers fighting with software that was bad twenty years ago and has not gotten better - and it’s why a specialist who can either work in the industrial space or work in something like aeronautics is going to choose one over the other almost every single time.
I want to be clear about what I am and am not arguing for here. I am not saying rip out the existing infrastructure. I am not saying replace your stack with whatever raised a Series A last week. I am also not saying to pile AI on top of every process and hope for the best. If you’re looking for someone to tell you that the answer is just “more frontier tech, faster,” that is not what this article is about.
What I am saying is this. Bravery in industrial automation looks like a few specific, concrete things.
It looks like running real pilots of new protocols on non-critical lines and taking the results seriously, not as one-off experiments to file away. It looks like evaluating new PLC providers and software-defined platforms with the same rigour you’d apply to an incumbent, rather than dismissing them out of hand because they are unfamiliar. It looks like funding modernisation of HMIs and operator tooling as a first-class investment rather than a perpetually-deferred nice-to-have. It looks like engaging with AI thoughtfully - identifying the use cases where it actually fits, deploying it in those use cases, and being honest about the ones where it doesn’t.
And, fundamentally, it looks like being willing to own the discomfort of change rather than passing the cost of stagnation onto the people who can least afford to pay it.
Now as I said earlier, I think FlowFuse is getting this balance 100% right. Of course I’m going to say that though - I’m the Developer Relations Advocate at FlowFuse. But hear me out - actually digest what I’m about to say.
FlowFuse as a solution treats everything in your stack as a message. It is protocol agnostic - once the message is in the system, it becomes pure data. It supports ancient protocols as well as frontier ones. And importantly, it has AI that actually makes sense. You can use MCP systems to connect documentation and live data sources to the FlowFuse Expert, and then interact with that data as first-class objects. You can get maintenance reports, shift summaries, heck you can even get functional troubleshooting that doesn’t just alert you to a problem, it tells you where the problem likely lives.
And the people who use FlowFuse (and preceding tech Node-RED) are short-circuiting much of this problem - because once you abstract away the older way of doing things and start treating everything as a data point, a source of message, then you can update individual lines, test new methods, and update as you go. You can revitalise your stack without breaking your stack - and you can actually get out of 1986 and step into 2026.
For that reason I think FlowFuse is doing it right - because they support your choice to engage with the frontier. Instead of just telling you to modernise, they’re telling you that you should do that - and then giving you a practical way forward.
And I think that’s a pretty dang good model that others in the industry should be looking at - especially if you’re one of those ancient providers who look at this and balk at the idea of having more than three colours in your interface.
The thing about technical inertia is that it always feels like the safe option. Doing nothing is, by definition, the lowest-risk move on any given day. But the days add up. The protocols get older, the PLCs get more locked in, the gap between industrial tooling and the rest of the technology landscape gets wider, and the workforce that has to deal with it gets smaller and more frustrated.
Ultimately, we cannot keep treating the status quo as a default. The status quo is a choice, made every day, by everyone who decides it is easier to live with the current pain than to take the risk of fixing it. And the longer we make that choice, the harder it becomes to make any other one.
The industrial space needs to be braver. Not reckless, not credulous, not chasing every new acronym that comes out of a vendor pitch deck - but braver than the version of itself that has been hiding behind earned caution as a justification for not doing the harder work. The frontier technologies are here. The new protocols are here. The new providers are here. The end users have been waiting.
It’s time we stopped making them wait.