Fixable Is Not the Same as Fixed. Where Your Applications Stand on Security Fixes Now, and Where They Should Be.
Some of an operator's own applications stand on software whose maker publishes no more fixes. Here is what we found in published support dates, the four ways to deal with such an application, and the benchmark we would set so the count of applications that cannot take fixes has a last date.
Most lines on the list of overdue fixes look alike. One is different.
Against the dealer portal, the column that should hold a fix says “no remediation available”. The framework the portal was built on reached the end of its life two years ago. Its makers publish nothing for that line now.
Four hundred dealers use the portal every day to activate connections. The exception has been renewed every quarter since. At the board meeting the managing director asks when it will end, and nobody has a date.
The paradox: Every other flaw on the list is waiting for a fix to be applied. This one is waiting for a fix that will never be written.
What We Found
For this article we went through the public record on software that stops receiving fixes: published support dates of common software, the US government’s list of flaws known to be used in attacks, and one survey of IT professionals.
Four findings stand out.
Support ends on a published date, and paid support ends too. For Java 8, an older version of a widely used programming language, standard support in one maker’s edition ended on 31 March 2022, with paid extended support until 31 December 2030. For Windows Server 2012 and 2012 R2, extended support ended on 10 October 2023, and paid security updates ended on 13 October 2026. For SQL Server 2016, extended support ended on 14 July 2026, and paid security updates run to July 2029. Paid support buys time. It does not buy a date that never comes.
A framework line can end while the framework goes on. Apache Struts, an old web framework that many business applications were built on, has 9 flaws on the US government’s list of flaws known to be used in attacks. Its 2.5 line reached end of life on 30 April 2024; newer lines of the framework are still supported. An application built on the old line gets no more fixes for it, and moving to a newer line can take real changes to the application.
Old systems stay because they still work. In one survey of about 500 IT professionals in the US, across industries and company sizes, run by a firm that sells software services and not about telecom, half said that their current system still works was a reason for not modernising. Nothing fails on the day the fixes stop.
Nobody in the public record counts the applications that cannot take fixes. We found no public account, from any operator, of how many of its own applications stand on software past its end date, or of a plan with a last date for them.
Our reading is that an application arrives at “no remediation available” by standing still. Its foundations reach a published end date; the newer version is a rewrite, not a fix; the application still works; and a replacement is priced as one large project and put off as one. The exception then becomes the firm’s policy for that application, written one quarter at a time.
What our review does not show: These dates and figures are cross-sector, and which of these products operators run was not researched. We found no case of an operator harmed through an unfixed flaw in a billing, customer or portal application, no figure for what paid support costs, and no Indian or mid-size operator with this problem on the record. The Java 8 dates are one maker’s edition. The survey was run by a vendor, in the US. The opening scene is imagined. That an application reaches this point by standing still is our reasoning.
What a Standing Exception Does Not Tell the Board
A standing exception tells the board that a risk is known. It does not tell it four things.
It does not say how many applications are in the same position.
It does not say whether each can be upgraded with modest changes, has paid support until a date, or can only be rebuilt. Those answers cost different amounts.
It does not say which part of the application is most exposed, and so where a rebuild would start.
And it does not say when the exception ends. “To be confirmed” is not a date.
The gap we see: an operator with one or two applications that cannot take fixes needs, more than another renewal, a count of those applications, our recommendation and a written decision for each (upgrade, paid support until a date, or rebuild), and for the ones that can only be rebuilt, a plan that moves them one module at a time, so that the count falls and the last exception has a closing date.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Deal With an Application That Cannot Take Fixes, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Renew the exception, with guards placed around the application by your security team | The application is about to be switched off, and the guards are judged enough until then | The flaw is still inside; the exception becomes permanent, and more is built on the application |
| Buy paid extended support, where it exists | A paid edition still issues security updates, and its end date is far enough away | It ends too, and for some software it has already ended |
| Upgrade the software underneath to a supported version | The newer version is close enough that the application moves across with modest changes | For some applications the newer version is a rewrite; your team or vendor does the upgrade and checks it |
| Rebuild the application one module at a time, onto software that is still supported | The part with no supported version left, where an upgrade would be a rewrite anyway | It costs the most and takes months; the old application is exactly as exposed until the last module has moved |
Our recommendation: first find out which of your applications are in this position and which answer fits each: the assessment records what each stands on, its support dates and what ties it there, so upgrade, paid support and rebuild are compared in one place. Rebuild only the part with no supported version, one module at a time, while the old application keeps running. Until the last module has moved, the old application is your team’s to keep running and guard, and it is exactly as exposed as before. We do not apply fixes, upgrade software in place, scan, monitor or guard anything, or work on network devices or the network.
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 applications, 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 |
|---|---|---|---|
| Own applications listed with what they stand on and its support dates | Known by memory | Every application listed with its framework, libraries, database, versions and published support dates | The map of the applications as they stand |
| Applications on software that gets no more fixes | Not counted | Counted, each with our recommendation and a written decision: upgrade, paid support until a named date, or rebuild | The risk register |
| Overdue fixes marked with a reason | ”Deferred: may affect service” | Each marked by your security team: can go in now, blocked by something named, or cannot be applied | The risk register |
| Modules of a rebuilt application moved | One large replacement, priced once and put aside | A staged plan; so many modules accepted, so many to go | The staged plan, reviewed at each stage |
| Old functions matched to new ones, in each rebuilt module | Not recorded | Each function of the old module linked to its replacement | The traceability matrix |
| Standing exceptions with a closing date | ”To be confirmed” | The count of applications that cannot take fixes falling, and the last one’s exception tied to the last module | The risk register and the staged plan |
The starting points above are what the public record suggests 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 telecom operator.
How We Work With You
- We listen: a free Reliability Review. A first conversation about the application your team cannot fix, and the exception it carries. 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.
- 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. Here the system is the applications your firm built or had built, and the assessment records what each one stands on (framework, libraries, database, versions and support dates) and what a fix underneath would touch or break, for each overdue fix, so your security team can mark it, and for each application on software that gets no more fixes, what an upgrade, paid support or a rebuild would involve, and our recommendation; the decision is yours. 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. Here that means only an application whose underlying software gets no more fixes, rebuilt module by module beside the old one, onto software 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 above. 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.
This approach has limits. A rebuild costs far more than renewing an exception, and it takes months. Until the last module has moved, the parts that remain still cannot take fixes and are exactly as exposed as before; your own team keeps them running and guarded. We do not apply security fixes, upgrade software in place, or scan, monitor or guard the old application. We do not work on network devices or the systems that run the network, or inside a packaged billing product. The rebuilt application will need fixes of its own, applied by your team, for as long as it lives: it is fixable, which is not the same as fixed. We promise no protection from attack. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP; a rebuilt module runs on React, Node.js, Python or Java. We have no published case of this work for a telecom operator.
At the end you hold the map of what each application stands on, the risk register with what each overdue fix would touch and the options, with our recommendation, for each application that cannot take fixes, the traceability matrix and code for every module we rebuilt, and the filled-in benchmark. Applying fixes, and keeping the rebuilt application current, are your team’s.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | The application customers use every day stops being the one the firm cannot repair. |
| CTO or CIO | The application moves, one module at a time, onto software whose maker still issues fixes, and the team can keep it current in the ordinary way. |
| CFO | Spend goes to the one application that holds the firm back, released module by module, each paid for when accepted. |
| CISO | The standing exception for an application that cannot be fixed gets a closing date. |
| Head of regulatory affairs | The item on the risk register that read “no remediation available” shows a plan with stages. |
None of these means an application cannot be attacked.
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| Apache Struts has 9 flaws on the US government’s list of flaws known to be used in attacks, and its 2.5 line reached end of life on 30 April 2024. | We do not apply fixes or upgrade frameworks in place. Where an operator’s own application stands on a line that gets no more fixes, and an upgrade would be a rewrite, we rebuild it one module at a time while the old one keeps running. |
| Paid security updates for Windows Server 2012 ended on 13 October 2026; for SQL Server 2016 they run to July 2029. | We do not upgrade operating systems or databases, or host anything. The assessment records which of an operator’s own applications are tied to such software, and what ties them, so the operator can choose between upgrade, paid support and rebuild. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We set the benchmark before the first module moves, so that “no remediation available” becomes a count that falls to zero on a date.
Sources
In this issue
Known security fixes never applied
Research note 1
Known Flaws Stay Open for Years. What Nobody Writes Down Is What the Fix Would Break.
Known security flaws stay open at operators because nobody writes down what the fix would break. What the public record shows, four ways and our benchmark.
Research note 2
Applied, and Checked by Your Own Team. Four Ways to Deal With Security Fixes That Keep Waiting, Weighed.
Indian operators must report security incidents within hours. What that means when your applications carry fixes nobody dares apply, four options weighed.
Issue study
Known Fixes, Still Waiting
Security fixes that wait for years on an operator's own applications: an attack wave on network devices using a flaw with a published fix, the options.
More from Telecom
Safety of life services depend on the old network
Operators Can Count the Accounts They Marked. What Nobody Can Count Is Who Was Never Asked.
Too risky to move off old systems
You Are Asked to Approve a Move Nobody Can Price. Where Your Replacement Plan Is Now, and Where It Should Be.
Customer data wrong or incomplete