Ransomware, il recovery in 24-48 ore resta fuori portata: 4 casi su oltre 800

15 settembre 2026 — Secondo il State of Recoverability 2026 di Fenix24, vendor specializzato in servizi di recovery ransomware, solo quattro clienti su oltre 800 engagement si sono avvicinati al proprio target di ripristino in 24-48 ore. E solo per operazioni parziali. Nessuno ha raggiunto piena capacità operativa prima di diverse settimane. Il report, basato su più di 500 recovery ransomware, è l'unica fonte primaria strutturata disponibile: rielaborato da testate specializzate, non verificato da studi indipendenti. I dati descrivono il campione Fenix24, non necessariamente tutte le aziende.

Il problema dell'identity: quando il sistema di accesso cade per primo

Active Directory era tipicamente il primo sistema maggiore a cadere sotto attacco. Il 94% dei clienti aveva unito i sistemi di backup alla stessa directory di produzione compromessa. Questo accorpamento trasforma il recovery in una ricostruzione dei meccanismi di accesso, non in un semplice ripristino dati.

Circa il 20% delle prime 48 ore veniva assorbito solo dal recovery dell'identity. Raggiungere un'infrastruttura minima viabile richiedeva almeno altre 72 ore. In questo lasso di tempo l'organizzazione resta con i sistemi di autenticazione da ricostruire: chi accede a cosa, con quali credenziali, in quale sequenza di dipendenze.

Il 99,2% dei clienti arrivava senza piano documentato per il recovery dei sistemi identity. Tra quelli che ne avevano uno, nessuno ha resistito al contatto con il threat actor. I piani teorici si sono rivelati inadeguati allo scenario reale, dove gli attaccanti avevano già alterato directory, privilegi e percorsi di accesso.

"Recovery can depend on the same login system an attacker has compromised. These figures describe Fenix24's engagements, not every business, but they identify a failure organizations should test for." — Jason Soroko, senior fellow at Sectigo

I backup intatti che non bastano

La sopravvivenza del backup non garantisce il ripristino. Nel 38% dei casi in cui i backup erano arrivati intatti o quasi attraverso l'attacco, Fenix24 ha rilevato che non potevano comunque supportare il recovery operativo.

Le cause sono misurabili: storage insufficiente nell'82% degli engagement, banda di rete inadeguata nel 38% per movimentare i dati alla scala necessaria. A queste si aggiunge un limite strutturale: nessun cliente conosceva il quadro completo delle proprie applicazioni e dipendenze. Senza questa mappa, il restore diventa esplorazione in tempo reale, con ogni nuova interconnessione scoperta che allunga la timeline.

Il cambio di metrica: da "tenere fuori" a "rientrare in fretta"

Secondo VMblog, che riporta il contesto analitico, Gartner ora orienta la misurazione della resilienza sulla velocità di recovery anziché sulla prevenzione. Questo spostamento riconosce che il rientro operativo, non solo lo stop all'ingresso, è il parametro rilevante.

Mark Grazman, CEO e co-fondatore di Fenix24, ha sintetizzato la transizione: "For twenty years, boards asked whether they were secure enough to keep attackers out. That's the wrong question now, because every organization eventually faces an attack. The question that matters is how fast the business gets back to operating, and most boards can't get a straight answer to it."

La stessa fonte riporta un dato di Cyentia Institute: la probabilità annuale di evento cyber significativo è quasi quadruplicata dal 2008. Grazman ha aggiunto: "AI is only sharpening the problem: attackers move faster every year, and a recovery plan built around days, not hours, is already out of date. Recoverability has to be a board-level metric, not an assumption."

MFA: controlli scarsi sulle console critiche

Il 95% dei clienti non disponeva di controlli MFA significativi sulle console infrastruttura critica, contro il 15% con controlli insufficienti all'ingresso di rete. L'attaccante che supera il primo perimetro trova quindi un secondo perimetro interno con difese ridotte, potendo muoversi verso i sistemi di backup e identity con minore attrito.

Cosa cambia

I dati Fenix24 descrivono fallimenti osservati, non prescrivono soluzioni. Il report non contiene indicazioni operative strutturate: non indica come testare i piani, non dettaglia architetture di separazione, non fornisce checklist di implementazione.

Quello che emerge è un profilo descrittivo. Le organizzazioni nel campione arrivano al recovery con tre carenze ricorrenti: nessuna mappa delle dipendenze, nessun piano identity documentato che regga allo scenario reale, nessuna separazione architetturale tra sistemi di autenticazione e sistemi di backup. Il report registra queste assenze, non indica come colmarle.

Il dato sulle "diverse settimane" per piena operatività, riportato dal report senza metrica definita, segnala che anche la misura del tempo di recovery manca di standardizzazione nel campione analizzato.

Chiusura

I numeri Fenix24 restano vincolati al proprio campione: vendor di servizi recovery che interviene su aziende già in crisi, spesso di dimensioni enterprise, con infrastrutture complesse. L'avvertimento di Soroko — "not every business" — qualifica l'intero quadro. Il report offre una fotografia di chi ha già fallito il recovery autonomo e ha chiesto aiuto esterno, non una statistica sulle capacità di tutte le organizzazioni.

Il valore del dato sta nel profilo ricorrente dei fallimenti, non nella generalizzazione. Chi legge questi numeri deve mantenere la distanza critica che il report aziendale non può garantire da sé.