Ventiquattro ore per segnalare, e vale già da settembre

Il regolamento sulla ciberresilienza — il Cyber Resilience Act, regolamento (UE) 2024/2847 — ha la sua data da titolo di giornale l'11 dicembre 2027: da quel giorno un prodotto con elementi digitali non potrà essere messo sul mercato europeo senza rispettare i requisiti essenziali di cibersicurezza. È la data su cui sono tarate quasi tutte le consulenze che girano.

Nel frattempo, l'11 settembre 2026, è entrato in applicazione l'articolo che obbliga i fabbricanti a segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi, con la piattaforma europea per farlo accesa lo stesso giorno. La differenza fra le due date è sostanziale: il 2027 chiede di progettare prodotti diversi, settembre 2026 chiede di avere già oggi una procedura che funzioni entro ventiquattro ore.

Che cosa si applica già e che cosa no

Il regolamento è del 23 ottobre 2024 ed è entrato in vigore il 10 dicembre 2024 — «entrare in vigore» vuol dire che il testo fa parte dell'ordinamento, non che tutti i suoi obblighi siano esigibili. Le date di applicazione, quelle che contano per chi deve adempiere, sono scalate: la Commissione europea, nella propria sintesi del testo legislativo, le elenca così. Il capo IV, sulla notifica degli organismi di valutazione della conformità, si applica dall'11 giugno 2026; gli obblighi di segnalazione previsti dall'articolo 14 dall'11 settembre 2026; il regolamento è pienamente applicabile dall'11 dicembre 2027.

In mezzo ci sono tappe che riguardano le amministrazioni più che le imprese. Ma due pezzi utili sono già usciti: il regolamento di esecuzione (UE) 2025/2392 del 28 novembre 2025, in vigore dal 21 dicembre 2025, con la descrizione tecnica delle categorie di prodotti «importanti» e «critici»; e il primo blocco di orientamenti della Commissione sull'applicazione del regolamento, atto C(2026) 5252 del 27 luglio 2026, dichiaratamente non vincolante, che secondo la pagina di presentazione contiene 67 esempi pratici e affronta i punti su cui si litiga: perimetro di applicazione, software libero e open source, soluzioni di elaborazione dati a distanza, modifiche sostanziali, periodo di assistenza.

Chi è «fabbricante» e che cos'è un «prodotto con elementi digitali»

Qui sta il punto che fa sbagliare i conti. «Prodotto con elementi digitali» non vuol dire oggetto di plastica con dentro un chip: la sintesi ufficiale di EUR-Lex descrive l'ambito come i prodotti messi a disposizione sul mercato dell'Unione che possono connettersi, direttamente o indirettamente, ad altri dispositivi o reti. Il software rientra, il firmware rientra, il gestionale venduto a licenza rientra. Restano fuori, perché coperti da normative di settore, i dispositivi medici, i prodotti aeronautici e automobilistici regolati da leggi specifiche e l'equipaggiamento marittimo; e resta fuori ciò che non è messo a disposizione sul mercato.

Quest'ultima precisazione è il discrimine che interessa il lettore che smanetta: un progetto tenuto per sé, o il software scritto per uso interno della propria azienda, non è messo sul mercato. Il confine esatto, però, non si traccia a occhio, e due casi — il software libero distribuito gratuitamente e i servizi in cui il software gira sui server del fornitore («soluzioni di elaborazione dati a distanza», nel lessico del regolamento) — sono materia degli orientamenti di luglio. Chi si trova lì ha un motivo concreto per leggerli prima di decidere di non essere interessato.

I quattro termini

La pagina della Commissione sugli obblighi di segnalazione descrive un meccanismo a scaglioni, lo stesso che chi conosce la direttiva NIS2 ha già visto all'opera. Due gli eventi che innescano l'obbligo: una vulnerabilità attivamente sfruttata contenuta nel prodotto, e un incidente grave che incida sulla sicurezza del prodotto.

Entro ventiquattro ore va trasmesso un preavviso; entro settantadue ore la notifica completa. Per le vulnerabilità, la relazione finale va presentata non più tardi di quattordici giorni dopo che una misura correttiva è disponibile; per gli incidenti gravi, entro un mese dalla notifica a settantadue ore. La logica del termine sulle vulnerabilità merita attenzione: non decorre dalla scoperta ma dalla disponibilità del rimedio. Il preavviso di ventiquattro ore all'autorità, invece, è dovuto subito.

La segnalazione, dice la Commissione, è indirizzata al CSIRT — il gruppo nazionale di risposta agli incidenti informatici — dello Stato membro in cui il fabbricante ha lo stabilimento principale, e l'informazione è messa contemporaneamente a disposizione di ENISA, l'agenzia europea per la cibersicurezza, salvo circostanze eccezionali. Il CSIRT che la riceve la condivide senza indugio con gli altri, e può ritardarne la diffusione per motivi giustificati. Si segnala una volta sola: è la piattaforma a smistare.

Dove si segnala, e chi preme il pulsante

La piattaforma si chiama CRA Single Reporting Platform. ENISA ne ha annunciato l'avvio l'11 settembre 2026, lo stesso giorno in cui l'obbligo è diventato esigibile: l'ha sviluppata e la gestisce, e secondo il comunicato consente di notificare una volta sola. Per gli steward del software open source — la figura che il regolamento costruisce per chi sostiene un progetto libero senza venderlo — il comunicato indica che l'obbligo dell'articolo 24, paragrafo 3, si applicherà dall'11 dicembre 2027.

Un dettaglio operativo che sfugge a quasi tutti i riassunti circolanti sta scritto sulla schermata d'ingresso del portale: la notifica non la manda «l'azienda», la manda una persona fisica designata. Il portale chiede di dichiarare se si è un «rappresentante incaricato» o un rappresentante di un CSIRT, e definisce il primo come l'individuo che presenta le notifiche per conto del fabbricante o dello steward, in relazione agli obblighi degli articoli 14, 16 e 24, paragrafo 3. Tradotto: serve un nome, serve che abbia accesso al portale, e serve che ci sia prima dell'incidente.

Perché ventiquattro ore sono un problema di organizzazione

Il termine non è tecnicamente difficile: compilare un modulo richiede minuti. La difficoltà sta prima. Il cronometro parte da quando il fabbricante viene a conoscenza del fatto, e nelle aziende la conoscenza arriva per vie informali: un cliente che chiama perché il dispositivo fa cose strane, un messaggio su un forum. Serve che chi riceve quella segnalazione sappia di avere in mano l'inizio di un termine di legge, e sappia a chi passarla.

Serve poi qualcuno che decida — con una soglia stabilita in anticipo, non sul momento — se una vulnerabilità è attivamente sfruttata o soltanto nota: una valutazione che in molte realtà piccole oggi nessuno è formalmente incaricato di fare. E vale la pena ricordare che un venerdì sera e un lunedì mattina sono separati da più di ventiquattro ore.

C'è infine un presupposto che sembra ovvio e quasi mai lo è: sapere quali dei propri prodotti con elementi digitali sono ancora in commercio e per quali si è assunto il ruolo di fabbricante. Chi rivende un dispositivo con il proprio marchio, chi incorpora un componente di terzi, chi mantiene online una vecchia versione del gestionale per tre clienti affezionati, scopre spesso di avere più prodotti di quanti pensasse. La sintesi EUR-Lex ricorda del resto che l'obbligo di diligenza riguarda anche componenti e servizi di terzi.

Cosa fare in pratica, da qui a Natale

La cosa più utile non è un progetto di conformità: è un foglio con l'elenco dei prodotti con elementi digitali che la propria azienda mette a disposizione sul mercato europeo, e accanto a ciascuno se si è fabbricante, distributore o importatore, perché gli obblighi cambiano. Su quell'elenco si capisce in cinque minuti se la questione riguarda o no.

Se riguarda, i passi successivi sono piccoli e tutti antecedenti al 2027: designare per nome il rappresentante incaricato e fargli completare la registrazione al portale ENISA prima che serva; scrivere mezza pagina di procedura che dica chi riceve le segnalazioni esterne, chi decide se un evento è notificabile, entro quante ore e con quale recapito di reperibilità; verificare che esista un canale pubblico attraverso cui un ricercatore possa segnalare una vulnerabilità senza passare dal centralino. Chi ha dubbi sul perimetro — software libero, servizi erogati a distanza, prodotti venduti anche fuori dall'Unione — faccia leggere gli orientamenti del 27 luglio 2026 a chi lo assiste: sono stati scritti per quei dubbi e contengono esempi.

Il resto può aspettare il 2027. La procedura delle ventiquattro ore no: è l'unica parte del regolamento che si giudica sul tempo di reazione, e il tempo ha già cominciato a contare.