Old Health Applications Lack the Basic Locks. The Reason Is Inside the Application.

The security team has finished a year-long project. Every system in the hospital now asks for a second login check as well as a password.

The report to the board says so, with one footnote. Six older applications are excluded. Their login screens cannot ask for anything beyond a name and a password, and on two of them a whole ward shares one account.

The board approves the report. The footnote is in smaller type.

What We Found

Before we suggest anything to a hospital group, a laboratory chain or a pharma company, we study its sector. For this article we went through the public record on basic security controls missing from old healthcare systems: a US congressional committee’s account of one attack, reporting of the review after another, a trade-press article, an Indian medical journal and attack figures for Indian healthcare, from 2021 to 2026.

Five findings stand out.

One server without a second login check was the way in. In early 2024 a large US processor of health insurance claims was hit by ransomware. At a congressional hearing later that year, its parent company’s chief executive described it as an older company with older technologies, and said the server the attackers used did not have MFA on it. MFA is a second login check, such as a code sent to a phone. A ransom of more than 20 million dollars was paid, and he estimated that the data of perhaps a third of Americans was taken. The record does not say why that server lacked the check.

Basic protections can go quietly out of date. After the ransomware attack on one European national health service in 2021, reporting of the review records that it was still using older systems with known security weaknesses, and that its antivirus definitions had not been updated for more than a year. This is an older case, from a national health service far larger than most of our readers.

Old servers waiting for a move can be a way in. According to a trade-press article written by a technology vendor’s executive, a large US supplier of health record systems said that an attacker used stolen login details to reach old migration servers that had not yet been moved to its cloud, and copied data out. The article gives no year and no figure for the damage.

In India, security maturity varies. An Indian medical journal describes hospitals as having “heterogeneous hospital information systems, variable security maturity across institutions”.

The pressure on Indian healthcare is high. One security vendor’s data puts attacks on Indian healthcare organisations at more than 8,000 a week each over six months, against just over 3,000 for the average Indian organisation, and the report links this to outdated systems and growing digitisation.

The record does not explain why old systems lack these controls. Our reading is that it is rarely a lack of will. The old application checks the password in its own code, assumes one login per department, and keeps no record of who opened what. The control cannot simply be switched on inside the application, because the obstacle is in its own code.

What Waits Behind “Not Possible on This System”

A missing control on an old system is usually filed as a security gap and accepted. Our reading is that it also holds the organisation in place.

The first cost is the exception itself. “Not possible on this system” is written once, then renewed every year. Renewing takes a signature. Ending it takes someone to change the application, so the signature wins.

The second cost is the answer the organisation can give. When a partner, an insurer or an auditor asks whether every system that holds patient data has these controls, the honest answer is “everywhere except” the oldest systems, which hold the most history.

The third cost is spending. A login product bought for the whole organisation never reaches the applications that cannot use it.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Bring an Old Application Under the Controls, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Put compensating controls around the application: limit which desks can reach it, watch its traffic	The application is due to move or be retired soon, and the date is set	On their own, they do not tell you who opened a record, and limiting desks does not stop a stolen password. Without an end date it becomes permanent
Harden the application’s code so it can take the control	The application is still needed, its code can be read, and the change is contained	Changing a login nobody understands can lock out a ward. It needs tests around the application first
Replace the parts that cannot take the control, module by module	The application’s login, accounts or records are built into every screen	It runs over several stages, and for a time two systems run side by side
Retire the systems left behind by a migration or an acquisition	The system does a few leftover jobs that can move elsewhere	Somebody, somewhere, still depends on it, and the leftovers are usually the awkward parts

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own systems, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Systems on the exception list	Renewed each year, the same length or longer	Each exception tied to the stage that ends it, and shrinking	The exception list beside the staged plan
The reason each control is missing	”Not possible on this system”	A written reason for each, from the application itself	The specification and the risk register
Applications with a login for each person	Shared department logins on the oldest systems	Every application able to take a personal login	The specification, then each accepted module
Applications with a record of who viewed what	No record on the oldest systems	Every application that holds patient data able to keep one	The specification, then each accepted module
Leftover systems with an end date	Not counted, or found by accident	Each one listed, with what it still does and the date it stops	The staged plan

The starting points above are what the public cases show and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a healthcare organisation.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the old applications on your exception list, and what is waiting on the answer. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module. Where a module touches clinical work, accepting it is your clinicians’ decision.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

Where the assessment shows that an application can be changed to take a control rather than replaced, the staged plan says so. Your security team decides which controls each system needs, and runs them once they are in. We do not work on packaged health record products, medical devices or plant control systems.

What changes for the business:

Role	What they gain
CEO	The organisation knows which old systems lack a basic protection, with a plan for each.
CTO or CIO	A written record of how each old application handles logins, access and records of use, so a control can be added without breaking it.
CFO	Security spending reaches the systems that need it most, and is not spent on tools an old application cannot use.
CISO	Each missing control has a reason written beside it and a way to add it. “Not possible on this system” stops being the last word.
Risk and compliance	A written account, system by system, of which controls exist, taken from the systems and not from the policy.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
At the US claims processor, the server the attackers used had no second login check.	Our part is narrower than this case. We do not supply or run login checks. Where an old application cannot take one, we write down why, and change or replace that part so the organisation’s own check can be applied.
At one European national health service, protection software had gone more than a year without its updates.	Our part is narrower. We do not run protection software. Our assessment records what an old application depends on, so the organisation’s own team can see what is no longer kept up to date.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We start inside the application, because that is where the missing control is blocked.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →