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 inizia l'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 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.
Stato a giugno 2026: la SRP è ancora in fase di sviluppo e deve essere operativa entro l'11 settembre 2026, con un periodo di test precedente. ENISA ha comunicato che fornirà le istruzioni di accesso e di registrazione, insieme a materiale di formazione e supporto per le prove operative, nel corso di giugno 2026; le modalità di registrazione sono quindi ancora in fase di pubblicazione. ENISA ha anche comunicato che in questa fase non sarà fornita un'API per la SRP: pianificare la prontezza alla segnalazione attorno all'invio tramite la piattaforma, non tramite automazione via API. Per i dettagli sul flusso di registrazione atteso si veda la pagina registrazione ENISA SRP. Segui la pagina della Commissione sulla segnalazione CRA e la pagina ENISA SRP prima di fare affidamento su uno specifico passaggio di registrazione.
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 il fabbricante ha prove attendibili di sfruttamento attivo.
- +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
Le FAQ SRP di ENISA (Q16) elencano i campi attesi per ogni fase di segnalazione. ENISA li inquadra come campi che saranno obbligatori (direttamente dal CRA o per conseguenza logica) o facoltativi, pertanto vanno trattati come provvisori fino a quando la piattaforma non è definitiva. Codici: X obbligatorio, O facoltativo, C copiato dal passaggio precedente come predefinito o aggiornato, A automatico (non mostrato al mittente), I obbligatorio se l'informazione è disponibile.
| # | Campo | 24h | 72h | Finale |
|---|---|---|---|---|
| Campi comuni | ||||
| 1 | Tipo di notifica (vulnerabilità / incidente) | X | C | C |
| 2 | Livello di notifica (24h / 72h / finale) | X | X | X |
| 3 | Orario di segnalazione, 24h | A | A | A |
| 4 | Orario di segnalazione, 72h | A | A | A |
| 5 | Orario di segnalazione, finale | A | A | A |
| 6 | Segnalante | A | A | A |
| 7 | Fabbricante | X | C | C |
| 8 | Prodotto | X | C | C |
| 9 | Tipo di prodotto (default / importante / critico) | O | C | C |
| 10 | Categoria di prodotto (se il tipo è importante o critico) | O | C | C |
| 11 | Stati membri in cui il prodotto è disponibile | I | C | C |
| 12 | Titolo | X | C | C |
| Vulnerabilità | ||||
| v13 | CVE ID | O | C | C |
| v14 | EUVD ID | O | C | C |
| v15 | Informazioni generali, in particolare: | O | X | C |
| v16 | a. Natura generale della vulnerabilità | O | X | C |
| v17 | b. Natura generale dell'exploit | O | X | C |
| v18 | Misure correttive o mitigative adottate | O | X | C |
| v19 | Misure correttive o mitigative che gli utenti possono adottare | O | X | C |
| v20 | Sensibilità considerata delle informazioni | O | I | C |
| v21 | Data in cui una misura correttiva o mitigativa è diventata disponibile | O | O | X |
| v22 | Descrizione completa della vulnerabilità, inclusi: | O | O | X |
| v23 | a. Gravità della vulnerabilità | O | O | X |
| v24 | b. Impatto della vulnerabilità | O | O | X |
| v25 | Attore malevolo che ha sfruttato / sta sfruttando la vulnerabilità | O | O | I |
| v26 | Dettagli sull'aggiornamento di sicurezza / misure correttive | O | O | X |
| Incidente | ||||
| i13 | Incidente ritenuto causato da atti illeciti o malevoli | X | C | C |
| i14 | Informazioni generali sulla natura dell'incidente | O | X | C |
| i15 | Data e ora di rilevamento dell'incidente | O | X | C |
| i16 | Data e ora in cui si è verificato l'incidente | O | X | C |
| i17 | Valutazione iniziale dell'incidente | O | X | C |
| i18 | Misure correttive o mitigative adottate | O | X | C |
| i19 | Misure correttive o mitigative che gli utenti possono adottare | O | X | C |
| i20 | Sensibilità considerata delle informazioni | O | I | C |
| Descrizione dettagliata dell'incidente, inclusi: | O | O | X | |
| i21 | a. Gravità dell'incidente (criteri di seguito) | O | O | X |
| i23 | b. Impatto dell'incidente | O | O | X |
| i24 | Tipo di minaccia o causa probabile | O | O | X |
| i25 | Misure di mitigazione applicate e in corso | O | O | X |
Criteri di gravità (i22): 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: FAQ ENISA SRP, Q16.
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 |
Conoscenza e prove
La definizione CRA richiede prove attendibili, non certezza forense. Se le prove non sono ancora attendibili, mantieni l'evento nel triage CVD o incident; quando lo diventano, il termine di 24 ore decorre dalla conoscenza del fabbricante.
Intake CVD e soglia di segnalazione
La policy CVD è il canale che trasforma le segnalazioni esterne in triage strutturato. Quando il triage produce prove attendibili di sfruttamento attivo, la segnalazione urgente corre in parallelo con la correzione e la divulgazione coordinata. 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 non è richiesto per nome, ma un registro di applicabilità è molto utile. Documenta se una CVE in un componente SBOM è not_affected, affected, fixed o under_investigation per una specifica versione del prodotto. Vedi la guida 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 prove attendibili; un'indagine forense conclusa non è richiesta prima dell'allerta iniziale.
- Confondere CVD e segnalazione urgente. La segnalazione del ricercatore è intake CVD; la segnalazione CRA parte con prove attendibili di 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 di settembre 2026.
Domande frequenti
Quando iniziano gli obblighi di segnalazione CRA?
La segnalazione obbligatoria CRA di vulnerabilità e incidenti inizia l'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 e per le segnalazioni volontarie; ENISA ha comunicato che la funzionalità di segnalazione volontaria sarà abilitata dopo l'11 settembre 2026. 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.