Unsupported Software Is Now a Board Matter. Most Firms Cannot Say Where It Is.
We reviewed the public record on unsupported software in financial services. Here is what we found, what it holds back, the options, and the benchmark we would set.
The auditor’s request is one sentence long. Please list all hardware and software in use that is past its maker’s end of support, with the plan for each.
Your technology head forwards it to three teams. Infrastructure sends a spreadsheet. Applications sends another. The vendor who looks after the loan system sends a third. The three do not agree.
Then someone mentions the server under the collections application. Nobody has restarted it in years, because nobody is sure it would come back.
The paradox: You are asked to avoid unsupported software, and you cannot say where it is.
What We Found
Before we suggest anything to a lender, we study its sector. For this article we went through the public record on unsupported software in financial services: the RBI’s direction on IT governance, its enforcement actions as reported in the press, makers’ published support dates, and the US government’s list of software flaws known to be exploited, from 2024 to 2026.
Four findings stand out.
The regulator has made it the institution’s problem. The RBI’s direction on IT governance, in force since 1 April 2024, says regulated entities “shall avoid using outdated and unsupported hardware or software”. The sentence is addressed to the institution, not to its IT department. A finding under it lands on the board’s table.
The inventory itself is under scrutiny. In April 2024 the RBI barred Kotak Mahindra Bank from taking new customers through its online and mobile channels and from issuing new credit cards. Among the areas the RBI cited were IT inventory management and patch and change management. The restrictions lasted about ten months.
The dates are published years ahead, and nothing happens on the day. Makers announce end of support well in advance. Standard support for IBM i version 7.4, for example, ended on 30 September 2026, with a paid extension available to 2029. The hard part is not finding the date for one product. It is knowing every product you run, layer by layer: the application, the framework under it, the application server, the database, the operating system and the hardware.
Old building blocks are attacked in practice. As of 11 October 2026, the US government’s list of flaws known to be exploited held 9 entries for Apache Struts, a framework many business applications were built on, and 13 for WebLogic Server, an application server. On a supported version, a fix exists. On a version past its end date, the next flaw will not get one.
What our review does not show: The enforcement case is a large bank, and the record gives only the headings the RBI cited. The list of exploited flaws does not show that any particular firm is exposed; that depends on the version it runs. We found no public case of a mid-size NBFC, broker or insurer with this problem, and no published figure for what extended support costs. We use the cases as lessons. We do not say mid-size firms have had the same events.
What Waits While the List Is Missing
Unsupported software is usually discussed as a security risk. Our reading of the record is that it is also a growth problem.
Look again at what the regulator restricted: new customers online and new credit cards. Both are growth. When the state of a firm’s IT becomes a regulatory finding, new business is the first thing held back.
The second cost is quieter. A firm without a standing record rebuilds the list every time someone asks: for the auditor, for the regulator, for a new security alert. Each time it is assembled in a hurry and is out of date a year later.
The third is what cannot be built. A new product built on a stack that no longer gets fixes inherits its risk, so the plan waits.
The gap we see: most firms running old systems can say that some of their software is out of support. Few can say which, what depends on it, and when each part will move. A firm that holds that record answers the auditor in a day and spends the rest of the year on its plans. A firm that does not keeps answering the same question.
This is our reading of the evidence. It is not a measured market figure.
Four Ways Forward, Weighed
A firm with unsupported software in its systems has four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Pay for extended support and keep the system | The maker offers it, and a date to leave is already set | It buys time and nothing else. The system is the same next year, and the option ends when the maker ends it |
| Upgrade in place to the maker’s newer version | The application runs on the new version with small changes | Old applications often need the old framework and server below them. The upgrade turns into a rebuild |
| Replace the whole system in one project | The system is small and well documented | One date carries all the risk. The list is still needed first, and it is usually missing |
| Write down what runs, then leave in stages, most exposed parts first | The system is old, layered and customised | It runs over several stages, not one quarter. The record will show more than anyone expects |
Our recommendation: start with the record, then leave in stages, moving the most exposed parts first. Treat extended support, where it is offered, as a bridge with an end date, not as the plan. We do not patch old software in place or sell extended support. While each part waits its turn, your current team or vendor keeps it protected.
Whichever option is chosen, the first step is the same: a written record of what runs, who still fixes it and what depends on it.
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 |
|---|---|---|---|
| A record of what runs | Three spreadsheets that do not agree | One record of every application in scope and every layer under it | The record is compared with the servers, databases and code |
| Items past their maker’s support date | Not counted, or counted only when asked | Each one listed, with what depends on it | The risk register |
| A plan against each item | ”Upgrade planned” beside every line | A stage, in order, against each item | The staged plan |
| Who hears it first | The auditor | The board, from its own team | Board papers |
| The count over time | Rebuilt from scratch at each audit | Falling with each stage | Reported at every review |
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 lender.
How We Work With You
- We listen: a free Reliability Review. A first conversation about the system, what the auditor or regulator has asked, and what is waiting on the answer. You leave with a short written note of what we found.
- 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.
- 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.
- If you approve, we build. We replace a system one module at a time while the old one keeps running, onto technology that is still supported. 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.
- 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.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | The board hears it from its own team, with a plan attached, before an auditor raises it. |
| CTO or CIO | One record of what runs, who still fixes it and what depends on it. The next audit question already has its answer. |
| CFO | Replacement becomes a planned line released in stages, not an emergency request in the middle of the year. |
| CISO | Each unsupported component is located, with what depends on it, so controls go where the exposure is. |
| Risk and compliance | A plan in stages to answer the finding, and progress to report against it at every review. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| The RBI cited Kotak Mahindra Bank’s IT inventory and its patch and change management among its reasons for restricting the bank. | Our assessment produces a map of the system as it stands and a risk register: a record the firm holds before anyone asks for it. Taking a plan to the regulator is the firm’s own job. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The record is yours to keep, and it answers the auditor’s question before it is asked.
Sources
In this issue
Unsupported software and hardware
Research note 2
Your Software's Maker Has Set the Date. The Plan Can Still Be Yours.
Extended support buys time and nothing else. What staying on software past its maker's date costs a lender, four ways to answer the letter, and our benchmark.
Research note 3
"Accepted Again" Is Not a Plan. A Shrinking Register Is.
Past end of support, a new flaw has no fix and is accepted again. The benchmark we would set to close those gaps, and the order the exposed parts move.
Issue study
When the Maker Stops Fixing the Software
An issue study from the public record: the RBI's position on unsupported software, a shared core retired by its vendor, a lender's options and our benchmark.
More from Banking
Fear of a failed system replacement
Before You Ask What a Replacement Costs, Ask What It Is Worth.
Outages at peak load