Dall'11 settembre 2026, i fabbricanti CRA devono segnalare vulnerabilità attivamente sfruttate e incidenti gravi tramite la piattaforma unica di segnalazione ENISA. Questa guida spiega cosa attiva una segnalazione, come funzionano le scadenze di 24 ore, 72 ore, 14 giorni e 1 mese, e dove si inseriscono CVD, VEX e le informazioni agli utenti.
Riepilogo
- La segnalazione urgente si applica dall'11 settembre 2026: entrambi i flussi usano un'allerta entro 24 ore e una notifica entro 72 ore; il rapporto finale arriva entro 14 giorni dalla disponibilità della correzione per le vulnerabilità e entro 1 mese dalla notifica a 72 ore per gli incidenti gravi.
- Invia una sola volta tramite ENISA SRP: la piattaforma instrada la segnalazione al CSIRT coordinatore e la rende disponibile a ENISA.
- Lo sfruttamento attivo richiede prove attendibili che un soggetto malintenzionato abbia sfruttato la vulnerabilità in un sistema senza autorizzazione; una divulgazione pubblica, una PoC pubblica o una dimostrazione di ricerca non bastano da sole.
- La policy CVD è obbligatoria: deve essere scritta, pubblicata, applicata e collegata alla soglia di segnalazione quando il triage trova sfruttamento attivo.
- VEX supporta le decisioni di segnalazione documentando se una CVE in un componente SBOM incide davvero sul prodotto.
- I dettagli sulle sanzioni stanno nella guida enforcement: segnalazioni tardive o mancanti possono creare un rischio sanzionatorio serio; usa sanzioni e enforcement CRA per livelli ed esenzioni PMI.
Il modello di segnalazione in pratica: avviso iniziale, notifica dettagliata, rapporto finale e rinvio all'enforcement.
Cosa deve essere segnalato
La segnalazione CRA ha due flussi obbligatori e un obbligo separato di informare gli utenti. L'obbligo ricade sul fabbricante del prodotto con elementi digitali immesso sul mercato UE:
- Segnalare ogni vulnerabilità attivamente sfruttata del prodotto al CSIRT coordinatore e a ENISA secondo il ciclo 24h / 72h / 14g.
- Segnalare ogni incidente grave che incide sulla sicurezza del prodotto secondo il ciclo 24h / 72h / 1 mese.
- Informare gli utenti interessati sulla vulnerabilità o sull'incidente e sulle misure correttive senza indebito ritardo.
Questa pagina copre anche due controlli collegati: la policy CVD obbligatoria e le prove di applicabilità come VEX. Nessuno di questi obblighi ha una soglia dimensionale. Microimprese e piccole imprese hanno solo una deroga sanzionatoria stretta per l'avviso entro 24h; non sono esentate dalla segnalazione.
La piattaforma unica di segnalazione ENISA (SRP)
La SRP è il canale unico per le segnalazioni CRA obbligatorie su vulnerabilità e incidenti. Il fabbricante segnala una volta tramite il punto di accesso elettronico del CSIRT coordinatore; la segnalazione è contemporaneamente disponibile a ENISA salvo l'applicazione eccezionale del meccanismo di diffusione ritardata. Il CSIRT coordinatore diffonde poi le informazioni ai CSIRT interessati negli altri Stati membri.
La regola sulla diffusione ritardata consente al CSIRT coordinatore di rinviare la trasmissione successiva in circostanze eccezionali, per motivi giustificati di cibersicurezza e per il tempo strettamente necessario. Il fabbricante può chiederlo e può segnalare quanto l'informazione sia sensibile, ma la decisione spetta al CSIRT, non a lui. Esiste un secondo ritardo, distinto, per una vulnerabilità di cui il CSIRT coordinatore è venuto a conoscenza attraverso una procedura di divulgazione coordinata. In quel caso il CSIRT può trattenere la notifica per motivi giustificati di cibersicurezza, per un periodo non superiore a quanto strettamente necessario e finché le parti di quella divulgazione non acconsentono a renderla pubblica. Vale la pena saperlo se sta conducendo un processo CVD, ma anche qui la decisione spetta al CSIRT, quindi non conti sulla tenuta di un embargo.
Le circostanze eccezionali particolari (PEC) sono un meccanismo distinto e più stretto. Si applicano soltanto alla notifica a 72 ore per una vulnerabilità attivamente sfruttata, e solo quando lo sfruttamento è circoscritto allo Stato membro del proprio coordinatore, quando una divulgazione più ampia andrebbe contro gli interessi essenziali di quello Stato, oppure quando la diffusione stessa creerebbe un rischio di cibersicurezza elevato e imminente. Il segnalante le invoca con un selettore nella piattaforma e può aggiungere una motivazione; decide il CSIRT coordinatore. Finché valgono, ENISA riceve comunque un insieme ridotto di informazioni: che una notifica è stata presentata, le informazioni generali sul prodotto, la natura generale dello sfruttamento e il fatto che sono stati addotti motivi di sicurezza. La notifica completa segue al termine del ritardo. Gli orientamenti PEC di ENISA descrivono la procedura.
Stato all'11 settembre 2026: la SRP è disponibile dall'11 settembre 2026 su portal.cra-srp.enisa.europa.eu. Sulla pagina iniziale si sceglie il ruolo Assigned Representative e si accede con EU Login: l'account è personale e richiede l'autenticazione a più fattori. ENISA ha aggiornato le FAQ e la guida alla registrazione dell'Assigned Representative il 10 settembre 2026, e le guide all'interfaccia e alle notifiche il 9 settembre 2026. Il 9 settembre 2026 ha pubblicato anche un AR User Manual di 55 pagine, il percorso schermata per schermata della registrazione, delle tre fasi di presentazione e dell'aggiornamento di una notifica. Il Glossario SRP, alla versione 1.3 e solo in inglese, è il riferimento campo per campo, e l'elenco dei CSIRT designati come coordinatori porta la data del 10 settembre 2026. Nella versione iniziale ENISA non fornisce un'API: le notifiche si inviano dall'interfaccia della piattaforma, e la segnalazione volontaria non è disponibile al lancio. ENISA indica la propria documentazione come soggetta a modifiche. Consulti la guida alla registrazione ENISA SRP e scriva a cra-srp-helpdesk@enisa.europa.eu in caso di necessità.
Scadenze di segnalazione in dettaglio
Calendario di segnalazione
| Passaggio | Vulnerabilità | Incidente grave | Punto di partenza |
|---|---|---|---|
| Allerta iniziale | 24 ore | 24 ore | Il fabbricante ne viene a conoscenza |
| Notifica dettagliata | 72 ore | 72 ore | Il fabbricante ne viene a conoscenza |
| Rapporto finale | 14 giorni dopo la disponibilità della misura correttiva o mitigativa | 1 mese dopo la notifica a 72 ore dell'incidente | Ancoraggi diversi |
| Informazione agli utenti | Senza indebito ritardo | Senza indebito ritardo | Avviso agli utenti |
Contenuto di ogni invio
L'allerta iniziale è un avviso, non un'analisi completa. La notifica a 72 ore fornisce informazioni generali su prodotto, exploit o incidente, misure prese, azioni per gli utenti e sensibilità quando pertinente. Il rapporto finale contiene almeno i dati richiesti per il rispettivo flusso: descrizione della vulnerabilità, gravità, impatto e misure correttive, oppure descrizione dell'incidente, causa probabile e misure in corso.
- Il fabbricante ne viene a conoscenza. Il termine di 24 ore parte quando una rapida valutazione iniziale dà al fabbricante un ragionevole grado di certezza che una vulnerabilità del suo prodotto è sfruttata attivamente.
- +24h. Invia l'allerta iniziale tramite ENISA SRP.
- +72h. Aggiungi dettagli tecnici, versioni interessate, stato dello sfruttamento e stato della correzione.
- Misura disponibile. Per le vulnerabilità, il termine del rapporto finale parte da qui, non dalla scoperta.
- +14g. Invia i dati finali per il flusso vulnerabilità o incidente.
Gli incidenti gravi seguono gli stessi passi di apertura a 24 ore e 72 ore, con il rapporto finale dovuto entro 1 mese dalla notifica a 72 ore.
Campi dati nel modello di segnalazione SRP
Il Glossario SRP di ENISA è il riferimento campo per campo di ciò che la piattaforma chiede in ogni fase. La versione 1.3 elenca 39 campi: 18 comuni ai due flussi, 12 che riguardano solo una vulnerabilità attivamente sfruttata e 9 che riguardano solo un incidente grave. È disponibile solo in inglese ed ENISA lo indica come stato attuale delle conoscenze, soggetto a modifiche. Codici: X obbligatorio, O facoltativo, C copiato dal passaggio precedente come predefinito o aggiornato, I obbligatorio se l'informazione è disponibile, - non applicabile in quella fase.
| # | Campo | Allerta iniziale 24h | 72h | Rapporto finale |
|---|---|---|---|---|
| Campi comuni | ||||
| 1 | Tipo di notifica (vulnerabilità / incidente) | X | C | C |
| 2 | Titolo | X | C | C |
| 3 | Sintesi | X | C | C |
| 4 | Nome del fabbricante | X | C | C |
| 5 | Stati membri in cui il prodotto è disponibile (CSIRT interessato) | X | C | C |
| 6 | Nome del prodotto | X | C | C |
| 7 | Versione del prodotto | X | C | C |
| 8 | Tipo di prodotto (default / importante / critico) | O | C | C |
| 9 | Classe di prodotto | O | C | C |
| 10 | Categoria di prodotto | O | C | C |
| 11 | Indicatore di fine supporto | O | C | C |
| 12 | Nome del componente | O | C | C |
| 13 | Misura mitigativa attesa a breve | O | C | C |
| 14 | Azione dell'utente in grado di ridurre l'impatto | O | C | C |
| 15 | Sensibilità considerata delle informazioni | O | O | C |
| 16 | Misure correttive o mitigative adottate | O | O | X |
| 17 | Misure correttive o mitigative che l'utente può adottare | O | O | X |
| 18 | Vettore di attacco | - | O | O |
| Vulnerabilità attivamente sfruttata | ||||
| v19 | CVE ID | O | C | C |
| v20 | EUVD ID | O | C | C |
| v21 | Informazioni generali | O | X | C |
| v22 | Data in cui una misura correttiva o mitigativa è diventata disponibile | O | O | X |
| v23 | Dettagli sull'aggiornamento di sicurezza o sulla misura correttiva disponibile | O | O | X |
| v24 | Descrizione completa della gravità della vulnerabilità | O | O | X |
| v25 | Descrizione completa dell'impatto della vulnerabilità | O | O | X |
| v26 | Data e ora in cui si viene a conoscenza della vulnerabilità attivamente sfruttata [1] | X | C | C |
| v27 | Attore malevolo che ha sfruttato / sta sfruttando la vulnerabilità | O | O | I |
| v28 | Circostanze eccezionali particolari (PEC) | - | O | - |
| v29 | Motivo del ritardo PEC | - | O | - |
| v30 | Ulteriori informazioni | O | O | C |
| Incidente grave | ||||
| i31 | Si sospetta che l'incidente derivi da atti illeciti o malevoli | X | C | C |
| i32 | Informazioni generali sulla natura dell'incidente | O | X | C |
| i33 | Misure di mitigazione applicate e in corso | O | O | X |
| i34 | Descrizione dettagliata della gravità dell'incidente | O | O | X |
| i35 | Descrizione dettagliata dell'impatto dell'incidente | O | O | X |
| i36 | Tipo di minaccia o causa principale che probabilmente ha provocato l'incidente | O | O | X |
| i37 | Data e ora in cui si viene a conoscenza dell'incidente (UTC) [2] | X | X | C |
| i38 | Data e ora in cui si è verificato l'incidente (UTC) | O | X | O |
| i39 | Valutazione iniziale dell'incidente | O | X | C |
Criteri di gravità (i34): un incidente grave è un incidente che (1) incide negativamente, o è in grado di incidere negativamente, sulla capacità del prodotto di proteggere la disponibilità, l'autenticità, l'integrità o la riservatezza di dati o funzioni sensibili o importanti; oppure (2) ha portato, o è in grado di portare, all'introduzione o all'esecuzione di codice maligno nel prodotto o nei sistemi informativi e di rete di un utilizzatore.
Fonte: Glossario SRP di ENISA, versione 1.3, ultimo aggiornamento 10 settembre 2026.
Cosa attiva l'obbligo di segnalazione
1. Vulnerabilità attivamente sfruttate
Una vulnerabilità attivamente sfruttata significa che esistono prove attendibili che un soggetto malintenzionato abbia sfruttato la vulnerabilità in un sistema senza autorizzazione e che il fabbricante ne sia venuto a conoscenza. Una PoC pubblica o una dimostrazione di ricerca non bastano da sole.
2. Incidenti gravi
Un incidente grave è soggetto a segnalazione quando incide, o può incidere, sulla capacità del prodotto di proteggere la disponibilità, l'autenticità, l'integrità o la riservatezza di dati o funzioni sensibili o importanti, oppure quando provoca o può provocare codice maligno nel prodotto o nei sistemi informativi e di rete dell'utilizzatore.
Scenari segnalabili e non segnalabili
| Scenario | Obbligo di segnalazione? | Perché |
|---|---|---|
| Segnalazione privata di un ricercatore | No | Nessuna prova di sfruttamento; gestire tramite CVD |
| PoC pubblica | No | La pubblicazione non è sfruttamento |
| Cliente segnala attività compatibile con sfruttamento | Valutare | Segnala se le prove sono affidabili |
| Sfruttamento osservato in ambiente reale | Sì | Prova affidabile di uso malevolo |
| Componente SBOM con CVE nota sfruttata | Valutare | Solo se il prodotto è effettivamente interessato |
| Il prodotto è preso di mira da attori di minaccia identificati | Sì | Prova diretta di sfruttamento |
| Un malware generico sfrutta una classe di vulnerabilità presente nel prodotto | Valutare | Solo se la specifica implementazione è interessata |
Conoscenza e prove
La definizione CRA usa prove attendibili per identificare una vulnerabilità sfruttata attivamente. La conoscenza è una verifica distinta: dopo una rapida valutazione iniziale, il fabbricante deve avere un ragionevole grado di certezza che una vulnerabilità del suo prodotto è sfruttata attivamente. Non serve completare un'indagine forense.
Intake CVD e soglia di segnalazione
La policy CVD è il canale che trasforma le segnalazioni esterne in triage strutturato. Se il triage indica uno sfruttamento attivo, valutalo subito. Il termine di segnalazione parte quando la valutazione iniziale dà al fabbricante un ragionevole grado di certezza. Una pagina CVD pubblica e un file security.txt in /.well-known/security.txt sono il modo pratico per rendere reperibile il contatto.
VEX e applicabilità delle vulnerabilità
VEX (Vulnerability Exploitability eXchange) è una dichiarazione strutturata e leggibile dalle macchine che indica se una vulnerabilità presente in un componente SBOM incide davvero su un prodotto specifico. Trasforma le corrispondenze CVE grezze in uno stato difendibile e riferito al singolo prodotto:
| Stato | Significato |
|---|---|
not_affected |
La vulnerabilità esiste nel componente ma non incide su questo prodotto (percorso di codice vulnerabile non raggiungibile, funzione mai chiamata, configurazione che mitiga e casi simili). Si attende una giustificazione. |
affected |
La vulnerabilità incide su questo prodotto. Si attendono un'azione e una raccomandazione. |
fixed |
La vulnerabilità era presente ed è stata corretta in questa versione. |
under_investigation |
Stato non ancora determinato; valutazione in corso. |
Ai fini della segnalazione la domanda decisiva è l'applicabilità unita allo sfruttamento attivo. Una vulnerabilità marcata affected e sostenuta da prove attendibili di sfruttamento attivo è il tipo di evento che fa partire il termine di 24 ore per l'allerta iniziale. Una vulnerabilità marcata not_affected con una giustificazione solida sostiene la decisione di non segnalare. Il CRA non nomina VEX, ma VEX è un modo pratico per conservare quella giustificazione. Per formati, esempi, tipi di giustificazione, strumenti e integrazione con l'SBOM, consulti la guida all'implementazione VEX.
Alleggerimento per piccoli fabbricanti
Microimprese e piccole imprese (definite come imprese con meno di 50 dipendenti e un fatturato annuo o un totale di bilancio fino a 10 milioni di EUR; le microimprese: meno di 10 dipendenti e 2 milioni di EUR) hanno una deroga sanzionatoria stretta solo per il mancato primo avviso entro 24h. La deroga non elimina l'obbligo di segnalazione e non copre la notifica a 72h o i rapporti finali. Le medie imprese non hanno questo alleggerimento. La struttura completa è in sanzioni e enforcement CRA.
Errori comuni
- Aspettare la certezza forense. Bastano una rapida valutazione iniziale e un ragionevole grado di certezza; non serve completare un'indagine forense.
- Confondere CVD e segnalazione urgente. La segnalazione del ricercatore è intake CVD; la segnalazione CRA parte quando la valutazione iniziale dà al fabbricante un ragionevole grado di certezza sullo sfruttamento attivo.
- Avere una sola persona di escalation. Il termine di 24 ore non si ferma nel fine settimana.
- Non pubblicare la policy CVD. Un documento interno non basta.
- Non registrare le decisioni di applicabilità. Senza VEX o equivalente è difficile difendere perché una CVE non incide sul prodotto.
- Trattare la SRP come un problema futuro. Template, reperibilità e relazione con il CSIRT servono prima del primo evento segnalabile.
Domande frequenti
Quando iniziano gli obblighi di segnalazione CRA?
La segnalazione obbligatoria CRA di vulnerabilità e incidenti si applica dall'11 settembre 2026. Da quella data i fabbricanti devono usare ENISA SRP per allerta 24h, notifica 72h e rapporti finali. I requisiti più ampi di sicurezza del prodotto si applicano dall'11 dicembre 2027.
Che cos'è ENISA SRP?
SRP è il canale comune per le segnalazioni CRA obbligatorie. La segnalazione volontaria non è disponibile al lancio e arriverà in una fase successiva. Segui la pagina della Commissione e la pagina ENISA SRP per i dettagli di registrazione.
La policy CVD è obbligatoria?
Sì. Ogni fabbricante deve avere una policy CVD e un canale pratico di intake. security.txt non è nominato dal CRA, ma è un modo pratico per pubblicare l'indirizzo di contatto.
Serve VEX?
VEX non è richiesto per nome, ma un registro di applicabilità è molto utile per motivare perché una CVE nota non incide sul prodotto.
Quali sanzioni si applicano?
Segnalazioni tardive o mancanti possono creare una seria esposizione sanzionatoria; solo microimprese e piccole imprese hanno una deroga stretta per il primo avviso entro 24h. Vedi sanzioni e enforcement CRA per la struttura completa.
Dove inviamo la segnalazione se il prodotto è venduto in più Stati membri?
Invia una sola volta tramite il punto SRP del tuo CSIRT coordinatore. Senza una sede principale nell'Unione si usa la catena rappresentante autorizzato, importatore, distributore, maggiore concentrazione di utenti.
Il termine di 24 ore si sospende nei fine settimana?
No. I termini corrono in tempo di calendario, quindi reperibilità nel fine settimana e nei giorni festivi è necessaria in pratica.
Come interagisce il CRA con NIS 2?
Entrambi possono applicarsi allo stesso evento, ma il CRA è a livello di prodotto tramite SRP e NIS 2 è a livello di entità o servizio tramite canale nazionale. Tratta le affermazioni secondo cui un invio basta per entrambi come non confermate finché le autorità non pubblicano orientamenti definitivi.
Il Glossario indica questo campo come obbligatorio nell'allerta iniziale a 24 ore e, nella stessa riga, annota che arriverà nella prossima versione della piattaforma. Finché quella versione non esce, può non trovarlo a schermo. Conservi il proprio orario di conoscenza e sia pronto a fornirlo in entrambi i casi. ↩︎
Il Glossario nota che nella versione attuale questo campo è etichettato «Date and time when the incident was detected (UTC time)». Il rilevamento non coincide con la conoscenza, quindi registri entrambi. ↩︎