La piattaforma CRA è operativa. Come preparare una segnalazione senza perdere le prime 24 ore.

Cosa cambia ora che la piattaforma è realmente operativa

ENISA ha avviato l’11 settembre 2026 la prima capacità operativa della Single Reporting Platform, o SRP. Da quella data i produttori che rientrano nel Cyber Resilience Act devono usare il portale per notificare due eventi precisi: vulnerabilità per le quali esistono prove affidabili di sfruttamento malevolo e incidenti con impatto grave sulla sicurezza di un prodotto con elementi digitali.

La segnalazione è unica. Il produttore seleziona il CSIRT designato come coordinatore; la notifica viene resa disponibile a ENISA e distribuita dal CSIRT agli altri organismi pertinenti. Non significa però che ogni bug, anomalia o tentativo debba finire nel portale. La funzione per le segnalazioni volontarie non è ancora disponibile e la valutazione dell’evento resta responsabilità del produttore.

Il nuovo elemento non è quindi una generica pagina web, ma una catena operativa con ruoli, scadenze e informazioni che cambiano tra allerta iniziale, notifica e relazione finale. La precedente guida Scenicom sul CRA spiegava chi può trovarsi nel perimetro e quali tempi preparare. Oggi il passaggio successivo è verificare se l’organizzazione sa davvero eseguire quella sequenza.

Primary e Secondary: l’accesso non può dipendere da una sola persona

Il portale usa account personali EU Login con autenticazione a più fattori. Non esiste, nella versione iniziale, un’identità aziendale separata che il team possa condividere. Ogni Assigned Representative deve quindi utilizzare il proprio account e l’impresa deve decidere in anticipo chi è autorizzato a rappresentarla.

Per ogni produttore è previsto un solo Primary AR e fino a venti Secondary AR. Il Primary amministra l’associazione con il produttore, invita o rimuove i Secondary e mantiene una visione complessiva. Entrambi i ruoli possono inviare e aggiornare notifiche secondo i rispettivi permessi. Le bozze fanno eccezione: rimangono nell’account personale che le ha create e non sono visibili agli altri rappresentanti.

Questo dettaglio rende rischioso affidare tutto a un unico referente. Una procedura utile assegna un titolare e almeno un sostituto, conserva fuori dal portale una checklist condivisa e stabilisce chi può approvare le informazioni. ENISA consiglia però di non avviare inutilmente la validazione dell’associazione prima che serva una notifica, per non sovraccaricare i CSIRT. La preparazione corretta consiste nel creare EU Login con MFA, nominare i ruoli e provare il percorso interno; la registrazione al produttore può avvenire quando è necessaria.

• Verificare che titolare e sostituto abbiano EU Login personale e MFA funzionante.
• Definire chi assume il ruolo Primary e chi può diventare Secondary.
• Conservare contatti e responsabilità in una procedura accessibile anche durante un blocco dei sistemi.
• Evitare account condivisi e credenziali trasmesse tramite email o chat.

L’orologio parte dalla consapevolezza, non dall’apertura del ticket

Il primo termine è l’allerta entro 24 ore da quando il produttore diventa consapevole dell’evento. La notifica più completa segue entro 72 ore. Per una vulnerabilità attivamente sfruttata, la relazione finale arriva entro quattordici giorni dalla disponibilità di una misura correttiva o mitigante; per un incidente grave, entro un mese dalla notifica delle 72 ore.

ENISA segnala una particolarità importante della versione attuale: il contatore delle 72 ore mostra una scadenza calcolata quarantotto ore dopo l’invio dell’allerta iniziale. In alcuni casi può quindi indicare un ritardo prima che siano trascorse settantadue ore dall’effettiva consapevolezza. Il contatore verrà aggiornato, ma non sostituisce la responsabilità dell’impresa.

La conseguenza pratica è semplice: serve un registro interno che annoti quando e come l’organizzazione ha acquisito consapevolezza, chi ha classificato l’evento, quando sono state inviate le diverse fasi e quali evidenze sostengono le decisioni. Affidarsi soltanto ai promemoria del portale significa perdere il riferimento giuridico e operativo più importante.

Scegliere il CSIRT sbagliato può costringere a ripetere la notifica

Il produttore deve individuare il CSIRT designato come coordinatore. In generale è quello dello Stato membro in cui si trova lo stabilimento principale nell’Unione, inteso come il luogo dove vengono prese prevalentemente le decisioni di cybersecurity sui prodotti digitali. Non è necessariamente la sede commerciale più visibile o il Paese con più clienti.

Se il centro decisionale non può essere determinato, il CRA prevede criteri successivi. Per organizzazioni senza stabilimento principale nell’UE entrano in gioco, in ordine, rappresentante autorizzato, importatore, distributore e distribuzione degli utenti. Sono valutazioni da documentare caso per caso, soprattutto nei gruppi con più società o sviluppo distribuito.

Le FAQ ENISA avvertono che una notifica inviata al coordinatore errato può essere invalidata e richiedere un nuovo invio. Nel mezzo di un incidente, scoprire il criterio per la prima volta consuma tempo. La scheda del prodotto dovrebbe quindi riportare già la base utilizzata per individuare il CSIRT, il referente che l’ha validata e la data dell’ultima revisione.

Preparare i dati prima del modulo: nella prima versione non c’è un’API

I campi cambiano in base al tipo di evento e alla fase. Per una vulnerabilità possono essere richiesti identificativi come CVE o EUVD, descrizione, sfruttamento osservato, gravità, impatto, natura dell’exploit e informazioni sull’attore malevolo quando disponibili. Per un incidente servono natura dell’evento, misure applicate o in corso, gravità, impatto e possibile causa. Non tutto è obbligatorio nelle prime 24 ore: il glossario SRP indica cosa diventa necessario nelle fasi successive.

ENISA consente di automatizzare il flusso interno, ma non offre un’API nella release iniziale. Il caricamento avviene tramite interfaccia web. Per una PMI è quindi più utile preparare un fascicolo strutturato che tentare integrazioni premature: anagrafica del prodotto e versioni, mercati coinvolti, componenti e fornitori, evidenze tecniche, cronologia, misure di contenimento, persone che approvano e testi già verificati.

Il fascicolo non deve duplicare dati sensibili senza controllo. Deve stabilire la fonte autorevole per ciascuna informazione e mantenere la tracciabilità delle modifiche. In questo modo il rappresentante può compilare il portale rapidamente e il team tecnico continua a investigare senza trasformare il modulo in un secondo sistema di gestione dell’incidente.

• Scheda stabile del prodotto, versioni e Paesi in cui è disponibile.
• Cronologia dell’evento con evidenze e decisioni di classificazione.
• Componenti terzi interessati e contatti dei fornitori coinvolti.
• Misure già applicate, misura correttiva prevista e rischi residui.
• Responsabile della qualità dei dati e approvatore finale della notifica.

Se il portale non è disponibile, il contatto diretto non chiude l’obbligo

Le FAQ affrontano anche l’indisponibilità temporanea della piattaforma. Il produttore deve attendere il ripristino e inviare la notifica tramite SRP. Se ritiene necessaria una comunicazione immediata, può contattare direttamente il CSIRT coordinatore, ma quel contatto non sostituisce il successivo invio nel portale.

Una procedura di continuità dovrebbe quindi conservare l’URL ufficiale, il contatto del coordinatore, l’ora dei tentativi, eventuali schermate o messaggi di errore e la persona incaricata di riprovare. Serve anche impedire che più persone inviino segnalazioni duplicate: una sola regia interna deve controllare stato, versioni e conferma finale.

La piattaforma è disponibile inizialmente in inglese. Nomi dei campi, classificazioni e sintesi tecniche vanno preparati senza improvvisare traduzioni durante l’incidente. Il glossario e i manuali ENISA sono documenti vivi: la procedura interna deve puntare alla versione corrente, non a una copia dimenticata in una cartella.

Una prova di prontezza in sette giorni, senza inviare nulla

Il collaudo non richiede una notifica di prova: la funzione volontaria non è ancora implementata e il portale va usato per eventi che rientrano negli obblighi. Si può però svolgere un’esercitazione interna su uno scenario fittizio, verificando persone, tempi e dati senza registrare una segnalazione reale.

Il primo giorno si elencano prodotti, versioni e responsabili. Il secondo si individua il possibile CSIRT coordinatore e si documenta il criterio. Il terzo si verifica EU Login con MFA dei referenti. Il quarto si simula l’arrivo di una vulnerabilità sfruttata, registrando il momento della consapevolezza. Il quinto si prepara il fascicolo delle 24 e 72 ore. Il sesto si testa l’assenza del titolare e l’indisponibilità del portale. Il settimo si trasformano le lacune in attività con proprietario e scadenza.

La visual editoriale di questo articolo è stata realizzata con il supporto di strumenti di intelligenza artificiale generativa e direzione creativa umana, senza testo o loghi di terzi. Rappresenta un segnale che attraversa controlli successivi, entra in un portale protetto e viene distribuito a più nodi coordinati: il valore non è nel singolo modulo, ma nella continuità dell’intero flusso.