3,136 subscribersSubscribed

CRA, sistemi obsoleti e data breach: si può davvero dire “avevo compensato il rischio”?

Antonio Ieranò

Information & Cybersecurity Strategist | Digital Sovereignty • AI Governance • Complex Systems | Author, Researcher & Occasional Philosopher | Views stubbornly my own. 🧠

October 7, 2026

Il Cyber Resilience Act sta cambiando il modo in cui guardiamo alla sicurezza dei prodotti digitali.

Non più solo “proteggersi dagli attacchi”.

Sempre di più: progettare, mantenere e aggiornare prodotti digitali in modo sicuro lungo tutto il loro ciclo di vita.

È un passaggio culturale importante.

Come osserva anche CyberSecItalia in un recente articolo sul recepimento italiano del CRA, la cybersicurezza entra “dentro” i prodotti digitali: non riguarda più solo chi usa la tecnologia, ma anche chi la produce, la distribuisce e la immette sul mercato.

Nel modello italiano, secondo quanto riportato, l’ACN assumerebbe un ruolo centrale come autorità di vigilanza del mercato, con un sistema di cooperazione che può coinvolgere anche Garante Privacy, Banca d’Italia, CONSOB, IVASS e autorità competenti in materia di IA, a seconda del tipo di prodotto.

Questo conferma un punto: la cybersecurity non è più una materia isolata.

È sempre più un tema industriale, regolatorio, organizzativo e di responsabilità.

Ma c’è una domanda molto pratica che molte aziende dovrebbero farsi:

cosa succede se uso ancora sistemi operativi, software o applicazioni custom non più aggiornabili?

E soprattutto:

in caso di data breach o attacco malevolo, posso difendermi dicendo che avevo messo in piedi protezioni adeguate?

La risposta breve è: sì, in astratto posso provarci.

La risposta più utile è: dipende.

Dipende da quanto quella scelta era conosciuta, valutata, documentata e realmente compensata.

Perché “compensare il rischio” non significa dire dopo l’incidente che c’era un firewall, un antivirus o una VLAN.

Significa dimostrare che il rischio era stato governato prima.

Il CRA non vieta automaticamente l’uso interno di sistemi obsoleti

Il CRA riguarda principalmente chi produce, importa, distribuisce o mette a disposizione sul mercato UE prodotti con elementi digitali.

Quindi un’azienda che usa internamente un vecchio sistema operativo o un vecchio applicativo non viola automaticamente il CRA solo per questo.

Ma attenzione: il CRA cambia il metro di giudizio.

Se il legislatore europeo sta affermando che i prodotti digitali devono nascere sicuri, ricevere aggiornamenti, gestire vulnerabilità e mantenere un livello di sicurezza lungo il ciclo di vita, allora usare stabilmente tecnologie non aggiornabili diventa sempre più difficile da giustificare.

In caso di incidente, la domanda non sarà solo:

“Quel sistema era conforme al CRA?”

La domanda sarà:

“Era ragionevole tenerlo in quelle condizioni?”

E ancora:

era censito?
era classificato?
era isolato?
era monitorato?
trattava dati personali?
era connesso alla rete?
aveva vulnerabilità note?
esisteva un piano di sostituzione?
chi aveva accettato formalmente il rischio?

Sistemi operativi obsoleti: il caso più difficile da difendere

Un vecchio sistema operativo fuori supporto è diverso da un singolo software non aggiornato.

Il sistema operativo è la base su cui poggiano identità, permessi, rete, logging, endpoint security, autenticazione, file system e spesso interi processi aziendali.

Se l’OS non riceve più patch, ogni nuova vulnerabilità può restare aperta in modo permanente.

Il caso classico è quello di vecchie versioni di Windows ancora presenti in ambienti produttivi, industriali, medicali, gestionali o collegati a macchinari.

La ragione può essere comprensibile.

Ma comprensibile non significa automaticamente accettabile.

Un sistema operativo fuori supporto, connesso alla rete aziendale, integrato nel dominio, esposto da remoto o usato per trattare dati personali è un rischio strutturale.

Per difenderlo dopo un incidente servono evidenze forti:

isolamento di rete effettivo;
accessi strettamente limitati;
assenza di esposizione diretta a internet;
hardening documentato;
monitoraggio specifico;
logging centralizzato;
backup e restore testati;
restrizioni applicative;
procedure operative;
accettazione formale del rischio;
piano di dismissione o migrazione.

Senza questi elementi, il sistema legacy rischia di diventare il punto debole non solo della rete, ma anche della difesa legale, assicurativa e organizzativa.

Software non più aggiornato: conta il contesto

Un software applicativo non più supportato è un caso più sfumato.

Non tutti i software legacy hanno lo stesso rischio.

Bisogna chiedersi:

è esposto a internet?
riceve file o input dall’esterno?
gestisce credenziali?
tratta dati personali?
comunica con sistemi critici?
gira con privilegi elevati?
è installato su molti endpoint?
ha vulnerabilità note?
è ancora mantenuto dal fornitore?
è sostituibile?

Un vecchio tool isolato, usato offline, senza dati sensibili e senza connessioni di rete può essere un rischio temporaneamente accettabile.

Un gestionale legacy che tratta dati personali, si integra con Active Directory, è accessibile da remoto e non riceve più patch è tutt’altra cosa.

Qui la difesa “avevamo misure di protezione” può reggere solo se quelle misure sono proporzionate e verificabili.

Software custom: la falsa zona grigia

Molte aziende hanno software custom sviluppato anni fa.

Applicazioni interne.

Gestionali verticali.

Tool produttivi.

Interfacce con macchinari.

Sistemi commissionati a fornitori che magari non esistono più.

Spesso non hanno un vero ciclo di aggiornamento, non hanno test di sicurezza, non hanno documentazione aggiornata e non è chiaro chi ne sia responsabile.

Il fatto che siano “custom” non li rende automaticamente sicuri.

E non li rende automaticamente irrilevanti.

Se il software resta solo interno, potrebbe non rientrare direttamente nel CRA come prodotto immesso sul mercato.

Ma l’azienda resta comunque responsabile della sicurezza del proprio ambiente.

Se invece quel software viene venduto, distribuito, fornito a clienti, integrato in un prodotto o reso disponibile a terzi, il discorso cambia: può avvicinarsi molto di più al perimetro degli obblighi del CRA.

In ogni caso, serve governance:

ownership chiara;
manutenzione;
gestione delle vulnerabilità;
controllo delle dipendenze;
logging;
controllo accessi;
ambienti separati;
backup;
documentazione;
piano di evoluzione o sostituzione.

Il problema del custom legacy è che spesso nessuno lo considera più “software”.

Diventa parte dell’arredamento aziendale.

Finché non si rompe.

O finché non viene usato come punto di ingresso.

Data breach: posso difendermi dicendo che avevo misure adeguate?

Sì, ma non basta dichiararlo.

In ambito GDPR, il punto non è dimostrare che l’incidente fosse impossibile.

Il punto è dimostrare che le misure tecniche e organizzative erano adeguate al rischio.

Anche la NIS2, per i soggetti in perimetro, insiste su gestione del rischio, incident handling, business continuity, sicurezza della supply chain, sicurezza nell’acquisizione e manutenzione dei sistemi, igiene informatica e controllo accessi.

Quindi, dopo un incidente, la domanda diventa:

l’azienda aveva davvero governato il rischio?

La difesa può essere credibile se dimostra quattro cose.

Il rischio era conosciuto

Il sistema era censito, classificato e valutato.

Non è stato “scoperto” dopo il breach.

La scelta era motivata

C’erano ragioni tecniche, operative o economiche documentate per mantenerlo temporaneamente.

Non semplice inerzia.

Le misure compensative erano reali

Segmentazione, hardening, access control, monitoring, logging, backup, vulnerability assessment, MFA, jump server, restrizione dei privilegi.

Non solo dichiarazioni generiche.

Esisteva un percorso di rientro

Un rischio eccezionale può essere accettato per un periodo.

Un rischio eccezionale accettato per sempre diventa un problema di governance.

Quando la difesa diventa fragile

La posizione dell’azienda diventa molto più difficile se il sistema obsoleto era:

fuori inventario;
non sottoposto a risk assessment;
connesso alla rete senza segmentazione;
accessibile da remoto senza controlli robusti;
usato con privilegi amministrativi;
privo di logging;
privo di backup testati;
noto come vulnerabile;
già segnalato da audit o IT;
mantenuto per anni senza piano di sostituzione;
coinvolto nel trattamento di dati personali o processi critici.

In questi casi dire “avevamo altre protezioni” rischia di sembrare una giustificazione ex post.

Non una vera gestione del rischio.

La vera distinzione: rischio accettato o rischio dimenticato?

Quasi tutte le aziende hanno sistemi legacy.

Questo è normale.

Il problema non è avere legacy.

Il problema è non governarlo.

Un sistema vecchio, isolato, documentato, monitorato, con accessi limitati e piano di sostituzione è un rischio gestito.

Un sistema vecchio, in rete, non censito, non patchabile e indispensabile a un processo critico è un rischio dimenticato.

Dopo un data breach, questa differenza diventa decisiva.

Perché l’azienda non sarà valutata solo per la presenza del sistema obsoleto.

Sarà valutata per il modo in cui ha scelto di conviverci.

Conclusione

Il CRA sposta il mercato verso prodotti digitali più sicuri, aggiornabili e mantenuti nel tempo.

Ma per le aziende utilizzatrici il messaggio è altrettanto chiaro:

la stagione del “funziona ancora, quindi lo teniamo” è sempre meno difendibile.

Tenere sistemi operativi fuori supporto, software non più aggiornati o applicazioni custom senza manutenzione non è necessariamente illecito in sé.

Ma è una scelta di rischio.

E come ogni scelta di rischio deve essere:

censita;
valutata;
approvata;
mitigata;
monitorata;
riesaminata;
collegata a un piano di uscita.

La sicurezza non richiede perfezione.

Richiede governo, proporzione e prove.

E sui sistemi non aggiornati, le prove devono essere particolarmente solide.

Fonti e spunti:

Cyber Resilience Act, Regolamento UE 2024/2847
GDPR, art. 32
Direttiva NIS2
CyberSecItalia, “Cyber Resilience Act, la cybersecurity nei prodotti digitali: non più solo compliance, ma anche sicurezza by design”