7 Agosto 2026 · News
Cyber Resilience Act: cosa cambia dall’11 settembre 2026
Dall’11 settembre 2026 i produttori di hardware e software con elementi digitali dovranno segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi di sicurezza secondo le tempistiche previste dal Cyber Resilience Act. La piena applicazione del regolamento arriverà l’11 dicembre 2027, ma il primo obbligo operativo entra in vigore molto prima e interessa anche prodotti già immessi sul mercato europeo.
Per aziende che progettano dispositivi connessi, applicazioni, sistemi IoT, macchine intelligenti e componenti software, questo significa preparare da subito responsabilità interne, flussi di segnalazione e documentazione di prodotto. La Commissione europea ha pubblicato il 27 luglio 2026 una nuova guida pratica per chiarire campo di applicazione, modifiche sostanziali, periodi di supporto, valutazione del rischio e notifiche.
Che cos’è il Cyber Resilience Act?
Il Cyber Resilience Act, Regolamento (UE) 2024/2847, introduce requisiti orizzontali di cybersicurezza per i prodotti con elementi digitali commercializzati nell’Unione europea. La logica è quella della sicurezza lungo l’intero ciclo di vita: progettazione, sviluppo, produzione, distribuzione, aggiornamento e gestione delle vulnerabilità.
Il regolamento riguarda, in termini generali, prodotti hardware e software e le relative soluzioni di elaborazione dati da remoto quando queste sono necessarie al funzionamento del prodotto. Possono quindi rientrare nel campo di applicazione dispositivi IoT, sistemi domotici, wearable, router, software, applicazioni, firmware, componenti digitali e numerosi prodotti professionali connessi.
| Esempio | Aspetto da verificare |
|---|---|
| Dispositivo IoT | Firmware, app, cloud e aggiornamenti di sicurezza |
| Macchina connessa | Interfacce di rete, accessi remoti e componenti software |
| Applicazione software | Vulnerabilità, dipendenze e modalità di distribuzione |
| Wearable o sensore smart | Autenticazione, comunicazioni, dati e periodo di supporto |
| Componente digitale separato | Ruolo nella catena di fornitura e responsabilità del produttore |
Il campo di applicazione contiene esclusioni e casi particolari. Prima di definire il piano di conformità è quindi necessario qualificare correttamente prodotto, servizi remoti, ruolo dell’azienda e modalità con cui il sistema viene messo a disposizione sul mercato.
Cosa cambia dall’11 settembre 2026?
Da questa data diventano applicabili gli obblighi di segnalazione previsti dall’articolo 14. Secondo la pagina ufficiale della Commissione europea sugli obblighi di reporting, il produttore deve notificare:
- le vulnerabilità contenute nel prodotto che risultano attivamente sfruttate;
- gli incidenti gravi che hanno un impatto sulla sicurezza del prodotto con elementi digitali.
Le tempistiche da conoscere
| Fase | Termine | Obiettivo |
|---|---|---|
| Allerta iniziale | Entro 24 ore dalla conoscenza | Segnalare rapidamente l’evento e le informazioni disponibili |
| Notifica completa | Entro 72 ore | Integrare valutazione, gravità, natura e misure adottate |
| Relazione finale: vulnerabilità | Entro 14 giorni dalla disponibilità della misura correttiva | Descrivere analisi, soluzione e gestione del rischio |
| Relazione finale: incidente grave | Entro un mese | Documentare cause, impatto e azioni correttive |
Le segnalazioni confluiranno nella Single Reporting Platform gestita da ENISA. L’azienda non può quindi aspettare l’incidente per decidere chi raccoglie le informazioni, chi valuta la gravità e chi è autorizzato a inviare la notifica.
L’obbligo riguarda anche prodotti già sul mercato?
Sì, per la parte relativa alle segnalazioni. La sintesi ufficiale del Cyber Resilience Act chiarisce che gli obblighi di reporting si applicano ai prodotti con elementi digitali già messi a disposizione sul mercato dell’Unione, compresi quelli commercializzati prima della piena applicazione del regolamento.
Questo è uno dei punti più importanti per le imprese: non basta controllare i nuovi progetti. Occorre costruire un inventario dei prodotti digitali ancora distribuiti o supportati, delle versioni software attive e dei canali attraverso cui possono emergere vulnerabilità e incidenti.
Cosa deve preparare concretamente un’azienda?
1. Inventario di prodotti e versioni
Creare un elenco dei prodotti con elementi digitali, includendo modello, versione hardware, firmware, software, servizi cloud, dipendenze principali, mercati e periodo di supporto. Senza una mappa aggiornata è difficile capire quale versione sia coinvolta e quanti utenti possano essere esposti.
2. Responsabilità e reperibilità
Definire chi riceve le segnalazioni, chi coordina la valutazione tecnica, chi prende la decisione sulla notifica e chi comunica con clienti, distributori e autorità. Le scadenze di 24 e 72 ore richiedono ruoli già assegnati e una procedura utilizzabile anche durante ferie o festività.
3. Canale per le vulnerabilità
Predisporre un punto di contatto riconoscibile per ricercatori, clienti e partner. Il canale deve permettere di ricevere informazioni tecniche in modo sicuro e di conservarne data, autore, prodotto coinvolto e stato di gestione.
4. Procedura di classificazione
Preparare criteri per distinguere una vulnerabilità potenziale da una vulnerabilità attivamente sfruttata e per riconoscere un incidente grave. La procedura dovrebbe prevedere escalation, raccolta delle evidenze, valutazione dell’impatto e approvazione della notifica.
5. Modelli di segnalazione
Creare in anticipo un modello per l’allerta iniziale, uno per l’integrazione entro 72 ore e uno per la relazione finale. In emergenza, partire da una struttura condivisa riduce errori e ritardi.
6. Tracciabilità di componenti e fornitori
Per molti prodotti la vulnerabilità nasce da una libreria, un modulo radio, un sistema operativo o un servizio esterno. È utile associare ogni componente al fornitore, alla versione, alle condizioni di aggiornamento e al referente tecnico.
La cybersicurezza diventa anche un problema di product design
Il CRA non riguarda soltanto il reparto IT. Le decisioni prese durante la progettazione influenzano accessi, aggiornamenti, manutenzione e comportamento dell’utente. Un’interfaccia poco chiara può favorire password deboli; una procedura di aggiornamento difficile può lasciare installate versioni vulnerabili; un’etichetta priva di identificazione può complicare la gestione di un richiamo o di una comunicazione urgente.
Nel percorso verso la piena applicazione del 2027, il progetto del prodotto dovrebbe coordinare:
- identificazione univoca di modello e versione;
- installazione e configurazione sicure;
- informazioni sul periodo di supporto;
- canali e messaggi per gli aggiornamenti;
- manuali chiari, comprensibili e leggibili;
- coerenza tra dispositivo, packaging, interfaccia e documentazione digitale;
- possibilità di intervenire sul prodotto senza compromettere sicurezza e usabilità.
La guida della Commissione pubblicata il 27 luglio 2026 dedica particolare attenzione proprio a campo di applicazione, modifiche sostanziali, periodo di supporto, valutazione del rischio e reporting, con esempi pratici pensati anche per microimprese e PMI. Il documento è disponibile nella pagina ufficiale dedicata alle linee guida CRA.
Checklist operativa prima dell’11 settembre
- identificare tutti i prodotti digitali ancora sul mercato o supportati;
- mappare firmware, software, cloud, librerie e fornitori critici;
- nominare responsabile e sostituto per le notifiche;
- definire un canale interno ed esterno per le vulnerabilità;
- preparare modelli per 24 ore, 72 ore e relazione finale;
- stabilire criteri di gravità ed escalation;
- verificare accesso e processo della Single Reporting Platform;
- collegare segnalazioni, ticket tecnici e versioni di prodotto;
- preparare messaggi per clienti e distributori;
- eseguire una simulazione prima della scadenza.
Questa checklist non sostituisce una valutazione legale o di cybersicurezza, ma aiuta product manager, progettisti e responsabili di prodotto a individuare subito le lacune organizzative più evidenti.
Come integrare il CRA nello sviluppo di un nuovo prodotto
Per i nuovi dispositivi conviene inserire i requisiti di sicurezza già nel brief iniziale. Architettura elettronica, software, interfaccia, packaging e assistenza devono essere progettati come parti di un unico sistema. Una verifica tardiva, quando stampi, firmware e manuali sono già congelati, rende ogni correzione più lenta e costosa.
Didonna Design Studio affianca aziende e startup nella progettazione di prodotti, interfacce, sistemi informativi, packaging e materiali tecnici. Scopri i nostri servizi e i progetti realizzati.
Stai sviluppando un prodotto connesso?
Possiamo aiutarti a coordinare dispositivo, interfaccia, identificazione, packaging e documentazione, preparando il progetto per le verifiche tecniche e normative.
Domande frequenti
Quando si applica il Cyber Resilience Act?
Il regolamento è entrato in vigore il 10 dicembre 2024. Gli obblighi di segnalazione si applicano dall’11 settembre 2026, mentre le principali disposizioni diventano applicabili dall’11 dicembre 2027.
Quali eventi devono essere segnalati?
I produttori devono notificare le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza dei prodotti con elementi digitali.
Quanto tempo ha il produttore per la prima segnalazione?
L’allerta iniziale deve essere inviata entro 24 ore dal momento in cui il produttore viene a conoscenza dell’evento. La notifica completa segue entro 72 ore.
La segnalazione riguarda anche prodotti venduti prima del 2027?
Sì. Gli obblighi di reporting si applicano anche ai prodotti con elementi digitali già messi a disposizione sul mercato dell’Unione.
Packaging e manuali rientrano nel lavoro di adeguamento?
Possono essere coinvolti perché identificazione, istruzioni, configurazione sicura, periodo di supporto e canali di aggiornamento devono risultare coerenti e comprensibili lungo l’esperienza del prodotto.