La risposta breve
L'obbligo di segnalazione del Cyber Resilience Act è ora in vigore. Dall'11 settembre 2026 ogni fabbricante di un «prodotto con elementi digitali» venduto nell'UE deve segnalare all'ENISA e al proprio CSIRT nazionale le vulnerabilità sfruttate attivamente e gli incidenti gravi — un preallarme entro 24 ore, una notifica più completa entro 72 ore e una relazione finale entro 14 giorni. Il conteggio parte quando si viene a conoscenza dei fatti, non quando si è finita la verifica, e la regola raggiunge i prodotti già sul mercato e i fornitori con sede fuori dall'UE.
Per i responsabili tecnici, il punto dolente è che si tratta di un obbligo di processo con una tempistica rapida, che arriva più di un anno prima dei requisiti di progettazione e documentazione del CRA. Sapere che esiste una falla sfruttata non è più solo una valutazione interna di gravità; è l'inizio di una tempistica regolamentare. I team che la gestiranno con calma sono quelli che trattano il rilevamento e la divulgazione delle vulnerabilità sfruttate come una capacità collaudata — lo stesso muscolo che costruiamo in un penetration test e audit di sicurezza, dove individuare e classificare problemi reali e sfruttabili è tutto ciò che conta.
Cosa è entrato in vigore l'11 settembre
Il Cyber Resilience Act (Regolamento (UE) 2024/2847) è la legge orizzontale di cybersicurezza dell'UE per i «prodotti con elementi digitali» — in pratica qualsiasi software o hardware in grado di connettersi a un dispositivo o a una rete, dal firmware e dai sistemi operativi alle app mobili, ai componenti prossimi al SaaS e agli apparati connessi di consumo. La maggior parte dei suoi obblighi — progettazione sicura, documentazione, conformità — si applica solo dall'11 dicembre 2027. Ma il regolamento ha anticipato un obbligo, entrato in vigore l'11 settembre 2026: l'obbligo di segnalazione.
Da quella data, un fabbricante che viene a conoscenza del fatto che una vulnerabilità del suo prodotto è sfruttata attivamente, o di un incidente grave che compromette la sicurezza del prodotto, deve notificare l'Agenzia dell'Unione europea per la cybersicurezza (ENISA) e il Computer Security Incident Response Team (CSIRT) nazionale competente. La tempistica è scaglionata e stretta: un preallarme entro 24 ore dalla conoscenza dei fatti, una notifica tecnica più completa entro 72 ore e una relazione finale entro 14 giorni dalla disponibilità di una misura correttiva per le vulnerabilità sfruttate — oppure entro un mese per gli incidenti gravi.
Due scelte di impianto la rendono più gravosa di quanto sembri. Primo, l'elemento scatenante è la conoscenza, non la conferma: analisi giuridiche indipendenti sottolineano che il conteggio parte non appena il fabbricante viene a conoscenza del problema, quindi un team non può condurre un'indagine interna con comodo e iniziare a contare dopo. Secondo, le segnalazioni passano dalla nuova piattaforma unica di segnalazione dell'ENISA, entrata in funzione lo stesso giorno; al lancio è un portale web manuale senza API pubblica né canale per segnalazioni volontarie, per cui l'invio non è ancora automatizzabile in una pipeline di incident. Il CSIRT che riceve la segnalazione la condivide con gli altri team nazionali competenti.
Chi rientra — anche i team italiani
L'errore di lettura più comune è credere che sia un problema delle sole aziende dell'UE. Non lo è. L'obbligo è legato all'immissione sul mercato dell'UE di un prodotto, per cui un fabbricante statunitense, britannico o di altro Paese extra-UE che fornisce software, un componente erogato in SaaS o un dispositivo connesso a clienti dell'UE rientra pienamente nell'ambito. Un fornitore con sede ad Austin o a Londra con utenti europei eredita lo stesso conteggio di 24 ore di uno di Berlino. Questa portata extraterritoriale è deliberata, e il meccanismo sanzionatorio è concreto: le multe amministrative possono raggiungere 15 milioni di euro o il 2,5% del fatturato annuo mondiale totale, a seconda di quale importo sia più elevato.
La seconda sorpresa è la portata sul parco installato. L'obbligo di segnalazione è l'unica parte del CRA che si applica ai prodotti già sul mercato, non solo a quelli nuovi immessi dopo una scadenza futura. Un firmware distribuito anni fa, una libreria integrata in un dispositivo o un'applicazione pubblicata molto prima dell'entrata in vigore del CRA rientrano tutti nell'obbligo dall'11 settembre se una vulnerabilità in essi contenuta è sfruttata attivamente. Per i team che costruiscono prodotti durevoli — e per chiunque fornisca software su misura che finisce nel prodotto connesso di un cliente — la conseguenza pratica è che codice legacy che non sviluppate più attivamente può comunque generare un evento di segnalazione in giornata.
I curatori open source hanno più margine: i loro obblighi specifici si applicheranno più avanti, dall'11 dicembre 2027, in riconoscimento di quanto i manutentori non commerciali differiscano dai fabbricanti. Ma i fornitori commerciali che integrano componenti open source in un prodotto non possono rinviare — se il prodotto distribuito contiene una falla sfruttata, a segnalare è il fabbricante che lo immette sul mercato.
Cosa significa per i team software
Il primo spostamento è che la gestione delle vulnerabilità diventa una tempistica regolamentata, non una preferenza interna. Molti team applicano già un processo di divulgazione coordinata, ma con la propria cadenza. Il CRA fissa la cadenza per lo scenario peggiore: lo sfruttamento in the wild. Ciò richiede una definizione interna inequivocabile di «conoscenza» e di «sfruttata attivamente», un decisore designato in grado di pronunciarsi anche fuori orario e una relazione che potete completare senza una settimana di stesura. Radicate tutto ciò nella stessa disciplina di sicurezza che applicate lungo la vostra pipeline cloud e DevOps — inventario degli asset, visibilità delle dipendenze e dell'SBOM, monitoraggio — perché non potete segnalare entro 24 ore su un prodotto di cui non sapete elencare i componenti.
Il secondo spostamento è prova e tracciabilità. Una relazione scaglionata a 24 ore, 72 ore e 14 giorni è, di fatto, la richiesta di una cronologia ricostruibile: quando avete appreso il problema, cosa sapevate a ogni passo, quale è stata la misura correttiva e quando è stata rilasciata. I team che registrano rilevamento, triage e decisioni di patch come eventi di primo livello produrranno questa narrazione quasi gratis; quelli che trattano la sicurezza come sapere informale dovranno assemblarla in affanno sotto la scadenza di un regolatore. È la stessa postura premiata dalla notifica di violazione entro 72 ore del GDPR — il CRA estende semplicemente quel riflesso dagli incidenti sui dati personali alla sicurezza del prodotto.
Il terzo spostamento è sovrapposizione e deconflitto. Un'unica falla sfruttata può ora far scattare insieme la segnalazione CRA, la notifica di violazione GDPR e, per gli operatori di infrastrutture critiche, gli obblighi di incidente NIS2 o DORA — ciascuno con il proprio destinatario e il proprio orologio. Per i player della FinTech e della HealthTech in particolare, la risposta non è gestire processi paralleli e improvvisati, ma progettare un unico flusso di incident che si dirama verso i regolatori giusti con il contenuto e i tempi giusti. Cablare bene tutto questo in anticipo costa molto meno che scoprire i conflitti in piena emergenza.
Cosa fare ora
- Verificate la vostra esposizione al mercato. Elencate ogni prodotto con elementi digitali che mettete a disposizione nell'UE — inclusi i componenti erogati in SaaS ed embedded, e gli elementi legacy ancora sul campo. Se uno di essi raggiunge utenti dell'UE, rientrate nell'ambito indipendentemente da dove abbiate sede.
- Definite «conoscenza» e «sfruttata attivamente». Mettete per iscritto i criteri e il responsabile designato che decide. L'ambiguità qui brucia la finestra di 24 ore, perché il conteggio parte dalla conoscenza dei fatti, non dalla fine dell'indagine.
- Predisponete le relazioni in anticipo. Redigete ora i modelli a 24 ore, 72 ore e 14 giorni e preparate un account e un flusso di lavoro sulla piattaforma unica di segnalazione dell'ENISA. Senza API al lancio, l'invio è manuale — provatelo finché diventa automatismo, non improvvisazione.
- Integratelo nell'ingegneria. Assicuratevi che rilevamento, visibilità delle dipendenze e dell'SBOM e decisioni di patch siano registrati come eventi, così che la cronologia della relazione si componga da sé. Non potete notificare in fretta su componenti che non vedete.
- Deconflittate con GDPR, NIS2 e DORA. Mappate quali incidenti attivano quali obblighi e progettate un unico flusso che instrada verso ciascun regolatore con il contenuto e l'orologio corretti, anziché procedure separate e concorrenti.
Domande frequenti
Cosa è cambiato l'11 settembre 2026?
Sono diventati applicabili gli obblighi di segnalazione del Cyber Resilience Act dell'UE (Regolamento (UE) 2024/2847). I fabbricanti di prodotti con elementi digitali venduti nell'UE devono ora segnalare all'ENISA e al CSIRT nazionale competente le vulnerabilità sfruttate attivamente e gli incidenti gravi. I requisiti di cybersicurezza più ampi del CRA si applicano più avanti, dall'11 dicembre 2027, ma l'obbligo di segnalazione è già in vigore.
Qual è la tempistica di segnalazione?
Per una vulnerabilità sfruttata attivamente: un preallarme entro 24 ore dalla conoscenza dei fatti, una notifica più completa entro 72 ore e una relazione finale entro 14 giorni dalla disponibilità di una misura correttiva. Gli incidenti gravi seguono le fasi a 24 e 72 ore con una relazione finale entro un mese. Il conteggio parte dalla conoscenza dei fatti, non dalla fine della conferma interna.
Si applica alle aziende fuori dall'UE?
Sì. L'obbligo è legato alla messa a disposizione di un prodotto sul mercato dell'UE, per cui un fabbricante statunitense, britannico o di altro Paese extra-UE che vende software, un componente SaaS o un dispositivo connesso a clienti dell'UE rientra nell'ambito. Le multe possono raggiungere 15 milioni di euro o il 2,5% del fatturato annuo mondiale, a seconda di quale importo sia più elevato.
I prodotti esistenti sono coperti?
Sì. L'obbligo di segnalazione raggiunge i prodotti già sul mercato dell'UE, non solo quelli nuovi. Un router, un'immagine firmware, una libreria o un'applicazione distribuiti prima dell'entrata in vigore del CRA rientrano nell'obbligo dall'11 settembre 2026 se contengono una vulnerabilità sfruttata attivamente. È la parte del CRA che tocca per prima il parco installato.
Come si invia una segnalazione?
Tramite la piattaforma unica di segnalazione (SRP) dell'ENISA, attiva dall'11 settembre 2026. Instrada la notifica al CSIRT del vostro Stato membro principale e poi agli altri team nazionali competenti. Al lancio è un portale web manuale senza API pubblica né opzione di segnalazione volontaria, quindi la mossa pratica è preparare modelli, responsabili e regole decisionali prima di un incidente anziché tentare di automatizzare l'invio.
Fonti
Commissione europea — Cyber Resilience Act: obblighi di segnalazione
TechHQ — EU Cyber Resilience Act reporting: cosa è cambiato l'11 settembre
Crowell & Moring — EU CRA: scadenza di segnalazione incidenti/vulnerabilità all'11 settembre 2026