Notifica di incidenti e vulnerabilità ai sensi del CRA

01Cosa deve essere notificato

L'Art. 14 del Cyber Resilience Act crea due obblighi di notifica per i fabbricanti di prodotti con elementi digitali. Sono più circoscritti di quanto sembrino a prima vista: i bug ordinari e le patch di routine non rientrano nell'ambito di applicazione. Art. 14

• Vulnerabilità attivamente sfruttate; una vulnerabilità del vostro prodotto per la quale esistono prove attendibili che un attore malevolo l'abbia sfruttata in un sistema senza l'autorizzazione del proprietario. Una vulnerabilità che scoprite e correggete prima che venga sfruttata è gestita attraverso il vostro normale processo di gestione delle vulnerabilità, non questo canale di notifica.
• Incidenti gravi; un incidente che pregiudica, o è in grado di pregiudicare, la capacità del prodotto di proteggere la disponibilità, l'autenticità, l'integrità o la riservatezza dei dati o delle funzioni. I criteri di gravità sono fissati all'articolo 14(5).

Gli obblighi non riguardano soltanto i fabbricanti commerciali. Responsabili di software open source hanno propri obblighi di notifica nella misura in cui sono coinvolti in prodotti con elementi digitali. Art. 24(3)

02Le tre scadenze

Ogni notifica si articola in tre fasi, calcolate dal momento in cui venite a conoscenza della vulnerabilità sfruttata o dell'incidente grave. Le finestre sono strette, ed è per questo che la preparazione conta. Art. 14(2)–(4)

• Entro 24hPreavviso. Una prima notifica del fatto che si è verificata una vulnerabilità attivamente sfruttata o un incidente grave, con l'indicazione, per gli incidenti, se si sospetti che sia causato da atti illeciti o malevoli.
• Entro 72hNotifica di vulnerabilità / incidente. Un resoconto più completo: la natura generale della vulnerabilità e dell'exploit, una valutazione iniziale e le misure correttive o di mitigazione adottate, oltre a quelle che gli utenti possono adottare.
• Rapporto finaleRapporto finale. Per una vulnerabilità, entro e non oltre 14 giorni dalla disponibilità di una misura correttiva o di mitigazione. Per un incidente grave, entro un mese dalla notifica a 72 ore. Espone la descrizione completa, la gravità, l'impatto e la correzione applicata.

Notate l'asimmetria nell'ultima riga: per le vulnerabilità il conteggio parte dall'esistenza di una correzione, per gli incidenti dalla notifica precedente. Sono meccanismi diversi e conviene inserirli separatamente nel vostro runbook.

03Quando inizia

Gli obblighi di notifica sono la prima parte principale del CRA ad entrare in vigore. Mentre la maggior parte delle disposizioni si applica dall'11 dicembre 2027, l'Art. 14 si applica dal 11 settembre 2026; 21 mesi dopo l'entrata in vigore del regolamento. ENISA ha aperto la piattaforma di notifica unica in quella stessa data. Art. 71

04A chi notificare

Le notifiche vanno a ENISA e al CSIRT designato come coordinatore, attraverso un unico punto di accesso anziché con invii separati a ciascuna autorità nazionale. Tale punto di accesso è la piattaforma di notifica unica, che ENISA istituisce, gestisce e mantiene ai sensi dell'articolo 16. Art. 14 · 16

Il CSIRT competente dipende dal vostro stabilimento principale nell'Unione o, se non siete stabiliti nell'UE, da quello del vostro rappresentante autorizzato. Il CSIRT ricevente trasmette la notifica ai CSIRTs degli Stati membri in cui il prodotto è disponibile e, se necessario, alle autorità di vigilanza del mercato. Art. 14(7) · 18

L'elenco dei coordinatori è stato pubblicato il 4 settembre 2026

Fino al 4 settembre 2026 non esisteva una risposta pubblicata alla domanda più pratica di questa pagina: quale team nazionale riceve effettivamente la vostra segnalazione. ENISA ha ora pubblicato un elenco dei CSIRT designati come coordinatori che indica uno o più URL di contatto per ciascuno dei 27 Stati membri, e lo ha ridatato 10 settembre 2026, quindi ricontrollate la vostra riga prima di affidarvi a una copia presa in precedenza. L'Irlanda rimanda a una pagina NCSC dedicata al CRA; la Spagna indica due percorsi INCIBE distinti, uno per gli incidenti e uno per il coordinamento delle vulnerabilità.

L'elenco vi dice chi è il coordinatore di ciascuno Stato membro. Non vi dice quale sia il vostro, e il criterio dell'articolo 14(7) è più restrittivo di quanto la maggior parte delle organizzazioni supponga. Il vostro stabilimento principale è lo Stato membro in cui le decisioni sulla cibersicurezza dei vostri prodotti con elementi digitali sono prese in via prevalente, che può essere un sito di sviluppo anziché una sede legale o la maggiore attività commerciale. Qualora ciò non possa essere determinato, il criterio sussidiario è lo Stato membro in cui avete il maggior numero di dipendenti nell'UE. In assenza di qualsiasi stabilimento nell'UE, l'ordine è il seguente: lo Stato membro in cui il vostro rappresentante autorizzato agisce per il maggior numero di prodotti, poi l'importatore che immette sul mercato il maggior numero di prodotti, poi il distributore che ne mette a disposizione il maggior numero, infine lo Stato membro con il maggior numero di utenti. Poiché ciò fissa il destinatario di ogni futura segnalazione, definitelo in anticipo, con il supporto legale, e mettete per iscritto le motivazioni.

Il supporto esiste su entrambi i fronti. ENISA gestisce un helpdesk, con particolare attenzione alle PMI, e i CSIRTs designati come coordinatori sono tenuti a fornire a loro volta supporto helpdesk sugli obblighi dell'articolo 14. ENISA inoltre inserisce le vulnerabilità corrette nel database europeo delle vulnerabilità, e pubblica ogni due anni una relazione tecnica sulle tendenze, la prima attesa entro 24 mesi dall'inizio degli obblighi di notifica. Art. 17(6)

La diffusione di una vulnerabilità notificata può essere sospesa dal CSIRT, ma non da voi

Il CSIRT destinatario può ritardare o sospendere l'ulteriore diffusione per motivi di cibersicurezza giustificati, per il periodo strettamente necessario; ad esempio quando una vulnerabilità rientra in una procedura di divulgazione coordinata. La Commissione ne ha precisato le condizioni nel Regolamento delegato (UE) 2026/881, adottato in data 11 dicembre 2025Quando un CSIRT trattiene una notifica deve informarne immediatamente ENISA, con una giustificazione e l'indicazione di quando procederà alla diffusione.

Separatamente, in circostanze particolarmente eccezionali potete contrassegnare una delle condizioni ristrette previste dall' Articolo 16(2) nella vostra notifica a 72 ore: che lo sfruttamento sia limitato allo Stato membro del vostro CSIRT, che un'ulteriore diffusione sarebbe contraria agli interessi essenziali di tale Stato membro, o che la diffusione comporti un rischio elevato e imminente per la cibersicurezza. In tal caso ENISA riceve solo informazioni limitate (che è stata effettuata una notifica, informazioni generali sul prodotto, la natura generale dell'exploit e il fatto che siano stati invocati motivi di sicurezza) finché il CSIRT non rilascia la notifica completa.

05Registrarsi sulla piattaforma

Gli orientamenti di ENISA sulla registrazione, ridatati 10 settembre 2026, e i suoi orientamenti sull'interfaccia, ridatati 9 settembre 2026, mostrano le schermate reali. La registrazione si è aperta insieme alla piattaforma l'11 settembre 2026, quindi ora è un percorso che potete effettivamente compiere anziché soltanto leggere. ENISA vi chiede comunque di non registrarvi in via preventiva, per il motivo esposto di seguito, il che rende conoscere il percorso in anticipo più utile e non meno: la prima volta che lo seguirete potrebbe benissimo essere con un orologio di 24 ore in corsa.

Nominate due persone prima di averne bisogno

La piattaforma assegna a ciascun fabbricante due tipi di account utente, e potete decidere oggi chi li ricoprirà. Un rappresentante primario si registra per primo e crea la voce del fabbricante sulla piattaforma. Tale persona invita poi un rappresentante secondario , che ricopre un ruolo di riserva per lo stesso fabbricante e può effettuare invii per suo conto. Entrambi sono persone fisiche designate nella vostra azienda. Poiché l'invio è manuale, un unico referente designato che sia in ferie, addormentato o che abbia lasciato l'azienda è un rischio operativo concreto: trattate quindi il secondo posto come necessario e non come facoltativo.

EU Login è la credenziale, ed entrambe le persone possono crearlo già oggi

Gli account della piattaforma si autenticano tramite EU Login, il servizio di accesso condiviso della Commissione europea utilizzato nei suoi sistemi online. Createne uno per il rappresentante primario e uno per il secondario su ecas.ec.europa.eu, utilizzando indirizzi e-mail aziendali che esisteranno ancora fra un anno. L'autenticazione a più fattori è obbligatoria: ENISA richiede la MFA sull'account EU Login prima del primo accesso alla piattaforma, quindi se le vostre persone dispongono già di semplici account EU Login, fate attivare loro la MFA ora anziché durante un incidente. Gli account EU Login sono personali, ed ENISA non gestisce alcuna autenticazione aziendale separata al di sopra di essi. La Commissione spiega che cos'è EU Login e come si inserisce nel suo più ampio quadro di identità, nelle sue pagine sull' identità digitale affidabile .

Il flusso di registrazione

Al primo accesso alla piattaforma selezionate il vostro ruolo, scegliete il vostro CSIRT designato da un menu a discesa, autenticatevi tramite EU Login, leggete e accettate l'accordo legale, confermate i vostri dati personali precompilati (nome, cognome, e-mail, denominazione legale), quindi inserite denominazione, indirizzo e informazioni aggiuntive del fabbricante. L'omissione di un campo obbligatorio del fabbricante blocca il flusso. Al termine lo stato del vostro account è "Active" e ricoprite il ruolo "AR Primary User" e ricevete un'e-mail di conferma, e l'entità del fabbricante viene creata nella piattaforma.

Il secondario si aggiunge tramite invito via e-mail dal primario, conferma i dati personali e del fabbricante precompilati ed è registrato nel ruolo "AR Backup User" per lo stesso fabbricante. Tale invito scade dopo 7 giorni, dopodiché il record viene contrassegnato come "Invitation Expired" e occorre inviarne uno nuovo. Configurate la riserva nella stessa sessione del primario; un invito scaduto scoperto nel mezzo di un incidente è un problema evitabile.

Il CSIRT verifica manualmente il vostro rappresentante, ma ciò non vi impedisce di notificare

Qualcuno deve confermare che una determinata persona possa davvero effettuare segnalazioni per conto di un determinato fabbricante, e tale verifica spetta al CSIRT designato come coordinatore, che ENISA ora abbrevia in CDaC. È un passaggio manuale, la procedura varia tra i CSIRT e ciascun CSIRT gestisce il proprio approccio. Fondamentalmente, avviene dopo il vostro primo accesso alla piattaforma e procede in parallelo con la vostra segnalazione. Nel suo aggiornamento del 3 agosto 2026 ENISA lo ha messo fuori discussione: la convalida da parte del CDaC non è un prerequisito per l'adempimento dell'obbligo di segnalazione previsto dal CRA, e non incide sulla vostra capacità di inviare notifiche. Un account non convalidato può comunque effettuare la segnalazione entro la finestra di 24 ore.

È anche per questo che ENISA consiglia di registrarsi e avviare la convalida solo quando avete effettivamente bisogno di notificare, anziché preregistrare l'intero mercato e sommergere i CSIRTs di verifiche ipotetiche. La preparazione da fare in anticipo riguarda gli account EU Login e la decisione su chi occuperà i due posti, non la registrazione sulla piattaforma.

Un account può gestire più fabbricanti

Gli stessi orientamenti definiscono la gestione ordinaria dei due posti. Un rappresentante primario invita un sostituto tramite indirizzo e-mail, il che crea un record contrassegnato come "Pending Invitation" senza alcun ruolo finché non viene accettato. Un rappresentante secondario può chiedere la promozione a primario, richiesta che viene sottoposta all'esame del CDaC. L'ENISA ha formalizzato questo aspetto il 17 settembre 2026, contrassegnando la domanda 9 delle FAQ come «[AGGIORNATA]» per precisare che un AR secondario «non dispone degli stessi permessi amministrativi dell'AR primario, ma può rivendicare il ruolo di AR primario, previo esame e approvazione da parte del CSIRT designato». Ciascuno dei due può rimuovere un'associazione, che viene quindi contrassegnata come "Deleted". E un singolo account può avere associazioni con più fabbricanti, ciascuna aggiunta tramite Association Management e ciascuna verificata separatamente.

Quest'ultimo punto è rilevante per i gruppi con più entità produttive e per le imprese che agiscono ai sensi dell'articolo 18 per fabbricanti stabiliti fuori dall'UE. È anche il punto in cui la trappola dei nomi descritta più sotto morde di più.

06Inviare una notifica

La segnalazione avviene da una dashboard. Create una notifica, poi integrate lo stesso record a ogni fase anziché presentare tre elementi distinti. Ogni fase ha la propria scheda e ciascuna può essere prima salvata come bozza. La dashboard può essere cercata per ID notifica, fabbricante o titolo, ordinata per titolo o ultimo aggiornamento e filtrata per Stato membro, tipo di invio o per il flag Action Required .

• PreavvisoAvviate una nuova notifica dalla dashboard, compilate i campi obbligatori e selezionate un fabbricante esistente o aggiungetene uno. Al momento dell'invio è accessibile al vostro CSIRT designato e, automaticamente, a ENISA. Le conferme via e-mail e tramite allarme vengono inviate al CSIRT, a ENISA e a ogni rappresentante registrato per quel fabbricante, non solo alla persona che ha effettuato l'invio.
• 72 oreDisponibile solo se esiste già un preavviso. Aprite la stessa notifica e completate la scheda delle 72 ore. ENISA la riceve automaticamente a meno che invocate le condizioni dell'articolo 16(2), nel qual caso il record viene contrassegnato con "72h Submitted under PEC" e la visione di ENISA è limitata finché il CSIRT non la rende disponibile.
• Rapporto finaleDisponibile solo quando esistono entrambe le fasi precedenti. ENISA lo riceve automaticamente, a meno che non siano state invocate le condizioni dell'articolo 16(2).

Che cosa è obbligatorio, e quando

ENISA ha pubblicato quali campi sono obbligatori in ciascuna fase. La tabella è un utile correttivo a un'ipotesi diffusa: il preavviso a 24 ore è un allarme, non un'indagine.

• A 24 ore; il tipo e il livello della notifica, il nome del fabbricante o dello steward, il prodotto e un titolo. Per gli incidenti, se si sospettino atti illeciti o malevoli. Gli Stati membri in cui il prodotto è disponibile sono richiesti solo se ne siete già a conoscenza.
• A 72 ore; la natura generale della vulnerabilità e dell'exploit, le misure correttive o di mitigazione adottate e le misure che gli utenti possono adottare. Per gli incidenti, quando è stato rilevato e quando si è verificato, oltre a una valutazione iniziale. La sensibilità si segnala in questa fase.
• Al rapporto finale; la descrizione completa, la gravità e l'impatto, la data in cui una misura correttiva è divenuta disponibile e il dettaglio dell'aggiornamento di sicurezza. Per gli incidenti, la probabile causa principale e le mitigazioni in corso.

Tra i campi facoltativi che conviene comunque registrare figurano il CVE ID e il EUVD ID, entrambi disponibili fin dalla prima fase.

Ogni campo ha un limite di caratteri, e uno di essi è molto breve

Il Glossario SRP di ENISA, dimensionato per la prima volta nella versione 1.1 del 5 settembre 2026 e ora alla versione 1.3 del 10 settembre 2026, è il documento ENISA che pubblica la dimensione di ciascuna casella. Scrivete i vostri modelli interni entro questi limiti, anziché scoprirli alle due di notte:

• 4000 caratteri per i campi descrittivi: la sintesi, le informazioni generali sulla vulnerabilità o sull'incidente, le misure correttive che gli utenti possono adottare, le descrizioni complete di gravità e impatto, la valutazione iniziale e, per gli incidenti, le misure di mitigazione applicate e in corso.
• 2000 caratteri per le misure correttive o di mitigazione che avete già adottato, e per il dettaglio dell'aggiornamento di sicurezza o della misura correttiva nella relazione finale.
• 800 caratteri per la giustificazione a testo libero che accompagna una richiesta PEC nella notifica di vulnerabilità a 72 ore.
• 255 caratteri per il titolo, il nome del prodotto, l'intervallo di versioni del prodotto, il nome del componente, il vettore di attacco, la giustificazione della sensibilità e la probabile causa principale.
• 100 caratteri per l'attore malevolo che ha sfruttato la vulnerabilità. È all'incirca una riga, quindi prevedete di nominare l'attore o di rinviare a un riferimento di indicatore anziché descrivere la campagna.

Il glossario conferma anche una piccola comodità: il campo Stati membri in cui il prodotto è disponibile arriva precompilato con il vostro CSIRT coordinatore, e gli altri mercati li aggiungete voi.

Le modifiche e il punto di non ritorno

Una notifica inviata può essere aggiornata e la piattaforma invia automaticamente un allarme e un'e-mail al vostro CSIRT, a ENISA e agli eventuali CSIRT che l'hanno già ricevuta tramite diffusione. Valgono due limiti: una notifica chiusa non può essere aggiornata e il record diventa non modificabile una volta inviato il rapporto finale.

Tenete d'occhio la scheda degli allarmi, anche nel fine settimana

Ogni account dispone di una scheda Alerts con codice colore: gli allarmi non letti sono azzurri e diventano grigi una volta aperti, e gli allarmi rossi compaiono solo quando è accaduto qualcosa di eccezionale. L'esempio fornito da ENISA è quello di un CSIRT designato che ha invalidato un invio. La segnalazione non è quindi la fine dello scambio e nessuna scadenza dell'articolo 14 si sposta perché una notifica vi è tornata indietro. Chi controlla quella scheda deve controllarla anche fuori orario, il che è un ulteriore argomento a favore di una casella di posta di team monitorata dietro entrambi i posti anziché di due indirizzi personali.

Il contatore di 72 ore della piattaforma non parte dalla conoscenza

Le FAQ rivelano come si comportano effettivamente i conti alla rovescia sullo schermo, e non seguono la scadenza legale. ENISA ha aggiornato le FAQ il 10 settembre 2026, il giorno prima dell'apertura, lasciando invariata questa risposta: il comportamento qui descritto è dunque quello entrato effettivamente in servizio. Nella versione attuale il contatore di 72 ore mostra una data di scadenza fissata a 48 ore dopo l'invio della segnalazione di 24 ore, non a 72 ore dopo il momento in cui ne siete venuti a conoscenza. ENISA afferma chiaramente che una notifica può quindi apparire in ritardo prima che siano trascorse 72 ore dalla conoscenza, e che la logica sarà modificata in una versione successiva per contare a partire dal campo "data e ora in cui ne siete venuti a conoscenza", sia per le vulnerabilità sia per gli incidenti.

I contatori del rapporto finale differiscono ancora. Per un incidente grave il contatore mostra un mese dopo la notifica di 72 ore. Per una vulnerabilità attivamente sfruttata non esiste alcun contatore, perché la scadenza dipende da quando diventa disponibile una misura correttiva, cosa che la piattaforma non può sapere.

Al lancio la piattaforma non registra quando ne siete venuti a conoscenza

Il 5 settembre 2026 ENISA ha sostituito il proprio Glossario SRP campo per campo con la versione 1.1, e due note a piè di pagina in esso contenute contano più di qualsiasi altra cosa nella pagina. Per una vulnerabilità attivamente sfruttata, il campo Date/time when you become aware reca la nota secondo cui sarà disponibile nella prossima versione della piattaforma. Per un incidente grave, la nota afferma che nella versione attuale il campo equivalente si chiama Date/time the incident was detected.

Accostato alla logica dei contatori sopra descritta, questo chiude il cerchio. Le FAQ dicevano che il contatore di 72 ore sarebbe stato corretto una volta arrivato il campo relativo alla conoscenza; il glossario diceva che il campo arriva in una versione successiva. Nessuno dei due si è mosso prima dell'apertura: ENISA ha nuovamente rivisto il glossario portandolo alla versione 1.3 il 10 settembre 2026 e ha lasciato intatte entrambe le note a piè di pagina. Perciò dal primo giorno la piattaforma non registra alcuna marca temporale di conoscenza per le vulnerabilità, e per gli incidenti registra il momento del rilevamento, che non è il momento della conoscenza.

07Che cosa potete fare oggi

Rispettare una finestra di 24 ore è un problema operativo, non di scartoffie. Ora che la piattaforma è aperta, l'elenco che segue non è più una preparazione a un evento futuro; l'obbligo è in corso, e tutto ciò che qui non avete fatto è un'esposizione e non un piano.

• Create i vostri account EU Login, con la MFA attivata. Per il referente primario e almeno una riserva. Bastano pochi minuti su ecas.ec.europa.eu, e la piattaforma non farà entrare nessuno senza autenticazione a più fattori, quindi attivarla fa parte del compito anziché esserne un perfezionamento.
• Individuate il vostro CSIRT designato. ENISA ha pubblicato un elenco dei coordinatori per tutti i 27 Stati membri il 4 settembre 2026, quindi questo è ora un compito che potete portare a termine. Applicate il criterio dello stabilimento principale dell'articolo 14(7), individuate la vostra riga e mettete per iscritto le motivazioni.
• Costruite internamente il modulo delle 24 ore. Un breve modello corrispondente ai campi obbligatori del preavviso di ENISA, in modo che la vostra prima segnalazione reale sia una trascrizione anziché una stesura. Tenetelo in un luogo che entrambi i rappresentanti possano aprire, perché le bozze sulla piattaforma sono visibili solo a chi le ha create.
• Nominate le persone, anche fuori orario. Decidete chi valuta che una notifica sia dovuta, chi la redige e chi la invia. Poiché non esiste alcuna API, l'ultimo passaggio è una persona designata davanti a una tastiera.
• Mantenete un SBOM accurato. Non potete notificare un componente che non sapevate di aver distribuito. Mantenete una distinta base del software e tenetela aggiornata al variare delle release.
• Monitoratelo di continuo. Confrontate i vostri componenti con le fonti di vulnerabilità note, così che una falla attivamente sfruttata emerga in poche ore e non in settimane. Il nostro SBOM e analizzatore di vulnerabilità confronta la vostra distinta base con l'NVD e il database europeo delle vulnerabilità (EUVD).
• Verificate che cosa rientri effettivamente nell'ambito di applicazione. La fase delle 72 ore richiede il tipo di prodotto e la categoria di cui all'allegato III o IV: definite quindi la classificazione prima di averne bisogno. Lo strumento di classificazione risponde a questa domanda, e il matrice di conformità collega la notifica ai più ampi obblighi di gestione delle vulnerabilità dell'Allegato I in cui è inserita.
• Decidete chi legge la scheda degli allarmi fuori orario. Un CSIRT designato può invalidare un invio, e l'allarme che lo comunica arriva nella piattaforma anziché soltanto nella vostra casella di posta. Mettete una casella di posta monitorata dietro entrambi i posti di rappresentante.
• Non affidatevi al conto alla rovescia della piattaforma. Registrate voi stessi l'orario in cui ne siete venuti a conoscenza. Il contatore di 72 ore sullo schermo decorre dall'invio della segnalazione di 24 ore, non dalla conoscenza, quindi può segnalare come in ritardo una segnalazione prima che la scadenza legale sia trascorsa.
• Read the AR User Manual, and watch the tutorial video. ENISA published the manual at launch and added the AR User Tutorial Video within days, so between the two, plus the guidance pages, you have the fullest available description of the live platform.
• Verificate di aver scelto il coordinatore giusto prima di inviare. ENISA avverte ora che selezionare il CSIRT designato come coordinatore sbagliato può portare all'invalidazione della notifica, lasciandovi a ripresentarla a quello corretto con l'orologio ancora in corsa.

08Seguitelo alla fonte

Questa pagina riflette la situazione all'11 settembre 2026, il giorno di apertura della piattaforma. Continuerà a muoversi, ed ENISA modifica le sue pagine in silenzio anziché annunciare ogni cambiamento. Nella settimana precedente il lancio le FAQ sono state riscritte il 4 settembre 2026 e aggiornate di nuovo il 10 settembre 2026, l'elenco dei coordinatori è comparso il 4 settembre 2026 ed è stato ridatato 10 settembre 2026, il glossario ha raggiunto la versione 1.1 il 5 settembre 2026 e la versione 1.3 il 10 settembre 2026, gli orientamenti sulle circostanze particolarmente eccezionali sono arrivati il 9 settembre 2026, e l'AR User Manual e i termini e condizioni della piattaforma sono stati pubblicati il 10 settembre 2026. Dal lancio, le FAQ sono state aggiornate di nuovo il 12 settembre 2026 (il video tutorial per gli utenti AR è stato pubblicato e la scheda informativa SRP è uscita in altre nove lingue) e il 17 settembre 2026, quando la domanda 9 è stata contrassegnata come «[AGGIORNATA]» per documentare che un AR secondario può rivendicare il ruolo di AR primario, previo esame del CDaC. Per le domande di supporto ENISA pubblica un indirizzo di helpdesk sulla pagina hub, cra-srp-helpdesk [at] enisa.europa.eu. Queste sono le fonti primarie; tutto quanto precede è la nostra lettura di esse.

• ENISA · La piattaforma di notifica unica stessa (attiva dall'11 settembre 2026); selezionate il ruolo Assigned Representative e accedete tramite EU Login con autenticazione a più fattori. È qui che si presentano le notifiche.portal.cra-srp.enisa.europa.eu
• ENISA · Piattaforma di notifica unica; la pagina hub, con la scheda informativa, il manuale utente, l'indirizzo di helpdesk e i collegamenti a ogni pagina di guida.enisa.europa.eu/topics/product-security/single-reporting-platform-srp
• ENISA · Domande frequenti sulla SRP (aggiornate il 10 settembre 2026); base giuridica, scadenze, instradamento, la tabella dei campi, la logica dei contatori, cosa fare durante un'interruzione del servizio e l'indirizzo della piattaforma. Riscritte il 4 settembre e ampliate il giorno prima del lancio. La più aggiornata delle pagine SRP di ENISA, e quella da preferire in caso di contrasto.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions
• ENISA · CRA SRP AR User Manual (10 settembre 2026); il manuale del giorno del lancio per gli Assigned Representatives, e la descrizione singola più completa della piattaforma così come si è effettivamente aperta.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-ar-user-manual
• ENISA · Elenco dei CSIRT designati come coordinatori (pubblicato il 4 settembre 2026, aggiornato il 10 settembre 2026); punti di contatto per tutti i 27 Stati membri. Individuate la vostra riga usando il criterio dell'articolo 14(7) nella sezione 04.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/list-of-csirts-designated-as-coordinators
• ENISA · Glossario SRP del CRA (versione 1.3, 10 settembre 2026); guida campo per campo su cosa significa ciascun campo di notifica, come compilarlo, il formato atteso, il limite di caratteri e la fase in cui si applica. Attenzione all'indirizzo: ENISA ha spostato il glossario su un URL glossary2 e quello più vecchio è ancora collegato da alcune delle sue stesse pagine, quindi controllate la riga della versione in alto prima di affidarvi a una copia.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-glossary2
• ENISA · Guida alla registrazione degli utenti SRP; il flusso di registrazione passo passo per utenti primari e di riserva, con schermate dell'interfaccia.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-user-registration
• ENISA · Guida all'invio delle notifiche SRP; come si inviano e si aggiornano il preavviso, la notifica a 72 ore e il rapporto finale, e che cosa attiva ciascuno stato.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-notification-submission-and-update
• ENISA · Guida alle funzioni dell'interfaccia SRP (9 settembre 2026); impostazioni, associazioni con i fabbricanti, il cruscotto e la scheda degli avvisi. Ridatata il giorno stesso del lancio, ora concorda con le FAQ sul fatto che un'associazione non verificata possa presentare fino a 20 notifiche.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-interface-functions
• ENISA · Termini e condizioni della CRA SRP (versione 1.0, 10 settembre 2026); i termini che accettate quando vi registrate sulla piattaforma, pubblicati il giorno prima della sua apertura.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-single-reporting-platform-terms-and-conditions
• ENISA · Guida sulle circostanze particolarmente eccezionali nella SRP (9 settembre 2026); quando si applica il PEC, l'interruttore e i motivi di ritardo nel modulo delle 72 ore, e che cosa fa il CSIRT coordinatore con la giustificazione. La quinta pagina di guida, e l'unica che affronta direttamente il PEC.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-particular-exceptional-circumstances-pec
• Commissione europea · Obblighi di notifica del CRA; la pagina di policy, comprese le FAQ sull'attuazione del CRA la cui sezione 5 riguarda la notifica. La Commissione ha aggiornato questa pagina l'11 settembre 2026 per confermare che la piattaforma è ora operativa, e il documento FAQ separato della Commissione è stato aggiornato l'ultima volta il 4 settembre 2026.digital-strategy.ec.europa.eu/en/policies/cra-reporting
• Commissione europea · Guida all'applicazione del CRA (27 luglio 2026); il punto 9.1 illustra gli obblighi di notifica dei fabbricanti e degli steward open source. La nostra sintesi della guida copre il resto.digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation
• EU Login; create l'account che la piattaforma utilizza e attivatevi l'autenticazione a più fattori. Fatelo ora.ecas.ec.europa.eu/cas/login

Per il testo vincolante, gli articoli da 14 a 17 delineano l'ecosistema della notifica e l'articolo 16 istituisce la piattaforma; leggeteli nel nostro lettore del regolamento. Le date chiave sono monitorate nella pagina stato dei lavori .

09Domande comuni