Old OT on the internet: not a back door, but the main entrance
This time, I want to talk to you about an often overlooked part of your IT operation that opens the door to your entire IT system.
Part 1 of this blog is about the risks of OT. Part 2 is a guide to get you started right away: forward this blog to your IT department if it gets too technical for you but you can see that your organization is at risk.
You see, your organization runs on more than laptops and SaaS. The real work happens at bridges, pumps, packaging lines, cooling installations, turbines. Operational Technology. Often extremely powerful. Often ancient. And often designed at a time when “network” meant: one closed cabinet, zero connections to the outside world.
Today, everything is connected. For convenience. For data. For cost savings. “Just” to monitor remotely. ‘Just’ to let suppliers take a look. “Just” to view your dashboards in the cloud. Until you realize that OT connection is not neutral. It is a conscious choice that poses a very high risk to your security profile.
Much OT still communicates with protocols that were never intended for the internet. Many systems run firmware that no one is allowed to touch anymore. Documentation is missing. Passwords belong to someone who has long since retired. Meanwhile, the outside world sees activity. Ha, an opportunity! And you know, curiosity is free, but the consequences... are costly.
Compare: you think the barrier to the parking lot is closed, but the doors to the factory hall are wide open. Not through a basement window, but through the entrance. With a neat doormat: “Welcome.”
Why does this happen? Because we have become accustomed to frictionless. Because “disconnected” feels old-fashioned. Because the business demands real-time graphs and the supplier demands “remote support.” And because replacement does not seem to be an option: OT lasts twenty years, sometimes longer. Downtime is more expensive than anything else.
So the question is not: “Do we have OT risk?”
The question is: “Where is it, how big is it, and who is already looking at it?”
In this blog, we zoom in on the blind spots that almost every organization has when OT and IT meet. What signs reveal that you are underestimating risks? What assumptions are you making without realizing it? And why “we've been doing this for years” is exactly what attackers hope to hear.
Be sure to read on if you think your connections are “safe enough.” Most organizations thought so too... until the headlines came.
Your OT still trusts anyone with a connector
Security by design is still lacking in many OT environments. Not because nobody wants it, but because the equipment comes from a different era. Back then, availability and speed came first. Security? Just put a firewall in front of it and you're done. The internet was external, the process network internal. Until malware learned to call outside itself. Today, an infected controller can easily make an outgoing connection to a command-and-control server, bypassing port rules that mainly think ‘from the outside in’.
Underneath that lies something even more fundamental: the communication model of much OT was never designed for hostile networks. Protocols are often unencrypted, without integrity checks, without real authentication. Everything is based on implicit trust: “if you can talk, you belong.” In a world of LAN islands, that was acceptable. In a world of supply chains, remote support, and cloud dashboards, it is a dangerous invitation.
And then there is the base layer: systems that do not speak TCP/IP at all. They communicate serially. To make them “network-ready,” the cabinet is equipped with a serial device server—the well-known Moxa-type devices—that transmits communication over Ethernet. The protocol remains what it was: blind, dumb, and docile. The outside looks modern; inside, the clock has been turned back decades. Oops.
Important detail: “old” refers to the year it was designed, not the date of manufacture. It is not unusual for brand-new laboratory equipment to be delivered today with exactly that serial heartbeat, plus an integrated converter. The marketing label says “network version”; the security says “1998.” Meanwhile, the threats of 2025 are: targeted ransomware, living-off-the-land, and attackers who understand OT-specific commands.
The result is a landscape full of implicit trust, low visibility, and high impact. Devices that silently assume every instruction is legitimate. Logging that doesn't exist or means nothing. Firmware that is ignored because every minute of downtime costs money. And a cultural legacy that still too often sees security as a disruption to the process, not a prerequisite for continuity.
Without security by design, a paradox arises: the more we connect to control and save, the greater the attack surface that we cannot see, measure, or control. This is not a marginal issue. It is the core risk of modern OT. For every sector.
Make OT managed, not accessible
OT is not IT. So don't treat it that way. The function is physical, the impact is immediate, and the tolerance for noise is zero. Security starts with design choices that remove friction for the process and add friction for attackers. Here's how to get it under control yourself:
1) Zone as if you mean it
OT should not be dangling “somewhere” in your corporate LAN. Create dedicated OT zones with their own VLANs and subnets, separate from office IT, Wi-Fi, supplier VPN, and management. Apply default deny between zones; explicitly whitelist what is really necessary. No “quickly” plugging in an access point or printer: OT is not mixed traffic.
2) Stop lateral movement before it starts
Attackers thrive on lateral jumps. Therefore, cut up “flat” OT segments and require every conversation to pass through a control point (L3/L4 policies). Only allow required <source, destination, port, protocol> pairs. OT device to OT device? Only if the process strictly requires it — otherwise, block. Use built-in host firewalls where available; otherwise, network-driven microsegmentation.
3) Install a secure front and back door
The OT itself rarely has modern security. Put what it does have in between: hardened jump servers for management, reverse proxies for application access, and where one-way traffic is sufficient: data diodes. Enforce strong authentication and least privilege at these connection points; they are your choke points and your log sources.
4) Measure what is normal, chase what is abnormal.
Trust is not control. Monitor OT traffic at the edges and within the zones. Learn what is “normal” for each asset (frequency, direction, protocol, payload size) and alert on deviations. Link network telemetry to asset inventory so that “strange traffic” can be immediately traced back to a specific device and a responsible party.
5) Limit what can break
Minimize protocols (less is better), shut down unused services, disable discovery/broadcasts where possible, and record who has access to which OT component and when. Every check mark you remove is one less attack path and one less incident you have to explain.
Key: make OT controlled, not accessible. Everything goes through a gatekeeper, nothing communicates without reason, and deviations are given priority. This limits risks, keeps your process fast, and reduces your attack surface.
Schedule your OT security check now
Your OT should be running but no longer open. If your bridges, pumps, or production lines are network-enabled without strict control, you increase your attack surface every day. Do you want data and remote insight, but without opening the front door?
Schedule a no-obligation appointment with me. In a single conversation, we will explore where your greatest exposures lie and what is needed to connect OT securely: clear zones, controlled connection points, and visibility of deviations. No theoretical talk; concrete findings, tailored to your environment and risks.
The result: you will know exactly where you are vulnerable today, what you can close off tomorrow, and how to keep your OT under control. Without disrupting your process.
👉 Do you want to make your OT securely network-enabled? Let's talk. hugo [at] sciante [dot] nl (subject: Diconnect%20OT) (Send me a message) or schedule an appointment right away.