Dall'11 settembre 2026 i fabbricanti di prodotti con elementi digitali venduti nell'Unione devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi ai sensi dell'articolo 14 del Cyber Resilience Act (CRA, Regolamento (UE) 2024/2847). L'obbligo si applica più di un anno prima del resto del regolamento e riguarda anche i prodotti già sul mercato. Questa guida spiega che cosa segnalare, entro quando, a chi e come, con i chiarimenti pubblicati dalla Commissione europea e una checklist di preparazione. Per il quadro generale del regolamento potete leggere la nostra panoramica sugli obblighi del Cyber Resilience Act per i fabbricanti.
In breve
- L'articolo 14 si applica dall'11 settembre 2026; il resto del CRA dall'11 dicembre 2027 (art. 71, par. 2).
- Due eventi fanno scattare la segnalazione obbligatoria: una vulnerabilità attivamente sfruttata nel prodotto e un incidente grave che ha un impatto sulla sicurezza del prodotto.
- Ogni segnalazione ha tre fasi: notifica di preallarme entro 24 ore, notifica entro 72 ore e relazione finale, che per una vulnerabilità scade 14 giorni dopo la disponibilità di una correzione e per un incidente un mese dopo la notifica delle 72 ore.
- Un solo invio sulla piattaforma unica di segnalazione dell'ENISA raggiunge contemporaneamente il CSIRT designato come coordinatore dello Stato dello stabilimento principale e l'ENISA. Per uno stabilimento principale in Italia quel CSIRT è il CSIRT Italia.
- L'obbligo vale anche per i prodotti immessi sul mercato prima dell'11 dicembre 2027, compresi quelli il cui periodo di assistenza è finito.
- La violazione dell'articolo 14 può comportare sanzioni fino a 15 milioni di euro o al 2,5% del fatturato mondiale annuo, se superiore.
Che cosa segnalare: vulnerabilità attivamente sfruttate e incidenti gravi
L'articolo 14 non chiede di segnalare ogni vulnerabilità. Indica due eventi, entrambi definiti dal regolamento (art. 14, par. 1 e 3).
Vulnerabilità attivamente sfruttata
È una vulnerabilità "per la quale esistono prove attendibili che un soggetto malintenzionato l'ha sfruttata in un sistema senza l'autorizzazione del proprietario del sistema" (art. 3, punto 42). Conta la prova di uno sfruttamento malevolo, non il punteggio di gravità. La Commissione porta due esempi di casi che non rientrano: una vulnerabilità zero-day segnalata tramite un programma di bug bounty senza prove di uno sfruttamento malevolo precedente, e una scoperta da un laboratorio che testa il prodotto per conto del fabbricante (FAQ della Commissione sul CRA, sezione 5.2). Entrambe possono comunque essere segnalate su base volontaria ai sensi dell'articolo 15.
Incidente grave che ha un impatto sulla sicurezza del prodotto
Un incidente è grave se (art. 14, par. 5):
- incide negativamente, o è in grado di incidere negativamente, sulla capacità del prodotto di proteggere la disponibilità, l'autenticità, l'integrità o la riservatezza di dati o funzioni sensibili o importanti; oppure
- ha portato, o è in grado di portare, all'introduzione o all'esecuzione di codice maligno nel prodotto o nei sistemi informativi e di rete di un utilizzatore del prodotto.
Da quando decorrono i termini
Tutti i termini decorrono dal momento in cui il fabbricante ne viene a conoscenza. Secondo la Commissione, questo accade dopo una valutazione iniziale dell'evento sospetto, quando il fabbricante ha un ragionevole grado di certezza che una vulnerabilità del suo prodotto sia attivamente sfruttata. Lo stesso vale quando ha un ragionevole grado di certezza che un incidente grave abbia compromesso la sicurezza del prodotto. La valutazione iniziale va svolta subito (orientamenti della Commissione sul CRA, C(2026) 5252, sezione 9.1).
Le scadenze
| Fase | Vulnerabilità attivamente sfruttata (art. 14, par. 2) | Incidente grave (art. 14, par. 4) |
|---|---|---|
| Notifica di preallarme | Entro 24 ore dalla conoscenza. Indica, se del caso, gli Stati membri in cui il prodotto è stato messo a disposizione. | Entro 24 ore dalla conoscenza. Precisa almeno se si sospetta che l'incidente sia il risultato di atti illegittimi o malevoli e indica gli Stati membri in cui il prodotto è stato messo a disposizione. |
| Notifica | Entro 72 ore dalla conoscenza: informazioni generali sul prodotto, natura generale dello sfruttamento e della vulnerabilità, misure correttive o di attenuazione adottate e quelle che gli utilizzatori possono adottare, grado di sensibilità delle informazioni. | Entro 72 ore dalla conoscenza: natura dell'incidente, valutazione iniziale, misure correttive o di attenuazione adottate e quelle che gli utilizzatori possono adottare, grado di sensibilità delle informazioni. |
| Relazione finale | Entro 14 giorni dalla messa a disposizione di una misura correttiva o di attenuazione: descrizione, gravità e impatto; se disponibili, informazioni sul soggetto malintenzionato; dettagli dell'aggiornamento di sicurezza o delle altre misure correttive. | Entro un mese dalla notifica delle 72 ore: descrizione dettagliata, gravità e impatto; tipo di minaccia o causa di fondo; misure di attenuazione adottate e in corso. |
Tre dettagli contano quando si progetta il processo:
- I termini delle due relazioni finali decorrono da momenti diversi: per una vulnerabilità dalla disponibilità di una correzione o attenuazione, per un incidente dalla trasmissione della notifica delle 72 ore.
- La notifica e la relazione finale sono dovute "a meno che non siano già state fornite le informazioni pertinenti" in una fase precedente.
- Il CSIRT che ha ricevuto per primo la notifica può chiedere una relazione intermedia sugli aggiornamenti della situazione (art. 14, par. 6).
Dove segnalare: la piattaforma unica e il CSIRT coordinatore
Le notifiche passano dalla piattaforma unica di segnalazione istituita e gestita dall'ENISA (art. 16). Il fabbricante trasmette una sola volta, attraverso il terminale per la notifica elettronica del CSIRT designato come coordinatore dello Stato membro in cui ha lo stabilimento principale, e la notifica è contemporaneamente accessibile all'ENISA (art. 14, par. 7). Quel CSIRT la inoltra poi ai CSIRT degli altri Stati membri in cui il prodotto è disponibile; può ritardare l'inoltro solo in circostanze eccezionali e per motivi di cibersicurezza giustificati.
Quale CSIRT
Lo stabilimento principale si trova nello Stato membro in cui sono prevalentemente adottate le decisioni sulla cibersicurezza dei prodotti. Se non è possibile determinarlo, è quello in cui il fabbricante ha lo stabilimento con il maggior numero di dipendenti nell'Unione. Un fabbricante senza stabilimento principale nell'Unione segue un ordine fisso: lo Stato del rappresentante autorizzato, poi dell'importatore, poi del distributore che tratta il maggior numero dei suoi prodotti e infine quello in cui si trova il maggior numero dei suoi utilizzatori.
In Italia il D.Lgs. 138/2024 designa il CSIRT Italia come coordinatore ai sensi dell'articolo 12 della direttiva NIS 2 (D.Lgs. 138/2024, art. 16) e il CRA definisce il proprio CSIRT coordinatore rinviando allo stesso articolo (art. 3, punto 51). Per un fabbricante con stabilimento principale in Italia il destinatario è quindi il CSIRT Italia, lo stesso organismo che riceve le notifiche degli incidenti NIS 2. L'ENISA avverte che una notifica inviata al CSIRT sbagliato può essere invalidata e va ripresentata a quello corretto (ENISA, FAQ della piattaforma, n. 18). L'elenco dei CSIRT designati come coordinatori è sulla pagina della piattaforma unica dell'ENISA.
La piattaforma
L'ENISA ha avviato la piattaforma l'11 settembre 2026 in una prima versione, che chiama "initial operating capability", e ne estenderà le funzioni nei prossimi mesi (ENISA, 11 settembre 2026). La Commissione la indica come operativa dall'11 settembre 2026 (Commissione, obblighi di segnalazione del CRA).
- Le notifiche sono trasmesse dai referenti del fabbricante sulla piattaforma (Assigned Representative, nella terminologia ENISA), ciascuno con un account EU Login personale e l'autenticazione a più fattori.
- Il CSIRT convalida il legame tra referente e fabbricante; nell'attesa della convalida le notifiche si possono già trasmettere.
- L'ENISA consiglia di registrarsi quando serve inviare una notifica: con un account EU Login già attivo la registrazione richiede pochi minuti (FAQ della piattaforma, n. 9, aggiornate al 3 ottobre 2026).
- All'8 ottobre 2026 il formato delle notifiche è definito dalla piattaforma e dalle guide, dal glossario e dal manuale utente dell'ENISA. Il regolamento consente alla Commissione di specificarlo con atti di esecuzione (art. 14, par. 10).
I CSIRT designati come coordinatori prestano assistenza sugli obblighi dell'articolo 14, in particolare a microimprese e piccole e medie imprese (art. 17, par. 6); l'ENISA mette a disposizione un helpdesk per le domande a cui le guide non rispondono.
Prodotti già sul mercato, componenti e open source
- Prodotti già sul mercato. L'articolo 14 si applica a tutti i prodotti che rientrano nel regolamento e sono stati immessi sul mercato prima dell'11 dicembre 2027 (art. 69, par. 3). La Commissione precisa che l'obbligo di segnalazione continua dopo la fine del periodo di assistenza, mentre i requisiti di gestione delle vulnerabilità dell'allegato I, parte II, non si applicano a questi prodotti (orientamenti, sezione 9.1).
- Sfruttamento noto prima dell'11 settembre 2026. Non va segnalato a posteriori lo sfruttamento attivo di cui il fabbricante era già a conoscenza prima di quella data. Una vulnerabilità nota da prima, ma di cui si scopre lo sfruttamento solo dopo l'11 settembre 2026, va segnalata (orientamenti, sezione 9.1).
- Componenti di terze parti. Se una vulnerabilità attivamente sfruttata del vostro prodotto proviene da un componente integrato, la segnalate voi; la segnala anche il fabbricante del componente, se il componente è stato immesso sul mercato. Una vulnerabilità del componente che non può essere sfruttata, o non è stata sfruttata, nel vostro prodotto non è per voi una segnalazione obbligatoria: va comunque comunicata a chi produce o mantiene il componente (art. 13, par. 6) e può essere notificata su base volontaria (FAQ, sezione 5.4).
- Gestori di software open source. I loro obblighi di segnalazione (art. 24, par. 3) si applicano dall'11 dicembre 2027 (Commissione, obblighi di segnalazione del CRA). Un fabbricante che integra componenti open source segnala dall'11 settembre 2026 come qualsiasi altro fabbricante.
Informare gli utilizzatori
Quando viene a conoscenza di una vulnerabilità attivamente sfruttata o di un incidente grave, il fabbricante ne informa gli utilizzatori interessati e, se del caso, tutti gli utilizzatori. Se necessario, indica anche le misure di attenuazione e correttive che possono adottare, se del caso in un formato strutturato e leggibile da un dispositivo automatico (art. 14, par. 8). Se il fabbricante non li informa tempestivamente, possono farlo i CSIRT che hanno ricevuto la notifica.
Informare gli utilizzatori non significa rendere pubblica la vulnerabilità. La Commissione osserva che, per i prodotti usati in ambienti sensibili, i dettagli possono essere limitati ai clienti interessati e che una divulgazione più ampia può seguire quando il problema è stato risolto (orientamenti, sezione 9.1).
Le sanzioni
La non conformità agli articoli 13 e 14 e ai requisiti essenziali di cibersicurezza dell'allegato I può comportare sanzioni amministrative pecuniarie. Il massimo è di 15 milioni di euro o, per un'impresa, del 2,5% del fatturato mondiale totale annuo dell'esercizio precedente, se superiore (art. 64, par. 2). È la fascia più alta del CRA, sopra quella di 10 milioni di euro o del 2% prevista per altri obblighi. L'importo tiene conto della natura, della gravità e della durata della violazione e delle dimensioni dell'operatore, con particolare riguardo a microimprese, piccole e medie imprese e start-up.
Il regolamento prevede un trattamento più favorevole per le microimprese e le piccole imprese che non rispettano soltanto il termine di 24 ore della notifica di preallarme; verificatene la portata esatta con l'autorità (art. 64, par. 10). Ogni Stato membro fissa le sanzioni entro i massimi del regolamento (art. 64, par. 1); all'8 ottobre 2026 il quadro italiano è in via di definizione. La sola notifica non aumenta la responsabilità di chi la presenta (art. 17, par. 4).
Checklist di preparazione
- Stabilire chi decide se un evento è una vulnerabilità attivamente sfruttata o un incidente grave, e riportare nella procedura di triage i criteri dell'art. 3, punto 42, e dell'art. 14, par. 5.
- Registrare per ogni caso quando si è conclusa la valutazione iniziale e con quale esito: da quel momento decorrono le 24 ore.
- Individuare lo stabilimento principale e il relativo CSIRT coordinatore; per uno stabilimento principale in Italia, il CSIRT Italia.
- Creare account EU Login personali con autenticazione a più fattori per almeno due persone che faranno da referenti sulla piattaforma, e leggere il manuale utente e il glossario dell'ENISA.
- Tenere l'elenco degli Stati membri in cui ogni prodotto è messo a disposizione: la notifica di preallarme lo richiede.
- Mantenere un inventario dei componenti, per esempio una SBOM, per capire in fretta se una vulnerabilità sfruttata di un componente riguarda il prodotto, e un canale per segnalarla a chi lo mantiene.
- Preparare modelli per le tre fasi e per l'avviso agli utilizzatori, con un campo per il grado di sensibilità delle informazioni.
- Includere nella procedura i prodotti già sul mercato e quelli fuori assistenza.
- Registrare la data in cui ogni correzione o attenuazione diventa disponibile: da lì decorrono i 14 giorni per la relazione finale su una vulnerabilità.
- Provare la procedura su un caso passato e misurare i tempi di ogni fase. La nostra guida al piano di gestione degli incidenti e notifica al CSIRT mostra come strutturare il documento nella NIS 2.
Se la vostra azienda è anche un soggetto NIS
Le segnalazioni del CRA e le notifiche NIS 2 sono obblighi distinti. Un incidente grave che riguarda il vostro prodotto può dover essere valutato anche come incidente significativo ai sensi del D.Lgs. 138/2024, con la propria pre-notifica, notifica e relazione finale al CSIRT Italia (art. 25). La sequenza è spiegata nella nostra guida alla notifica degli incidenti secondo l'articolo 25; i soggetti della Legge 90/2024 seguono anche la tassonomia degli incidenti dell'ACN.
Con il Digital Omnibus (COM(2025) 837) la Commissione ha proposto un punto di ingresso unico gestito dall'ENISA, che potrebbe basarsi sulla piattaforma del CRA: la segnalazione di un incidente grave fatta dal fabbricante ai sensi del CRA varrebbe anche come segnalazione NIS 2, se contiene le informazioni richieste. All'8 ottobre 2026 è una proposta, non è stata adottata e le regole del CRA restano invariate. Sulle altre proposte europee in discussione potete leggere la nostra analisi della revisione del Cybersecurity Act.
Se siete anche soggetti NIS 2, con il nostro servizio di notifica degli incidenti NIS 2 vi guidiamo nel preparare le comunicazioni sugli incidenti significativi nei tempi della NIS 2: pre-notifica, notifica e relazione finale.