Only four out of more than 800 clients (0.5%) assessed by Fenix24 came close to their own 24 to 48-hour ransomware recovery targets, and then only for partial business operations. None reached full operational capacity until several weeks after the incident.
The finding comes from the incident response firm’s first State of Recoverability report, drawn from more than 500 ransomware recoveries and published on September 15.
Recovery plans failed the same way each time, it said, looking sound on paper and coming apart once an attacker was inside.
Identity Systems Delay Ransomware Recovery
Fenix24 found 99.2% of clients arrived with no documented identity recovery plan, and none of the plans that did exist survived contact with the threat actor.
“Recovery can depend on the same login system an attacker has compromised,” said Jason Soroko, senior fellow at Sectigo. “These figures describe Fenix24’s engagements, not every business, but they identify a failure organizations should test for.”
The directory itself was the problem in nearly all of them. Fenix24 said Active Directory was usually the first major system to fall, and that 94% of clients had tied their backup systems to the very directory the attacker seized.
Roughly 20% of the opening two days went on identity alone, spent getting a single authentication source clean enough to trust. Reaching minimum viable infrastructure took at least another 72 hours.
Meanwhile 95% had no meaningful multifactor controls on critical infrastructure consoles, against 15% at network ingress.
Read more on ransomware recovery: CISO Lessons in Ransomware Response and Recovery After a Real-World LockBit Attack
Surviving Backups Still Fail to Restore Businesses
In 38% of engagements where backups came through the attack intact or nearly so, Fenix24 said they still could not carry the recovery. Some sets predated anything usable, others had been corrupt or partial well before the intrusion, and some were simply the wrong format or took longer to restore than a rebuild would.
Others carried an immutable label on hardware that could not deliver it.
Not one client knew its full application and dependency picture. The nearest equivalents lived in configuration databases that fell with everything else, or got drawn up mid-recovery once the business was forced to choose what came back first.
Two constraints were physical and routinely overlooked. Storage ran short in 82% of engagements, leaving restored data nowhere to land without overwriting the forensic record, and in 38% of cases the network could not move data at recovery scale.
To counter these shortfalls, Fenix24 said organizations should identify their most revenue-critical business service and demand a complete dependency map for it, third parties included, then run the full restore path end to end against current recovery targets. It called simulations and untested plans the same answer.
