Fighting the Sword of Damocles
HuFiCon Management Memo:
Journey with the CISO
A mountain climb to cyber security resilience. Find out how to get to the summit of cyber security resilience in Inge van der Beijl's management memo, from her presentation at the Human Firewall Conference (HuFiCon) on the 14.11.2024.
The climb will take you from the base camp of foundational security to the high-camp of a security conscious culture, all the way to the summit consisting of strategic security integration.
Inge van der Beijl
Director Innovation
This is the second article in our three-part series on legacy system risks and how to mitigate them. It's based on Hansje's academic thesis, "Shadow of the Past," which examined legacy risks for universities beyond conventional mitigation strategies, developed as part of a cyber security masterclass programme at Antwerp Management School. You can read the research article, co-authored with Stephanie Kelder and Yuri Bobbert, in a Springer volume, published 24 May 2026.
In our first blog in this series on Legacy Systems, we explained what makes a system "legacy" and why these ageing assets quietly raise business risk in both IT and OT environments. For the technical focussed professionals reading this blog, in the published paper you can read a simulated breach that shows how attackers can exploit weaknesses in practice. And brace yourself, because in the next blog you will read about what our Northwave professionals come across in their expertise fields.
The question we're left with is the practical one: what do you actually do about it? In this second instalment, we move from problem to approach. We look at how to prevent legacy from building up in the first place, how to buy yourself time when you can't patch, and how to structure a lifecycle-based mitigation strategy that CISOs, CIOs and boards can act on. At the end of this article, you'll find a practical flowchart to guide your steps when taking control of legacy system risk.
Legacy Doesn't Have to Be Inevitable
Legacy is often treated as something that simply happens to an organisation over time. In reality, the result of choices made at implementation or postponed actions at the end-of-life date years earlier. There are four broad strategies for dealing with legacy, and they aren't mutually exclusive. Most mature organisations use all four, applied to different parts of the business.
-
Prevent legacy from forming. The cheapest way to mitigate legacy risk is to never create it in the first place. Every step you take up the stack, from Infrastructure-as-a-Service to Platform-as-a-Service, to Software-as-a-Service, shifts parts of patching and lifecycle responsibility to a vendor whose business model depends on keeping the platform current. This is especially relevant for SMEs and smaller organisations, which typically have the least capacity to manage lifecycles themselves and benefit the most from offloading them. Automating lifecycle management for the systems you do keep in-house is the second half of this equation.
-
Automate the way out. Organisations that do keep infrastructure in-house are increasingly defaulting to containment through containerisation (Kubernetes, Docker). Rather than patching a large server, teams rebuild and redeploy new images on a regular cadence, sometimes weekly, so that "legacy" never gets the chance to accumulate in the first place. This doesn't eliminate lifecycle work because, at a minimum, the container platform itself also needs to be kept up to date. However, it becomes a routine, automatable process instead of a periodic, high-risk project.
-
Build compensating controls. Sometimes you genuinely cannot patch or upgrade. The vendor is gone, the software is welded to a critical business process, or the knowledge required to touch the system safely no longer exists in-house. This is where compensating controls come in: security measures placed around or in front of the legacy system rather than inside it. Think about strict access controls, network segmentation, application-layer filtering, jump hosts, and increased monitoring. Compensating controls don't fix the underlying vulnerability, but they are the most realistic and often the only control available while a legacy asset must remain in service. Extended vendor support can buy additional time here too, but it should be treated as exactly that: a window for mitigation, not a long-term answer.
-
Accept the risk, deliberately. Occasionally, the right call is to do nothing further, formally and consciously. This is only acceptable when it's a risk-based decision in which the cost-benefit of the options above have been previously weighed, and when it is assessed by people with the competence and expertise to actually assess the risk and documented as such. "We didn't get round to it" is not the same as "we accepted this risk."
Prevention Starts at Procurement, especially in OT
Legacy is much more difficult to manage in OT. Downtime is costly, safety-critical processes make patching risky, and equipment lifecycles are measured in decades rather than years. This makes prevention at the moment you commission new equipment especially valuable in OT environments. Before signing off on a major piece of equipment, we recommend three concrete steps:
- Ask to see the supplier's security policy and audit results. Don't take vendor security posture on faith; make it part of due diligence.
- Contractually require updatability. Specify that intelligent components such as PCs and PLCs must remain updateable for the lifetime of the device, not just for the first two years.
- Agree explicitly on vendor connectivity. Define, in writing, how and when a supplier connects to your equipment, for maintenance or otherwise, so remote access doesn't become an unmanaged backdoor.
These three questions cost nothing to ask and can prevent unsupported and/or unpatchable systems.
A Structured Framework: Six Dimensions of Lifecycle Management
Prevention and compensating controls address individual systems, but organisations also need a repeatable, governance-level structure to manage legacy across the entire system. In our research, we identified six dimensions that together form the foundation of a lifecycle mitigation approach: Time, Scope, Change, Vendor, Process, and Data.
- Time. Force the use of explicit lifecycle and migration strategies. Set a maximum server lifespan (typically 3 to 5 years for IT and 7 to 12 for OT) and tie replacement directly to procurement and maintenance planning, so retirement isn't left to chance.
- Scope. Decide upfront whether you fully replace a system or retain core components, and enforce strict version discipline (for example, never more than one or two versions behind) to limit exposure.
- Change. Redesign processes with zero-trust and security-by-design principles, and factor operating system choices in early so migrations don't introduce new risk. Where legacy systems must remain, controls like Multi-Factor Authentication (MFA) can sometimes be pushed onto the firewall in front of them, making better use of infrastructure you already have.
- Vendor. Formalise a vendor strategy and embed security requirements into procurement contracts: checklists (ISO 27001, NIST, or CIS), Service Level Agreements, End-of-Life-support commitments, reputation, and availability. Verify that vendors keep their own tooling current, and that MFA on their equipment is enforced continuously, not just configured once.
- Process. Define clearly how processes and responsibilities transfer during migration and build in continuity measures such as redundancy, so a transition doesn't itself become a source of downtime.
- Data. Design data migration as a structured, step by step program: first classify and minimise what needs to move, then secure the pipeline with encryption, strict access controls, and testing before full rollout. Link this to growth by choosing scalable architectures and documenting clear migration runbooks, so future moves can reuse the same hardened approach instead of reinventing it each time.
The value of this framework is that it turns "we know legacy is risky" into something a CISO or Security manager can actually govern: each dimension can be translated into SMART actions (Specific, Measurable, Achievable, Relevant, Time-bound), assigned an owner, and tracked. It also conceptually maps onto existing governance frameworks like NIST CSF, COBIT and IEC 62443 so it fits into structures your organisation likely already uses for other risk domains, rather than requiring a parallel process.
From Reactive Firefighting to Proactive Governance
The common thread across all of this, prevention, automation, compensating controls, and the six-dimension framework, is a shift in posture. Too many organisations treat legacy as a technical debt problem to be dealt with when there's budget or time. As we argued in blog one and will demonstrate in the third blog, legacy is an active, current security risk, not a passive one. It behaves less like debt accruing quietly in the background and more like the sword hanging over your head: mostly ignored, until the thread finally gives.
Structured lifecycle hygiene, clear policy, effective governance, and shared responsibility across IT, OT, procurement and leadership are what move an organisation from reacting to legacy incidents to actively managing legacy risk. None of this requires chasing the newest tools or trends. It requires discipline applied consistently to the systems you already have.
Use the flowchart below as a reference guide for three essential actions that will help you mitigate legacy system risk. Click here for a printable version of the chart.
We are here for you
Need help with your cyber security or wondering how secure your business really is?
Get in touch and we will help you find the best solution.