Segnalazione CRA di vulnerabilità e incidenti

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.

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:

1. Segnalare ogni vulnerabilità attivamente sfruttata del prodotto al CSIRT coordinatore e a ENISA secondo il ciclo 24h / 72h / 14g.
2. Segnalare ogni incidente grave che incide sulla sicurezza del prodotto secondo il ciclo 24h / 72h / 1 mese.
3. 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 particolarmente eccezionali (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 al 6 novembre 2026: la SRP è disponibile dall'11 settembre 2026 su portal.cra-srp.enisa.europa.eu. Sulla pagina iniziale si sceglie il ruolo Assigned Representative, l'account SRP che presenta le notifiche per conto di un fabbricante o di un gestore di software open source. Non coincide con il mandatario ai sensi del CRA. L'accesso avviene con EU Login: l'account è personale e richiede l'autenticazione a più fattori. Il 4 novembre 2026 ENISA ha portato la piattaforma alla versione 1.3 e indica che la documentazione è ancora in aggiornamento. Le FAQ portano la data del 15 ottobre 2026, mentre le guide alla registrazione, all'interfaccia e alle notifiche dell'Assigned Representative portano la data del 12 settembre 2026. Il 9 settembre 2026 ENISA ha pubblicato per la prima volta l'AR User Manual e il 4 novembre 2026 lo ha ripubblicato come versione 1.3: è il percorso schermata per schermata della registrazione, delle tre fasi di presentazione e dell'aggiornamento di una notifica. Il Glossario SRP è alla versione 1.6 ed è il riferimento campo per campo. È disponibile solo in inglese. L'elenco dei CSIRT designati come coordinatori porta la data del 10 settembre 2026. Nella versione iniziale non c'è un'API: ogni notifica passa dall'interfaccia della piattaforma, e la segnalazione volontaria non è ancora disponibile. ENISA indica tutta la propria documentazione come stato attuale delle conoscenze, soggetto a modifiche. Crei l'account EU Login prima di averne bisogno, 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

Contenuto di ogni invio

Allerta iniziale (24 ore). L'allerta iniziale è un avviso, non un'analisi completa. Per le vulnerabilità va inviata senza indebito ritardo ed entro 24 ore dalla presa di conoscenza, e dovrebbe indicare, se del caso, gli Stati membri in cui il fabbricante sa che il prodotto è stato messo a disposizione. Per gli incidenti gravi deve precisare anche, come minimo, se si sospetta che l'incidente derivi da atti illeciti o malevoli. I modelli interni possono aggiungere campi come versione del prodotto, gravità, ambito dell'impatto e responsabile, ma sono campi operativi, non tutti sono minimi di legge.

Notifica dettagliata (72 ore). In questa fase ci sono due obblighi distinti. La notifica a 72 ore della vulnerabilità riguarda le vulnerabilità attivamente sfruttate e fornisce informazioni generali su prodotto, sfruttamento, vulnerabilità, misure adottate, misure che l'utente può adottare e, se del caso, grado di sensibilità. La notifica a 72 ore dell'incidente riguarda gli incidenti gravi e fornisce informazioni generali sull'incidente, una valutazione iniziale, misure adottate, misure che l'utente può adottare e, se del caso, grado di sensibilità.

Rapporto finale. Per le vulnerabilità il termine di 14 giorni parte da quando è disponibile una misura correttiva o di attenuazione, non dalla scoperta e non dalla notifica a 72 ore. Il rapporto finale deve includere almeno la descrizione della vulnerabilità, gravità e impatto, le informazioni su chi l'ha sfruttata, se disponibili, e i dettagli sull'aggiornamento di sicurezza o su altre misure correttive. Per gli incidenti gravi il termine di 1 mese si ancora alla notifica dell'incidente a 72 ore e il rapporto finale deve includere almeno una descrizione dettagliata dell'incidente, gravità e impatto, tipo di minaccia o causa di fondo probabile e misure di attenuazione adottate o in corso.

1. 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.
2. +24h. Invii l'allerta iniziale tramite ENISA SRP.
3. +72h. Aggiunga dettagli tecnici, versioni interessate, stato dello sfruttamento e stato della correzione.
4. Misura disponibile. Per le vulnerabilità, il termine del rapporto finale parte da qui, non dalla scoperta.
5. +14g. Invii 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.6 elenca 43 campi: 19 comuni ai due flussi, 13 che riguardano solo una vulnerabilità attivamente sfruttata, 9 che riguardano solo un incidente grave e 2 note di chiusura. È 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.

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.6, ultimo aggiornamento 21 ottobre 2026.

Cosa attiva l'obbligo di segnalazione

La segnalazione CRA ha due categorie di attivazione: le vulnerabilità attivamente sfruttate e gli incidenti gravi che hanno un impatto sulla sicurezza del prodotto.

1. Vulnerabilità attivamente sfruttate

Una vulnerabilità attivamente sfruttata è una vulnerabilità del prodotto per la quale esistono prove attendibili che un soggetto malintenzionato l'abbia sfruttata in un sistema senza autorizzazione. Il fabbricante deve inoltre essere venuto a conoscenza di tale sfruttamento prima che il termine di segnalazione inizi a decorrere.

Non coincide con la divulgazione pubblica, con una proof of concept pubblicata o con un ricercatore che dimostra la sfruttabilità in laboratorio. Questi segnali appartengono alla gestione delle vulnerabilità e al triage CVD, a meno che non producano prove attendibili di uno sfruttamento malevolo contro un sistema reale.

2. Incidenti gravi

Un incidente grave è un incidente con impatto sulla sicurezza del prodotto che soddisfa uno di questi due criteri:

• 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
• 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.

Scenari segnalabili e non segnalabili

Conoscenza e prove

La definizione del CRA usa prove attendibili per individuare una vulnerabilità attivamente sfruttata. 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 occorre aver completato un'indagine forense.

Intake CVD e soglia di segnalazione

La policy CVD è il processo di intake che trasforma le segnalazioni esterne dei ricercatori in un triage strutturato. Quando il triage indica uno sfruttamento attivo, lo valuti subito. Il termine di segnalazione urgente parte quando quella valutazione iniziale dà al fabbricante un ragionevole grado di certezza. La policy è obbligatoria per ogni prodotto con elementi digitali e non esiste alcuna soglia per le PMI né dimensionale. Una pagina CVD pubblica e un file security.txt in /.well-known/security.txt sono il modo pratico per rendere reperibile il canale di segnalazione.

Per la policy CVD in sé, compresi i contenuti richiesti, le convenzioni sulla finestra di divulgazione, il linguaggio di safe harbour e i modelli di comunicazione con i ricercatori, si veda la guida CRA alla divulgazione coordinata delle vulnerabilità. Per come la CVD si colloca nel ciclo più ampio di gestione delle vulnerabilità, si veda la gestione delle vulnerabilità CRA. Per la panoramica combinata di gestione e segnalazione ai sensi dell'Articolo 14, si veda gestione e segnalazione delle vulnerabilità.

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:

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. Microimprese: meno di 10 dipendenti e 2 milioni di EUR) sono esentate dalle sanzioni pecuniarie solo per il mancato rispetto del primo termine di preallarme di 24 ore. L'alleggerimento riguarda le sanzioni sui termini di quella sola prima fase.

Restano obbligatori, senza alleggerimento per le PMI:

• La notifica dettagliata a 72 ore.
• Il rapporto finale a 14 giorni per le vulnerabilità e il rapporto finale a 1 mese per gli incidenti gravi.
• La policy CVD.
• Tutti gli altri obblighi di sicurezza del prodotto previsti dal CRA, compresa la base dell'assenza di vulnerabilità sfruttabili note.

Le medie imprese non rientrano nell'alleggerimento. È una deroga sanzionatoria ristretta, non un regime di segnalazione ridotto. Per la struttura sanzionatoria più ampia, compresi i richiami e i poteri di vigilanza del mercato, si veda sanzioni e vigilanza del mercato per il CRA.

Errori comuni

• Aspettare la certezza forense prima di far partire il termine. 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 è un input CVD. La segnalazione urgente parte quando la valutazione iniziale dà al fabbricante un ragionevole grado di certezza di sfruttamento attivo. La policy CVD deve contenere una soglia esplicita per questo passaggio.
• Escalation con un solo punto di fallimento. Una sola persona autorizzata a segnalare, irraggiungibile il venerdì sera. Il termine di 24 ore non si ferma.
• Primo contatto con il CSIRT coordinatore durante un incidente. Stabilisca ora la relazione e l'instradamento, quando nessun termine sta correndo.
• Nessuna policy CVD pubblicata. Serve una policy pubblica. Un documento interno non basta.
• Nessuna decisione di applicabilità. Senza VEX o un registro equivalente è difficile difendere perché una CVE nota nel suo SBOM non è sfruttabile nel suo prodotto.
• Trattare la SRP come un problema futuro. Template, turni di escalation e relazioni con il CSIRT devono essere pronti prima del primo evento segnalabile, non costruiti durante.

1. Il Glossario spiega questo campo come il momento in cui il fabbricante o un'altra parte pertinente ha rilevato per la prima volta («first detected») la vulnerabilità. Il rilevamento non coincide con la conoscenza, quindi registri entrambi. ↩︎