Avete bloccato un attacco informatico al vostro prodotto connesso e ora dovete decidere se notificarlo

Alle 9:12 il sistema di monitoraggio rileva un tentativo di accesso non autorizzato al software che controlla un macchinario connesso. I controlli di sicurezza bloccano il traffico. Il macchinario continua a funzionare, non risultano dati alterati e non è stato eseguito codice estraneo. Per il gruppo tecnico l'attacco è stato respinto. Per chi deve applicare il Cyber Resilience Act, invece, il lavoro comincia proprio qui.

La domanda non è soltanto se l'episodio sia stato pericoloso. Occorre capire se si è già verificato un incidente, se siamo ancora davanti a un quasi incidente e, nel primo caso, se l'incidente sia abbastanza grave da dover essere notificato. Da questa qualificazione dipende l'avvio del termine di 24 ore previsto per il preallarme.

Dall'11 settembre 2026 l'articolo 14 del regolamento (UE) 2024/2847 del Parlamento europeo e del Consiglio, del 23 ottobre 2024, relativo a requisiti orizzontali di cibersicurezza per i prodotti con elementi digitali (Cyber Resilience Act, CRA), si applica ai prodotti che rientrano nel suo ambito, compresi quelli immessi sul mercato prima della piena applicazione del regolamento. Il fabbricante non può quindi rinviare questa decisione al 2027.

Il cronometro non parte dal primo allarme

Un allarme tecnico non coincide automaticamente con la conoscenza di un incidente grave. Può segnalare un comportamento anomalo, un tentativo respinto o una compromissione ancora da verificare. Il progetto di orientamenti allegato alla comunicazione C(2026) 5252 della Commissione europea del 27 luglio 2026 indica al fabbricante di svolgere subito una valutazione iniziale. Il momento rilevante arriva quando, dopo quella valutazione, esiste un ragionevole grado di certezza che si sia verificato un incidente grave e che la sicurezza del prodotto sia stata compromessa.

Questa precisazione evita due errori opposti. Il primo è notificare come incidente grave ogni segnale generato dagli strumenti di sicurezza. Il secondo è attendere la ricostruzione completa dell'attacco prima di far partire i termini. Il CRA prevede una comunicazione progressiva proprio perché, nelle prime ore, molte informazioni possono essere ancora incomplete: un preallarme entro 24 ore, una notifica più articolata entro 72 ore e una relazione finale entro un mese dalla notifica delle 72 ore.

La valutazione iniziale deve quindi essere rapida, ma non può ridursi alla formula «attacco bloccato». Bisogna ricostruire fino a dove è arrivato l'evento e che cosa ha effettivamente toccato.

Prima viene la compromissione, poi la gravità

Il CRA non costruisce da solo la distinzione tra incidente e quasi incidente. L'articolo 3 rinvia alle definizioni della direttiva (UE) 2022/2555 del Parlamento europeo e del Consiglio, del 14 dicembre 2022, relativa a misure per un livello comune elevato di cibersicurezza nell'Unione (direttiva NIS2).

Per la NIS2, un incidente è un evento che compromette la disponibilità, l'autenticità, l'integrità o la riservatezza di dati o servizi dei sistemi informativi e di rete. Il quasi incidente è invece l'evento che avrebbe potuto produrre quella compromissione, ma è stato efficacemente evitato o non si è materializzato.

La prima domanda, quindi, non riguarda ancora la gravità. Riguarda il fatto. La sicurezza di un sistema è stata davvero compromessa, oppure i controlli hanno fermato il tentativo prima che ciò accadesse?

Se il tentativo avrebbe potuto compromettere la sicurezza del software, ma è stato bloccato prima di qualsiasi violazione, la definizione conduce verso il quasi incidente. La segnalazione prevista dall'articolo 15 del CRA è volontaria. Se invece l'attaccante ha ottenuto accesso a un account, ha alterato una configurazione o ha sottratto una credenziale, la compromissione si è già verificata. Il successivo contenimento limita le conseguenze, ma non trasforma retroattivamente l'incidente in un quasi incidente.

Solo a quel punto si valuta la gravità ai fini dell'articolo 14.

La possibilità di un danno futuro non rende obbligatorio ogni allarme

La difficoltà nasce dalle parole usate dal CRA. Un incidente può essere grave non soltanto quando incide già sulla capacità del prodotto di proteggere dati o funzioni sensibili o importanti, ma anche quando è «in grado di incidere» su quella capacità. Lo stesso vale se l'incidente ha portato, o è in grado di portare, all'introduzione o all'esecuzione di codice malevolo nel prodotto o nei sistemi dell'utilizzatore.

Queste espressioni impediscono di attendere il danno finale. Se un ambiente utilizzato per creare gli aggiornamenti del prodotto viene compromesso e l'accesso ottenuto può consentire l'inserimento di codice malevolo, non occorre aspettare che un aggiornamento infetto raggiunga un cliente. La compromissione dell'ambiente esiste già; la conseguenza più grave è ancora potenziale. La lettura più prudente e coerente con l'articolo 14 porta alla notifica obbligatoria.

La parola «può», però, non cancella il passaggio precedente. Il testo parla sempre di un incidente, cioè di un evento che ha già compromesso la sicurezza di un sistema. Se il tentativo è stato fermato prima di ogni compromissione, la sola possibilità di conseguenze serie non basta, secondo la lettura più solida delle definizioni, a trasformarlo in un incidente grave.

Il progetto di orientamenti pubblicato dalla Commissione non scioglie espressamente questo nodo. Nei paragrafi dedicati alle notifiche si concentra sul momento in cui il fabbricante viene a conoscenza dell'incidente e non analizza il confine con il quasi incidente. Inoltre, il documento non è vincolante. La conclusione deve quindi essere presentata per quello che è: un'interpretazione fondata sulla concatenazione delle definizioni del CRA e della NIS2, non una soglia ufficiale già chiarita in ogni dettaglio.

Tra il tentativo respinto e l'incidente grave resta uno spazio intermedio

La distinzione non si esaurisce nell'alternativa tra quasi incidente e incidente grave. Può essersi verificata una compromissione reale che non raggiunge i criteri di gravità dell'articolo 14, paragrafo 5.

Immaginate che venga compromesso un account tecnico secondario, immediatamente disattivato, che non consente di intervenire su dati o funzioni sensibili o importanti e non può essere usato per introdurre codice malevolo. Siamo oltre il quasi incidente, perché l'accesso non autorizzato si è verificato. Ma, se la ricostruzione tecnica esclude entrambi i criteri di gravità previsti dal CRA, la notifica obbligatoria non scatta. L'incidente può comunque essere segnalato volontariamente ai sensi dell'articolo 15.

Questa terza possibilità conta anche sul piano documentale. Se l'impresa registra soltanto «notificato» oppure «non notificato», perde la ragione della decisione. Fra i due esiti possono esserci fatti molto diversi: un tentativo integralmente respinto, una compromissione circoscritta sotto la soglia di gravità oppure un incidente già capace di colpire una funzione importante.

La vulnerabilità segue un percorso diverso

Il dubbio sulla notifica non deve essere confuso con la gestione della vulnerabilità che ha reso possibile il tentativo. Una vulnerabilità, anche sfruttabile, non è di per sé un incidente. Il CRA disciplina separatamente la vulnerabilità attivamente sfruttata, gli incidenti e gli obblighi di trattamento delle vulnerabilità.

Questo significa che «non notificabile come incidente grave» non equivale a «irrilevante» o «da non correggere». Può essere necessario intervenire sul prodotto, informare i clienti o rispettare obblighi contrattuali e altre norme anche quando la soglia dell'articolo 14 non è raggiunta. Al tempo stesso, una nota pubblicata oggi non può presentare come già generalmente applicabili tutti gli obblighi di gestione delle vulnerabilità del CRA: l'articolo 14 si applica dall'11 settembre 2026, mentre l'articolo 13 e l'allegato I si applicheranno in via generale dall'11 dicembre 2027.

La distinzione è particolarmente importante per i prodotti immessi sul mercato prima di quella data. Come chiarisce la Commissione, il fabbricante può essere già tenuto a notificare un incidente grave anche quando, per quel prodotto, gli obblighi di trattamento delle vulnerabilità previsti dal CRA non sono ancora applicabili.

La decisione deve poter essere ricostruita

Nelle prime ore non serve un dossier definitivo. Serve una traccia che permetta di capire che cosa l'impresa sapeva e quando lo ha saputo. La registrazione dovrebbe identificare il prodotto e il sistema coinvolti, descrivere la compromissione effettivamente accertata e separarla dagli effetti rimasti soltanto possibili. Dovrebbe poi spiegare perché i dati o le funzioni interessati sono, oppure non sono, sensibili o importanti e quale elemento tecnico rende plausibile l'introduzione di codice malevolo.

Il punto più delicato è il momento della conoscenza. Conservate l'ora del primo segnale, ma anche quella in cui la valutazione iniziale ha raggiunto un ragionevole grado di certezza. È da questo secondo momento che può decorrere il termine, e la differenza deve risultare dai fatti, non da una formula inserita dopo.

Una procedura aziendale utile non chiede soltanto al gruppo tecnico se l'attacco sia stato bloccato. Chiede dove sia stato bloccato. Se la barriera ha impedito ogni compromissione, il percorso porta verso il quasi incidente. Se la barriera è intervenuta dopo un accesso o un'alterazione, occorre valutare la gravità dell'incidente e le conseguenze che è ancora capace di produrre.

Questa è la decisione che il fabbricante deve saper prendere prima che il cronometro delle 24 ore diventi il problema principale.