CRA, cosa cambia con la versione 1.3 della piattaforma di segnalazione ENISA

Dall’11 settembre 2026 i fabbricanti di prodotti con elementi digitali devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi attraverso la Single Reporting Platform (SRP) gestita da ENISA, come prevede l’articolo 14 del Cyber Resilience Act. Il 4 novembre 2026 la piattaforma è stata aggiornata alla versione 1.3 ed è stato pubblicato un nuovo manuale per gli Assigned Representatives, cioè le persone che operano sulla piattaforma per conto del fabbricante.

L’aggiornamento non introduce nuovi obblighi e non sposta le scadenze di legge. Chiarisce però diversi aspetti pratici su accessi, ruoli e gestione delle notifiche, che conviene riportare subito nelle procedure interne, perché sono proprio le procedure a fare la differenza quando il tempo a disposizione si misura in ore.

Le scadenze restano le stesse

• Un early warning entro 24 ore dal momento in cui il fabbricante viene a conoscenza della vulnerabilità sfruttata o dell’incidente grave.
• Una notifica entro 72 ore, con le informazioni generali disponibili e una prima valutazione.
• Un rapporto finale, che per le vulnerabilità attivamente sfruttate va inviato entro 14 giorni dalla disponibilità di una misura correttiva o di mitigazione e per gli incidenti gravi entro un mese dalla notifica a 72 ore.

Il tempo decorre dal momento in cui il fabbricante viene a conoscenza del problema, quindi è importante che le procedure interne stabiliscano con chiarezza chi registra quel momento e come.

Cosa chiarisce il nuovo manuale

• L’accesso alla piattaforma avviene con EU Login e autenticazione a più fattori, e gli account sono personali, quindi non si possono condividere credenziali tra colleghi.
• Il Primary AR, una volta validata la sua associazione con il fabbricante, può invitare uno o più Secondary AR, che garantiscono continuità anche quando il referente principale non è disponibile.
• L’invito al Secondary AR ha una durata limitata, che il manuale indica in sette giorni, quindi va accettato e completato per tempo.
• La validazione dell’associazione tra Assigned Representative e fabbricante avviene in parallelo alla segnalazione e non impedisce di inviare notifiche, che restano possibili fino a un massimo di venti prima che la verifica diventi obbligatoria.
• Un Secondary AR può chiedere di assumere il ruolo di Primary, con l’approvazione del CSIRT competente, per esempio quando il referente principale lascia l’azienda.
• Il CSIRT di riferimento si sceglie in fase di registrazione, e una scelta sbagliata può rendere non valida la notifica.

Assigned Representative non vuol dire rappresentante autorizzato

È facile confondere i termini. L’Assigned Representative è un ruolo operativo all’interno della piattaforma, cioè la persona che materialmente invia le notifiche. Il rappresentante autorizzato previsto dall’articolo 18 del CRA è invece una figura giuridica che agisce per conto del fabbricante nell’Unione. Possono coincidere, ma non è detto, e i documenti interni dovrebbero indicarlo in modo esplicito.

Tre casi da non confondere

Uno degli errori più frequenti è trattare allo stesso modo eventi che il CRA distingue nettamente. Runbook e procedure dovrebbero separare con chiarezza tre situazioni.

• Incidente grave sul prodotto, cioè un evento che compromette, o può compromettere, la capacità del prodotto di proteggere disponibilità, autenticità, integrità o riservatezza di dati e funzioni. Va segnalato secondo l’articolo 14.
• Vulnerabilità attivamente sfruttata, per la quale esistono prove affidabili che qualcuno l’abbia sfruttata senza autorizzazione. Anche questa va segnalata secondo l’articolo 14.
• Vulnerabilità ordinaria, scoperta internamente o segnalata da un ricercatore ma senza evidenza di sfruttamento. Non rientra nell’obbligo di notifica dell’articolo 14 e si gestisce con il normale processo di gestione delle vulnerabilità e di divulgazione coordinata.

Una vulnerabilità ordinaria può diventare attivamente sfruttata in qualsiasi momento, per esempio quando compare un exploit in circolazione. Il processo deve prevedere una rivalutazione continua e indicare chi decide il passaggio da un caso all’altro.

Cosa aggiornare nei documenti CRA

• Runbook di segnalazione, con i passi operativi sulla piattaforma, i modelli per early warning, notifica e rapporto finale e le informazioni da raccogliere in ogni fase.
• Matrice RACI, che indichi chi è responsabile, chi approva, chi va consultato e chi informato tra PSIRT e team di prodotto, SOC, compliance, legale e Assigned Representative.
• Catena di escalation, con tempi e contatti alternativi, così che le 24 ore non vengano consumate cercando la persona giusta.
• Gestione degli account, con almeno due Assigned Representative attivi, MFA configurata e una verifica periodica che gli accessi funzionino.
• Registro delle decisioni, che documenti quando l’azienda è venuta a conoscenza dell’evento, come lo ha classificato e perché.

Un esempio di flusso

1. Il SOC o il team di prodotto rileva un’anomalia o riceve una segnalazione e apre un caso.
2. Il PSIRT valuta se si tratta di un incidente grave, di una vulnerabilità attivamente sfruttata o di una vulnerabilità ordinaria e registra l’orario di presa di conoscenza.
3. Se il caso rientra nell’articolo 14, compliance e Assigned Representative preparano l’early warning e lo inviano entro 24 ore.
4. Entro 72 ore si completa la notifica con le informazioni disponibili e una prima valutazione.
5. Il team di prodotto sviluppa la correzione o la mitigazione, mentre il PSIRT aggiorna il CSIRT e, se necessario, gli utilizzatori.
6. Si invia il rapporto finale nei tempi previsti e si aggiorna il registro con le lezioni apprese.

In sintesi

La versione 1.3 della piattaforma non cambia le regole, ma rende più chiaro come applicarle. È il momento giusto per verificare che account, ruoli e procedure siano pronti, perché una segnalazione ben fatta dipende molto più dall’organizzazione interna che dallo strumento.

Per un quadro completo degli obblighi consulta la pagina su CRA e Regolamento Macchine e l’articolo sul Regolamento Macchine 2027. Se vuoi impostare o rivedere i processi di segnalazione, contattaci e possiamo integrarli con il presidio del nostro SOC.