# La Single Reporting Platform del CRA: guida completa alla segnalazione > Dall'11 settembre 2026 vulnerabilità sfruttate e incidenti gravi si notificano su un'unica piattaforma ENISA. Cos'è la SRP, chi si registra, cosa si scrive in ogni notifica, chi la riceve e in quante ore. Guida dalle fonti ufficiali, con i riferimenti all'articolato del CRA e alla guidance ENISA. - URL: https://albertoscarpa.com/guide/it/single-reporting-platform-guida/ - Lingua / Language: Italiano - Pubblicato: 2026-08-12 - Aggiornato: 2026-08-12 - Tag: CRA --- Dall'11 settembre 2026 scatta l'obbligo più vicino del Cyber Resilience Act, è un obbligo di segnalazione, non un requisito di prodotto. Chi scopre una vulnerabilità attivamente sfruttata o subisce un incidente grave deve notificarlo, e da quella data lo fa su un canale unico gestito da ENISA, la Single Reporting Platform (SRP). Questa guida raccoglie cosa prevedono le fonti ufficiali sulla piattaforma: chi notifica, con quale account, cosa scrive, in quanto tempo. È aggiornata alla guidance ENISA di agosto 2026. *Questa guida riporta il testo vincolante del CRA e la guidance ufficiale di ENISA e della Commissione, con riferimenti puntuali. Le letture operative e i consigli applicativi, come scegliere l'AR o come decidere se una segnalazione diventa notifica, sono negli articoli del blog collegati in fondo.* Se il quadro generale del CRA non è ancora a fuoco, il punto di partenza è [Il CRA in un'ora](/guide/it/cra-in-un-ora/); per come questa scadenza si colloca rispetto alle altre, [Le scadenze del CRA](/guide/it/scadenze-cra/). ## Cos'è la SRP e perché esiste La SRP è un punto di ingresso unico per le segnalazioni previste dal CRA. Il fabbricante notifica una volta sola, la piattaforma smista al CSIRT nazionale competente e a ENISA. Un solo invio raggiunge tutti i destinatari, non serve notificare più autorità separatamente. In pratica, per chi vende in più Stati membri, cambia la logistica della segnalazione: un modulo unico che la piattaforma instrada alle autorità nazionali competenti. Il fabbricante indica dove il prodotto è disponibile, il CSIRT che riceve per primo diffonde la notifica agli altri CSIRT interessati e, se serve, alle autorità di vigilanza del mercato. La base giuridica è l'articolo 16 del CRA (Regolamento UE 2024/2847): ENISA istituisce la piattaforma, ne gestisce le operazioni quotidiane e ne garantisce la sicurezza. L'architettura prevede terminali di notifica elettronica nazionali (i CSIRT) e uno a livello di Unione (ENISA). ## Quando è operativa La piattaforma è prevista operativa per l'11 settembre 2026, la stessa data in cui si applica l'articolo 14 del CRA, quello che introduce gli obblighi di segnalazione. È previsto un periodo di test prima del lancio. L'URL pubblico della piattaforma non è ancora stato comunicato: ENISA lo pubblicherà sulla propria pagina prima dell'avvio. Da notare: la data non è una scadenza di conformità del prodotto, è l'attivazione di un processo. Un'azienda può avere prodotti ancora lontani dai requisiti essenziali (che si applicano dall'11 dicembre 2027) ed essere comunque soggetta all'obbligo di segnalazione da settembre 2026, anche per prodotti già sul mercato. ## Cosa si deve notificare, e cosa si può notificare Il CRA distingue due piani. Obbligatorio (art. 14): il fabbricante notifica le vulnerabilità attivamente sfruttate (vulnerabilità per cui esistono prove attendibili che un attore malevolo l'ha sfruttata) e gli incidenti gravi che hanno un impatto sulla sicurezza del prodotto. I criteri di gravità dell'incidente sono all'art. 14, par. 5. Gli open-source software steward sono soggetti agli obblighi nella misura in cui sono coinvolti con prodotti con elementi digitali (art. 24, par. 3). Volontario (art. 15): chiunque, non solo il fabbricante, può notificare su base volontaria vulnerabilità, minacce informatiche, incidenti e quasi incidenti. La SRP abiliterà questa funzione dopo l'11 settembre 2026. Il CSIRT può trattare le notifiche obbligatorie in via prioritaria rispetto a quelle volontarie. La distinzione conta perché definisce cosa fa scattare l'orologio. Solo lo sfruttamento attivo di una vulnerabilità, o l'incidente grave, attivano l'obbligo e i suoi tempi. Una vulnerabilità nota ma non sfruttata sta sul piano volontario. ## Le scadenze: 24 ore, 72 ore, relazione finale I tempi decorrono dal momento in cui il fabbricante viene a conoscenza dello sfruttamento o dell'incidente. L'art. 14, par. 2 (per le vulnerabilità) e par. 4 (per gli incidenti) fissano tre passaggi: - Preallarme, entro 24 ore. - Notifica, entro 72 ore, con informazioni generali e una valutazione iniziale. - Relazione finale: per le vulnerabilità, entro 14 giorni dalla messa a disposizione di una misura correttiva; per gli incidenti gravi, entro 1 mese dalla notifica. Il preallarme entro 24 ore è una notifica preliminare, con i pochi campi che identificano il caso; le informazioni di dettaglio arrivano nei due passaggi successivi. ## Chi notifica: il rappresentante e la registrazione Sulla piattaforma opera l'Assigned Representative (AR), l'utente che invia le notifiche per conto del fabbricante o dell'open-source steward. La guidance ENISA (pagine pubblicate a luglio, aggiornate al 3 agosto 2026, non vincolanti) descrive due ruoli e due percorsi di registrazione. Il Primary AR si registra scegliendo il ruolo e il CSIRT coordinatore, autenticandosi tramite EU Login, accettando l'accordo, confermando i dati precompilati e inserendo i dati del fabbricante. Al termine l'account è attivo con ruolo di AR primario. Un AR di backup (Secondary) si registra tramite un invito email inviato dal primario; l'invito scade dopo 7 giorni. Da notare: la validazione dell'AR da parte del CSIRT coordinatore avviene dopo la registrazione, ma non è un prerequisito per notificare. Corre in parallelo alla segnalazione e non blocca l'invio. Proprio per non sovraccaricare i CSIRT, ENISA consiglia di registrarsi e avviare la validazione solo quando serve notificare davvero, non in anticipo. L'account EU Login si può creare da subito: https://ecas.ec.europa.eu/cas/login. È l'unico passo che non dipende dal lancio della piattaforma. ## Cosa si scrive in ogni notifica La FAQ ENISA (domanda 16) pubblica i campi del modulo, distinti per le tre scadenze. I campi derivano dal CRA (art. 14) e, per alcuni, da una lettura logica di ENISA. Sintesi di cosa è obbligatorio a ciascuno stadio. Preallarme (24 ore). Solo i campi che identificano il caso: tipo di notifica (vulnerabilità o incidente), prodotto, fabbricante o open-source steward, titolo. Per un incidente va precisato subito se si sospetta un atto illecito o doloso (coerente con l'art. 14, par. 4, lett. a). Gli Stati membri in cui il prodotto è disponibile sono richiesti se l'informazione è già disponibile. Il resto è opzionale. Notifica (72 ore). Entra la sostanza tecnica. Per una vulnerabilità: natura della vulnerabilità e dello sfruttamento, misure correttive o di attenuazione adottate e quelle che gli utilizzatori possono adottare. Per un incidente: natura dell'incidente, data e ora del rilevamento e dell'accadimento, valutazione iniziale, misure adottate e misure per gli utilizzatori. In entrambi i casi il grado di sensibilità delle informazioni va indicato, se rilevante. Relazione finale. La descrizione completa. Per una vulnerabilità: gravità e impatto, data in cui la misura correttiva è disponibile, dettagli sull'update di sicurezza. Per un incidente grave: gravità (con i criteri dell'art. 14, par. 5), impatto, tipo di minaccia o causa alla radice, misure di mitigazione applicate e in corso. Due dettagli pratici. Alcuni campi si copiano in automatico dallo stadio precedente e si possono aggiornare; altri (orari di reporting, identità di chi invia) li compila la piattaforma. In questa fase non sono previste API: la compilazione è manuale, anche per chi gestisce volumi alti di notifiche. ## Chi riceve la notifica, e come viaggia Alla trasmissione, la notifica raggiunge simultaneamente il CSIRT designato come coordinatore dello Stato membro in cui il fabbricante ha lo stabilimento principale e ENISA (art. 14, par. 1 e 3; art. 16). Il CSIRT che riceve per primo la diffonde senza ritardo agli altri CSIRT coordinatori degli Stati membri in cui il fabbricante ha indicato che il prodotto è disponibile, e, se necessario, alle autorità di vigilanza del mercato. Un'eccezione riguarda le circostanze eccezionali. Il CSIRT ricevente può ritardare o sospendere la diffusione ad altri Stati membri per motivi giustificati di cibersicurezza (art. 16). Le condizioni sono precisate dal Regolamento delegato (UE) 2026/881, adottato l'11 dicembre 2025. In circostanze particolarmente eccezionali, quando nel modulo delle 72 ore il fabbricante marca una delle condizioni dell'art. 16, par. 2, lett. a-c, ENISA riceve solo informazioni parziali finché il CSIRT ricevente non divulga la notifica completa. ## Quale CSIRT è il tuo Il CSIRT coordinatore competente è determinato dallo stabilimento principale del fabbricante (o del suo rappresentante autorizzato, se il fabbricante non è stabilito nell'UE). L'art. 14, par. 7 fornisce i criteri per individuarlo. Per un fabbricante con stabilimento principale in Italia, il riferimento è il CSIRT Italia, presso l'Agenzia per la Cybersicurezza Nazionale (ACN). ENISA pubblicherà l'elenco dei CSIRT designati come coordinatori in una fase successiva. ## Approfondimenti Le scelte operative sulla SRP sono trattate negli articoli del blog, che partono da questa guida: [Come si sceglie l'Assigned Representative](/blog/it/assigned-representative-srp-scelta/) e [Da segnalazione a notifica: quando aprire una notifica SRP](/blog/it/da-segnalazione-a-notifica-srp/). --- *Riferimenti: Regolamento (UE) 2024/2847 (CRA), articoli 14, 15, 16, 24 e Allegati pertinenti; Regolamento delegato (UE) 2026/881 (condizioni per il ritardo della diffusione delle notifiche). Guidance non vincolante: pagine ENISA sulla SRP e relativa FAQ (aggiornate al 3 agosto 2026), orientamenti della Commissione. Numeri di articolo verificati sul testo ufficiale del CRA in lingua italiana.*