Cyber Resilience Act, 24 ore per il primo avviso: cosa cambia per le imprese

Immaginiamo una società che sviluppa e commercializza un software per archiviare e condividere documenti, comprendente soluzioni di trattamento dati da remoto, installato sui server dei clienti. Un lunedì mattina, un cliente segnala accessi anomali e lo scaricamento di documenti riservati. I tecnici della società devono ricostruire l’intrusione e verificare se altri clienti siano esposti.

Dall’11 settembre 2026, il Cyber Resilience Act (CRA), Regolamento (UE) 2024/2847, impone ai fabbricanti un primo avviso entro 24 ore dalla conoscenza di determinati eventi. L’impresa deve quindi valutare l’obbligo mentre l’indagine tecnica è in corso.

Il CRA copre hardware e software commercializzati nella Ue, il cui uso previsto o ragionevolmente prevedibile comprenda una connessione di dati a un dispositivo o a una rete, anche indiretta. Il programma dell’esempio, accessibile via rete, rientra in questo ambito. Sono esclusi, tra l’altro, dispositivi medici e veicoli soggetti a specifiche norme europee.

La società vende il programma con il proprio marchio: per il CRA è il fabbricante, anche se alcuni componenti sono forniti da terzi. L’obbligo di notifica riguarda anche prodotti già immessi sul mercato, compreso il software acquistato dal cliente nel 2025. Secondo le linee guida della Commissione, continua anche dopo la fine del supporto.

I tecnici accertano che l’attaccante ha sfruttato una falla nel componente che controlla gli accessi. Le prove mostrano l’uso della vulnerabilità senza il permesso del proprietario del sistema: ricorrono quindi i presupposti della vulnerabilità attivamente sfruttata. La semplice scoperta di una falla non sarebbe sufficiente. Per i componenti di terzi, la Commissione precisa che occorre verificare lo sfruttamento nel prodotto del fabbricante.

Secondo le linee guida della Commissione, pubblicate il 27 luglio 2026 e non vincolanti, la conoscenza dell’evento richiede un ragionevole grado di certezza. La verifica iniziale va svolta il prima possibile. Se questa certezza è matura alle 10 del lunedì, il preallarme deve partire entro le 10 del martedì. Il termine potrebbe però decorrere prima, se la segnalazione del cliente conteneva già prove sufficienti. Conviene documentare tempi ed elementi della valutazione.

Occorre anche verificare se l’intrusione sia un incidente grave. Questa categoria comprende gli eventi che compromettono, o possono compromettere, la capacità del prodotto di proteggere disponibilità, autenticità, integrità o riservatezza di dati o funzioni sensibili o importanti. Comprende anche quelli che comportano, o possono comportare, l’introduzione o l’esecuzione di codice malevolo nel prodotto o nei sistemi degli utenti.

Il fabbricante deve procedere senza ritardi ingiustificati. Le 24 ore sono un limite massimo, non un periodo da attendere. Le notifiche vanno inviate tramite la piattaforma unica di ENISA, operativa dall’11 settembre, e sono indirizzate al CSIRT coordinatore competente, il gruppo nazionale di risposta agli incidenti informatici, e a ENISA, l’Agenzia europea per la cybersicurezza.

Il preallarme deve indicare, ove pertinente, i Paesi Ue nei quali il fabbricante sa che il prodotto è stato fornito. Per un incidente grave, va anche precisato se si sospetta un’origine illegittima o malevola. Servono quindi dati di vendita consultabili rapidamente, per individuare i Paesi nei quali il software è stato distribuito.

Entro 72 ore dalla conoscenza dell’evento, dunque entro le 10 del giovedì nell’esempio, segue la notifica dettagliata, sempre senza ritardi ingiustificati. I contenuti dipendono dal tipo di evento e includono la prima valutazione e le misure adottate o utilizzabili dai clienti.

Per la vulnerabilità attivamente sfruttata, la relazione finale va inviata entro 14 giorni dalla messa a disposizione di una misura correttiva o di riduzione del rischio. Una misura temporanea che riduce il rischio di sfruttamento può far decorrere i 14 giorni quando viene messa a disposizione. Per un incidente grave, la relazione finale è dovuta entro un mese dalla notifica dettagliata. La notifica a 72 ore e la relazione finale non richiedono un nuovo invio se le informazioni pertinenti sono già state fornite.

Il fabbricante deve informare tempestivamente gli utenti interessati e, quando opportuno, tutti gli utenti, indicando ove necessario le misure di protezione. La società deve quindi individuare quali clienti usino il software vulnerabile. La Commissione chiarisce che la comunicazione va calibrata sul rischio e non richiede sempre la divulgazione pubblica dei dettagli tecnici.

Una misura temporanea potrebbe essere limitare l’accesso al programma alla sola rete interna, se efficace contro l’attacco. Il cliente avrebbe bisogno di sapere come procedere e quali funzioni resterebbero disponibili a chi lavora a distanza. Le comunicazioni dovrebbero quindi essere preparate insieme da tecnici, funzione legale e responsabili dei rapporti con i clienti.

L’impresa potrebbe aver bisogno del fornitore del componente per ricostruire l’attacco e correggere la falla. Un contratto che gli consenta di rispondere dopo 24 ore può lasciare il fabbricante senza informazioni utili entro il proprio termine. Se il fabbricante ha già acquisito conoscenza dell’evento, attendere la risposta del fornitore non sospende la scadenza. Il primo avviso dovrà essere predisposto con gli elementi disponibili.

I contratti dovrebbero prevedere contatti reperibili, tempi di primo riscontro e aggiornamento, accesso alle prove tecniche e collaborazione nella correzione. Dovrebbero anche consentire le comunicazioni necessarie ad autorità e clienti. Il cliente può infatti avere propri obblighi di notifica (ad esempio, ai sensi di NIS2 o DORA), che la segnalazione CRA del fabbricante non assolve automaticamente.

La società dovrà anche prepararsi alla disciplina generale del CRA, applicabile dall’11 dicembre 2027 ai prodotti immessi sul mercato da quella data. Quelli già immessi vi saranno soggetti solo se subiranno, da allora, modifiche sostanziali. Il fabbricante dovrà integrare la valutazione dei rischi nella progettazione, predisporre la documentazione tecnica, svolgere la valutazione di conformità, redigere la dichiarazione UE di conformità e apporre la marcatura CE.

Dovrà inoltre gestire le vulnerabilità per un periodo di supporto che rifletta la durata d’uso attesa del prodotto. Il minimo è di cinque anni; se l’uso atteso è più breve, il supporto deve coprirne la durata. Per programmi o prodotti destinati a un uso più lungo può servire un periodo superiore. La società deve quindi verificare che gli impegni del fornitore del componente le consentano di mantenere sicuro il proprio software nel tempo.

I distributori del programma dovranno verificare, tra l’altro, la marcatura CE e la presenza di documenti e istruzioni. Chi importa software da Paesi extra Ue dovrà accertare che il fabbricante abbia svolto la valutazione di conformità e redatto la documentazione tecnica.

Se i documenti sottratti contengono dati personali, occorre valutare anche gli obblighi previsti dal GDPR.

Il caso mostra perché le imprese debbano predisporre procedure integrate per gli incidenti, coordinando il CRA con NIS2, AI Act, GDPR e DORA, ove applicabili. La verifica dipende dall’attività, dai prodotti e dai sistemi coinvolti, dal ruolo dell’impresa e dalle date di applicazione.

Una raccolta comune delle informazioni deve consentire di valutare i presupposti di ciascuna notifica e rispettarne destinatari e scadenze.

_______

*Alessandro Ferrari, Partner, Head of Technology Sector, DLA Piper