When Loyal Equipment Becomes Your Biggest Liability
Part two of The Three Deaths of a Device — cyber security across the device lifecycle
The server was not new. That was precisely why nobody wanted to touch it.
At Kōwhai Regional Services, it lived in a corner of the comms room behind a tangle of labelled cables and a decade’s worth of institutional confidence. It ran a finance-adjacent application. It had survived office moves, restructures and three different IT managers. Every month it did its job. Every month it generated the same quiet conclusion: leave it alone.
When the vendor announced end of support, the email went into a shared mailbox. When a vulnerability advisory followed, the server was still working. When the security team asked for an inventory of unsupported systems, its name did not make the first cut.
That is how legacy equipment becomes dangerous: not with a bang, but through a series of reasonable decisions made in isolation.
The old system is rarely a problem because it is old. It is a problem because it has become invisible — absent from the asset register, outside the patching routine, and owned by nobody with the authority or budget to retire it. Meanwhile, it remains connected to a modern environment full of identities, data and pathways an attacker would be very happy to inherit.
The quiet shift from dependable to exposed
Every device has an end-of-support date, whether it is recorded or not. At that point, a vendor may stop delivering security fixes, firmware updates, drivers, replacement parts or meaningful technical support. The equipment can still power on. The business application can still open. But its security posture has changed.
That distinction matters. “Still working” is an operational measure. “Still supported” is a risk measure.
New Zealand’s National Cyber Security Centre (NCSC) makes the connection plainly: an asset list should capture end-of-life and end-of-support dates, and those dates should be shared early enough for an organisation to assess the risk, migrate or put mitigations in place. Australia’s Australian Cyber Security Centre (ACSC) gives the same executive warning: legacy technology that no longer receives security updates is more vulnerable to cyber attack.
Neither position says every older device must be binned overnight. Both make the more useful point: unsupported technology must be known, consciously governed and treated differently from a current, supported asset.
A regional lesson: the appliance nobody was watching closely enough
In January 2021, the Reserve Bank of New Zealand disclosed a cyber incident involving a third-party file-transfer application, Accellion File Transfer Appliance (FTA). Attackers exploited a vulnerability in the standalone application and accessed sensitive information. The incident was serious enough that the Office of the Privacy Commissioner later issued a compliance notice, identifying weaknesses in a third-party system and in some of the Bank’s processes.
The point is not to reduce a complex incident to a single technology label. It is this: a specialised system at the edge of an organisation can carry an outsized risk when its lifecycle, vendor exposure and data flows are not being managed as one picture.
That lesson travels across the Tasman. Australian organisations have their own legacy burden — ageing line-of-business systems, industrial and facilities equipment, older network appliances and software that survives because replacement seems disruptive. Public-sector guidance from the Victorian Office of the Information Commissioner describes the familiar risk scenario: support is unavailable, patches are infrequent or expensive, and the system remains business-critical anyway.
This is the confrontation in the device lifecycle story. The organisation knows the equipment is old. The equipment continues to deliver value. Replacing it will cost money and cause disruption. The risk therefore feels deferrable — right up until it is not.
“We didn’t know” is a lifecycle failure
An unsupported device that is not on the register cannot be planned for. An application with no recorded owner cannot be escalated. A network appliance with no mapped dependencies cannot be safely replaced. These are not merely IT documentation problems. They are security control failures.
A credible asset register for in-life management should tell you, at minimum:
- what the asset is, where it sits physically and on the network, and which system it supports;
- who owns it and who supplies patches or technical support;
- which software versions and services are running;
- its warranty, end-of-life and end-of-support dates; and
- what data, integrations, firewall rules and business processes depend on it.
That last point is easy to miss. A replacement project can fail if a forgotten scanner, printer, dock, access-control system, backup process or vendor connection still relies on the old environment. But the answer is not to postpone discovery. It is to do it before the vulnerability forces your hand.
Regular network scans help find the things that evade the spreadsheet: shadow IT, unapproved cloud components, unmanaged devices and unsupported software versions. Cross-reference the scan with the register. Every mismatch is a question worth answering.
Not every legacy asset requires the same answer
There is a tendency to frame this as a binary choice: replace everything or accept the risk. In reality, there is a practical hierarchy.
First choice: remove or replace. If a legacy system is no longer essential, take it out of service. If it is essential but unsupported, a planned replacement is the strongest long-term control. It restores vendor support, reduces technical debt and gives the organisation a chance to simplify dependencies rather than replicate them.
Second choice: isolate. Some equipment cannot be replaced on the timetable anyone would choose. It may run a piece of specialised machinery, support a critical workflow or require a major migration. In that case, reduce the blast radius. Physically isolate it where possible. Separate it on the network. Limit access to the smallest group of people and systems required.
Third choice: compensate and monitor. Put a legacy service behind a modern proxy or virtual patching layer that can inspect traffic and enforce stronger encryption. Remove unnecessary services, close ports, restrict administrative access, monitor its normal behaviour and create an incident-response plan specific to that system. If a critical component must remain, maintain spares where practical; an unsupported asset is not easier to replace after it fails.
These are not loopholes. They are conscious risk treatments. The difference is evidence: a named owner, a documented decision, a review date, controls that are actually in place and a funded route out.
Regulation is catching up with the server room
The legal standard on both sides of the Tasman is not “buy the newest hardware.” It is reasonable protection, judged in context.
In New Zealand, Information Privacy Principle 5 under the Privacy Act 2020 requires agencies to have reasonable safeguards against loss, unauthorised access, use, modification, disclosure and misuse of personal information. In Australia, Australian Privacy Principle 11 requires organisations holding personal information to take reasonable steps to protect it from misuse, interference and loss, and from unauthorised access, modification or disclosure.
For organisations holding customer, employee, patient or financial data, an unpatched and unsupported system is difficult to square with either obligation when a workable alternative — replacement, isolation or compensating controls — has been ignored. The question after an incident will not be whether the equipment was old. It will be whether the organisation knew its exposure, assessed it and acted reasonably.
Insurance asks the same question, earlier
Cyber insurance is not a substitute for lifecycle management. It is a financial backstop that increasingly expects basic controls to exist before the policy responds.
Underwriting questionnaires commonly probe for asset inventory, vulnerability and patch management, multifactor authentication, endpoint protection, backups and incident response. In Australia especially, the market has sharpened its focus on critical vulnerabilities and patching obligations. In New Zealand, the questions are broadly the same because the risk is the same: an insurer needs to understand whether an organisation can identify its exposed systems and address known weaknesses.
The exact terms of a policy matter, and every organisation should test them with its broker. But the operating principle is simple: if you cannot show what you own, who supports it and how you manage end-of-support risk, you will have a harder conversation at renewal — and a much harder one after a claim.
Treat time as an asset-management input
The best lifecycle programmes do not wait for a technology to become a crisis. They turn time into a visible planning signal.
At Divers, that starts with a clearer picture of the estate: asset data, serials, age, location and lifecycle status managed in one place, rather than scattered across invoices, spreadsheets and tribal knowledge. It continues with practical support for the transition — staging and deployment for replacement equipment, secure warehousing and spares where continuity demands them, and Smart Hands support to make the change happen without creating a new operational headache.
The outcome is not a perfectly modern fleet at all times. It is an organisation that knows where it is exposed, has decided what to do about it and can prove the decision was deliberate.
Kōwhai’s old server did not become a risk on the day the vendor ended support. It became a risk the day no one assigned an owner, recorded the deadline or funded the next move.
That is the slow betrayal: equipment that earned trust over years can keep receiving it long after it has stopped earning it.
In the final part of this series, we follow the device out the door. Because retiring an asset without retiring its data is not an ending at all — it is simply handing the next risk to someone else.
---
This article is general information, not legal, insurance or cyber-security advice. Review your own regulatory duties, contractual commitments and insurance policy conditions with appropriately qualified advisers.
Sources and further reading
- [NCSC New Zealand — Asset lifecycle management](https://www.ncsc.govt.nz/protect-your-organisation/asset-lifecycle-management/)
- [ACSC Australia — Managing the risks of legacy IT](https://www.cyber.gov.au/business-government/protecting-devices-systems/legacy-technology-management/managing-the-risks-of-legacy-it-executive-guidance)
- [Office of the Privacy Commissioner NZ — Compliance notice relating to the Reserve Bank cyber attack](https://www.privacy.org.nz/resources-and-learning/decision-notes/compliance-notice-issued-to-reserve-bank-of-new-zealand-following-cyber-attack/)
- [OAIC Australia — APP 11: Security of personal information](https://www.oaic.gov.au/privacy/australian-privacy-principles/australian-privacy-principles-guidelines/chapter-11-app-11-security-of-personal-information)
- [Victorian Office of the Information Commissioner — Legacy systems risk scenario](https://ovic.vic.gov.au/information-security/risk-scenario-2-legacy-systems-case-study/)