There's huge difference between _sensors_ and _actuators_. You can put sensors online if you don't care too much about data leaking out. You put _actuators_ online... You need to be able to deal with the consequences.
If your network isn't air gapped, then it's vulnerable, and attackers will side step the "read only" path to affect control system changes.
You can't drive my car simply by pointing a webcam on the steering wheel.
My position is that if there's any connection, of any practical type, between the control system and the outside world, an attacker will be able to find ways to break things.
Even if it just boils down to "an attacker made our dashboards report numbers wrong and so we closed a valve to prevent an issue that didn't exist, and inadvertently destroyed our own product", the outcome is the same.
I would be much more worried about the human element of technology development. Namely that having a web based interface which shows data, but can’t change anything would feel unnatural. I can totaly imagine that you make the choice, implement it correctly. you have your website only showing things but unable to make changes.
A day later a product person asks for the ability to set the temperature on the web interface. You kindly and patiently explain to them that due to safety reasons you can’t implement that feature. They will understand and nod.
A month later one of the execs asks for a similar feature. They might also present the feature as mission critical, or even package it in the language of safety. After all customer X just lost so much money because we couldn’t do this one simple thing via the web interface. You argue with them and your viewpoint eventually wins. But it is a bit hard to argue because you ultimately have to argue that you / your team cannot be trusted to implement the feature safely. So you have to make it sound like you are both competent enough to be trusted with this hard decision and incompetent at making things secure enough the same time. A hard sell. But you win somehow.
Then a month later there is a hackathon. And one of the new hires puts together this amazingly looking new product UI. Everyone is amazed it is genuenly a delight to use. But it completely ignores the data diode principles. You have to kick it into the long grass, or modify it so much that it is barelly recognisable.
Then a month later a new product development start. Your company is hoping to conquer some new vertical, and need to make a cheaper version of the product. So an electrical engineer is tasked to cost optimise the control unit. They correctly point it out that we could reduce the BOM cost by more than half if only we got rid of the data diode and the second set of microcontroller. You have to argue the safety case. People nod. But you are loosing more and more “political capital”. Upper management asks you to work with the EE on how you can maintain the safety while also cutting cost. You know that this won’t be easy and the savings won’t be as much.
And so on and so on. So even if the company implements such data diode, and implements it correctly and safely. Future product and business pressures will work against it. Realistically you are not going to win every single argument about it. One day you will come back from a holiday and there will be someone who circumvented it either because they didn’t know better, or didn’t believe that they cannot be trusted to make the circumvention safe enough. It is a people problem, not a tech problem. If there is even such a distinction.
Temperature sensor is a sensor. Refrigeration compressor motor is an actuator.
GPS positioning of a car is a sensor. Motor to turn the wheel is an actuator.
Aircraft altimeter is a sensor. Motors to control control surfaces are actuators.
And so on.
It can be implemented with a fiber optics cable with only the transmitter on the secure side, a laser+photo cell for real air gap, cutting the rx cable in a rs232 or having a microcontroller with an output pin connected to another controllers input pin. By handling it with hardware instead of software you get a very secure partition between the trusted and untrusted side.
It's used to monitor for example industrial systems and power plants.
Wikipedia calls it unidirectional network: https://en.wikipedia.org/wiki/Unidirectional_network
Or, in other words, you'd expect the managers to be smart enough not to set all the fridges to 50°C, whatever data they read on their screens.
The most straightforward way to make a fridge with control over Ethernet is to slap on a 5-10 years old industrial temperature control product and wire up sensors and actuators onto it. In such cases, the industrial system that would be now 25 years by now would be running some cumulative 35 years old RTOS and Claude is going to find out it has bunch of basic buffer overflows that can make the fridge explode if exploited.
Some devices are sensors, like temperature sensors. It's not that they're "read only", it's that... You can't override temperature. For that, you need other devices. Like a switch to a motor that operates refrigeration compressor. That would be an actuator. If you put the data from the sensor online, the worst case scenario is someone unauthorized gets your data. If you build interface to control an actuator online... You can read the article up top.
The problem is that all major cloud providers (AWS and Azure for sure, and I'm sure Google as well) have a large number of services targeting IoT devices, both to read and control. So default architectural decision is "We'll just plug these into AWS IoT, it's secure, reliable, highly available, and has all the features we need, all we have to do is to configure what we want and we're all set". Which in reality is not that secure just because of how IoT is designed. But AWS/Azure obviously push for these solutions because it gives them more revenue.
Most of those companies bet on air-gapping their systems and hoping nobody cares enough to hack them