Dall’11 settembre 2026 i produttori di hardware e software devono notificare le vulnerabilità già sfruttate e gli incidenti gravi: il primo avviso va inviato entro 24 ore, la notifica completa entro 72.
Dall’11 settembre 2026, quando in un prodotto digitale venduto nell’Unione europea emerge una vulnerabilità che qualcuno sta già sfruttando, il tempo smette di appartenere soltanto all’attaccante e al gruppo di sicurezza che cerca di fermarlo: diventa tempo normativo, scandito da un primo avviso entro 24 ore, da una notifica più completa entro 72 e, successivamente, da una relazione finale che deve spiegare che cosa è accaduto e come il rischio è stato corretto.
È il primo passaggio operativo del Cyber Resilience Act, il Regolamento europeo 2024/2847 la norma che introduce requisiti comuni di sicurezza per i prodotti con elementi digitali commercializzati nell’Unione europea. La maggior parte degli obblighi entrerà pienamente in applicazione l’11 dicembre 2027, quando sicurezza del prodotto, gestione delle vulnerabilità, aggiornamenti e documentazione diventeranno condizioni necessarie anche per la marcatura CE; il calendario, però, contiene una data più vicina, che molte aziende hanno lasciato sullo sfondo e che adesso arriva con la precisione di un conto alla rovescia. Quella data è l’11 settembre 2026.
Indice dei contenuti
Il Cyber Resilience Act comincia prima del 2027
La distanza tra il 2026 e il 2027 ha creato un equivoco comodo, soprattutto nelle imprese che hanno interpretato il Cyber Resilience Act come un cantiere normativo ancora aperto, importante ma rimandabile; secondo il calendario ufficiale della Commissione europea , invece, gli obblighi di segnalazione previsti dall’articolo 14 diventano applicabili quindici mesi prima delle altre disposizioni principali.
Da quel momento i produttori devono comunicare due tipi di eventi: le vulnerabilità attivamente sfruttate, per le quali esistono prove affidabili di un utilizzo da parte di un soggetto malevolo senza il permesso del proprietario del sistema, e gli incidenti capaci di produrre un impatto grave sulla sicurezza di un prodotto con elementi digitali.
La distinzione è importante, perché il Cyber Resilience Act non impone di segnalare automaticamente ogni bug, ogni vulnerabilità scoperta durante un test o ogni nuova CVE assegnata a un componente: il cronometro parte quando il produttore viene a conoscenza di uno sfruttamento attivo e non autorizzato, oppure quando si verifica un incidente grave che colpisce, o può colpire, disponibilità, autenticità, integrità o riservatezza di dati e funzioni rilevanti.
Il punto sembra tecnico, ma contiene la parte più difficile della norma: per rispettare le 24 ore, un’azienda deve sapere con precisione quando può dirsi realmente consapevole dell’evento, chi possiede le informazioni necessarie e chi ha l’autorità per trasformare un segnale raccolto dal SOC, una comunicazione ricevuta da un ricercatore o un allarme proveniente da un fornitore in una notifica formale. Che cosa deve essere segnalato entro 24 ore
Il primo adempimento è una comunicazione preliminare, da trasmettere senza ritardo e comunque entro 24 ore dal momento in cui il produttore viene a conoscenza della vulnerabilità attivamente sfruttata o dell’incidente grave. In questa fase non è richiesta una ricostruzione completa, che in molti casi sarebbe impossibile ottenere in un solo giorno; l’azienda deve però indicare la natura dell’evento, i prodotti coinvolti, gli Stati nei quali questi sono stati messi a disposizione e, per gli incidenti, se esistono elementi che facciano pensare a un’azione illecita o malevola.
Entro 72 ore deve seguire una notifica più articolata, con le informazioni disponibili sulla vulnerabilità, sulla natura dell’exploit, sull’impatto dell’incidente e sulle misure correttive o di mitigazione già adottate. Per una vulnerabilità sfruttata attivamente, la relazione finale va presentata entro 14 giorni dalla disponibilità di una correzione, come una patch; per un incidente grave, il termine indicato da ENISA nelle FAQ operative è di un mese dalla notifica delle 72 ore.
La logica è quella di una conoscenza che si costruisce nel tempo: la prima comunicazione segnala il pericolo, la seconda offre una valutazione iniziale, la relazione finale mette in fila causa, conseguenze e rimedio. Aspettare di aver compreso tutto prima di comunicare significa perdere il termine più importante.
La Single Reporting Platform di ENISA
Le segnalazioni passano attraverso la Single Reporting Platform, realizzata e gestita da ENISA, che dall’11 settembre consente al produttore di effettuare un’unica comunicazione, selezionando il CSIRT designato come coordinatore nello Stato membro nel quale vengono prese prevalentemente le decisioni sulla sicurezza dei prodotti. Per un’impresa italiana, in condizioni ordinarie, il riferimento sarà quindi il CSIRT Italia; la notifica viene resa disponibile contemporaneamente a ENISA, mentre il CSIRT che la riceve la condivide con gli organismi degli altri Paesi nei quali il prodotto è presente e, quando necessario, con le autorità di vigilanza del mercato. Esistono circostanze eccezionali nelle quali la diffusione delle informazioni può essere ritardata, quando una condivisione immediata aumenterebbe il rischio per la sicurezza; devono però essere indicate e motivate durante la procedura, perché l’eccezione non è una casella da selezionare per proteggere la reputazione dell’azienda. La piattaforma concentra informazioni che, per loro natura, possono diventare preziose anche per un attaccante: prodotti coinvolti, vulnerabilità già utilizzate e misure ancora incomplete. ENISA dichiara di aver predisposto controlli tecnici e organizzativi per proteggere la riservatezza, insieme a test periodici; resta un’infrastruttura critica, perché raccoglie in un solo punto una parte della conoscenza più sensibile dell’ecosistema digitale europeo.
Chi deve rispettare gli obblighi del Cyber Resilience Act
Il perimetro del Cyber Resilience Act comprende i prodotti con elementi digitali messi a disposizione sul mercato europeo, quando il loro uso previsto o ragionevolmente prevedibile comporta una connessione diretta o indiretta, fisica o logica, con un dispositivo o una rete.
Dentro questa definizione entrano software, sistemi operativi, applicazioni, dispositivi IoT, router, apparati industriali, componenti di rete e molti prodotti fisici nei quali il codice svolge una funzione essenziale; possono rientrare anche alcune soluzioni di elaborazione remota collegate al prodotto, mentre un servizio SaaS autonomo non ricade automaticamente nel regolamento soltanto perché viene erogato attraverso internet. Il soggetto principalmente obbligato è il produttore, vale a dire chi sviluppa o fa sviluppare un prodotto e lo commercializza con il proprio nome o marchio. Importatori e distributori possono assumere le responsabilità del produttore quando vendono il prodotto con il proprio marchio oppure lo modificano in modo sostanziale, una circostanza che rende decisivo comprendere chi controlla davvero sviluppo, aggiornamenti e decisioni di sicurezza lungo la filiera. Gli obblighi di segnalazione riguardano anche i prodotti immessi sul mercato prima della piena applicazione del regolamento, purché rientrino nel suo campo di applicazione. L’11 settembre, quindi, non si apre un perimetro riservato ai nuovi prodotti: il produttore deve guardare anche a ciò che ha già distribuito e che continua a funzionare nelle infrastrutture dei clienti.
Che cosa cambia per l’open source
Il software libero e open source sviluppato o fornito al di fuori di un’attività commerciale resta in gran parte escluso dagli obblighi destinati ai produttori; il legislatore ha però introdotto la figura dell’open-source software steward, l’organizzazione che sostiene in modo sistematico lo sviluppo di prodotti open source destinati ad attività commerciali. Secondo la documentazione ENISA sulla piattaforma di segnalazione , anche questi soggetti devono comunicare vulnerabilità attivamente sfruttate e incidenti gravi nella misura in cui sono coinvolti nello sviluppo dei prodotti interessati.
È un passaggio delicato, perché gran parte dell’economia digitale poggia su componenti mantenuti da comunità ristrette, fondazioni o singoli sviluppatori, mentre il valore economico viene spesso raccolto molto più avanti nella catena; il Cyber Resilience Act prova a distinguere il lavoro aperto e non commerciale dalle attività strutturate, senza cancellare il problema della responsabilità lungo una filiera nella quale chi scrive il codice, chi lo incorpora e chi lo vende raramente coincidono.
Le 24 ore cambiano l’organizzazione dell’impresa
Il termine di 24 ore rende insufficiente una procedura custodita in un documento e mai sottoposta a prova; il venerdì sera, durante una festività o mentre il responsabile abituale è irraggiungibile, il tempo continua a scorrere con la stessa velocità.
Le aziende devono quindi identificare in anticipo almeno cinque elementi:
1. quali prodotti rientrano nel campo di applicazione del Cyber Resilience Act e quali versioni sono ancora presenti sul mercato;
2. quali segnali possono dimostrare che una vulnerabilità è sfruttata attivamente;
3. chi decide che l’evento è soggetto a notifica e registra il momento nel quale l’azienda ne è venuta a conoscenza;
4. chi è autorizzato a utilizzare la piattaforma ENISA e a rappresentare il produttore;
5. come vengono informati clienti, partner, distributori e utenti delle misure necessarie a contenere il rischio.
ENISA prevede un rappresentante principale per ciascun produttore e fino a venti rappresentanti secondari; l’accesso utilizza un account EU Login personale, protetto con autenticazione a più fattori. La registrazione richiede pochi minuti e può essere completata anche mentre la validazione del rappresentante è ancora in corso, ma la semplicità del modulo non risolve ciò che accade prima: raccolta delle prove, classificazione dell’evento, coordinamento tra sicurezza, sviluppo, direzione e ufficio legale.
Il rapporto tra Cyber Resilience Act, NIS2 e DORA
Il Cyber Resilience Act si inserisce in un sistema europeo nel quale agiscono già NIS2, DORA, GDPR e norme settoriali; gli obblighi possono incontrarsi sullo stesso incidente, ma osservano soggetti e oggetti diversi.
La direttiva NIS2 guarda soprattutto alla sicurezza e alla continuità delle organizzazioni essenziali o importanti; DORA disciplina la resilienza operativa digitale del settore finanziario. Il Cyber Resilience Act segue il prodotto lungo il proprio ciclo di vita, dal progetto alla distribuzione, fino agli aggiornamenti e alla gestione delle vulnerabilità.Un attacco può quindi generare più obblighi paralleli: il produttore del software segnala la vulnerabilità secondo il CRA, l’azienda che subisce l’incidente comunica secondo NIS2, mentre un intermediario finanziario valuta anche gli adempimenti previsti da DORA. La segnalazione unica promessa dalla piattaforma ENISA riguarda il percorso interno al Cyber Resilience Act, non cancella automaticamente le altre notifiche previste dalla legge. Per questo la conformità non può essere distribuita in silos, con una procedura per ogni regolamento e persone diverse che scoprono troppo tardi di stare descrivendo lo stesso attacco.
L’intelligenza artificiale accorcia anche il tempo della difesa
Il nuovo obbligo arriva mentre l’intelligenza artificiale sta aumentando la velocità con cui il codice viene analizzato, le vulnerabilità vengono trovate e gli exploit vengono costruiti. Digitalic ha raccontato questa trasformazione attraverso Gemini 3.5 Flash Cyber, progettato per individuare e correggere autonomamente le vulnerabilità e con GPT-6 Astra, capace secondo OpenAI di affrontare sistemi informatici complessi con un’autonomia superiore.
La stessa accelerazione opera su entrambi i lati: aiuta i ricercatori a esaminare milioni di righe di codice, ma riduce anche l’intervallo tra la pubblicazione di una falla e il suo utilizzo offensivo. Il Cyber Resilience Act porta questa compressione dentro l’organizzazione aziendale, chiedendo che la catena di responsabilità sia abbastanza veloce da trasformare una scoperta tecnica in una decisione verificabile entro un giorno. Il software, per anni, è stato venduto come se le vulnerabilità fossero una conseguenza quasi naturale della complessità, da risolvere con aggiornamenti successivi e tempi decisi dal produttore; il regolamento europeo cambia quel rapporto, perché considera la sicurezza una proprietà del prodotto e la gestione delle falle una responsabilità che continua dopo la vendita.
Cosa devono fare subito le aziende per il Cyber Resilience Act
Entro l’11 settembre un produttore dovrebbe avere mappato i propri prodotti, nominato i responsabili delle segnalazioni, verificato gli accessi alla piattaforma, stabilito una procedura per gli eventi fuori orario e definito quali fonti monitorare: segnalazioni dei clienti, bug bounty, ricercatori indipendenti, CSIRT, database delle vulnerabilità, fornitori di componenti e sistemi interni di rilevamento. Serve soprattutto una traccia del momento in cui l’informazione diventa abbastanza affidabile da costituire consapevolezza, perché da lì partono le 24 ore; senza questa registrazione, l’impresa rischia di discutere per giorni su quando abbia realmente saputo ciò che i suoi sistemi avevano già rilevato.
