COMMENTARY: Most enterprises run on Linux. Many of these systems are aging, unsupported, and increasingly vulnerable to security threats. While new applications get deployed to the cloud with modern security practices, critical legacy
Linux installations supporting everything from financial services to transportation networks remain frozen in time.
The uncomfortable truth: these systems are accumulating vulnerabilities faster than organizations can address them.
Trapped between compliance and catastrophe
The Linux ecosystem, favored for its flexibility and robustness, has inadvertently created islands of technological isolation. Organizations find themselves stranded on these islands when their critical systems run on distributions that have reached end-of-life (EOL).
[
SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
Take, for example, a major North American railway company that continued to run its locomotive control systems on Red Hat Enterprise Linux 6, years after the distribution had reached
EOL. This wasn’t a case of negligence — it was a reflection of how difficult, risky, and expensive it is to upgrade deeply embedded systems.
Upgrading would have meant pulling locomotives out of service, potentially disrupting operations across the rail network. Even if the company could manage logistics, the technical debt was daunting: hardware dependencies, recertification requirements, safety testing, and legacy software tightly coupled to the OS version. The cost and risk of doing it wrong far outweighed the benefits of simply being on a supported OS.
And yet, staying put wasn’t an option either. Running unpatched systems meant the company was exposed to critical vulnerabilities — an unacceptable risk in safety-critical environments. Worse, it jeopardized their ability to pass audits and meet the cybersecurity requirements mandated by the Transportation Security Administration (TSA).
When following rules means breaking security
There’s a growing gap between what security regulations demand and what operational environments can support. TSA directives, FedRAMP, PCI DSS 4.0 — all expect timely remediation of vulnerabilities, regardless of whether the system in question is modern or obsolete.
In theory, it’s simple: stay patched, stay compliant. In practice, organizations are forced into a no-win situation: either attempt a disruptive system overhaul or live with known vulnerabilities and hope compensating controls hold. Most settle for the latter — deploying segmentation, intrusion prevention, and lots of documentation to check compliance boxes. But this approach doesn’t eliminate the risk. It just buries it under layers of complexity.
Security teams are left maintaining increasingly fragile environments, spending more time on compliance paperwork than on actual security improvements. Everyone knows the systems are vulnerable, but no one wants to break production.
Break the security-upgrade cycle
The good news? That binary choice — upgrade or accept risk — has finally been challenged.
New approaches are emerging that let organizations apply post-EOL security patches to legacy systems without full OS upgrades. In the case of the railway company, instead of forcing an overhaul, the team focused on the root issue: vulnerabilities.
By backporting critical patches directly to their RHEL 6 systems, they could close high-risk exposures, pass TSA audits, and continue operations without disruption. No risky replatforming. No recertification headaches. Just targeted security fixes applied where they were needed most.
It wasn’t a magic bullet — but it was a practical, technically sound solution that respected the constraints of a real-world environment.
Infrastructure security needs to grow up
We’ve spent years pretending that we can upgrade all systems on schedule. But in critical infrastructure — where uptime, safety, and stability rule — that’s just not realistic. Legacy systems aren’t going away anytime soon, and neither are the vulnerabilities targeting them.
If we want to protect these environments, we need to rethink how we define "secure." That means moving beyond cosmetic compliance and toward tools that actually reduce risk — even when traditional tools fall short.
We shouldn't make security a choice between disruption and exposure. It’s time to demand better.
Itamar Sher, chief executive officer, Seal SecuritySC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.
