Legacy technology is argued as a question of how likely an attack is, when the larger exposure is how long the business stays down once viable backups have already been found.
The target was not the problem
In Fenix24’s State of Recoverability Report, reported by Infosecurity Magazine on 15 September 2026, only four of more than 800 assessed clients came close to their own target of restoring partial business operations within 24 to 48 hours. None reached full operational capacity inside that window.
That is one firm’s engagement data, covering more than 800 clients and more than 500 recoveries, a self-selected population rather than a random sample. Even so, the interesting part is not that targets get missed, which should surprise nobody who has watched an outage. The interesting part is why. That data and one unusually well-documented public case point at the same two constraints, and neither is the backup.
What exposure became visible
A recovery time objective is usually read as a measurement. It is a negotiated statement of tolerable downtime, written as though a system had failed cleanly while everything around it kept working.
That assumption survives because most testing starts from a working estate. The backup platform is reachable, the network exists, identity works, and replacement capacity is present or quietly assumed. The exercise asks whether the data can be restored, not whether the organization can rebuild the world that data needs in order to be worth anything.
The gap between those two questions is the exposure. The clock is not set by the best documented system, but by the oldest unsupported dependency and by the identity service the attacker took first.
The evidence
The British Library’s own review, Learning Lessons from the Cyber-Attack, published on 8 March 2024, refuses to reduce recovery to a backup story.
The October 2023 attack was claimed by the Rhysida group. The review gives the likely point of entry as a Terminal Services server installed in 2020 for external access by trusted partners, reached through compromised privileged credentials on a domain that had been left out of scope for multi-factor authentication “pending further renewal of the Library’s infrastructure”. The attackers exfiltrated data, destroyed servers, encrypted systems and locked out users. The Library paid no ransom.
What happened next matters, because the backups held. The review records that “in December, it was confirmed that viable sources of backups had been identified that were unaffected by the cyber-attack”. It adds that the Library expects to restore all of its data eventually, but was “hampered temporarily by the lack of viable infrastructure on which to restore it”.
The data existed. The place to put it did not.
The review is blunter still about the systems themselves: “A few key software systems, including the library management system, cannot be brought back in the form that they existed in before the attack, either because they are no longer supported by the vendor and the software is no longer available, or because they will not function on the Library’s new secure infrastructure.” Its own conclusion is the most useful sentence published about this attack: “our reliance on legacy infrastructure is the primary contributor to the length of time that the Library will require to recover from the attack.”
The duration followed from that. Services were severely restricted for the first two months, and a searchable version of the main catalogue returned on 15 January 2024. The infrastructure rebuild had been under way since December 2023 and was due to complete by mid-April 2024, before the phased restoration of systems and data could begin. Mid-April was not the end of recovery. It was the point at which restoration could start.
Why the exposure existed
Two constraints turned an incident into a rebuild program.
The first is the restore target. Data cannot be restored onto an estate that has been destroyed, distrusted, or deliberately left behind because the new secure build will not accept the old system. Rebuilding that target is not a runbook step. It is procurement, architecture and change control under pressure, with its own supplier lead times.
The second is supportedness. An application the vendor no longer sells may not be reinstallable once the running copy is destroyed, and one that will not run on the current secure build cannot be restored onto it. For those systems the word recovery quietly means replacement, which is a project rather than an incident task.
Both constraints were properties of the estate on an ordinary Tuesday, knowable before anything happened. Neither shows up in a backup success report.
Which assumptions failed
The first failed assumption is that intact backups mean recoverability. Fenix24 reported that in 38 percent of engagements where backups were intact, those backups still could not carry the recovery. That is one firm’s engagement data rather than a population statistic, but it matches the British Library’s account: viable backups did not amount to a viable service.
The second is that the restore path is independent of the systems under attack. Fenix24 reported that 94 percent of its clients had tied their backup systems to Active Directory, which attackers seized first, and that 99.2 percent arrived with no documented identity recovery plan. Recovering identity alone consumed roughly 20 percent of the first 48 hours, and minimum viable infrastructure took at least a further 72. If the backup console, the privileged access model and the server build process all authenticate against the service that has just been compromised, the recovery plan begins inside the blast radius.
The third is that legacy is only a likelihood problem. Duration is the larger exposure: an organization can survive the intrusion and still lose two quarters rebuilding what could not be restored.
Where the loss lands
The loss is operational and strategic, not regulatory. The Library’s review states that the net financial impact was still being calculated, and no figure had been published at that point.
What is visible instead is an incident converting into a multi-quarter rebuild program. The capital, the engineering capacity and the leadership attention allocated to the organization’s strategy are spent on recovery instead. Much of that work may have been necessary eventually, but the timing is no longer chosen.
One detail cuts the other way. The Library’s cloud-based email, finance, HR and payroll systems functioned normally throughout, and the review records that the lack of network segmentation let the attack do more damage than a modern design would have allowed. The damage was bounded by architecture rather than by the attackers’ ambition, and architecture decides where recovery stops being restoration and starts being reconstruction.
What management could have seen
Most of this was identifiable in advance, though not by asking whether backups exist.
The first question is whether any recovery exercise has ever started from bare infrastructure with identity unavailable. One that begins with a working domain and a reachable backup platform has not tested the event that matters.
The second is whether the application inventory records, per application, the vendor support status and whether it will run on the current secure build target. That field predicts the recovery schedule better than the backup report does. A system that can be restored technically but not reinstalled legally or securely is not on the same timeline as a supported platform.
The third is whether recovery time objectives attach to business processes rather than individual systems. A catalogue or a payment run depends on identity, databases, file stores and third-party connectivity, and returns only when the whole chain returns. The fourth is who owns the restore order, which is a business decision about which services earn scarce rebuild capacity first, not a technical schedule.
Those answers live with the people who run the applications. Turning them into a credible recovery duration takes someone who has watched a restore sequence fail under dependency pressure, which is why this work lands when an outside analyst and the internal teams build the picture together.
The duration case
The usual case for retiring legacy systems is that they make an attack more likely. That can be entirely true and still lose, every budget cycle, to something more visible.
The stronger case is the one the British Library’s review makes without setting out to. Legacy decides how long the organization stays down afterwards, and whether recovery means restoring data or rebuilding platforms under pressure. The backups were viable. The data was recoverable. Recovery still ran into quarters, because the estate could not receive what the backups held.
Every organization with a recovery time objective should know what its oldest unsupported dependency does to that number.