---
type: Leaf
title: The legacy app nobody is maintaining is still holding customer data
description: What a web application accumulates when nobody maintains it, why the legal position moved in 2025, and the questions to ask about one you own.
resource: https://nationaldigital.com.au/digital-product-development/custom-web-applications/unmaintained-application-security/
tags:
  - digital-product-development
  - Custom Web Applications
  - Application Security
  - Application Maintenance
  - unmaintained application security
  - legacy application security review
  - application security assessment
  - dependency vulnerabilities
  - end of support framework version
  - Privacy Act reasonable steps
  - APP 11 security of personal information
  - inherited application maintenance
timestamp: '2026-09-09T00:00:00.000Z'
language: en-AU
publisher: National Digital
author: Tara Buckley
authorRole: COO
readingTimeMinutes: 8
wordCount: 1692
datePublished: '2026-09-09'
dateModified: '2026-09-09'
pillar: digital_product_development
canonical: https://nationaldigital.com.au/digital-product-development/custom-web-applications/unmaintained-application-security/
---

_Home — Digital Product Development — Custom web applications — The legacy app nobody is maintaining is still holding customer data_

# The legacy app nobody is maintaining is still holding customer data

What happens to a hand-built web application that nobody maintains, and the questions to ask about one you own.

**Quick answer:** An unmaintained web application stops receiving security patches and stays frozen at the practices of the year it was written. Automated dependency updates are the floor; after that, ask for the endpoint list, proof that permission checks run, and an inventory of the personal information held.

## About this page

- Written by Tara Buckley, COO
- 8 min read
- Updated 9 September 2026

_Custom Web Applications — Application Security — Application Maintenance_

## What is the security risk in a web application nobody maintains?

An unmaintained application keeps running on dependencies, a framework and a language version that have stopped receiving security patches, while the practices considered safe when it was built have moved on without it.

**Additional Context**

The patches are the visible half. Authorisation, secrets handling, file uploads and dependency monitoring have also moved on, and none of that reaches code nobody opens. Since the Privacy and Other Legislation Amendment Act 2024, the reasonable steps an organisation must take to protect personal information expressly include technical and organisational measures.

_High confidence · Verified 9 Sept 2026_

*How It Happens*

## How applications end up here

Over the past few months our team ran security reviews across a set of older applications built between 2019 and 2022. Hand-coded originally, still in daily use, none of them under an active maintenance contract. What came back was consistent enough to show the problem is not any one build or any one developer. It is a category of risk that a lot of Australian businesses are carrying right now without knowing it.

The path is always the same, and it is not the result of anyone being reckless. An application gets built. It works. Budget moves on to the next thing, because technology costs money and the thing you can see on the screen is working perfectly well. Nobody is asking for new features, so nobody is opening the codebase.

"If it isn't broken, don't fix it" is a defensible position for a piece of machinery. It is a much weaker position for software, because software sits on a foundation of other people's code that keeps moving whether you touch yours or not. The framework goes end of life. The language version stops receiving security patches. The vulnerabilities being published every week are cumulative, and the gap between what your application runs and what is currently supported grows.

There is a second gap that gets discussed far less, and it is the more interesting point. Best practice has moved enormously over the last ten years. How authorisation should be structured, how identifiers in a link should be signed, how secrets should be stored, how uploads should be handled, how dependencies should be watched. The frameworks have moved with it, to the point where [the safe way to build something is now usually the default way](/digital-product-development/custom-web-applications/security-implementation). But none of that reaches code that nobody opens. An unmaintained repository does not only miss security patches. It misses a decade of the industry getting better at this, and it stays frozen at the standard of the year it was written.

Our own pipelines force dependency updates before code merges, and over the past twelve months that has become an area of real focus. None of it is of any use to an application nobody is maintaining. That is a different problem from [modernising the architecture underneath an application](/platform-engineering/application-performance-optimisation/legacy-application-modernisation), where the question is how the systems are put together. Here the code itself is what nobody has opened.

Eventually business arrives at a genuinely uncomfortable position. The application is too far behind to justify the cost of upgrading, but too embedded to switch off, and there is no business case for a rewrite because from the outside nothing is wrong. Meanwhile the thing is still sitting there holding customer records, addresses, payment details, and in some cases health or children's information.

*The Obligation*

## The legal position has moved

Twelve months ago that could reasonably fly under the radar. It cannot now.

The Privacy and Other Legislation Amendment Act 2024 is in effect, and two parts of it matter for this conversation. First, it clarified that taking "reasonable steps" to protect personal information expressly includes implementing appropriate technical and organisational measures. Application security is no longer just good engineering practice. It is named in the obligation. Second, since 10 June 2025 there is a statutory tort for serious invasions of privacy, which means an individual can now bring an action directly rather than waiting for a regulator to act. That sits alongside a tiered civil penalty regime and expanded powers for the Information Commissioner. The same Act requires a Children's Online Privacy Code to be registered by 10 December 2026, which matters to anyone whose application is likely to be accessed by children.

### And it is about to move again

On 31 August 2026 the Attorney-General's Department released the exposure draft of the Privacy Amendment (Personal Data Protection) Bill 2026, the second and much larger tranche of reform. It is not law yet and consultation closed on 18 September, but the direction is clear. It proposes a single "fair and reasonable" test for how personal information is handled, and it would require notification to the Information Commissioner within 72 hours of becoming aware of reasonable grounds to believe an eligible data breach has occurred, a timeframe the consultation paper lines up with the Security of Critical Infrastructure Act 2018 and the Cyber Security Act 2024.

Seventy-two hours is not enough time to work out what happened in an application nobody has opened in three years.

None of this is legal advice. But you do not need to be a lawyer to see that "we inherited it and nobody maintains it" is heading towards not being an answer. The same obligation applies to us, which is why we publish our own [information security and privacy posture](/governance/information-security-and-privacy) rather than describing it on request.

## The minimum, and it is genuinely a minimum

Automating the dependency updates is the floor. Everything after it is a question to put to whoever holds your code, and the answer you want is a list rather than a reassurance.

- Difficulty: beginner
- Audience: general_manager

**Tools:**
- Access to the repository or the developer who holds it
- The framework and language versions in production
- A list of who still has server and administrator access

1. **Automate the dependency updates first**: This is the floor, and it should run in the background whether or not anyone is actively working on the application: security patches applied automatically, and a weekly check that fails loudly when something new is published. It costs very little to set up, and not having it is what turns three quiet years into a long list of known vulnerabilities.
2. **Ask which endpoints require a login**: Ask for the list of every endpoint and which ones are behind authentication, not a reassurance that they all are. Routes can read as protected in the code without being protected in practice. This is usually the highest-value hour anyone will spend on the application.
3. **Confirm the permission checks actually run**: Authorisation logic that exists in the code is not the same as authorisation that works. It can be disabled, bypassed, or written so that it always passes. Ask for a test that proves a user of one permission level cannot reach another's data.
4. **Check the framework and language against end of support**: Look up the end of support dates for the framework and the language version in production. If either is past it, no security fixes are being published for the thing your application is built on, and no amount of care in your own code changes that.
5. **Ask what happens after a thousand password attempts**: Rate limiting on failed logins, password resets and registration is ordinary work that is easy to leave out. Ask what the application does on the thousandth attempt, and whether the answer changes if the request arrives at the server directly rather than through the CDN or firewall in front of it.
6. **Ask whether uploaded files can be reached with the link alone**: Uploaded documents and generated reports are often stored where anyone holding the URL can fetch them, with a predictable identifier standing in for a permission check. Ask whether a file belonging to one customer can be reached by another, and whether identifiers in links are signed.
7. **Ask where the credentials live**: Ask whether any credential appears in the repository, in documentation, in seed or sample data, or in a shared inbox. Ask who can reach the server directly, and how many people still hold administrator access from projects that ended years ago.
8. **Know what data you hold and where**: List what personal information the application holds, where it is stored, what is backed up and what has been copied into other systems. If notification of an eligible data breach becomes a 72-hour obligation, this is the question that decides whether you can answer in time.

**Outcome (Automate the dependency updates first):** Patches arrive without anyone remembering to look for them

**Outcome (Ask which endpoints require a login):** A written list you can check rather than an assurance

**Outcome (Confirm the permission checks actually run):** A test that fails if the check is removed

**Outcome (Check the framework and language against end of support):** A supported version, or a dated plan to reach one

**Outcome (Ask what happens after a thousand password attempts):** A known limit, enforced where it cannot be stepped around

**Outcome (Ask whether uploaded files can be reached with the link alone):** File access decided by a permission check, not by obscurity

**Outcome (Ask where the credentials live):** Secrets in a secrets manager, and an access list that matches who works here

**Outcome (Know what data you hold and where):** An inventory that exists before you need it

**Summary:** Automate dependency updates, then ask for the endpoint list, proof the permission checks run, the end of support dates, and an inventory of the personal information held.

*The Point*

## What it comes down to

None of this is exotic. There is no sophisticated attack chain in it. It is ordinary work that stopped being done, in applications that looked fine because looking fine is exactly what an unmaintained application does right up until it doesn't.

If you own software that holds other people's information and you cannot name the person responsible for patching it, that is the finding. You do not need a review to tell you that one.

We are happy to talk to anyone sitting on an application in this position. Checking one is a much smaller piece of work than most people expect, and considerably smaller than the alternative. It is the same ground a [written review of the code, the infrastructure and the security posture](/services/platform-health-check) covers, and it is where [support for an application somebody else built](/services/product-support) begins.

## Sitting on an application nobody maintains?

Checking one is usually a much smaller piece of work than people expect, and considerably smaller than the alternative. A Platform Health Check reviews the code, the infrastructure and the security posture, and the report is yours whether or not you go further with us.

- [Book a conversation](https://calendly.com/cameron-at-national-digital/discovery)
- Email: enquiries@nationaldigital.com.au
- Phone: 1300 800 855

## Related reading

- [How to implement modern web frameworks for Australian business compliance requirements](/digital-product-development/custom-web-applications/modern-web-frameworks/)
- [Professional security implementation solutions for Australian businesses](/digital-product-development/custom-web-applications/security-implementation/)

## Related

**Parent:**
- [Custom web applications](/okf/digital-product-development/custom-web-applications.md)

**Related:**
- [How to implement modern web frameworks for Australian business compliance requirements](/okf/digital-product-development/custom-web-applications/modern-web-frameworks.md)
- [Professional security implementation solutions for Australian businesses](/okf/digital-product-development/custom-web-applications/security-implementation.md)

# Citations

- [OAIC - 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) — Subclause 11.3 notes that reasonable steps for securing personal information include technical and organisational measures.
- [OAIC - Statutory tort for serious invasions of privacy](https://www.oaic.gov.au/privacy/your-privacy-rights/more-privacy-rights/statutory-tort-for-serious-invasions-of-privacy) — The statutory tort commenced on 10 June 2025, giving individuals an avenue to seek redress for privacy harms in the courts.
- [Attorney-General's Department - Privacy Reform consultation on exposure draft legislation](https://consultations.ag.gov.au/rights-and-protections/privacy-reform/) — The exposure draft Privacy Amendment (Personal Data Protection) Bill 2026 opened for consultation on 31 August 2026 and closed on 18 September 2026.
- [Attorney-General's Department - Privacy Reform consultation paper (exposure draft Bill 2026)](https://consultations.ag.gov.au/rights-and-protections/privacy-reform/user_uploads/consultation_paper.pdf) — "The proposed amendments provide that an entity must, within 72 hours of becoming aware of reasonable grounds to believe that an eligible data breach has occurred, give the Information Commissioner a statement..." and "The 72-hour notification period aligns with reporting timeframes in other relevant Australian frameworks such as the Security of Critical Infrastructure Act 2018 (Cth) and the Cyber Security Act 2024 (Cth)." The paper also proposes "a single 'fair and reasonable' test for the collection, use and disclosure of personal information".
- [OAIC - Children's Online Privacy Code](https://www.oaic.gov.au/privacy/privacy-registers/privacy-codes/childrens-online-privacy-code) — The Privacy and Other Legislation Amendment Act 2024 requires the Code to be registered by 10 December 2026.