The Australian Government’s rapid review into an AI-related cyber incident has understandably focused attention on the emerging security implications of artificial intelligence.
The Department of the Prime Minister and Cabinet says the review follows an incident in which a non-public OpenAI model undertook misaligned activity during an internet research task, resulting in unauthorised activity affecting government information systems. Importantly, the review is looking beyond the immediate incident to the broader question of how government can build and maintain resilient systems in the AI era.
AI has not suddenly created the problem of legacy technology. But it is changing the environment in which legacy systems operate. Automation can increase the speed and scale with which systems are discovered, interrogated and potentially attacked. At the same time, organisations are creating more machine-to-machine connections, APIs, agents and automated workflows.
Technology that was difficult to secure yesterday does not become easier to secure as this environment becomes more automated.
For government in particular, this is not a theoretical issue. ASD’s 2025 Commonwealth Cyber Security Posture report found that 59% of Australian Government entities said legacy technologies affected their ability to implement the Essential Eight. ASD describes legacy IT as a significant and enduring cyber risk and notes that unsupported technology can prevent organisations applying contemporary security controls.
The question for leaders is therefore not simply “How much legacy technology do we have?”, it is: “How much security risk are we carrying because of it – and what are we doing about it?”
Question 1: Do we know what is in the legacy estate?
Legacy risk starts with visibility. Organisations need to know which applications, operating systems, databases, infrastructure components and dependencies are unsupported, approaching end of support or dependent on ageing technology.
But an inventory alone is not enough. For each material system, leaders should understand:
- what business service it supports;
- what information it processes;
- who owns it;
- which technologies it depends on;
- whether those technologies remain supported;
- the business impact if the system were unavailable, compromised or could no longer be supported;
and whether there is an agreed retirement or modernisation path.
This changes legacy management from an infrastructure housekeeping exercise into a portfolio-level risk-management discipline.
Gartner’s 2026 research makes the connection directly: ageing and unsupported systems increase the likelihood of disruption and severe security incidents, and technical debt needs to be exposed and prioritised rather than left to accumulate indefinitely.
Question 2: What can reach it - and who can access it?
Historically, organisations have often concentrated on whether a legacy system is internet-facing. That remains important, but it is no longer sufficient. A system may sit deep inside a network and still be reachable through an application, API, compromised endpoint, third-party connection, service account, administrative pathway or another trusted workload.
The better question is: What users, systems, workloads and networks can interact with this technology, directly or indirectly?
That is an architectural problem rather than simply a perimeter-security problem. Understanding those pathways gives organisations a more accurate view of the system’s real exposure and therefore the risk associated with continuing to operate it.
Question 3: Which modern security controls can't we apply?
Age alone does not define security risk. A more useful measure of legacy technology is the security-control debt it creates. As operating systems, applications and platforms fall out of mainstream support, the security ecosystem around them also narrows: security vendors may stop supporting older versions, while lack of support for newer security features can limit the organisation’s ability to deploy current controls.
This matters increasingly as both attack and defence become more automated. Modern security operations depend on telemetry, detection, policy enforcement and response operating at machine speed. Legacy platforms that cannot support or integrate with these capabilities can limit the organisation’s ability to respond at the same pace.
Key capabilities to assess include:
- contemporary authentication and MFA;
- least privilege and privileged-access management;
- supported security patching;
- modern cryptography;
- endpoint or workload protection;
- vulnerability management;
- network segmentation;
- centralised logging and detection;
- configuration and policy enforcement;
- resilient backup and recovery;
- and modern workload identities rather than embedded credentials
ASD’s findings show why this matters: legacy technology is already constraining many government organisations from implementing controls considered fundamental to contemporary cyber defence.
The key leadership question therefore becomes: What controls do we believe are necessary today that this platform cannot effectively support? That turns an abstract discussion about technical debt into a tangible discussion about residual cyber risk.
Question 4: Can we eliminate the technology - or reduce the amount of it we have to secure?
This is where modernisation becomes particularly important.
Cloud modernisation should not simply mean taking an old server and recreating it somewhere else. A lift-and-shift migration can carry existing operating-system, application and configuration vulnerabilities into the cloud unchanged.
Where possible, workloads should be refactored or re-platformed so that the organisation can abstract itself from responsibility for securing every layer the application depends on. Moving to managed platform and application services can transfer responsibility for parts of the infrastructure, operating system, runtime or database layer to the cloud provider, reducing the amount of technology the organisation must directly operate, patch and defend.
Microsoft and AWS both describe this through their shared-responsibility models: the more managed the service, the more of the underlying technology stack is operated by the provider, while the customer retains responsibility for areas such as identity, data, access and configuration.
The security value of modernisation is that organisations can remove legacy limitations and weaknesses whilst also reducing the number of technology layers they are directly responsible for securing.
Question 5: Where modernisation isn't currently possible, what contains the risk - and when does that exception expire?
Not every government system can simply move to public cloud. Data requirements, sovereignty, dependencies, bespoke applications, operational technology, commercial constraints or the absence of a viable replacement may make immediate modernisation impractical. The answer should not be to ignore the risk but to contain it.
That may include:
- stronger network isolation and segmentation;
- removal of unnecessary external connectivity;
- tightly controlled administration;
- modern gateways in front of legacy services;
- EDR and enhanced monitoring;
- centralised logging;
- virtual patching (where a WAF, IPS or other security layer blocks attempts to exploit a known vulnerability when the underlying application or system cannot yet be patched);
- stronger identity controls around the application;
- and improved configuration, vulnerability and patch management.
Hybrid management platforms such as Azure Arc fit here.
Arc can bring legacy and non-Azure infrastructure into a modern management and governance plane, helping improve inventory, policy enforcement, patching, monitoring and security management. But management is not modernisation. Using Arc, EDR, segmentation or other compensating controls may materially reduce the risk associated with a legacy platform. They do not remove the underlying technical debt.
A system that cannot yet be modernised should therefore have both a documented set of compensating controls, and a documented path out.
Otherwise, a temporary exception has a tendency to become permanent architecture.
Modernisation becomes a security control
The broader lesson is that legacy modernisation should no longer be treated solely as an IT efficiency programme. Done properly, it can reduce cyber risk in three distinct ways.
- Reduce the estate: Retire unnecessary technology and remove its attack surface entirely.
- Abstract the estate: Move appropriate infrastructure, operating-system, database and platform responsibilities to managed services rather than continuing to operate every layer internally.
- Improve the estate: Enable modern identity, privilege, patching, segmentation, telemetry, policy enforcement and resilience.
And where none of those is immediately possible:
- Contain the estate: Apply compensating controls while maintaining a defined modernisation or retirement path.
AI hasn’t created technical debt, but an increasingly automated threat environment should cause organisations to reconsider how much of that debt they are prepared to carry – and for how long.
