Why can some critical infrastructure not be patched?

Some technical debt sits in end of life technology that simply cannot receive updates, as the NCSC acknowledged in its guidance on preparing for a vulnerability patch wave.

Is an old system automatically insecure?

No. An old system is not automatically insecure. The risk rises when it is connected to something it was never designed to talk to.

Does US air traffic control still use floppy disks?

The underlying story is real, but it applies to a handful of legacy subsystems, not the whole network. The FAA has started replacing legacy display systems with E IDS, aiming for 435 sites by the end of 2028.

What did the GAO find about FAA air traffic control systems?

In September 2024 the GAO found that 51 of 138 systems were unsustainable and 54 were potentially unsustainable. Of those 105 systems, 58 had a critical operational impact on safety and efficiency.

Do nuclear power plants run on COBOL?

No. Plants use a mixture of analogue instrumentation, programmable logic controllers, embedded systems, industrial control platforms and increasingly digital instrumentation and control systems. COBOL is a business data processing language rather than a control language.

07 Nov 2026 Cyber

When Critical Infrastructure Cannot Be Patched: The CVE Wave Meets Legacy Systems

By Andrew Baker · Group CIO, Capitec Bank · 7 November 2026

1. Yes, the Floppy Disks Are Real (But Not Everywhere)

The video opened with the claim that American air traffic control runs on Windows 95 and floppy disks. It sounded like the kind of thing that gets repeated until everyone believes it, so I went looking. The story turns out to be real, but the headline version is wrong in a way that matters. Radar, flight data processing and controller radio do not run off floppy disks. The floppies live mostly in a family of supporting information display systems, the screens that show controllers weather, equipment outages and operational notices. Those systems matter and they are genuinely ancient, but they are one slice of a very large network rather than the whole thing.

In mid 2025 the then acting FAA Administrator Chris Rocheleau told Congress the plan was to replace the system outright, with no more floppy disks or paper strips. Then on 5 November 2026, two days before I sat down to write this, the FAA announced it had started replacing four legacy display systems, some dating back to the 1980s, with its new Enterprise Information Display System (E-IDS). The first sites are the airports at Atlantic City, Nashville and Rochester plus data hubs in Atlanta and Salt Lake City, and the target is 435 sites by the end of 2028. What struck me most was the timeline. The contract was awarded to Leidos back in 2020, and until the current push the FAA was expecting to finish installing it in 2034. That is up to fourteen years to replace a set of display terminals.

{
  "type": "bar",
  "data": {
    "labels": ["Original plan", "Accelerated plan"],
    "datasets": [{
      "label": "Years from contract award (2020) to full E-IDS deployment",
      "data": [14, 8],
      "backgroundColor": ["#f97316", "#3b82f6"],
      "borderColor": "#ffffff",
      "borderWidth": 1
    }]
  },
  "options": {
    "indexAxis": "y",
    "plugins": {
      "title": { "display": true, "text": "Replacing floppy disk era display systems: years from contract to completion (source: GAO via Gizmodo)" },
      "legend": { "display": false }
    },
    "scales": { "x": { "beginAtZero": true, "title": { "display": true, "text": "Years" } } }
  }
}

The bigger picture is no more comforting. In September 2024 the US Government Accountability Office reported that 51 of the FAA’s 138 air traffic control systems were unsustainable and another 54 were potentially unsustainable. That is three quarters of the estate, and 58 of those 105 systems have a critical operational impact on the safety and efficiency of the national airspace.

{
  "type": "doughnut",
  "data": {
    "labels": ["Unsustainable (51)", "Potentially unsustainable (54)", "Sustainable (33)"],
    "datasets": [{
      "data": [51, 54, 33],
      "backgroundColor": ["#ef4444", "#f59e0b", "#3b82f6"],
      "borderColor": "#ffffff",
      "borderWidth": 2
    }]
  },
  "options": {
    "plugins": {
      "title": { "display": true, "text": "FAA's 138 air traffic control systems by sustainability rating (source: GAO-24-107001)" },
      "legend": { "position": "bottom" }
    }
  }
}

A follow up GAO report in September 2026 looked at the FAA’s accelerated rebuild and concluded that the agency was effectively buying speed at the cost of certainty, without a full lifecycle cost estimate or master schedule.

Before anyone reads this as a story about bureaucratic neglect, though, it is worth pausing. Many of these systems have not survived because nobody could be bothered to replace them. They have survived because ripping out a working safety critical system is dangerous in its own right. When your phone becomes obsolete it is annoying. When an air traffic control upgrade goes wrong, aircraft get grounded, or worse. That is why these programmes run for years rather than sprints.

2. Nuclear Power Plants: The Ultimate Legacy Systems

I went into the nuclear research with a confident assumption: these plants are mostly running COBOL or Delphi. I was wrong, and the reason I was wrong ended up making the argument stronger. COBOL is a business data processing language, not something you use to control a reactor, and Delphi did not even ship until 1995, long after most of today’s fleet was designed.

What you actually find inside a nuclear plant is a mix of analogue instrumentation, programmable logic controllers, embedded systems, specialist industrial control platforms and, more recently, digital instrumentation and control. When the US Nuclear Regulatory Commission commissioned guidance on programming languages for safety systems back in 1996, the resulting report (NUREG/CR-6463) covered Ada, C and C++, PLC ladder logic, IEC 1131-3 sequential function charts, Pascal and PL/M, with a later revision adding structured text and function block diagrams. A lot of the most important safety functions are not software at all. When malware turned up at Germany’s Gundremmingen plant in 2016, the operator’s spokesman made the point that the systems controlling the nuclear process itself were analogue, and so isolated from cyber threats.

The key thing to understand is that these are not enterprise applications written in an unfashionable language. They are engineered systems where the hardware, software, control logic and physical process have been validated together as one thing. Change any part of it and you may be looking at months of safety analysis, testing, regulatory review and possibly new hardware. Nobody is running a vulnerability scanner, downloading a patch and rebooting the reactor on a Tuesday evening.

Now imagine you find a critical vulnerability in a control system that has run flawlessly for thirty years. The vendor may no longer exist. The development environment may be gone. The engineers who wrote it have probably retired, and the replacement hardware might need a completely different control architecture. Even if someone could write a patch, proving it does not interfere with a safety function could take far longer than writing it. In that situation the risk of changing the system can honestly be greater than the risk of leaving the vulnerability where it is, provided the system is properly isolated. That condition is carrying a lot of weight, so let’s talk about it.

3. The Air Gap Deserves More Respect Than It Gets

Perimeter security has become slightly unfashionable. We talk about zero trust, endpoint detection, continuous monitoring and assuming the attacker is already inside, and for an enterprise estate those are exactly the right instincts. But for systems that cannot be patched, I think the humble air gap deserves a lot more respect than it usually gets.

The term gets used loosely, so it is worth being precise, because three quite different architectures tend to hide under the same label. The first is true physical disconnection: no network path of any kind between the protected system and anything less trusted. That is a genuine air gap. The second is unidirectional connectivity, usually built with a data diode, a hardware device that lets data flow out of the protected environment while making it physically impossible for anything to flow back in. A data diode is not an air gap, because a connection does exist, but the direction of that connection is enforced by physics rather than configuration. The third is segmentation with controlled two way access: firewalls, jump hosts and a DMZ between the control network and the corporate one. That is useful and often necessary, but it is clearly the weakest of the three, because a firewall is only ever as good as its rules, its firmware and the people looking after it.

In the US, nuclear licensees must protect the digital systems that support safety, security and emergency preparedness functions under 10 CFR 73.54, using defence in depth, and the NRC’s own material is explicit that no single failed control should be able to compromise safety and security functions. In practice the most critical systems tend to sit behind the first or second architecture, either physically separated or connected outward only through hardware enforced one way devices.

What those first two have in common is that they remove the inbound path, and that changes the attacker’s problem completely. Picture a thirty year old controller with a vulnerability that would be trivial to exploit if it were reachable from the internet. With no inbound path, an attacker on the other side of the world cannot scan it, fingerprint it or fire an exploit at it. They have to get creative: compromise a maintenance laptop, tamper with an update, slip in infected removable media, or come in through a trusted supplier. Those threats are real, but they take far more access, patience and money than spraying exploits at whatever answers on port 443.

This is really the crux of the whole piece: a vulnerability is not the same thing as an exploitable attack path. A critical CVE on an internet facing login server may need fixing within hours. The same score on an isolated industrial controller does not automatically carry the same urgency. The consequence of exploitation may be far worse, but the likelihood and the routes in are radically different. So I would argue air gaps remain one of the most important defences we have for systems that cannot easily be patched. They do not make the software any more secure. They make it a great deal harder to reach.

4. Stuxnet Proved That Air Gaps Are Not Invincible

You cannot write about nuclear plants and air gaps without Stuxnet turning up, and rightly so, because it proved beyond argument that isolation does not equal immunity. The malware went after Siemens WinCC and Step 7 control environments associated with Iran’s nuclear programme, as ENISA’s analysis sets out, and it spread on removable media using either autorun files or the Windows shortcut vulnerability CVE-2010-2568, according to MITRE ATT&CK. Symantec’s detailed dossier on the malware concluded that it probably moved across ordinary networks first, then rode infected USB drives over the final hop to engineering machines that were never connected to an untrusted network.

That is the awkward truth about every air gap. People still have to maintain the equipment. Software still needs updating. Engineers still need their diagnostic tools, suppliers still deliver parts, and every so often somebody has to move data from one side to the other. Every one of those routines is a potential bridge, which is why MITRE now catalogues replication through removable media as a technique specifically associated with reaching disconnected networks.

Gundremmingen shows what this looks like in real life. In April 2016 the operator RWE found Conficker and W32.Ramnit on a computer in unit B that had been retrofitted in 2008 with data visualisation software for the fuel handling equipment, and the same malware was found on 18 removable drives used with office computers that were kept separate from the plant’s operating systems (The Register, Dark Reading). There is no evidence the reactor’s safety systems were touched, and because the machine was not on the internet the malware had no way to call home. But it showed very clearly that disconnected computers still get infected.

The lesson is not that air gaps are pointless because Stuxnet beat one. It is that an air gap removes whole classes of remote attack while leaving others very much alive, and it only holds if you are strict about portable devices, maintenance processes, supplier access and where your software comes from. NIST’s short guide on portable storage media in OT environments is a good place to start. A well designed air gap is a boundary that needs looking after every day, not a cable someone unplugged twenty years ago and then forgot about.

5. The Real Danger Is Connecting Old Systems to New Networks

If you ask me where the biggest risk actually sits, it is here. For decades industrial systems were built on assumptions that no longer hold: trusted operators, locked doors, predictable networks and the comfortable belief that nobody outside the building could ever talk to them. Then somebody decided that hooking them up to the corporate network would make life easier. Management wanted dashboards. Engineers wanted to diagnose problems from home. A vendor wanted to sell predictive maintenance. The business wanted the data in a cloud analytics platform. Every one of those requests sounds perfectly sensible on its own, and together they can quietly dismantle the isolation the original design depended on.

Before long a controller designed in the 1990s is chatting to a modern Windows workstation, which sits on an enterprise network full of remote access services, third party suppliers, cloud connections and thousands of laptops. The controller has not changed at all. Its exposure has changed completely.

A legacy system does not need to change for its security posture to deteriorate. Sometimes all that needs to change is the network around it.

I think this is the dimension we miss most often when we talk about legacy risk purely in terms of patch age. There are really three clocks running at once: how fast vulnerabilities are being found, how fast you can patch, and how fast the connectivity around a system is changing. A controller can sit untouched for thirty years while its risk climbs steadily, one reasonable looking integration project at a time, and nobody ever makes a single decision that feels like the moment it became exposed. So every change to the connectivity of a legacy system should be treated as a security change to the system itself, with its original design assumptions reviewed before the cable goes in rather than after the incident report.

It does not help that the controller usually has no way to defend itself. It may not support modern authentication or encryption, it probably produces no useful security logs, it may fall over if you install an endpoint agent on it, and patching it may mean stopping the physical process it controls. We take something built for a trusted, isolated world, drop it into one where trust cannot be assumed, and then act surprised when it gets popped.

6. Not Every CVE Deserves the Same Response

I still believe what I wrote in May: traditional patch cycles are becoming structurally incompatible with how fast attackers now move. But this research sharpened something I had underplayed.

Patching is not the objective. Reducing exploitable risk is the objective.

Most of the time those two line up. Sometimes they do not. Take three systems that all contain the same vulnerable component: an internet facing application, an internal application behind decent controls, and an isolated industrial controller that needs physical access for maintenance. Treating them as the same risk would be daft. The first could be under attack within hours of disclosure. The second can be reached through a phished laptop or lateral movement. The third realistically needs physical access, compromised maintenance kit or a supply chain attack.

%%{init: {'theme':'base','themeVariables':{'fontSize':'15px','lineColor':'#e5e7eb','primaryTextColor':'#ffffff'}}}%%
flowchart LR
    A["Same vulnerable component"]:::neutral --> B["Internet facing app"]:::high
    A --> C["Internal app behind controls"]:::medium
    A --> D["Air gapped controller"]:::low
    B --> B1["Remote attack exposure: HIGH<br/>Scanned and exploited within hours"]:::high
    C --> C1["Remote attack exposure: MEDIUM<br/>Phishing, stolen credentials, lateral movement"]:::medium
    D --> D1["Remote attack exposure: LOW<br/>Removable media, maintenance laptop, supplier<br/>Consequence if compromised may still be severe"]:::low
    classDef neutral fill:#1f2937,stroke:#ffffff,color:#ffffff,stroke-width:2px
    classDef high fill:#991b1b,stroke:#ffffff,color:#ffffff,stroke-width:2px
    classDef medium fill:#92400e,stroke:#ffffff,color:#ffffff,stroke-width:2px
    classDef low fill:#1e3a8a,stroke:#ffffff,color:#ffffff,stroke-width:2px

It is worth being clear about what that diagram does and does not say. It shows how easy each system is to reach remotely, not its overall risk. A nuclear controller with low remote exposure can still carry a catastrophic consequence if somebody does get to it, and that is exactly why the boundary controls in section 4 matter so much.

The raw CVE score tells you almost none of this. To prioritise properly you need to know whether the vulnerability is reachable, whether it is realistically exploitable, what controls already sit in front of it, what access an attacker would need and what happens if they succeed. It also helps to remember how few vulnerabilities are ever exploited at all. One analysis of CISA’s Known Exploited Vulnerabilities catalogue found that only around 151 of the 48,185 CVEs published in 2025 were both disclosed and added to the catalogue that same year, roughly 0.3 percent. Exploitation data always lags, so that number will rise, but the shape of the problem is clear.

{
  "type": "bar",
  "data": {
    "labels": ["CVEs published in 2025", "2025 CVEs added to CISA KEV in 2025"],
    "datasets": [{
      "label": "Count",
      "data": [48185, 151],
      "backgroundColor": ["#3b82f6", "#ef4444"],
      "borderColor": "#ffffff",
      "borderWidth": 1
    }]
  },
  "options": {
    "plugins": {
      "title": { "display": true, "text": "Disclosed versus known exploited, 2025 (log scale; sources: Jerry Gamblin, Safeguard analysis of CISA KEV)" },
      "legend": { "display": false }
    },
    "scales": { "y": { "type": "logarithmic", "title": { "display": true, "text": "CVEs (log scale)" } } }
  }
}

The NCSC’s own patch wave guidance points the same way, telling organisations to deal with their internet facing attack surface first and to prioritise with something like CISA’s Stakeholder Specific Vulnerability Categorization rather than raw severity. None of this is a licence to ignore the isolated system. But automatically patching a safety critical controller because a scanner turned a dashboard red can introduce operational risk of its own. A system with fifty known CVEs and no credible remote path in may well be better protected against internet attacks than a fully patched one with an exposed management interface and a leaked password. The fifty CVEs are not harmless; you just need to understand how anyone would actually use them.

7. The Forgotten Risk: Nobody Knows How It Works Any More

There is another problem with legacy infrastructure that worries me more than the CVEs, and that is knowledge quietly walking out of the door. A system built forty years ago may still run perfectly, but the people who designed it have retired, the documentation has gaps, the supplier has been bought and sold three times, the spare parts stopped being made a decade ago, and the current team knows how to operate it without really knowing why it behaves the way it does. It works because it has always worked. Ask what would happen if a particular board failed, or if one setting were changed, and you get a lot of careful silence.

That is a resilience problem as much as a security one. An unpatchable system is one problem. A system you cannot rebuild is a bigger one. A system you cannot rebuild because nobody understands it any more is the one that keeps me up at night, because that is the point where technical debt stops being a line item and becomes existential.

And here is the uncomfortable bit. Plenty of organisations would tell you they have this covered because they hold backups, spare hardware and a binder of documentation. That is not the same as being able to recover. The only question that really matters is whether you have demonstrated, on real or representative hardware, that you can bring the actual operational capability back safely: not restore an image to a test box, but stand the system up, reconnect it to the process and prove it behaves correctly. If that exercise has never been done, or was last done by someone who has since retired, the recovery plan is a hope rather than a capability. For critical infrastructure, proving you can restore and rebuild deserves the same attention as preventing the attack in the first place.

8. Modern Is Not the Same as Safe

It is tempting to assume that newer software is automatically safer. It usually comes with better tooling, more mature security practices, active vendor support and far better visibility, but it also brings a long tail of dependencies: operating systems, container runtimes, cloud services, identity providers, libraries, update mechanisms, remote management and network connectivity. Every one of those is another way to fail and another place to find vulnerabilities. Swap a small controller running a fixed image for a general purpose operating system with remote admin tools and a stack of third party components, and you may well have made the attack surface bigger, not smaller.

I spent a large chunk of my career building trading systems on FPGAs, where small, deterministic and slightly boring was the entire point, so I have some sympathy for engineers who resist adding layers. Sometimes replacement is clearly necessary, and the FAA’s display systems are a good example of kit that has reached the end of the road. Sometimes the smarter move is to keep a stable control environment and modernise everything around it. And sometimes the safest architecture is deliberately dull: limited functionality, no unnecessary dependencies, no internet connectivity and tightly controlled maintenance. When the system can hurt people if it misbehaves, excitement is not what you are designing for.

9. What Should Organisations Actually Do?

For modern, connected enterprise systems, my advice from May stands: shrink the time from discovery to exposure assessment to fix, with automated dependency discovery, continuous monitoring, fast patching, a smaller attack surface and strong detection. For legacy operational technology the playbook looks different:

1⃣ Know exactly what is connected to what. Build and maintain an accurate map of your industrial systems and every connection between operational networks, enterprise networks, suppliers and remote access. Most organisations are surprised by what they find.

2⃣ Keep genuine isolation where you can, and be honest about which kind you have. If a safety critical system does not need connectivity, do not give it any. Where data must leave, prefer a data diode to a firewall rule, and stop calling a segmented network air gapped when it is not.

3⃣ Treat connectivity changes as security changes. Any new integration with a legacy system should trigger a review of its original design assumptions before anything is plugged in.

4⃣ Control everything that crosses the boundary. Maintenance laptops, removable media, updates and vendor equipment need rigorous approval, scanning and handling. That is the road Stuxnet travelled.

5⃣ Prioritise on exposure, not just severity. Ask whether the vulnerability is reachable, how it could realistically be exploited and what the physical consequences would be.

6⃣ Prove you can recover. Backups and spares are necessary but not sufficient. Rehearse restoring the actual operational capability, and keep the people and documentation needed to do it.

7⃣ Modernise on purpose. Replace systems because it measurably improves safety, reliability, supportability or risk, not because they are old.

10. Two Very Different Victims

When I wrote the original piece I saw the CVE wave as a speed problem, and for most of the systems most of us run, it still is. Critical infrastructure adds a second problem that speed cannot solve, because some systems simply cannot move faster. They cannot do continuous deployment, cannot reboot every Tuesday and cannot tolerate a badly tested update. For them, security has to come from architecture, isolation, controlled change and the proven ability to recover.

There is a real irony in all this. We are building AI that can find vulnerabilities at astonishing speed, while some of the world’s most important infrastructure is protected, at least partly, by the plain fact that it is not connected to anything that AI can reach. Stuxnet proved that protection is not absolute, but it is still enormously valuable.

So perhaps the real lesson of the CVE wave is not only that we need to patch faster. It is that we need to be much more disciplined about what we connect in the first place. The safest system is not necessarily the newest one. Sometimes it is the one that nobody on the internet can talk to.

References

Andrew Baker, The CVE Wave Is Coming. Most Organisations Are Not Prepared., 21 May 2026
Jerry Gamblin, 2024 CVE Data Review, January 2025
Jerry Gamblin, 2025 CVE Data Review, January 2026
NCSC, Preparing for a vulnerability patch wave, 1 May 2026
The Register, US air traffic control enters the 21st century, starts to abandon floppy disks, 6 November 2026
Gizmodo, FAA Plans to Retire Floppy Disks by 2028, 5 November 2026
FAA, Enterprise Information Display System (E-IDS)
Tom’s Hardware, FAA to eliminate floppy disks used in air traffic control systems
GAO, Air Traffic Control: FAA Actions Are Urgently Needed to Modernize Aging Systems (GAO-24-107001), September 2024
GAO, Air Traffic Control Systems: Ambitious New Modernization Effort Needs to Improve Cost and Schedule Planning (GAO-26-107992), September 2026
US NRC, 10 CFR 73.54 Protection of digital computer and communication systems and networks
US NRC, Cyber security framework overview (ML21308A026)
US NRC, NUREG/CR-6463 Review Guidelines on Software Languages for Use in Nuclear Power Plant Safety Systems, 1996
ENISA, Stuxnet Analysis
MITRE ATT&CK, T1091 Replication Through Removable Media
The Register, German nuke plant viruses, April 2016
Trend Micro, Malware Discovered in German Nuclear Power Plant, April 2016
Dark Reading, German Nuclear Power Plant Infected With Malware, April 2016
Safeguard, What share of vulnerabilities actually get exploited
NIST, SP 1334 Reducing the Cybersecurity Risks of Portable Storage Media in OT Environments, September 2025
CISA, Stakeholder Specific Vulnerability Categorization (SSVC)