Retrofitting Legacy Control Systems to Tackle Evolving OT Cyber Threats

Hi everyone,

I’m new to the EngX community and looking forward to learning from you all. I’d like to start a conversation about something I think many of us face and that is updating legacy control systems in power plants and other critical infrastructure, especially when it comes to growing OT cyber threats.

Lot of these systems were designed decades ago, with reliability in mind but little thought given to cybersecurity. Today, they’re exposed to new risks that weren’t imagined back then. The challenge is finding a way to retrofit these systems efficiently and without tearing everything apart or causing long periods of downtime.

In the UK, where our energy and infrastructure systems are heavily relied upon, even a small disruption can create big problems. So how do we make these updates both secure and practical?

I’m particularly interested in hearing how others have approached efficient retrofitting and what worked, what didn’t, and how you balanced the iron triangle of cost, time, quality and scope. Are there certain strategies or tools that helped modernize your systems without overhauling them completely.

Would love to hear your thoughts and experiences.

Thanks,

Taimur | MIET 

Parents
  • Hi everyone, and thank you for starting this important discussion.

    As someone working in the ICS/OT domain, I’ve seen first-hand how challenging it is to modernise legacy control systems in critical infrastructure—especially in sectors like power generation, where uptime, safety, and compliance are non-negotiable.

    You're absolutely right—many of these systems were built for reliability and longevity, not cybersecurity. But today, with increasing OT cyber threats and growing interconnectivity, we can't afford to ignore the risks. That said, a full system overhaul isn’t always feasible. I’ve found that successful retrofitting lies in balancing risk reduction with practical constraints like time, cost, and operational disruption.

    Here are a few approaches I’ve seen work in practice:

    Small blue diamond Risk-based retrofits using tools like Cyber-PHA or CyberHAZOP to prioritise high-impact upgrades.
     Small blue diamond Network segmentation and DMZs to isolate legacy equipment from enterprise IT and internet-connected systems.
     Small blue diamond Compensating controls such as protocol-aware intrusion detection, application whitelisting on HMIs, and read-only historian interfaces.
     Small blue diamond Secure remote access using jump servers with multi-factor authentication, session recording, and time-bound permissions.
     Small blue diamond Standards-based frameworks like IEC 62443 and NCSC’s Cyber Assessment Framework (CAF) to structure retrofit plans and align with regulatory expectations.

    One strategy that’s worked particularly well is the “wrapper” approach—layering modern protections and interfaces around legacy assets, allowing phased upgrades and limiting downtime. Conversely, what hasn't worked well is trying to lift-and-shift IT tools into OT environments without accounting for latency, determinism, or vendor lock-in.

    I'd be really interested to hear from others here:

    • Have you used similar strategies, or different ones that worked better?

    • What lessons have you learned in terms of balancing security, cost, and uptime during upgrades?

    - Simha

  • Hi,

    Very interesting post.

    What you would make of this option below ?

    The MQTT protocol is the only thing flowing into the IT network via the data diode. 

    Note: of course we need to have specific hardware to translate MMS (Manufacturing Message Specification) to MQTT for things like IEDs.

    OT_IT

    Updates are done via an air-gapped cloud infrastructure(on a separated connection only open at specific time slots). Basically we effectively "trip the breaker" between our office environment and our power controls.

    Cheers,

  • Humm. I rather like the idea of a "data diode" but I'm not sure how it would work in practice. Just about any reliable protocol I can think of has some means of confirming safe arrival of the data (and therefore triggering re-transmission if it didn't) - therefore needs a reverse data flow of some kind in order to operate at all. Once there's a reverse path in existence, there's the opportunity to use it for mischievous means.

    MQTT presumably runs over some other protocol (often TCP/IP but could be other I suppose) - which means you're also at the mercy of any vulnerabilities of that layer of software (and all those below it). Hopefully the day of crude memory injection simply by passing oversized packets are over, but still vulnerabilities in such layers are far from unknown. Never assume that just because something was intended to operate in some way, it can't be "persuaded" to do something quite different.

       - Andy.

  • usually 'professional'  data 'diodes' are configured per protocol much like firewalls,  and effectively spoof the acknowledgements to the sender, while keeping a local copy until the real ack is received, just in case a resend is needed after all, much as you do for things like satellite links, where the latency is very long, and the buffering over the network at the end points would otherwise be restrictive.

    The acks the sender gets are then not actually those coming in over the wider network which are just used to manage the buffer state.

    Mike

  • Hello,

    Data diode solutions use proxies on both the send and receive sides to satisfy the transport layer (i.e. TCP connection) requirements by responding with the appropriate protocol messages (acks, nacks, etc.) to the endpoints on both source and destination networks. After the send side proxy terminates the TCP session, the payload is extracted from the packets and transported across the diode. On the receive side, a new TCP session is initiated, and the packets are sent to the destination endpoint. In this way, the source (OT) side remains invisible to the external networks and endpoints but data is able to flow from the OT network to the IT network.

    How does the source network know the destination received the data?

    The source can’t ask the destination if the data was received, the destination needs to be able to determine, on its own, if it received all the data. In our case the  data diodes provide an internal validation mechanism to achieve this. The source side calculates a running hash code value that is inserted in each packet so that the destination can verify if any transmit problems exist.

    Cheers,

  • Indeed, but physically you've still got a single "box" that's capable of bi-directional communication on both sides, relying on just the software not to pass data in a particular fashion - and software can sometimes be compromised (either bugs or by malicious acts). I'm not saying it's not a useful defence - just not something to rely on as your only barrier. More part of an overall "defence in depth" approach (in the same way that firewalls would only be one layer of defence in a proper system).

       - Andy.

  • Ah, if there is a physical one-way valve, (e.g. opto) and it's not a common system fore and aft of that (e.g. same processor writing and reading from the opto pat), then that would provide more reassurance. But still, multiple layers of defence are often more reliable. Single points can and do fail.

       - Andy.

  • What is your threat model and what does it include? Are we talking about a teenage script kiddie in his bedroom scanning for open ports and running exploits or are we talking about sophisticated state-sponsored actors?

    As others have pointed out, some diodes are glorified packet filterers or firewalls and you're putting trust in a single company. This may or may not be a good idea than using open-source solutions that have a decentralised verification model.

Reply
  • What is your threat model and what does it include? Are we talking about a teenage script kiddie in his bedroom scanning for open ports and running exploits or are we talking about sophisticated state-sponsored actors?

    As others have pointed out, some diodes are glorified packet filterers or firewalls and you're putting trust in a single company. This may or may not be a good idea than using open-source solutions that have a decentralised verification model.

Children
  • Hello,

    a data diode is a piece of hardware that enforces a one-way flow of data using physics. It relies on a transmitter (like an LED) on the sensitive side and a receiver (like a photo-sensor) on the corporate side.

    Which means stream operational data out to the corporate network, but it is physically impossible for a hacker to send malicious commands in, because there is no transmitter on the receiving end to send data back.

    In our case the cyber vectors are mainly:

    • IT-to-OT Pivoting: Attackers compromise the corporate IT network , then pivot into the OT network due.
    • Exploiting the Decentralized Edge: The rapid integration of millions of decentralized renewable energy sources drastically expands the attack surface. 
    • Legacy OT Protocols: Similar to the rest of the world, older substations still rely on industrial protocols designed without modern encryption or authentication.
    All of this in a energy grid highly decentralized. Managed by four major Transmission System Operators (TSOs) and hundreds of regional and municipal DSOs.
    Who normally is attacking?
    • Nation-State Actors (APTs)
    • Cybercriminals
    • Supply Chain Threats
    Cheers,
  • I'm no expert but my understanding is that not all such hardware use one-way physical channels (see Owl_Talon_one_Card_Datasheet_V7.pdf). Even if a fiber optic cable is used, can it be independently verified that no 2-way transceiver is installed e.g. hardware backdoor?

    The concept sounds reasonable but just making the point that with security-specific customised hardware you're putting putting a lot of trust in one vendor which is potentially a target for supply-chain attacks. Same for so-called "secure element" chips.

  • no 2-way transceiver is installed e.g. hardware backdoor?

    well, in some shall we say, ' quite important'  places the fibres run from place to place in clear trunking or conduit throughout their whole length so they can be visually  inspected by security guards , who know what the installation  is supposed to look like from their previous rounds. Any extra wires or boxes would trigger the process for discovering an incident.

    Fibres can be 'tapped' unbroken by carefully bending them around a tight radius close to the snapping point, so that some of the light is scattered from the core into the cladding. This can be detected if it is over done by the reduced signal level at the far end. 


    The idea of the fully inspectable length is that any such equipment would be spotted.

    Regards,

    Mike

  • But even with a very short length of FO, how can you tell it's really only transmitting in one direction?

  • But even with a very short length of FO, how can you tell it's really only transmitting in one direction?

    Buy extras of the equipment at each end. Strip it down and see what is inside. If it's got a receiver on the transmit side, or a receiver on the transmit side, it's not a proper data diode, but something programmed to act like one.

  • Gosh, 

    this is what we have in a substation. And if I am not mistaken this is from 2019 (first generation). 

    We have "KRITIS operators" that are legally mandated to deploy specialized OT Intrusion Detection Systems.

    If a utility supplies more than a specific threshold of people, their facilities are classified as Critical Infrastructure (KRITIS). They must implement state-of-the-art security and pass strict, biennial audits by the BSI(Bundesamt für Sicherheit in der Informationstechnik).

    I would never guess that a data diode would generate so much interest... 

  • Hello,

    When the network is built, they(companies like LANCIER) record a "Golden Trace" (a snapshot of the healthy fiber.) Then normally you have Remote Fiber Test Systems (RFTS) managed by companies like LANCIER.That runs an OTDR(Optical Time-Domain Reflectometer) test automatically every few minutes. It overlays the new trace on top of the Golden Trace. If a new "event" (dip/spike) appears that wasn't there yesterday, the system triggers a silent alarm and emails the GPS coordinates of the new event to the administrator of that DSO(Distribution System Operators) area.

    Cheers,