Someone must take responsibility for ageing legacy technology
The problem with legacy technology is that nobody must make a decision about it. A system reaches the end of its supported life, the security team raises a concern, operations explains why replacement is difficult, and the request for funding gets pushed into another budget cycle. Meanwhile, the legacy technology keeps running.
A protective relay installed 20 years ago may still do its job perfectly well. So might a network router, an industrial controller or the database behind an essential government service. Replacing any of them can be expensive and disruptive. The people responsible for keeping services running have legitimate reasons to resist unnecessary changes.
But someone needs to decide how long those systems can safely remain in service.
The first step is to identify the critical systems that cannot be upgraded, then take the decision on them to someone who can act.
My recent ASPI report, Past its use-by-date, examined the risks created by end-of-life technology across the Indo-Pacific. What stands out is how easily responsibility disappears between the people who understand the technical problem and those who control the money.
South Korea offers a particularly uncomfortable example. After a 2025 data breach on the country’s largest mobile carrier, SK Telecom, investigators found that a critical operating system vulnerability had remained unpatched despite a fix being available since 2016. Attackers had reportedly maintained access for years. This happened in a country that is routinely held up as a global leader in digital infrastructure.
In the Philippines, state health insurer PhilHealth suffered a major ransomware attack in 2023 after its antivirus licence had expired. The subsequent argument over procurement requirements showed another way that systems can end up exposed. Security protection can lapse because an organisation fails to maintain the commercial arrangements needed to keep it working.
Neither case can be explained simply by the age of the equipment. That is part of what makes the problem difficult to govern.
There is also a cost that rarely appears in the original decision to defer replacement. Old systems become harder to restore after an incident. Replacement components disappear from the market. The people who know how to maintain them retire. New applications inherit dependencies on equipment that nobody wants to touch.
Eventually, keeping the old system alive begins to dictate what the rest of the organisation can do.
The approaching transition to post-quantum cryptography makes this especially concerning.
We spend much time discussing which cryptographic algorithms organisations should adopt and when migration should begin. Those conversations tend to assume that existing systems can be upgraded. Some simply cannot.
Consider a protective relay, a device that isolates faults in an electricity network, that was installed in an electrical substation in 2012. It was designed to operate for 25 years, which takes it through to 2037. Its firmware, the built-in software that runs the device, might be checked for authenticity using a digital key fixed in its chip. If the hardware cannot accept a new way of checking authenticity, then there is no software patch that will solve the problem.
The relay could still be doing its job in 2037. Its security may have become impossible to maintain years earlier.
Much of the concern about quantum computing centres on adversaries collecting data now in the hope of decrypting it later. And future quantum capabilities could undermine the digital checks that devices use to confirm software is authentic, leaving some long-lived equipment unable to establish trust securely.
Nobody can give operators a reliable date for when that threat becomes practical. But the time required to replace a substation controller, telecommunications platform or other critical system is something they can estimate today.
An operator that begins planning now can use scheduled outages, attend to dependencies with suppliers and fund replacement systems over several years. Leave it too late and the same work becomes considerably harder, particularly when several systems need attention at once.
This is where I think Australia’s critical-infrastructure sector needs to concentrate its efforts.
Most operators already maintain asset registers and risk registers. The useful question is whether those records tell management which critical systems have lost vendor support, which will lose it soon and which cannot accommodate the security changes they will need during their remaining operational lives.
For those systems, someone should be able to explain what replacement involves, how long it will take and what the organisation is doing in the meantime.
That information belongs in capital planning and board reporting. Where replacement is impracticable, the decision to continue operating should be explicit, with appropriate controls and a date for reconsideration.
Procurement needs attention too. A product expected to remain in service for 20 years should come with a credible account of its security-support life and upgrade options. Otherwise, the next generation of legacy problems is being bought today.
I would start by setting operators a fairly simple challenge: within 90 days, identify the critical systems that cannot be upgraded, work out what replacing them would involve, and put the decision in front of someone with the authority to act.
About Author
