Dall’11 settembre 2026 diventano applicabili gli obblighi di segnalazione del Cyber Resilience Act per le vulnerabilità attivamente sfruttate e gli incidenti gravi che riguardano la sicurezza dei prodotti con elementi digitali. È una data importante perché anticipa l’applicazione degli obblighi principali del regolamento, prevista dall’11 dicembre 2027, e porta subito un tema concreto dentro le organizzazioni: riuscire a riconoscere, qualificare e comunicare un evento entro tempi brevi.
Il nuovo canale unico predisposto da ENISA semplifica l’invio verso le autorità, ma non risolve il problema più difficile. Una piattaforma può ricevere una notifica; non può stabilire al posto del produttore quando è iniziata la consapevolezza dell’evento, se gli indizi dimostrano uno sfruttamento attivo, quali versioni sono coinvolte o chi deve approvare le informazioni da trasmettere.
Per questo la conformità non comincia dal modulo. Comincia dal processo con cui supporto clienti, sviluppo, sicurezza, responsabili di prodotto, legale e direzione condividono segnali, decisioni ed evidenze.
Cosa cambia davvero dall’11 settembre
La Commissione europea chiarisce che i produttori devono segnalare due categorie di eventi: le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza di un prodotto con elementi digitali. La distinzione è essenziale. Non ogni vulnerabilità presente in un prodotto attiva automaticamente una notifica obbligatoria e non ogni anomalia operativa è un incidente grave ai sensi del CRA.
Per una vulnerabilità attivamente sfruttata serve un’evidenza affidabile che un attore malevolo l’abbia utilizzata senza autorizzazione in un sistema. Per gli incidenti, la valutazione riguarda l’impatto grave sulla capacità del prodotto di proteggere disponibilità, autenticità, integrità o riservatezza di dati e funzioni.
Quando ricorrono le condizioni, il processo prevede:
- un early warning senza indebito ritardo e comunque entro 24 ore dalla conoscenza dell’evento;
- una notifica più completa entro 72 ore, con informazioni generali e una prima valutazione;
- un rapporto finale entro un mese dalla notifica iniziale per gli incidenti gravi;
- per le vulnerabilità attivamente sfruttate, un rapporto finale entro 14 giorni da quando è disponibile una misura correttiva, come una patch.
Nelle prime 24 ore l’organizzazione non deve conoscere già ogni dettaglio. Deve però produrre un quadro iniziale attendibile, dichiarare ciò che è ancora incerto e aggiornare la segnalazione man mano che l’analisi procede.
Il punto critico è stabilire quando nasce la consapevolezza
Il conteggio parte da quando il produttore viene a conoscenza della vulnerabilità attivamente sfruttata o dell’incidente grave. Nella pratica, però, l’informazione può arrivare da molti canali: una segnalazione di un ricercatore, un ticket di assistenza, un alert telemetrico, un cliente, un fornitore, un repository pubblico, un CSIRT o una notizia tecnica.
Se questi segnali restano separati, il rischio è doppio. L’azienda può accorgersi tardi che più anomalie descrivono lo stesso evento, oppure può iniziare analisi parallele senza fissare una cronologia condivisa. Entrambe le situazioni rendono fragile la ricostruzione del momento di conoscenza.
Ogni canale deve alimentare lo stesso registro degli eventi di sicurezza del prodotto, con data e ora, fonte, versioni coinvolte, stato della verifica, responsabile dell’analisi e decisioni assunte. La tracciabilità permette di motivare perché un evento è stato segnalato, escluso o riclassificato.
La piattaforma unica riduce gli invii, non le decisioni
La Single Reporting Platform del CRA sarà operativa dall’11 settembre 2026 ed è gestita da ENISA. Il produttore presenta la notifica una sola volta e seleziona il CSIRT coordinatore, individuato in via generale sulla base del luogo della sede principale. La segnalazione viene resa disponibile a ENISA e condivisa con gli altri CSIRT interessati e, quando necessario, con le autorità di vigilanza del mercato.
Il modello evita comunicazioni duplicate, ma richiede dati coerenti a monte: prodotti distribuiti nei diversi Stati membri, ruolo di produttore, sede principale e soggetti della filiera capaci di fornire informazioni tecniche.
In condizioni eccezionali il CSIRT può ritardare la diffusione della notifica per motivi di cybersicurezza giustificati. Non è una scelta ordinaria del produttore né una ragione per trattenere autonomamente la segnalazione.
Un processo operativo in sei passaggi
1. Costruire l’inventario dei prodotti e dei ruoli
Per ogni prodotto con elementi digitali occorre associare versioni supportate, componenti, responsabile di prodotto, referente security, canali di distribuzione, Paesi interessati e dipendenze critiche. Bisogna anche chiarire chi è produttore, importatore, distributore o open-source software steward: ruoli diversi non vanno confusi.
2. Unificare intake e orologio dell’evento
Supporto, vulnerability disclosure, SOC, fornitori e team di sviluppo devono inoltrare i segnali a un registro comune. Il momento della prima ricezione, le verifiche successive e ogni cambio di classificazione devono essere registrati con criteri uniformi.
3. Definire un triage specifico per il CRA
Il punteggio di gravità tecnica, da solo, non basta. La checklist deve chiedere se esiste evidenza affidabile di sfruttamento, quale impatto riguarda il prodotto, quali dati o funzioni sono coinvolti, quante versioni risultano esposte e quali fatti restano da verificare. Una CVE elevata non equivale automaticamente a sfruttamento attivo; allo stesso modo un incidente serio può emergere prima che esista un identificativo pubblico.
4. Preparare la catena decisionale
Nelle prime ore deve essere chiaro chi coordina l’analisi, chi decide la classificazione, chi valida gli aspetti legali e chi invia la notifica. Le sostituzioni devono essere previste: una scadenza di 24 ore non può dipendere dalla disponibilità di una sola persona.
5. Predisporre un set minimo di evidenze
Conviene preparare in anticipo un modello con descrizione dell’evento, prodotti e versioni, cronologia, indicatori disponibili, impatto iniziale, misure adottate, contatti e incertezze aperte. Il modello deve aiutare a essere precisi senza includere dati personali o dettagli non necessari.
6. Provare il flusso con una simulazione
Un tabletop exercise può partire da un ticket cliente ambiguo poi collegato a uno sfruttamento reale. La prova deve misurare i tempi per riunire il team, classificare l’evento, approvare l’early warning e organizzare gli aggiornamenti.
Gli errori da evitare
Il primo errore è delegare tutto al team tecnico. La segnalazione riguarda il prodotto, il mercato e le responsabilità dell’organizzazione: servono competenze tecniche, legali e di business. Il secondo è attendere la certezza assoluta. Le finestre progressive esistono proprio perché l’analisi si completa nel tempo; ciò che conta è distinguere fatti, valutazioni e ipotesi.
Il terzo è usare lo stesso playbook per ogni normativa. Un evento può interessare anche NIS2, privacy, contratti o regole settoriali, ma destinatari, soglie e tempi non coincidono automaticamente.
Infine, non bisogna confondere la segnalazione con la remediation. Informare le autorità non sostituisce contenimento, comunicazione ai clienti, sviluppo della patch, gestione delle versioni vulnerabili e monitoraggio dello sfruttamento.
Checklist per arrivare pronti al 11 settembre
- Verificare quali prodotti e versioni rientrano nel perimetro CRA.
- Assegnare responsabili e sostituti per triage, decisione e invio.
- Collegare supporto, disclosure, SOC, sviluppo e fornitori a un registro comune.
- Formalizzare i criteri per sfruttamento attivo e incidente grave.
- Preparare i dati necessari per early warning, notifica e rapporto finale.
- Mappare sede principale, CSIRT coordinatore e mercati di distribuzione.
- Integrare il flusso CRA nel piano di incident response senza cancellarne le specificità.
- Eseguire almeno una simulazione e correggere tempi morti e passaggi informali.
Le 24 ore sono un test di governance
La piattaforma unica rende più semplice notificare una volta sola. Ma il valore della segnalazione dipende dalla capacità dell’organizzazione di trasformare segnali frammentati in una decisione verificabile. Inventario, responsabilità, tracciabilità e simulazioni sono quindi parte della sicurezza del prodotto, non soltanto della compliance.
Prepararsi prima dell’11 settembre consente di affrontare un evento reale con meno improvvisazione e informazioni migliori. Se vuoi verificare se il tuo processo di vulnerability e incident management è pronto per le scadenze CRA, contattami: posso aiutarti a mappare ruoli, evidenze e flussi decisionali e a testarli con una simulazione concreta.
Fonti
- Commissione europea, Cyber Resilience Act – Reporting obligations
- ENISA, Frequently Asked Questions sulla CRA Single Reporting Platform, aggiornate al 3 agosto 2026
- Commissione europea, Guidance to support timely Cyber Resilience Act implementation, 27 luglio 2026
- EUR-Lex, Regolamento (UE) 2024/2847 – Cyber Resilience Act
- Commissione europea, Cyber Resilience Act
Nota di trasparenza: il testo e le immagini associati a questo articolo sono stati realizzati in parte con il supporto di sistemi di intelligenza artificiale e sottoposti a revisione editoriale umana.