Cyber Resilience Act: il rischio di sicurezza nascosto nell’obbligo di segnalazione che scatta a settembre
Cyber Resilience Act è il regolamento che, dall’11 settembre 2026, obbligherà i produttori di prodotti con elementi digitali a segnalare alle autorità le vulnerabilità sfruttate attivamente e gli incidenti gravi, entro tempi cronometrati. È il primo banco di prova operativo di una norma che entrerà pienamente in vigore solo nel dicembre 2027, ed è anche il punto su cui la comunità della sicurezza ha discusso più a lungo, perché dietro un adempimento apparentemente tecnico si nasconde una domanda scomoda: concentrare in un’unica piattaforma le segnalazioni di vulnerabilità ancora aperte e già sfruttate rende il sistema più sicuro o costruisce un bersaglio nuovo.
La scadenza di settembre non riguarda la conformità dei prodotti, che arriverà dopo, ma proprio la catena di notifica. Da quella data un produttore che scopre una vulnerabilità sfruttata in un suo prodotto avrà ventiquattro ore per un primo allarme, settantadue per una notifica completa e quattordici giorni, dalla disponibilità di una misura correttiva, per la relazione finale; per gli incidenti gravi il termine ultimo è un mese. Tutto passa per la Single Reporting Platform gestita da ENISA, lo sportello unico verso cui converge la segnalazione, indirizzata al CSIRT competente e contemporaneamente all’agenzia europea. Sul piano degli adempimenti la meccanica è chiara, ed è già stata mappata in dettaglio altrove; qui interessa il suo risvolto di sicurezza.
Cosa scatta l’11 settembre
La novità sostanziale è che la segnalazione delle vulnerabilità sfruttate diventa un obbligo di legge con una sveglia che parte dal momento della scoperta, non più una buona pratica lasciata alla maturità del produttore. L’articolo 14 del regolamento impone di notificare separatamente le vulnerabilità attivamente sfruttate e gli incidenti gravi, attraverso la piattaforma unica, così che l’informazione raggiunga il CSIRT designato come coordinatore e ENISA nello stesso momento. La logica è quella già nota dalle altre norme europee di settore, dalla scansione delle ventiquattro e settantadue ore della NIS2 a quella del GDPR: ridurre la finestra tra l’evento e la consapevolezza delle autorità.
Per orientarsi tra le date e i soggetti obbligati restano utili le guide dedicate agli adempimenti del Cyber Resilience Act, che distinguono ciò che è già applicabile da ciò che entrerà in vigore nel 2027. Il punto che merita attenzione, però, non è il calendario, ma cosa accade ai dati una volta entrati nella piattaforma. Perché una segnalazione di vulnerabilità sfruttata e non ancora corretta è, per definizione, l’informazione più sensibile che esista in sicurezza: descrive una porta aperta che qualcuno sta già attraversando.
Il paradosso del Cyber Resilience Act: un registro di vulnerabilità sfruttate
Qui sta il nodo che ha attraversato l’intera fase negoziale. Quando la norma era ancora una proposta, una lettera aperta firmata da decine di esperti di sicurezza, tra industria, accademia e società civile, mise in guardia contro l’obbligo di segnalazione nella sua formulazione originaria. L’argomento era preciso e tecnicamente fondato: imporre la notifica rapida di vulnerabilità sfruttate ma non ancora risolte avrebbe creato, nelle mani delle autorità, una sorta di registro in tempo reale di falle aperte, accessibile a numerose agenzie governative. Un archivio del genere non aiuta a difendersi, perché chi lo consulta non può usare quelle informazioni per proteggere i sistemi altrui, ma diventa un bersaglio di enorme valore, oltre a prestarsi a un possibile uso di intelligence e sorveglianza.
I firmatari segnalavano anche un secondo effetto, più sottile. L’obbligo di segnalare in tempi strettissimi rischia di produrre un effetto dissuasivo sulla ricerca in buona fede, perché i ricercatori spesso hanno bisogno di tempo per verificare, testare e correggere una vulnerabilità prima che diventi pubblica o nota a troppi soggetti. Comprimere quel tempo, nel timore della scadenza, significa spingere verso una divulgazione prematura, che è esattamente la condizione in cui una vulnerabilità è più pericolosa. La gestione delle vulnerabilità come processo ordinato e gli obblighi di segnalazione rapida convivono, in altre parole, in una tensione che non si risolve da sola.
La risposta del testo finale: ritardare la divulgazione
La versione definitiva del regolamento non ha ignorato quelle obiezioni, e ha introdotto un correttivo che è la chiave per leggere l’intero impianto. La segnalazione resta obbligatoria e va inviata nei tempi previsti, ma il regolamento, all’articolo 16, consente al CSIRT che riceve la notifica di ritardarne la diffusione verso i CSIRT degli altri Stati membri per motivi attinenti alla sicurezza, per esempio quando è in corso una divulgazione coordinata o il produttore sta per rilasciare una correzione e il rischio di una diffusione immediata supererebbe i benefici. Il CSIRT che decide di trattenere la notifica deve informarne ENISA, motivare la scelta e indicare quando procederà alla diffusione.
Per dare contenuto preciso a questo meccanismo, il regolamento ha previsto un atto delegato, adottato dalla Commissione l’11 dicembre 2025 (Regolamento delegato UE 2026/881), che enumera i motivi di ritardo: la natura dell’informazione notificata, l’impossibilità per il CSIRT di garantirne la riservatezza, e la compromissione o l’indisponibilità temporanea della piattaforma unica. Quest’ultimo motivo è rivelatore, perché la norma stessa mette in conto che la Single Reporting Platform possa essere attaccata e la tratta come una superficie di rischio da proteggere; non a caso, commentando l’atto, la Cybersecurity Coalition ha avvertito che un produttore potrebbe inviare una notifica attraverso una piattaforma già compromessa senza accorgersene. Lo spostamento concettuale è importante: la norma non promette che l’informazione sensibile non venga raccolta, perché la raccolta resta il cuore dell’obbligo, ma sposta la salvaguardia sul momento della diffusione, distinguendo tra chi segnala, chi riceve e chi viene informato. È un compromesso ragionevole, che però non azzera il rischio: i dati delle vulnerabilità sfruttate continuano a concentrarsi presso i CSIRT e ENISA, e la loro protezione diventa essa stessa una questione di sicurezza critica, perché un archivio simile è prezioso tanto per chi difende quanto per chi attacca.
Una norma che va difesa come un’infrastruttura
Cyber Resilience Act, in conclusione, non è solo un capitolo di compliance per i produttori, ma un esperimento di governance della conoscenza più pericolosa che la sicurezza maneggi, quella sulle falle aperte. Il successo dell’obbligo di segnalazione non si misurerà sul numero di notifiche raccolte, ma sulla capacità delle autorità di proteggere quella piattaforma con lo stesso rigore che chiedono ai produttori, e di usare con misura il potere discrezionale di ritardare la divulgazione. La piattaforma unica di ENISA, dall’11 settembre, diventa di fatto una delle infrastrutture più sensibili dell’ecosistema cyber europeo, e andrà difesa come tale. Se quella protezione regge, il Cyber Resilience Act avrà trasformato un rischio in un vantaggio collettivo; se cede, avrà concentrato in un solo punto ciò che prima era disperso, offrendo agli attaccanti la mappa che cercavano. La differenza, ancora una volta, non sta nella norma scritta, ma in come verrà fatta funzionare.
