To face AI intrusion, counting legacy systems will be easy. Fixing them won’t
The Department of Home Affairs has made an important start. In response to an OpenAI agent reaching non-public files on a decades-old Medicare Statistics portal, last week it issued a direction that required agencies to identify and manage security risks in legacy IT systems. This will ensure agencies understand and assess their legacy technology base.
But the hard part will be acting on what the stocktake finds. Retiring legacy systems requires money, scarce skills and leverage over vendors that no directive can supply on its own.
This matters because AI is sharply reducing the time and expertise needed to find and exploit simple weaknesses in ageing, poorly maintained systems. Yet old systems often survive for rational reasons rather than simple neglect: they encode complex business rules that are hard to replicate, hold data that is difficult to migrate and underpin public services that cannot be interrupted during a changeover. Agencies will therefore have to triage aggressively, prioritising the highest-risk systems while mitigating the risks of those that realistically won’t be replaced for several years. The government should also use its collective leverage with vendors, both to extend security support for systems already in service and to write binding support periods into future contracts. End-of-support dates can too often be determined by vendors’ commercial imperatives rather than taxpayers’ value for money.
The direction requires all non-corporate federal agencies to complete a legacy technology stocktake and a risk management plan. The plan must include a reduction target and a prioritisation strategy. Some cases will be easy – the Medicare statistics site accessed by the OpenAI agent was taken offline, which raises the question of why it was connected to the internet at all. The government has become used to connecting everything for convenience; agencies now need to ask whether the convenience and benefits of connectivity outweigh the risks. If not, disconnecting the system makes sense.
On the other hand, core operational systems that deliver public services can’t just be disconnected. These are also often the hardest to migrate: the business logic that they implement needs to be understood, documented and replicated; existing data needs to be moved to the new system with zero loss or corruption; and the transition between operating old and new systems needs to be seamless. This won’t be a quick process – and with finite funding, technical skills and business expertise, not everything can be migrated at once.
Agencies will need to ruthlessly prioritise, based on assessments of the risk of breach, the impact of the system and its data, and the effort required to migrate the system. For those systems that will have to wait and can’t be disconnected from the internet, agencies will need to consider how to mitigate the risks. We need to avoid the mistake of trotting out the Essential Eight – the Australian Signals Directorate’s set of basic cyber security measures – as a guideline for these cases. It is often missed that the directorate itself actually describes them as designed for internet-connected Windows-based IT networks – whereas old systems generally consist of , bespoke applications and ageing .
Other options are needed. Systems can be protected by placing dedicated security hardware or software between them and the wider internet, with additional authentication before a user can gain access. Network isolation and segmentation limit what an attacker can reach after a compromise, and enhanced logging and monitoring improve the chance of detecting one.
All of this will be a major undertaking for agencies, but they should not have to shoulder it alone: they should expect more from their vendors. If a system is 20 years old, then often replacement is the only viable way forward. But for systems that are only a few years old and still running reliably, agencies should be able to expect vendors to keep them supported and secure.
Under section 13.7 of Home Affairs’ direction, a product counts as legacy only if it is out of support, including extended support, from its vendor or developer. It also must be impractical or uneconomic to maintain. A vendor’s commercial decision to end support therefore helps determine what the federal government must treat as legacy, even where a product still has years of useful life.
This creates a perverse incentive: shorter support periods cut vendors’ maintenance costs and create opportunities to sell replacement systems. Changing support arrangements for existing systems will require some challenging commercial discussions with vendors. The government should coordinate these negotiations across agencies, through the whole-of-government arrangements the Digital Transformation Agency already manages with major vendors, so that continued support for systems already in service is a factor in future procurement decisions.
The government can also use its combined procurement leverage to stop old technology building up again. New contracts should require minimum security support periods matched to a system’s expected life, end-of-support dates disclosed at purchase, caps on extended-support pricing, . The EU has provided a precedent: the Cyber Resilience Act, which imposes similar conditions on vendors.
The stocktake will tell the government what it has and where to start. Fixing it will take funding, skills and vendors willing to share the burden.
About Author
