When One Server Has No Second Lock

1. At a Glance

Issue study · From the public record. None of the organisations named here was an IOanyT client, and IOanyT had no part in the events described. Everything about them comes from the public record.

Organisation type	A large US processor of health insurance claims, whose attackers used a server without a second login check, set beside a national health service’s older case and India’s position
Size band	The claims processor: very large. Our reader: a mid-size hospital group, laboratory chain or pharma company
Region	The claims processor: US. The health service: Europe. The wider picture and the data protection date: India
The decision at stake	What to do with old systems that cannot take the controls the rest of the organisation now has, or that fell outside them
The public outcome	Ransomware in 2024. A ransom of tens of millions of dollars was paid, and the data of a very large share of Americans was taken. The record does not say why the server lacked the check
Why it matters to a mid-size health organisation	Most have the basic controls “everywhere except” a few old systems. The question is whether those systems are brought under the controls on a plan, or stay the exception until something forces the issue

2. The Business Problem, in the Buyer’s Words

“We rolled out a second login check last year, and I reported it to the board. Six old applications are in the footnote. Two of them have a whole department on one shared login, and none of them can tell me who opened a patient’s record. There is also the old patient system we were meant to switch off after the migration. Now a hospital group wants our laboratory work, and question twelve on its form asks whether every system has these controls. I have written ‘partially’ three years running.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The organisation is caught between a security rule it has adopted and old applications that cannot carry it. Renewing the exception looks cheaper every year, and the partial answer stays the same.

3. What We Found

Method. We went through the public record on basic security controls missing from old healthcare systems: a US congressional committee’s account of the attack on a large claims processor, reporting of the review after the attack on one European national health service, a trade-press article, a news summary of a US inspector general’s report, an Indian medical journal, attack figures for Indian healthcare, and reporting of the dates for India’s data protection rules, from 2021 to 2026.

One server without a second login check. In 2024 a large US processor of health insurance claims was hit by ransomware.

What	Public record
How the organisation was described	As an older company running older technology (its parent company’s chief executive, at a congressional hearing)
The server the attackers used	It did not have a second login check
Ransom	Tens of millions of dollars, paid
Data taken	Of a very large share of Americans
Cost	Billions of dollars in total, according to one vendor-written trade-press article

Protections that went out of date. After the 2021 attack on one European national health service, reporting of the review records that it was still using old systems with known security weaknesses, and that its protection software had not been updated for more than a year. An older case.

Servers waiting for a move. According to the same vendor-written article, a large US supplier of health record systems said an attacker used stolen login details to reach old migration servers that had not yet been moved to its cloud, and copied data out. No year and no impact figure are given.

The wider picture. A news summary of a report by the US health department’s inspector general lists “the sector’s reliance on legacy technology” among the limits on improving cybersecurity. An Indian medical journal describes hospitals as having “heterogeneous hospital information systems, variable security maturity across institutions”. One security vendor’s data puts attacks on Indian healthcare organisations at several thousand a week each over six months, more than twice the figure for the average Indian organisation. In an article of 11 May 2026, a business-advisory publication writes that 13 and 14 May 2027 “is widely regarded as the ‘hard enforcement’ date” of India’s data protection rules (DPDP), with penalties up to 2.5 billion rupees for major violations. We do not say what those rules require.

Our reading of why the controls are missing. These four are our reasoning from the cases above. None is a review’s or a regulator’s finding.

1. The old application checks passwords in its own code, assumes one login per department, or keeps no record of use, so the control cannot simply be switched on.
2. Nobody has a written record of how the application handles logins and access, so nobody can predict what a change would break.
3. The system fell outside the programme: kept after a migration, or brought in with an acquisition, and on none of the security team’s lists.
4. The exception has no plan behind it: “remediation planned” is written each year, with no stages, no owner and no date.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Put compensating controls around the old application	It will move or be retired soon, on a set date	No personal logins and no record of who viewed what; becomes permanent without a date	Right only as a bridge with an end date
Harden the application’s code so it can take the control	It is still needed, its code can be read, and the change is contained	A change to a login nobody understands can stop a department	Right where the assessment shows the application can take the control
Replace the parts that cannot take the control, module by module	The login, accounts or records are built into every screen	Several stages; two systems side by side for a time	Our recommendation for what cannot be hardened
Retire the systems left behind by a migration or an acquisition	They do a few leftover jobs that can move elsewhere	Every remaining use must be found first	Our recommendation for what was left behind

5. Our Recommendation, and the Decision It Asks of the Board

For the applications a health organisation built or had built for it (billing, registration, laboratory and pharmacy applications, portals and reporting): assess first. Write down how each old application handles logins, accounts and records of use, and why each missing control is missing. Then harden what can take the control, replace what cannot, one module at a time with the old application still running, and retire the systems left behind by migrations and acquisitions. Put the systems that hold the most sensitive data, and the most exposed, first. Compensating controls are a bridge with an end date. The organisation’s own security team chooses, supplies and runs the controls; IOanyT does not.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the organisation’s own figures, taken in the first review.

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 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 that stays 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 listed, with what it still does and the date it stops	The staged plan
What the answer on the form rests on	”Remediation planned”	Named stages with dates, some already complete	The staged plan and the acceptance records

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the old applications on the exception list, the systems left behind, and the questions being asked about them. 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 study 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.
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. A traceability matrix links every old function to its replacement. 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.

8. What the Client Would Own

• The map and the specification: what each old application does, in writing and portable to any supplier.
• The risk register: what the assessment found, listed before any price is set.
• The traceability matrix: every old function linked to its replacement, with how it was checked.
• The code: the new modules are the client’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

9. What This Approach Does Not Cover

• IOanyT does not supply security controls or monitoring: no login-check product, protection software, firewall or monitoring service. The client’s own security team chooses, supplies and runs the controls.
• IOanyT does not keep the old systems protected or running while their applications wait. The client’s own team or vendor does that. Until a control is in, or an application has moved, the system is as exposed as before.
• Nothing here is a promise that an attack will not happen, or that IOanyT’s work protects patients or keeps care running.
• IOanyT does not offer a compliance, audit or legal service, does not say what the DPDP Act or any other rule requires, does not complete questionnaires for a client, and cannot make an organisation compliant.
• IOanyT does not work on packaged health record products, medical devices or their software, or pharma plant control systems.
• Clinical acceptance of any module is the organisation’s own decision, made by its clinicians.
• This study does not say IOanyT would have prevented the events described, or that IOanyT has done this work for a healthcare organisation.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
House Energy and Commerce Committee, 2024	The claims processor: the description, the server without a second login check, the ransom, the data taken
Vendor-written article in trade press, 26 May 2026	The claims processor’s cost estimate; the health record supplier’s migration servers
HIPAA Journal, 2021	One European national health service
HIPAA Journal, 23 January 2026	US health department’s inspector general (news summary)
Indian Journal of Critical Care Medicine, 25 May 2026	Indian hospital information systems
News report of a security vendor’s data, updated 2 July 2025	Attacks per week on Indian healthcare organisations
A business advisory firm’s briefing, 11 May 2026	DPDP enforcement date as described, and penalty ceiling

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 old 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 →