I recently attended a Fortinet event focused on Operational Technology (OT) and IoT security.
Coming from a network architecture background, one thing that stood out to me was how different the priorities of OT environments can be compared to traditional IT networks.
In IT, we are used to thinking about patching, authentication, encryption, segmentation, endpoint protection, and regular security updates.
In OT, the priority is often much simpler:
Keep the system running.
And sometimes, that creates a very different security challenge.
OT Was Built to Be Trusted
Many OT environments were designed years ago with the assumption that the systems and devices inside the network could be trusted.
A PLC, controller, sensor, or industrial workstation was expected to communicate with other trusted devices.
The mindset was often:
If the system tells me to do something, I do it.
That works well when everything inside the environment is trusted.
The problem starts when that same environment becomes connected to modern IT networks, remote access systems, cloud platforms, or the internet.
The old assumptions no longer hold.
OT Is Different From IT
One of the biggest challenges with OT is that availability is extremely important.
You cannot always simply reboot a PLC, install an update, or replace an old workstation just because a vulnerability has been discovered.
Some systems may be running continuously.
Some devices may be using legacy operating systems.
And some equipment may be difficult or even impossible to patch without affecting production.
For example, an industrial machine may still depend on an old Windows PC to configure or control it.
The security team may see an outdated operating system.
The operations team sees:
“This machine is working. Don’t touch it.”
Both sides have a valid point.
That’s why securing OT requires a different approach.
The Problem With Flat IT and OT Networks
One of the things that caught my attention was the risk of having IT and OT environments connected without proper segmentation.
A flat network can make it easier for an attacker to move from one environment to another.
For example:
IT → OT → PLC → Industrial Process
If an attacker compromises an IT workstation and the network provides broad access to OT systems, the attack may no longer be limited to stealing data.
It could potentially affect an actual physical process.
This is where network architecture becomes important.
Segmentation, controlled communication, visibility, and well-designed remote access are not just security concepts.
In OT, they can become part of protecting the physical operation itself.
Remote Access Can Become a Weak Point
Remote access is another interesting challenge.
Operations teams need remote access for monitoring, maintenance, troubleshooting, and vendor support.
But poorly designed or overly trusted remote access can become a path into the OT environment.
This is especially concerning when there is limited visibility into:
- Who is accessing the environment
- What they are accessing
- When they are accessing it
- Which protocols are being used
- Whether the connection is properly secured
Remote access should not simply mean:
“The user can connect to OT.”
It should mean:
“The user can securely access only what they need, for the time they need it.”
Visibility Is Critical
Another important lesson for me was visibility.
You cannot protect what you don’t know exists.
OT environments can contain PLCs, HMIs, sensors, controllers, engineering workstations, medical devices, legacy systems, and many other devices.
Some may not even be well documented.
This makes asset inventory extremely important.
You need to understand:
What devices do we have?
Where are they?
What are they communicating with?
What protocols are they using?
Which systems are legacy?
Which systems are critical?
Protocol visibility is especially important because OT networks may use protocols that are very different from what traditional IT teams normally see.
For a network architect, this changes the question from simply:
“Is the device connected?”
to:
“What is the device actually doing on the network?”
Unencrypted Protocols
Many OT protocols were not originally designed with modern cybersecurity in mind.
Some protocols may have little or no encryption or authentication.
That means traffic could potentially be observed or manipulated if an attacker gains access to the network.
Again, the reason isn’t necessarily that OT engineers ignored security.
These protocols were designed for a different time and a different threat model.
The challenge today is that these systems are now connected to much larger and more interconnected networks.
Don’t Forget the Internet
Another interesting point was the existence of internet-connected industrial devices.
Tools such as Shodan demonstrate how much information about internet-connected devices can potentially be discovered.
This highlights an important security principle:
If a device doesn’t need to be exposed to the internet, don’t expose it.
This becomes even more important for industrial systems.
A PLC or industrial control system generally shouldn’t be treated like a normal internet-facing server.
Patching Isn’t Always Simple
In IT, patching is usually part of the normal security lifecycle.
In OT, patching can be much more complicated.
Before applying a patch, teams may need to consider:
- Will the application still work?
- Is the PLC compatible?
- Does the vendor support the update?
- Can the system be taken offline?
- Is there a maintenance window?
- What happens if the patch causes an outage?
This is why OT security cannot simply be:
“Patch everything immediately.”
It needs to consider risk, availability, safety, and operational requirements.
OT and Healthcare: IoMT
The same concept extends beyond factories.
Healthcare environments are another area where connected devices can introduce significant risk.
This is where IoMT — Internet of Medical Things — becomes important.
Think about medical devices, patient monitoring systems, imaging equipment, and wearable devices.
The consequences of a security incident can go beyond data loss.
It can potentially affect:
- Patient safety
- Data privacy
- Business continuity
- Revenue
- Brand and reputation
And once again, legacy technology makes things more complicated.
Some medical equipment may depend on older operating systems or specialized software because the equipment itself has a much longer lifecycle than a typical IT workstation.
You might have a modern network surrounding a medical device that still relies on a legacy Windows PC.
Replacing the PC isn’t always as simple as installing a newer version of Windows.
The software, drivers, medical equipment, and certification requirements may all be connected.
What This Means for Network Architects
For me, the biggest takeaway from the event wasn’t a specific security product.
It was the importance of architecture.
OT security needs to start with understanding the environment.
Before talking about security controls, we need to understand:
Assets → Connectivity → Communication → Risk → Segmentation → Access
We need visibility first.
Then we can design appropriate controls around the environment.
The architecture also needs to recognize that OT is not simply another VLAN inside the network.
It has different requirements.
Different protocols.
Different availability requirements.
Different lifecycles.
And potentially much higher consequences when something goes wrong.
Final Takeaway
One thing I took away from the event is that OT security isn’t just about protecting computers.
It’s about protecting the systems that operate the physical world.
Factories.
Utilities.
Healthcare.
Transportation.
Industrial processes.
And increasingly, connected devices around us.
The challenge is that many of these systems were never designed for today’s threat landscape.
So the goal isn’t necessarily to replace everything overnight.
It’s to understand the environment, improve visibility, reduce unnecessary exposure, segment critical systems, control access, and gradually bring security into an environment that was originally built around trust and availability.
The technology may be different, but the networking principles still matter.
Know what you have.
Know how it communicates.
Control who can access it.
And design the network so that one compromised system doesn’t become a compromise of everything.