Cyber Resilience Act: segnalazione delle vulnerabilità

Dall'11 settembre 2026, per l'articolo 14 del Cyber Resilience Act (regolamento UE 2024/2847), il fabbricante che scopre una vulnerabilità attivamente sfruttata in un suo prodotto la notifica, tramite la piattaforma unica dell'ENISA, al CSIRT coordinatore del proprio Stato (in Italia il CSIRT Italia) e all'ENISA: preallarme entro 24 ore, notifica entro 72 ore, relazione finale entro 14 giorni dalla correzione.

È l'unica parte del regolamento già applicabile ai fabbricanti, ed è anche quella che arriva prima dei requisiti di prodotto: la politica di divulgazione coordinata, la distinta base del software e gli aggiornamenti di sicurezza dell'Allegato I diventano obbligatori solo dall'11 dicembre 2027. Per un anno abbondante, quindi, si deve saper segnalare prima che la norma imponga di avere in ordine il processo che produce la segnalazione. Il quadro generale del regolamento, perimetro e classi di prodotto compresi, sta nella guida Cyber Resilience Act: cos'è e chi riguarda; qui si parla solo di segnalazione.

Cosa va segnalato: due eventi diversi

L'articolo 14 contiene due obblighi paralleli, con la stessa struttura ma con oggetti diversi.

La vulnerabilità attivamente sfruttata

L'articolo 3 distingue tre gradi. Una vulnerabilità è un punto debole che una minaccia informatica può sfruttare (punto 40). È sfruttabile quando un avversario può usarla efficacemente in condizioni operative pratiche (punto 41). È attivamente sfruttata quando esistono prove attendibili che un soggetto malintenzionato l'ha sfruttata in un sistema senza l'autorizzazione del proprietario (punto 42).

Solo il terzo grado fa scattare l'obbligo. Una falla con un exploit dimostrativo pubblicato è, nella logica delle definizioni, sfruttabile; diventa attivamente sfruttata quando arrivano le prove di un uso reale e non autorizzato. È la valutazione che va presidiata con più cura, perché da lì partono i tempi.

L'incidente grave che ha un impatto sulla sicurezza del prodotto

Il secondo evento è l'incidente, e il paragrafo 5 dell'articolo 14 lo considera grave in due casi:

• incide, o è in grado di incidere, sulla capacità del prodotto di garantire disponibilità, autenticità, integrità o riservatezza di dati o funzioni sensibili o importanti;
• ha portato, o è in grado di portare, all'introduzione o all'esecuzione di codice malevolo nel prodotto o nei sistemi informativi e di rete di un suo utilizzatore.

Il caso tipico del secondo punto è la compromissione della catena di rilascio: un aggiornamento firmato che porta con sé codice malevolo verso tutti i clienti che lo installano.

I tempi: 24 ore, 72 ore, relazione finale

Per entrambi gli eventi i termini decorrono dal momento in cui il fabbricante ne è venuto a conoscenza, e ogni passaggio va fatto senza indebito ritardo entro il limite massimo.

1. Preallarme entro 24 ore. Indica, se del caso, gli Stati membri in cui il fabbricante sa che il prodotto è stato messo a disposizione. Per l'incidente grave dice anche se si sospetta che sia frutto di atti illegittimi o malevoli.
2. Notifica entro 72 ore. Informazioni generali, se disponibili, sul prodotto, sulla natura dello sfruttamento o dell'incidente, sulle misure correttive o di attenuazione già adottate e su quelle che gli utilizzatori possono adottare, con il grado di sensibilità attribuito alle informazioni.
3. Relazione finale. Per la vulnerabilità, entro 14 giorni dalla messa a disposizione di una misura correttiva o di attenuazione, con descrizione, gravità, impatto, eventuali informazioni sull'attaccante e dettagli dell'aggiornamento. Per l'incidente grave, entro un mese dalla notifica delle 72 ore, con descrizione, causa di fondo probabile e misure di attenuazione adottate e in corso.

Il paragrafo 6 aggiunge che il CSIRT che ha ricevuto la notifica può chiedere una relazione intermedia. Il conto alla rovescia della relazione finale sulla vulnerabilità parte dalla correzione, non dalla scoperta: se la patch richiede sei settimane, la relazione va inviata entro due settimane dalla sua disponibilità.

A chi si segnala e con quale strumento

La piattaforma unica di segnalazione dell'ENISA

Le notifiche obbligatorie passano dalla piattaforma unica di segnalazione dell'articolo 16, gestita dall'ENISA. Secondo le FAQ ufficiali dell'agenzia (aggiornate al 15 ottobre 2026), la piattaforma è operativa dall'11 settembre 2026, è raggiungibile su portal.cra-srp.enisa.europa.eu e richiede che i rappresentanti incaricati dal fabbricante abbiano un account EU Login personale con autenticazione a più fattori. Un rappresentante primario registra l'azienda scegliendo il CSIRT competente, e può invitare rappresentanti secondari.

Se la piattaforma non è disponibile, l'ENISA indica di attendere il ripristino e poi inviare la notifica; chi ritiene necessaria una comunicazione immediata può contattare direttamente il proprio CSIRT, ma la notifica sulla piattaforma resta dovuta quando torna in funzione.

Quale CSIRT

Il paragrafo 7 dell'articolo 14 indica il CSIRT designato come coordinatore dello Stato membro in cui il fabbricante ha lo stabilimento principale, cioè quello in cui si prendono prevalentemente le decisioni sulla cibersicurezza dei prodotti; se non si riesce a stabilirlo, quello con più dipendenti nell'Unione. La notifica è contemporaneamente accessibile all'ENISA, quindi non serve un invio separato.

Per un fabbricante con stabilimento principale in Italia il destinatario è il CSIRT Italia: il CRA rinvia al coordinatore designato ai sensi dell'articolo 12 della direttiva NIS2 (articolo 3, punto 51), e l'articolo 16, comma 1, del D.Lgs. 138/2024 designa a quel ruolo il CSIRT Italia. Le FAQ dell'ENISA avvertono che una notifica inviata al CSIRT sbagliato può essere invalidata e va ripresentata.

Chi non ha uno stabilimento principale nell'Unione segue un ordine fisso: lo Stato del rappresentante autorizzato che agisce per il maggior numero di suoi prodotti, poi quello dell'importatore, poi del distributore, infine quello con il maggior numero di utilizzatori.

Cosa succede dopo l'invio

Il CSIRT che riceve per primo la notifica la diffonde ai CSIRT degli Stati in cui il prodotto è disponibile e passa alle autorità di vigilanza del mercato le informazioni che servono loro (articolo 16, paragrafi 2 e 3). La diffusione può essere ritardata per motivi di cibersicurezza: il regolamento delegato (UE) 2026/881, in vigore dal 10 maggio 2026, ne fissa le condizioni, tra cui il caso in cui il fabbricante comunica che una misura di attenuazione efficace sarà disponibile entro 72 ore. Dopo la correzione, l'ENISA, d'intesa con il fabbricante, inserisce la vulnerabilità nella banca dati europea delle vulnerabilità (articolo 17, paragrafo 5). La sola notifica non espone il fabbricante a una maggiore responsabilità (articolo 17, paragrafo 4).

Informare gli utilizzatori

La notifica alle autorità non basta. Il paragrafo 8 chiede al fabbricante di informare gli utilizzatori interessati, e se del caso tutti gli utilizzatori, della vulnerabilità o dell'incidente e delle misure che possono adottare per attenuarne l'impatto, se del caso in un formato strutturato e leggibile da una macchina. Se il fabbricante non lo fa tempestivamente, possono farlo i CSIRT che hanno ricevuto la notifica.

In pratica serve un canale già pronto verso i clienti: una pagina di avvisi di sicurezza, una lista di contatti tecnici aggiornata, un formato di advisory che il cliente possa importare nei propri strumenti.

Prodotti già sul mercato, componenti, importatori

• Parco installato. L'articolo 69, paragrafo 3, estende gli obblighi dell'articolo 14 a tutti i prodotti nell'ambito di applicazione immessi sul mercato prima dell'11 dicembre 2027. Un apparato venduto anni fa e ancora in uso rientra nella segnalazione, anche se è esente dai requisiti di prodotto.
• Importatori e distributori. Quando vengono a conoscenza di una vulnerabilità nel prodotto, ne informano il fabbricante senza indebito ritardo (articoli 19 e 20). La notifica all'ENISA resta del fabbricante.
• Componenti di terzi. L'articolo 13, paragrafo 6, chiede di segnalare la vulnerabilità di un componente, open source compreso, a chi lo mantiene. Fa parte degli obblighi che si applicano dall'11 dicembre 2027, ma una vulnerabilità sfruttata in una libreria integrata è già oggi una vulnerabilità sfruttata nel prodotto.
• Gestori di software open source. Per loro l'obbligo di segnalazione previsto dall'articolo 24, paragrafo 3, si applica dall'11 dicembre 2027, come conferma l'ENISA nelle sue FAQ.

Sanzioni e deroga per micro e piccole imprese

L'articolo 64, paragrafo 2, prevede per la non conformità agli obblighi dell'articolo 14 sanzioni amministrative pecuniarie fino a 15 milioni di euro o, per le imprese, fino al 2,5% del fatturato mondiale totale annuo dell'esercizio precedente, se superiore. Le norme sanzionatorie nazionali le stabiliscono gli Stati membri.

Il paragrafo 10, nel testo rettificato con la rettifica pubblicata il 2 luglio 2025 (che ha portato il rinvio ai paragrafi da 2 a 9), esclude le sanzioni pecuniarie per i fabbricanti che si qualificano come microimprese o piccole imprese solo per il mancato rispetto del termine di 24 ore del preallarme. Restano dovuti la notifica delle 72 ore, la relazione finale e l'informazione agli utilizzatori. L'articolo 17, paragrafo 6, prevede inoltre che i CSIRT coordinatori prestino assistenza tecnica ai fabbricanti, in particolare a quelli di minori dimensioni.

Cosa deve esistere prima della prossima vulnerabilità

Ventiquattro ore comprendono notti e fine settimana. Il lavoro da fare prima è soprattutto organizzativo:

1. Account e ruoli. Almeno due rappresentanti registrati sulla piattaforma ENISA, con EU Login e autenticazione a più fattori, e il CSIRT competente già individuato.
2. Inventario dei prodotti. Quali prodotti con elementi digitali sono sul mercato, in quali versioni e in quali Stati membri: è la prima informazione chiesta dal preallarme. Una SBOM per prodotto permette di capire in pochi minuti se una vulnerabilità in un componente vi riguarda.
3. Fonti di segnale. Chi vi dice che una vulnerabilità è sfruttata: segnalazioni di clienti e ricercatori, comunicazioni dei CSIRT, threat intelligence, telemetria dei vostri servizi. Senza un punto di raccolta presidiato, la conoscenza arriva tardi o si disperde.
4. Chi decide. Una persona, con un sostituto, che valuta se le prove sono attendibili e fa partire l'orologio. Conviene scrivere la regola di decisione e registrare l'ora in cui l'azienda ne è venuta a conoscenza.
5. Modelli pronti. Bozze di preallarme, notifica e advisory per gli utilizzatori, con i campi già compilati per ogni prodotto.

Chi è anche soggetto NIS2 tiene presente che le due notifiche non si sostituiscono. Il D.Lgs. 138/2024, all'articolo 25, chiede di notificare al CSIRT Italia gli incidenti significativi che colpiscono i propri servizi, con pre-notifica entro 24 ore e notifica entro 72 ore; il CRA chiede di notificare ciò che riguarda il prodotto messo sul mercato. Lo stesso evento può far scattare entrambe, con contenuti diversi: il dettaglio è nella guida alla notifica degli incidenti NIS2. Per le altre date del regolamento c'è il calendario delle scadenze CRA 2026 e 2027.

Il punto da cui partire

L'obbligo di segnalazione regge solo se a monte c'è qualcuno che vede lo sfruttamento quando succede. Se volete capire come impostare il monitoraggio e la gestione degli incidenti che alimentano le notifiche, partite dalla nostra pagina sui servizi di cybersecurity.