I produttori di software e hardware connessi sono già soggetti ai primi obblighi del Cyber Resilience Act: quando un prodotto con elementi digitali presenta una vulnerabilità attivamente sfruttata o subisce un incidente grave, il fabbricante deve utilizzare il sistema europeo di segnalazione gestito da ENISA. Per le imprese interessate serve quindi un processo capace di classificare l’evento, individuare il CSIRT competente e rispettare i termini previsti per le diverse comunicazioni.
In sintesi:
- l’articolo 71, paragrafo 2, del Regolamento (UE) 2024/2847 rende applicabile l’articolo 14 dall’11 settembre 2026;
- l’articolo 14 del Regolamento (UE) 2024/2847 impone ai fabbricanti di segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza del prodotto;
- l’articolo 14 del Regolamento (UE) 2024/2847 prevede un preallarme entro 24 ore, una notifica entro 72 ore e una successiva relazione finale con termini diversi per vulnerabilità e incidenti;
- l’articolo 69, paragrafo 3, del Regolamento (UE) 2024/2847 estende gli obblighi di segnalazione anche ai prodotti con elementi digitali immessi sul mercato prima dell’11 dicembre 2027.
- Cyber Resilience Act, obbligo di notifica per i fabbricanti
- Prodotti con elementi digitali: software e hardware interessati
- Vulnerabilità e incidenti che fanno scattare la segnalazione
- Notifica ENISA: preallarme, comunicazione e relazione finale
- Single Reporting Platform: procedura e controlli
- Cyber Resilience Act e NIS2 disciplinano obblighi diversi
- Linee guida UE e applicazione CRA dal 2027
Cyber Resilience Act, obbligo di notifica per i fabbricanti
Dall’11 settembre 2026 i fabbricanti di prodotti con elementi digitali devono segnalare gli eventi previsti dall’articolo 14 del Cyber Resilience Act. Il nuovo adempimento riguarda un segmento specifico della sicurezza informatica, legato ai prodotti commercializzati nell’Unione europea. La fonte normativa è il Regolamento (UE) 2024/2847 del Parlamento europeo e del Consiglio del 23 ottobre 2024.
Ai sensi dell’articolo 3 del regolamento, il fabbricante è la persona fisica o giuridica che sviluppa o fabbrica il prodotto, oppure lo fa progettare, sviluppare o fabbricare, e lo commercializza con il proprio nome o marchio. L’obbligo può quindi riguardare anche un’impresa che affida lo sviluppo a un fornitore esterno e vende il risultato con il proprio marchio.
L’articolo 21 estende gli obblighi del fabbricante anche a importatori e distributori quando immettono sul mercato il prodotto con il proprio nome o marchio commerciale oppure gli apportano una modifica sostanziale. Una regola analoga opera, ai sensi dell’articolo 22, per altri soggetti che effettuano una modifica sostanziale e mettono successivamente il prodotto a disposizione sul mercato.
Gli obblighi dell’articolo 14 interessano anche i prodotti già commercializzati prima della piena applicazione del CRA. L’articolo 69, paragrafo 3, deroga infatti al regime transitorio e assoggetta alla segnalazione tutti i prodotti con elementi digitali che rientrano nell’ambito del regolamento, compresi quelli immessi sul mercato prima dell’11 dicembre 2027.
Per i gestori di software open source disciplinati dall’articolo 24, gli specifici obblighi di segnalazione decorrono invece dall’11 dicembre 2027. La versione attuale della piattaforma ENISA accetta quindi le notifiche obbligatorie dei fabbricanti previste dall’articolo 14.
Prodotti con elementi digitali: software e hardware interessati
Il Cyber Resilience Act si applica ai prodotti software e hardware con elementi digitali messi a disposizione sul mercato quando la finalità prevista o l’uso ragionevolmente prevedibile comprende una connessione dati diretta o indiretta, logica o fisica, a un dispositivo o a una rete.
La definizione dell’articolo 3 comprende anche i componenti software o hardware commercializzati separatamente e le soluzioni di elaborazione dati da remoto associate al prodotto. Per queste ultime il regolamento richiede che il software sia stato progettato e sviluppato dal fabbricante, o sotto la sua responsabilità, e che la sua assenza impedisca al prodotto di svolgere una delle proprie funzioni.
Tra gli esempi richiamati dalla Commissione rientrano app, programmi informatici, dispositivi intelligenti e altri prodotti hardware collegabili. L’inquadramento va effettuato sul prodotto effettivamente commercializzato e sulle sue funzioni, evitando di considerare automaticamente qualsiasi servizio digitale o software accessibile online come prodotto soggetto al CRA.
Vulnerabilità e incidenti che fanno scattare la segnalazione
L’articolo 14 impone la notifica soltanto per una vulnerabilità attivamente sfruttata o per un incidente grave che incide sulla sicurezza di un prodotto con elementi digitali. La semplice conoscenza di una vulnerabilità priva di evidenze affidabili di sfruttamento da parte di un soggetto malevolo non rientra nell’obbligo di segnalazione previsto da questa disposizione.
| Evento rilevato | Trattamento ai fini dell’articolo 14 |
|---|---|
| vulnerabilità conosciuta senza evidenze affidabili di sfruttamento da parte di un soggetto malevolo | fuori dalla segnalazione obbligatoria dell’articolo 14 |
| vulnerabilità con evidenze affidabili di sfruttamento da parte di un soggetto malevolo | notifica obbligatoria come vulnerabilità attivamente sfruttata |
| incidente privo dei criteri di gravità previsti dal regolamento | fuori dalla segnalazione obbligatoria dell’articolo 14 |
| incidente che compromette o può compromettere dati o funzioni protette oppure comporta o può comportare l’introduzione o l’esecuzione di codice malevolo | notifica obbligatoria se ricorrono i requisiti dell’incidente grave |
Il regolamento definisce attivamente sfruttata una vulnerabilità per la quale esistono prove affidabili che un soggetto malevolo l’abbia sfruttata in un sistema senza l’autorizzazione del proprietario. Il presupposto dell’obbligo è quindi l’evidenza dello sfruttamento, non la sola esistenza del difetto.
L’articolo 14, paragrafo 5, considera grave l’incidente che incide o può incidere negativamente sulla capacità del prodotto di proteggere disponibilità, autenticità, integrità o riservatezza di dati o funzioni sensibili o rilevanti, oppure che porta o può portare all’introduzione o all’esecuzione di codice malevolo nel prodotto o nei sistemi dell’utilizzatore.
Notifica ENISA: preallarme, comunicazione e relazione finale
Il fabbricante che viene a conoscenza di un evento soggetto all’articolo 14 deve rispettare una sequenza di segnalazioni che parte dal momento della conoscenza della vulnerabilità attivamente sfruttata o dell’incidente grave. I termini legali decorrono da questo momento e non dalla registrazione sulla piattaforma.
| Fase | Termine e contenuto |
|---|---|
| preallarme | entro 24 ore dalla conoscenza dell’evento, con le prime informazioni disponibili |
| notifica | entro 72 ore dalla conoscenza dell’evento, con informazioni generali, valutazione iniziale e misure adottate o disponibili |
| relazione finale su vulnerabilità attivamente sfruttata | entro 14 giorni dalla disponibilità della misura correttiva o di attenuazione |
| relazione finale su incidente grave | entro un mese dalla notifica trasmessa entro le 72 ore |
Per una vulnerabilità attivamente sfruttata, la relazione finale deve descrivere la vulnerabilità, la gravità e l’impatto, riportare le informazioni disponibili sul soggetto malevolo e illustrare l’aggiornamento di sicurezza o le altre misure correttive rese disponibili. La scadenza dei 14 giorni decorre dalla disponibilità della misura correttiva o di attenuazione.
Per un incidente grave, la relazione finale deve includere una descrizione dettagliata, la gravità e l’impatto, il tipo di minaccia o la causa che ha probabilmente originato l’incidente e le misure applicate per limitarne gli effetti.
L’articolo 14, paragrafo 8, impone inoltre al fabbricante di informare gli utilizzatori interessati dalla vulnerabilità attivamente sfruttata o dall’incidente grave e, quando necessario, comunicare le misure correttive o di attenuazione che possono adottare.
Single Reporting Platform: procedura e controlli
La CRA Single Reporting Platform è il canale unico attraverso il quale il fabbricante trasmette la notifica al CSIRT designato come coordinatore e a ENISA. La piattaforma è accessibile dal portale CRA SRP di ENISA ed evita l’invio separato alle autorità dei diversi Stati membri nei quali il prodotto è disponibile.
Per predisporre una segnalazione occorre coordinare in anticipo responsabilità aziendali, accesso alla piattaforma e raccolta delle informazioni richieste:
- individuare l’impresa che assume giuridicamente il ruolo di fabbricante e la persona incaricata di presentare la segnalazione;
- determinare il CSIRT designato come coordinatore in base ai criteri dell’articolo 14, paragrafo 7;
- predisporre per il rappresentante incaricato un account personale EU Login con autenticazione multifattore;
- registrare internamente il momento in cui il fabbricante acquisisce conoscenza dell’evento, dal quale decorrono i termini legali;
- raccogliere le informazioni disponibili per il preallarme e aggiornare la medesima segnalazione nelle fasi successive fino alla relazione finale.
Il criterio principale per individuare il CSIRT coordinatore è lo Stato membro nel quale si trova lo stabilimento principale del fabbricante, inteso come il luogo in cui vengono assunte prevalentemente le decisioni sulla cibersicurezza dei prodotti con elementi digitali. Se questo criterio non consente l’individuazione, l’articolo 14 e le istruzioni ENISA prevedono criteri successivi basati sulla struttura dell’impresa e sulla presenza nell’Unione.
Le FAQ ENISA sulla Single Reporting Platform, aggiornate al 17 settembre 2026, richiedono un EU Login con autenticazione multifattore. Ogni fabbricante può associare alla piattaforma un rappresentante principale e fino a 20 rappresentanti secondari; entrambi i profili possono presentare e aggiornare le notifiche secondo le rispettive autorizzazioni.
Alla data del 18 settembre 2026 occorre inoltre controllare con attenzione il timer delle 72 ore mostrato dalla piattaforma. ENISA segnala che la versione attuale calcola la scadenza visualizzata 48 ore dopo l’invio del preallarme; in alcuni casi il sistema può quindi indicare una notifica come scaduta prima che siano trascorse 72 ore dalla conoscenza dell’evento. Il termine giuridico continua a decorrere dal momento in cui il fabbricante ha acquisito conoscenza della vulnerabilità o dell’incidente, ed ENISA ha annunciato un aggiornamento del calcolo.
La piattaforma accetta attualmente le segnalazioni obbligatorie dell’articolo 14. La funzionalità per le comunicazioni volontarie previste dall’articolo 15 sarà introdotta in una fase successiva, secondo le informazioni pubblicate da ENISA.
Cyber Resilience Act e NIS2 disciplinano obblighi diversi
Il Cyber Resilience Act lega gli obblighi esaminati al prodotto con elementi digitali e al soggetto che assume il ruolo di fabbricante. La NIS2 disciplina invece la sicurezza delle reti e dei sistemi informativi dei soggetti che rientrano nelle categorie individuate dalla normativa europea e nazionale.
Una stessa impresa può quindi essere soggetta a CRA e NIS2 per presupposti differenti. Un produttore di dispositivi o software può dover segnalare attraverso la piattaforma ENISA un evento relativo al proprio prodotto ai sensi del CRA e, se è anche soggetto NIS, rispettare gli obblighi previsti per gli incidenti che interessano reti e sistemi aziendali.
Linee guida UE e applicazione CRA dal 2027
Gli orientamenti C(2026) 5252 della Commissione UE accompagnano imprese e sviluppatori nell’interpretazione del CRA sebbene abbiano natura non vincolante; affrontano ambiti di applicazione, elaborazione dati da remoto, software libero e open source, modifiche sostanziali, periodi di assistenza, segnalazioni e valutazione del rischio.
Per microimprese e PMI, la Commissione accompagna gli orientamenti con 67 esempi applicativi, casi d’uso, diagrammi e schemi. Tutta la documentazione è online sul sito web dedicato al CRA.
La piena applicazione del Cyber Resilience Act è prevista dall’11 dicembre 2027. Da quella data acquistano efficacia generale anche i requisiti di cibersicurezza dei prodotti, la valutazione del rischio, gli obblighi di gestione delle vulnerabilità, la documentazione tecnica, la valutazione di conformità e le altre prescrizioni previste dal regolamento.
