DIGITAL BUSINESS,TECH NEWS

How Organisations can keep the Lights On

Protecting OT is now a top priority because a successful attack doesn’t just steal data, it can turn off the lights.

October 22, 2025

Steven De Mot, Business Development Manager for OT at Fortinet

 

Operational Technology (OT) refers to any hardware and software that monitors and controls physical processes in industries such as manufacturing, energy, utilities, and transportation. These sectors are in the spotlight of both hackers and regulators (NIS2). Its importance has surged in recent years as industrial systems have become increasingly connected to corporate networks and the internet. This convergence of IT and OT boosts efficiency and data-driven decision-making but also exposes vital physical systems to cyber threats. Protecting OT is now a top priority because a successful attack doesn’t just steal data, it can turn off the lights.

We spoke to Steven De Mot, Business Development Manager for OT at Fortinet.

 

“Patching or unpatched?” has become a topical question in Luxembourg following the recent cyberattack in the summer of 2025. Can you implement protocol-aware virtual patching for unpatched local controllers and remote data collectors? If yes, how do you achieve this without slowing down networks?

“We can definitely assist, but what we do is never going to be a replacement for actual patching, which is still necessary. When we talk about operational technology that is running 24/7, you don’t have a patching window. Typically, you can only deploy patches after you have approval from your specific vendor, and for this, you need a lot of things to fall into place before you can actually patch. So what we can do in the meantime is virtual patching, which means we identify devices, and we see traffic passing through the network. We understand from which vendor the device is, this enables us to do a lookup in our patch management databases, and we can see if we have known vulnerabilities for this device. The third step is making sure that the actual exploitation of this vulnerability never reaches the device. We are basically a man in the middle stopping the attack using our intrusion prevention system, which we’ve also made OT-aware. We understand OT-specific protocols for these devices, and we use those two things combined to do our virtual patching. That’s definitely something our customers are actively using in these windows between when the exploit appears and when a patch for the asset is available.”

 

If an organization has thousands of remote sites, how can it effectively segment data flows within industrial units between the shop floor and the business environment? As a remote CISO, what’s your advice on tracking and addressing threats in real time?

“There’s a lot of questions in one go, but I’ll have a stab at it! For most larger businesses, you typically have an IT part of the business and a production site. We ensure that traffic between IT and OT is properly segmented, and you do that by implementing one layer of firewall. But a lot of our customers are thinking beyond that and are saying, ‘I’m not going to use the same firewall I use for internet-facing traffic for my IT and production environments.’ Suddenly, this becomes a dependency for OT, and for efficient OT operations, you need as few dependencies as possible. For 24/7 production environments, you don’t want dependencies, so we build an additional layer of firewalls — typically an internet-facing firewall and then an IT/OT segmentation layer on the other side of the network. This acts as a Demilitarized Zone (DMZ), where you can have a safe exchange of traffic.

Historically, companies talked a lot about the air gap, and in some organizations, physical separation between IT and OT still exists — fortunately so, because in the most critical environments it’s needed. However, for organizations that operate in connected environments, we segment between IT and OT in a safe way, enabling communication between the two worlds while creating as few dependencies as possible. That’s basically the first step when you think about architecture. For distributed organizations, we build an advanced network to interconnect all these sites. It’s a key business question to identify if you need your IT interconnected between different sites, or if your OT environments also need to be connected. Are they dependent, for example, do you have a distributed electricity network where you want management of the control systems from a central area, and you don’t have people in the field? You will then have to build a Software-Defined Wide Area Network (SD-WAN) specifically for your OT environment. We build the security layer on top of what you’ve done, then integrate event management that connects easily to the firewall. This all feeds data to the FortiAnalyzer, which is your central place to monitor all your logs and correlate different events from various sites. It can all happen in that central space.”

 

Many companies struggle with third-party or contractor access to their networks. What specific controls should be enforced for vendor access, especially in low-bandwidth regions?

“This is probably the hottest topic on the market at the moment. When I look at the projects we are running in Belgium and Luxembourg, it’s definitely on everyone’s radar — and that makes sense. In Belgium, we have a cyber fundamentals framework released by the government that is very clear about what you should be implementing. But if you are somewhere else, you could very easily look at, for example, ISO 27001 or IEC 62443 (the gold standard in OT security) if it’s OT-specific. The rules are quite clear: you must have control over who is connecting, what they’re connecting to, what credentials they are using, and whether you have a proper approval workflow. When can they use them, and when they actually want to use them, can someone in my organization responsible for the specific asset approve the connection? After the fact, can you prove what they actually did? Do you have a video recording of what they did? Do you have searchable logging so you can look for specific commands? These kinds of things, I’d say at a high level, are the main requirements. Make sure that you can control the connections and review them later, because that’s really something I see auditors asking for everywhere now: ‘prove to me that what they said they did is actually what they did in your environment.’ Don’t forget that every device within the IoT scope that needs to be online all the time — even air conditioning, door-opening systems, or CCTV software — if it is using legacy hardware, will still need the same security.”

 

We often hear devices described as “rugged.” What does that really mean in practice, and how do you manage secure updates for such devices?

“When we develop hardware, for example firewalls, switches, and access points for IT environments, we make them suitable for certain conditions. We test them to ensure they can withstand vibrations. If you use them on a ship — where I used to work, in the maritime industry — there’s a lot of vibration. A 30,000 brake horsepower engine running continuously creates strong vibrations, so these are the kinds of constraints you need to work around. That’s basically what ‘ruggedized’ means. And it doesn’t stop there. You also need specific certifications — typically ATEX certification when working in explosive environments, or industry-specific ones such as IEC 61850 for electrical applications. We perform these certifications for our ruggedized products.”

 

On threat detection and response, which OT protocols are natively parsed for DPI? And what is the workflow or latency for coordinated response across firewalls, NDR, and SOC tooling?

“We support basically all the industry-standard protocols, from transport to utilities. We have combined them all in our OT Security Service license that you can get for our firewalls, which also supports deep packet inspection. We don’t just recognize — we can also look through packets to confirm it’s actually valid traffic. We also check exploits for those protocols, investigating as deeply as checking which value is being sent to which machine. You can actually set thresholds — for example, say that a pump should never receive a value higher than 10 — and we’ll block it if it does. That’s how we ensure security at the network level.”

Watch video

In the same category