Why New IIoT Hardware Still Ships with Modbus

Walk into almost any factory built in the last forty years and you will eventually find Modbus.

Sometimes it is hiding behind the door of an electrical cabinet on a terminal block nobody has touched since commissioning. Sometimes it is running through kilometres of RS-485 linking pumps, drives and PLCs. Sometimes it is travelling inside Ethernet frames across a network that also carries the site CCTV.

None of that is remarkable. Old kit is old kit, and industry keeps old kit running.

What is remarkable is that manufacturers are still adding Modbus to equipment being designed right now, in 2026, for products that will ship in 2027 and still be in service in 2045.

Think about that for a moment. Mobile networks have gone from analogue through 2G, 3G, 4G and 5G, with 6G already being argued about in standards meetings. Wi-Fi has been through seven generations. USB has changed its connector three times and its mind more often than that. Even HDMI is on its umpteenth revision.

Yet a protocol published by Modicon in 1979 is still one of the first things an engineer checks for on a datasheet. Not as a legacy tick-box. As a primary interface.

Modbus did not survive because it won. It survived because nobody could work out how to make everyone stop.

That is the interesting bit, and it is not really a story about a protocol at all. It is a story about how engineering decides what is worth keeping, and about how consistently clever people underestimate how hard it is to replace something that is merely good enough.

1979: a solution to a problem that no longer exists

To understand why Modbus is still here, you have to understand what it replaced, because the thing it replaced was genuinely awful.

In the 1960s and early 1970s, a factory control system was relay logic. Physical relays, wired into panels, implementing the process logic in copper and contacts. If you wanted to change how a machine behaved, you rewired a wall. Commissioning took months. A modification took weeks. Fault-finding took a torch, a multimeter and a strong sense of humour.

The programmable logic controller fixed the logic problem. Bedford Associates built the Modicon 084 for General Motors in the late 1960s, the eighty-fourth project the company had taken on, which is where the number comes from. Modicon stood for Modular Digital Controller. Now you could change the process by editing a program rather than rewiring a panel.

But it created a second problem. Once you have several intelligent controllers scattered across a plant, plus a supervisory computer that wants to know what they are doing, you need them to talk. And in the late 1970s, the only way to do that was still more wiring, or a proprietary link that only worked if every device on it came from the same vendor.

In 1979, Modicon published Modbus. A multidrop messaging interface with one master issuing requests and multiple slaves responding. It ran over RS-232 initially, and quickly settled onto RS-485 because RS-485 gave you distance, speed and true multidrop on a pair of wires.

Two decisions made in 1979 are the entire reason we are still talking about it in 2026.

Decision one: they gave it away

Modicon published the spec. No licence fee, no royalty, no membership required, no certification body standing at the door with an invoice. Any manufacturer could implement Modbus in their device and nobody could stop them or charge them.

In 1979 that looked like Modicon giving away an advantage. In hindsight it was the most commercially astute thing anyone in industrial networking has ever done, and it was almost certainly an accident.

Decision two: they made it stupid

I mean that as a compliment. Modbus has a data model you can fit on a beermat: coils, discrete inputs, input registers, holding registers. Bits and 16-bit words. That is the lot.

There is no object model. No type system beyond “sixteen bits”. No discovery, no negotiation, no session management, no subscription mechanism. A master asks for a range of registers, a slave hands them over, and everyone gets on with their day. The whole protocol data unit maxes out at 253 bytes.

That mapped almost perfectly onto how a PLC’s memory was organised anyway, which meant implementing it cost a device manufacturer almost nothing. An eight-bit microcontroller with a couple of kilobytes of ROM could speak Modbus. In 1979 that mattered enormously. What nobody realised at the time is that it would still matter in 2026, because there is always a new class of device at the bottom of the market where a fraction of a penny of BOM cost decides the design.

The wire nobody could beat

Here is something the protocol comparisons never account for, because they compare protocols.

Modbus did not survive on its own. It survived bolted to RS-485, and RS-485 is the genuinely brilliant part of the arrangement. If you want to understand the stubbornness of the whole edifice, this is where to look, because the protocol is replaceable in principle and the wire mostly is not.

RS-485 is differential. It does not send a voltage referenced to ground, it sends the difference between two conductors in a twisted pair. Interference from a contactor slamming shut, a VFD switching, or forty metres of parallel mains cable hits both conductors more or less identically, and the receiver subtracts one from the other. The signal survives. The noise cancels itself.

That single property is why a bus you installed in 2003 still works in an environment that would flatten anything single-ended. It is also why nobody has ever needed to replace it.

What you get for a pair of wires

• Distance. Around 1,200 metres at modest baud rates. Not 100 metres like Ethernet. Not 15 metres like RS-232. Over a kilometre, on cable you can buy anywhere, terminated with a soldering iron.
• Multidrop. Thirty-two standard unit loads on a segment, and modern fractional-unit-load transceivers push that considerably higher. One pair, daisy-chained through every device on the run. No switch, no star, no patch panel, no IP addressing scheme, no VLAN.
• Common mode tolerance. The receiver copes with a substantial ground potential difference between one end of the run and the other, which matters enormously on a site where the earth at the pump house is not quite the earth at the switchroom.
• No power budget. A transceiver costs pennies and almost nothing in current. There is no PHY, no stack, no negotiation.

Compare that to what industrial Ethernet asks of you. Managed switches. Segment lengths measured in hundreds of feet. A cabinet full of things that need firmware updates and IP addresses and eventually a network engineer. All of which is entirely correct if you are synchronising nine servo axes. All of which is preposterous if you want to read a kilowatt-hour counter in a substation eleven hundred metres away, once a minute, for the next twenty years.

There is a twenty-year-old RS-485 segment on more sites than I can count where the Windows box polling it has been replaced six times and the bus has never been touched.

That is the actual story. Not that the protocol is durable. That the layer underneath it never developed a reason to change.

Three generations who were certain they had killed it

Modbus has been on its deathbed since roughly 1985, and the industry has produced an obituary about once every three years since. What I find genuinely funny is not that they were wrong. It is that each generation was wrong in exactly the same way as the last, while being completely convinced the last lot had simply not tried hard enough.

Generation one: the fieldbus wars

Modicon went first, which is the detail everyone forgets. Modbus Plus arrived in the 1980s as a token-passing network, faster and cleverer than serial Modbus and thoroughly proprietary. The company that invented Modbus tried to replace Modbus and could not. It sold well. It is not what your new energy meter speaks.

Then came the fieldbus wars, and they were wars. Profibus. DeviceNet. Interbus. CANopen. Foundation Fieldbus. ControlNet. Every one of them was technically better than Modbus in ways that were trivial to demonstrate on a slide. Deterministic timing. Device profiles. Cyclic data exchange. Configuration tools that knew what a device was, rather than which registers it happened to have.

The engineers who built these were not fools and they were not wrong about the technology. They were wrong about one thing: they assumed the industry was capable of choosing. Every fieldbus arrived with a consortium, a membership fee, a conformance test, a stack licence and a vendor with a strategic interest in the outcome. Which meant that specifying one was never an engineering decision. It was a bet on a market, placed by someone who would be blamed personally if the market went the other way.

And so the safe answer, on every mixed site, for every specifier who wanted to still be employed in five years, was to also support Modbus. Just in case. The fieldbuses did not fail. They won their niches and left the fallback in place. The fallback ate everything that was not a niche.

Generation two: industrial Ethernet does it again

By the late 1990s the previous generation’s mistake was obvious to everybody, and the new generation had learned precisely the wrong lesson from it. The problem, they concluded, had been the wiring. Ethernet was cheap, fast and already everywhere in the office. Put the plant on Ethernet and the fragmentation goes away.

Ethernet arrived. The fragmentation did not go away. It moved up a layer and got worse.

EtherNet/IP, Profinet, EtherCAT, Powerlink, Sercos. Same cable, same connectors, entirely incompatible protocols, several of which quietly break standard Ethernet to get determinism. All genuinely excellent for machine control. All still camps you have to join. Identical error, better cabling.

Modbus, meanwhile, did the one thing none of them did. In 1999, Modbus TCP took the existing protocol data unit, wrapped it in a seven-byte header and put it on port 502. That was the whole change. Same function codes. Same register model. Same everything above the wire.

It was not ambitious. It was not clever. It meant twenty years of installed knowledge, tooling and drivers upgraded to Ethernet for free, while everyone else was asking the industry to learn a new thing. Guess which one the market took.

Generation three: IT arrives and makes the same mistake in a different accent

The current generation came from outside the plant, which was supposed to be the advantage.

OPC UA is a serious piece of engineering and I want to be fair to it. It has a proper information model, security designed in from the start, and it genuinely solves the semantic problem that Modbus does not even acknowledge exists. On the sites that have implemented it properly, it is the right answer. It is also heavy, and it never went into the twelve pound temperature transmitter, and the twelve pound temperature transmitter is where most of the devices are.

Then MQTT and Sparkplug B, arriving from the IT side with event-driven publish-subscribe instead of the endless polling, which is a legitimately better architecture and I will defend it. But look at what the industry actually did with it. It did not replace Modbus with MQTT. It bought a box that speaks Modbus at the bottom and MQTT at the top.

Eleven replacements in forty-seven years. Every one still in service. Not one of them ever became the thing you could assume was already there.

That is the pattern, and it repeats because each generation looks at the previous failure and concludes the previous lot picked the wrong technology. They did not. They made the wrong assumption. All three generations assumed convergence: that the industry would eventually all pick the better thing, pay the transition cost once, and be done.

There has never been a moment when everybody was replacing everything at the same time. There is always a brownfield. There is always a panel from 2004 that still works, still holds pressure, still passes inspection, and the business case for touching it is exactly zero. Convergence requires a coordinated pause that industry has never once managed and never will.

So they all won something. Profinet and EtherNet/IP own machine control. Foundation Fieldbus and Profibus PA own process instrumentation. BACnet owns building HVAC. EtherCAT owns motion. OPC UA owns plant-wide integration where the site has its act together. Every single one of them is a success.

Modbus won the thing none of them wanted, which was being the lowest common denominator. In a permanently multi-vendor world, that turns out to be the most defensible commercial position on the board.

Modbus is not good

I want to be blunt about that, because there is a strain of nostalgia in this industry that mistakes survival for merit, and I am not writing that article.

It polls, which is wasteful by design. It has no concept of what its own data means. Its model is 16-bit, which was fine when everything was an integer and is a running sore now that nothing is.

And then there are the specific, stupid, load-bearing annoyances that anyone who has actually done this work is already nodding at.

The off-by-one that has cost more engineer-hours than any other design flaw in industrial networking

Holding register 40001 in the documentation is register address 0 in the protocol. The convention with the leading 4 is a data model notation, not an address, and the two are offset by one. Half the vendors document one way, half the other, a good number document both inconsistently in the same PDF, and absolutely nobody says which they meant. Every Modbus integration on earth begins with reading a value that is nearly right, being briefly pleased, and then realising it is the register next door.

The byte order that is only half specified

The spec says big-endian for a 16-bit value. It says nothing whatsoever about which register comes first when a 32-bit float spans two of them. So every vendor picked. Some picked one way, some the other, some picked differently between two products in the same catalogue. This is why every gateway on the market has a dropdown offering you ABCD, CDAB, BADC and DCBA, and why the correct engineering procedure is to try all four and see which one produces a temperature rather than a number with an exponent in it.

The frame that is delimited by silence

Modbus RTU has no start byte and no end byte. Frames are separated by 3.5 character times of quiet on the bus, and characters within a frame must not be separated by more than 1.5. It is elegant on a UART with nothing between it and the wire. It falls apart the moment you put a buffering USB-to-serial adapter in the path, because the adapter batches bytes on its own schedule and your beautiful timing-based framing dissolves. Which is why the cheap adapter works on the bench and does not work on site, and why every engineer over a certain age owns one specific adapter that they do not lend to anyone.

The register map that exists as one photocopy

The protocol carries no semantics, so the meaning lives in a document. In a healthy world that document is a PDF on the vendor’s site. In the real world it is a spreadsheet somebody made in 2011, saved to a laptop that has since been wiped, and the only surviving copy is a photocopy in the maintenance folder in the switchroom, annotated in biro by a contractor who left in 2016. That biro annotation is load-bearing. It is the only record that registers 30044 to 30046 are not what the printed map says they are, because the panel was modified.

I am not exaggerating for effect. This is a normal Tuesday.

And there is no security. None whatsoever. We will get to that.

So why is it winning?

Because engineering values things that technology commentary does not measure.

A protocol that is good enough and works everywhere beats a protocol that is technically superior and works in half the market. That is not a compromise or a failure of nerve. In an industry where a chiller has a thirty year service life and the company that made it may not outlive it, that is the correct engineering answer, and the people making it are not being conservative. They are being right.

Modbus is what you use when you cannot assume anything about the other end. And you can never assume anything about the other end.

The register map is the actual product

If you want the single clearest evidence that Modbus is not a legacy hangover, stop looking at old industries and look at solar.

Photovoltaics has no brownfield problem. Utility-scale solar barely existed when Modbus TCP was already twenty years old. The inverter industry got to design its data interfaces on a clean sheet, with no installed base to appease, at a moment when OPC UA and MQTT were both mature, well documented and actively promoted by people with budgets.

It picked Modbus. Deliberately. In this century.

The SunSpec Alliance defined standard Modbus register maps for inverters, meters and other distributed energy resources, so a monitoring platform could talk to any compliant device without a vendor-specific driver. And that is the whole trick, sitting in plain sight. Not a new protocol. A published register map on top of the old one.

Which is the thing all eleven replacements missed.

Modbus was never the product. The register map is the product. Modbus is just the agreed way to fetch it.

Every replacement attacked the transport, because the transport is the visible bit and the bit you can benchmark. The actual problem was always semantics, and semantics is a social problem, not a technical one. It is solved by an industry agreeing what a thing is called and writing it down. You do not need a new protocol for that. You need a table and enough people to agree to it.

Solar worked that out. So did battery storage, EV charging, building submetering and CHP, each of which has ended up with some flavour of the same arrangement: publish the register list, everyone implements it, and the 1979 protocol carries it because the 1979 protocol is already in the silicon and costs nothing to include.

Once you see it that way, “Modbus is old” stops being an argument at all. Modbus is not a technology choice. It is a calling convention. Nobody complains that a function call is old.

Who kept it alive

Nobody owns Modbus, which means nobody markets it, which means the ecosystem that sustains it is invisible unless you go looking. It runs in four rough tiers, and not one of them would have designed it.

The controls vendors

Schneider Electric ended up owning the Modicon name, which is a decent piece of irony given how much of Schneider’s own portfolio competes with the thing Modicon gave away. Siemens, ABB, Omron, Mitsubishi Electric, Delta, WAGO and Phoenix Contact all support Modbus alongside their own preferred protocols, and every one of them would rather you used theirs. They support it anyway, because a controller that cannot talk to a third-party meter does not get specified, and getting specified is the whole game.

Modbus is the interoperability tax these companies pay to be allowed in the room. They have been paying it for four decades and none of them can stop, because the first one to stop loses the tenders.

The long tail nobody writes about

This is the tier that actually holds the population, and it has no famous names in it at all.

Variable frequency drives. Power meters. Temperature controllers. Weighing indicators. Gas detectors. Pressure transmitters. Level sensors. Soft starters. Inverters. UPS. Generator controllers. Thousands of manufacturers, most of whom you have never heard of and never will, all shipping RS-485 Modbus as standard because their customers expect it and it costs them the price of a transceiver and a few kilobytes of firmware to provide.

If you want to know why Modbus will still be here in 2040, it is this tier. Not the big vendors. The four hundred pound flow meter that needs a data interface and cannot afford a stack.

The industrial networking layer

Moxa, Red Lion, HMS Anybus, Advantech, ICP DAS, Westermo, Contemporary Controls. Serial device servers, protocol converters, remote I/O, edge controllers.

This entire tier exists because the plant floor never converged. That is its commercial reason for being. Every one of these companies is, in a sense, monetising the failure of generations one and two, and Modbus is usually one side of every conversion these boxes perform. They are unglamorous, expensive relative to their component cost, and completely load-bearing.

The cellular gateway generation

This is the newest tier and the most relevant one for our readership. Teltonika, Robustel, Milesight, InHand Networks, Four-Faith, Digi International and others took the protocol conversion job and added the thing every earlier tier had assumed you already had: a network.

That single addition changed the addressable market completely. A protocol converter is useful when you have a control room and a cable run to it. A cellular gateway with a Modbus master, an MQTT client and a VPN is useful when the asset is a pump station eleven miles from anything, a solar farm in a field, or a battery container in a car park with no fixed line and no prospect of one.

From serial converter to edge platform

The gateway tier deserves more attention than it gets, because it has quietly become the most interesting box on the site and it happened in stages that nobody announced.

Stage one was the serial device server, roughly the late 1990s. A dumb pipe. RS-485 in, TCP socket out, no understanding of what was passing through it. It did not know it was carrying Modbus. It was a cable extender with an IP address, and it was enough, because all anyone wanted was to move the SCADA host into a different building.

Stage two was the protocol converter. Now the box understood Modbus. It could be a master on one side and a server on the other, translate RTU to TCP, and increasingly convert Modbus to something else entirely: BACnet, EtherNet/IP, Profinet. This is where Moxa, HMS and Red Lion made their names, and it is still a large and healthy business.

Stage three added the network, which is the cellular generation. Now the box has a modem, a SIM, a firewall and a VPN client, and the asset no longer needs to be near anything. This is the point at which telemetry stopped being a civil engineering problem.

Stage four is where we are now, and it is a genuine change in kind rather than degree. The gateway has become a small Linux computer that happens to have serial ports.

Containers, so you can run your own code next to the poll cycle without asking the vendor’s permission. Node-RED, which has done more for practical industrial integration than any enterprise platform I can name, because it lets the person who understands the process wire up the logic without a software team. A local MQTT broker, so the site keeps working when the link is down. Local scripting. Increasingly, small inference models running against the register data before it goes anywhere.

Which means the interesting question is no longer “what protocol does it speak”. It is “what does it do to the data between reading it and sending it”. And that is a question almost nobody writes down properly.

What actually happens inside the gateway

Everyone draws the gateway as a box with an arrow going in and an arrow coming out. Here is what is actually in the box, in order, because this is where the engineering lives and where most of the integration failures happen.

1. The poll cycle

The gateway is a Modbus master. It has a list: device address, function code, start register, quantity, interval. It works through that list on a schedule and starts again.

The instinct is to poll fast. Resist it. RS-485 at 9600 baud is a shared medium with one conversation at a time, and every request has a response, a turnaround delay and 3.5 character times of mandated silence before the next frame. Poll thirty devices every second on one segment and you will not get thirty responses per second, you will get timeouts, and the timeouts will be intermittent, and you will spend a fortnight on it.

Match the poll rate to the physical process. A tank level does not change meaningfully in 200 milliseconds. Neither does a building’s chilled water temperature. The number of sites polling a thermostat at high frequency because that was the default in the config file is genuinely depressing.

Group your reads. One request for registers 40001 to 40020 is one transaction. Twenty requests for one register each is twenty, and it is the same data.

2. The map

This is the step that matters and the step people skimp on. Register 40012 becomes chiller_2_supply_temp. That is not cosmetic. That is the moment the data acquires meaning, and it should happen at the edge, in the cabinet, once, rather than in six different dashboards in three different tools by four different people who each guessed slightly differently.

The map is where the scaling lives too. The device reports 2347 and means 234.7 degrees, because a 16-bit integer cannot hold a decimal point and the vendor’s solution was a divide-by-ten you will find on page 31. Apply it here. Do not let a raw integer into your platform and hope somebody remembers.

And this is where the byte order fight happens. Two registers, one 32-bit float, four possible orderings, one correct answer. The gateway’s dropdown exists because of a gap in the 1979 specification that will never be closed.

3. The filter

The naive gateway publishes everything it reads. If you poll a hundred registers every five seconds, that is 1.7 million messages a day, of which perhaps four thousand contain information.

Deadbanding is the fix: only report a value when it has moved by more than a threshold, or when a maximum interval has elapsed regardless, so the platform can tell the difference between “unchanged” and “dead”. Set the deadband above the sensor’s noise floor or you will publish the noise floor, forever, at cellular data rates.

This is the single largest lever on cost in a cellular deployment and it is a checkbox most people never open.

4. Store and forward

The link will drop. Not might. Will. A gateway that discards readings during an outage is a gateway that produces a dataset with holes in it, and in the regulated sectors a hole in the dataset is a compliance problem rather than an inconvenience.

So the gateway buffers to flash, timestamps at the point of reading rather than the point of publishing, and forwards the backlog when the link returns. That distinction between reading time and publishing time is not a detail. Get it wrong and after every outage your historian shows a flat line followed by a vertical wall of readings that all claim to have happened at 14:32.

5. Publish

Northbound, over MQTT with TLS, into a broker and then into whatever is consuming it, whether that is a historian, a dashboard, a platform like ThingsBoard, or a model looking for anomalies. Increasingly the payload is Sparkplug B rather than bare JSON, which adds the state awareness that lets the consumer distinguish “the value is unchanged” from “the gateway has gone”.

By this point the data has a name, a unit, a timestamp, a scale and an encrypted path. None of which Modbus provided. All of which happened in a box on a DIN rail eleven miles from the nearest office.

Where it actually is

Readers who work in one vertical tend to assume Modbus is a quirk of their own patch. It is not. It is the connective tissue of the built environment.

Buildings, which is bigger than anyone thinks

Building management deserves its own heading because the scale of it is routinely underestimated, including by people who work in it.

The received wisdom is that buildings are BACnet. And the controllers are, mostly. But BACnet stops at the controller, and Modbus owns nearly everything hanging off it. The chiller has a Modbus interface. So does the boiler, the CHP unit, the generator, the UPS, the water treatment skid, the pool plant, the AHU inverters, and every single one of the electricity submeters, which in a large building means hundreds of devices on their own dedicated RS-485 runs going back to a panel in a riser cupboard.

The BACnet to Modbus gateway is one of the most reliably specified items in the entire building services industry, and it exists because two protocols both won and neither could finish the job. A modern BMS integration is, in practice, a Modbus integration with a BACnet fringe.

And then the energy retrofit market arrived and made it worse in the best possible way. Every building being metered for net zero reporting is being metered over Modbus, because the meters were already there, or because the cheapest compliant meter on the market has RS-485 and nothing else.

Everywhere else

• Water and wastewater. Pump stations, reservoirs, treatment works. RTUs polling flow meters and level sensors over RS-485, backhauled over cellular, buffering locally when the link drops, because the link always drops.
• Energy monitoring and submetering. If it counts kilowatt hours and reports them to anything, it almost certainly has a Modbus register map. This is very likely the single largest population of Modbus devices in existence.
• Solar PV. Inverters, string monitors, weather stations, revenue meters. SunSpec register maps over Modbus TCP or RTU.
• Battery energy storage. BMS, PCS, meters and site controllers. New industry, new hardware, 1979 protocol, no apology offered.
• CHP and generation. Engine controllers exposing hundreds of registers, polled by whatever is doing the dispatch.
• EV charging. OCPP handles the back office. Modbus handles the meters, the load management and the site controller.
• Manufacturing and food production. Line-side data collection, OEE, utilities monitoring, everything the PLC is too busy to care about.
• Oil, gas and utilities. Wellhead RTUs, pipeline telemetry, substation devices. Often over spectacularly poor links.
• Agriculture. Irrigation controllers, grain monitoring, environmental sensing.
• Rail, traffic and smart cities. Signalling peripherals, roadside cabinets, street lighting controllers, air quality stations.
• Environmental monitoring. Regulatory reporting equipment, where a data gap is a legal problem rather than an inconvenience.

The common thread is not age. It is that in every one of those sectors, the asset outlives the software, the vendor mix is never under one company’s control, and the person integrating it inherits decisions made by people who left the business a decade ago.

The part with no defence

Everything above is a defence of Modbus. This section is not.

Modbus has no authentication, no encryption and no integrity protection. The CRC in an RTU frame catches line noise, not malice. Any host that can reach a Modbus TCP server on port 502 can read any register on it and write to any coil it likes. There is no login. There is no concept of a user. The device does what it is told because in 1979 the only thing that could tell it anything was already inside the fence.

That was a reasonable assumption when network security meant a padlock on the substation door. It is not a reasonable assumption on a converged IT and OT network, and it is an actively dangerous one on anything with a public address.

The Modbus Organization did respond. In 2018 it published the Modbus Security specification, wrapping Modbus TCP in TLS with X.509v3 certificates for mutual authentication and role information carried in a certificate extension, running on port 802 rather than 502. It is a sound piece of work.

Adoption has been thin, and the reasons are instructive. Partly it means running a PKI across a device estate historically commissioned by an electrician with a laptop and a fortnight. Partly TLS costs processing budget that the bottom of the market does not have, and the bottom of the market is where the devices are. And partly because the industry had already solved the problem well enough by other means, which is that you do not secure Modbus. You contain it.

There is also nothing at all for serial. There is no TLS on an RS-485 bus and there is no realistic prospect of one. If someone has physical access to that pair, they own the bus, and the only control you have is the lock on the cabinet.

None of that fixes Modbus. It makes Modbus irrelevant to the threat model by refusing to let it near anything hostile. Which is, if you are honest about it, exactly what our industry does with every other insecure thing it cannot afford to replace. We do not fix them. We build a wall and agree not to discuss it.

What happens next

I am not going to tell you Modbus is being replaced, because I would be the twelfth person to say that and the first eleven were wrong.

What is changing is its job description.

For most of its life Modbus was the whole path. A SCADA host polled a device and that was the architecture, end to end, one protocol. What is happening now is that it is being pushed down to the field layer only, with something else carrying it upward, and the gateway is where the handover happens.

Edge compute makes the connection more important, not less

There is a comfortable assumption that if the gateway does the processing, the link matters less. The opposite is true. Once you filter at the edge, you send fewer messages, and every one that goes is a message somebody acts on. You have replaced a high-volume, low-consequence stream with a low-volume, high-consequence one. The link stops being a data pipe and starts being a decision path, and the connectivity underneath it matters more than it did, not less.

Sparkplug B wraps it rather than replacing it

Sparkplug B is the most credible thing to happen to this problem in years, precisely because it does not try to be a fieldbus. It sits on MQTT, adds state awareness, birth and death certificates, and a topic namespace that means something. Gateways that poll Modbus and publish Sparkplug are doing the translation the industry actually needed, which was never “replace the wire” but “give the data a name before it leaves site”.

Note what that is. It is generation three finally learning the lesson generations one and two never did: do not try to replace the incumbent. Sit on top of it and make it useful.

The unified namespace is the register map argument again

Everything the UNS movement argues for is what SunSpec did to solar, generalised. Publish the meaning, agree the structure, stop caring what the transport is. Modbus is perfectly happy underneath a UNS. It has no opinion about anything. That is its superpower and always was.

AI at the edge inherits the same registers

Every anomaly detection model running on a gateway in 2026 is being fed by a Modbus poll cycle. The model is new. The data source is forty-seven years old. Nobody in the pitch deck mentions this, and the model does not care, because a float is a float regardless of how undignified its journey was.

Forty-seven years, and counting

Consumer technology and engineering have never wanted the same things, and we keep judging one by the other’s standards.

Consumers replace a phone every three years and treat the old one as an embarrassment. A water company expects a pump station to run for thirty and treats replacement as a failure of planning. Those two worlds produce completely different definitions of the word “obsolete”, and Modbus only looks obsolete if you are holding the wrong one.

It is not fashionable. It is not elegant. It was not designed for security, it was not designed for the cloud, and it was not designed for a world where the device at the other end of the wire might be attacked by someone on a different continent who has never seen a pump. Every criticism levelled at it is true, and I have levelled most of them myself, in this article, at some length.

And every day, millions of Modbus transactions move quietly through factories, treatment works, substations, solar farms, hospital plant rooms, grain stores and roadside cabinets, doing the job. Not because anyone chose it recently. Because in 1979 someone published a specification, charged nothing for it, and made it simple enough that stopping was never worth the effort.

That is not a technical achievement. It is a much rarer thing: a standard that solved a real problem and then had the good sense to get out of the way.

Three generations of engineers have built something better and watched it not matter. Not because their work was poor. It was excellent. Because they were solving the problem in front of them, and the problem in front of them was never the actual problem. The actual problem was that industry cannot stop, cannot coordinate, and cannot agree, and the only thing that survives those three conditions is the thing that asks nothing of anyone.

Nearly fifty years on, Modbus has become one of the most successful engineering standards ever created. Not because it was right. Because it was there, and it never stopped being there.

Have a look at the next piece of industrial kit that lands on your desk. Check the interfaces. It will be there too.