Fabbricanti e gestori OSS verso la Single Reporting Platform di ENISA
Il regolamento (UE) 2024/2847, noto come Cyber Resilience Act (CRA), introduce a decorrere dall’11 settembre 2026 l’obbligo per i fabbricanti di prodotti con elementi digitali e per i gestori di software libero e open source di segnalare vulnerabilità attivamente sfruttate e incidenti gravi attraverso la Single Reporting Platform (SRP) di ENISA. Si tratta di un’applicazione scaglionata della disciplina europea: mentre i requisiti essenziali di cibersicurezza divengono applicabili dal 11 dicembre 2027, il flusso informativo verso le autorità nazionali è anticipato. Il documento fattuale pubblicato da ENISA chiarisce che la piattaforma unica rappresenta il punto di raccordo centrale per comunicare una sola volta a tutti i destinatari istituzionali, secondo una logica di diffusione automatica verso i CSIRT degli Stati membri interessati.
Chi è obbligato: la nozione di fabbricante e di gestore OSS
L’obbligo grava su chiunque immetta sul mercato dell’Unione un prodotto con elementi digitali assumendone la responsabilità commerciale, indipendentemente da chi ne abbia materialmente sviluppato il codice. Rientra nella qualifica di fabbricante anche l’impresa che commissioni a terzi lo sviluppo di un software e lo distribuisca con il proprio marchio. I gestori di software libero e open source — tipicamente fondazioni e organizzazioni senza scopo di lucro — sono soggetti a obblighi alleggeriti e proporzionati, limitati alla misura del loro coinvolgimento nello sviluppo di prodotti con elementi digitali destinati a un uso commerciale. Il criterio di collegamento è geografico: si applica il CRA ai prodotti resi disponibili sul mercato europeo, indipendentemente dalla sede del fabbricante; i fabbricanti di Paesi terzi possono designare un rappresentante autorizzato.
Gli eventi da segnalare: vulnerabilità attive e incidenti gravi
Due sono le tipologie di eventi soggetti a notifica. La prima è costituita dalle vulnerabilità attivamente sfruttate, definite come difetti noti e attualmente oggetto di sfruttamento da parte di attori malevoli: non la vulnerabilità in sé, ma la circostanza della sua exploitazione attiva genera l’obbligo. La seconda è costituita dagli incidenti gravi, cioè eventi che incidono gravemente sulla sicurezza del prodotto in termini di compromissione di disponibilità, autenticità, integrità o riservatezza. L’articolo 14, paragrafo 5, del CRA specifica i criteri di valutazione della gravità, ai quali deve essere sottoposta ogni segnalazione. La qualificazione dell’evento richiede analisi tecnica preventiva: un incidente grave per il prodotto presso gli utilizzatori può non incidere sulla sicurezza dell’infrastruttura del fabbricante, e viceversa. Si consiglia pertanto la costruzione di una matrice di gravità dedicata, distinta da quella utilizzata per gli incidenti di sicurezza aziendale.
I termini di segnalazione: ventiquattro ore, settantadue ore e oltre
Il processo di notifica si articola in tre fasi temporali. L’allerta precoce (early warning) deve essere trasmessa entro ventiquattro ore dalla conoscenza dell’evento, con contenuto minimale destinato ad attivare il sistema di allerta europeo. La notifica tecnica, trasmessa entro settantadue ore, contiene le informazioni generali sull’evento, una valutazione iniziale e i dettagli dei prodotti e versioni interessati, nonché le misure di mitigazione disponibili. La relazione finale ha termine differenziato: per le vulnerabilità, deve essere trasmessa non oltre quattordici giorni dalla disponibilità della misura correttiva; per gli incidenti gravi, entro un mese dalla notifica intermedia. Quest’ultima asimmetria ha implicazione significativa: il termine per le vulnerabilità è agganciato a un evento futuro e non prevedibile, il che richiede un presidio duraturo e un collegamento formale tra il rilascio della patch e la decorrenza dell’obbligo.
Il CSIRT destinatario e la diffusione automatica
Il CSIRT nazionale al quale trasmettere la segnalazione è determinato dal luogo di stabilimento principale del fabbricante. Per le imprese italiane il destinatario è il CSIRT Italia, presso l’Agenzia per la cybersicurezza nazionale. Il CSIRT ricevente diffonde automaticamente la notifica agli altri CSIRT degli Stati membri nei quali il prodotto è disponibile e la mette a disposizione di ENISA, consentendo alle autorità di vigilanza del mercato di esercitare i propri compiti. Questa architettura di diffusione automatica realizza l’obiettivo della segnalazione unica: il fabbricante non moltiplica le comunicazioni verso i ventisette CSIRT, ma trasmette una volta sola. La riservatezza delle informazioni è protetta mediante misure di sicurezza della piattaforma; il legislatore europeo ha previsto altresì l’istituto del differimento della diffusione in circostanze eccezionali, secondo le condizioni specificate dal regolamento delegato (UE) 2026/881.
Il coordinamento con la direttiva NIS2 e il GDPR
La struttura temporale della segnalazione CRA — ventiquattro ore, settantadue ore, relazione finale — riproduce consapevolmente lo schema della direttiva (UE) 2022/2555 (NIS2), recepita in Italia con il decreto legislativo 4 settembre 2024, n. 138. I due regimi hanno però oggetto e presupposti diversi. La NIS2 impone obblighi ai soggetti qualificati come essenziali o importanti e riguarda incidenti che incidono sulla fornitura dei servizi; il CRA impone obblighi a fabbricanti in quanto tali, indipendentemente dal settore e dalla dimensione, e riguarda eventi di sicurezza del prodotto immesso sul mercato. Un’impresa manifatturiera non soggetta a NIS2 può essere pienamente obbligata dal CRA per il software embedded nei suoi prodotti. Merita segnalazione che la segnalazione ai sensi dell’articolo 14 del CRA non sostituisce la notificazione della violazione di dati personali prevista dagli articoli 33 e 34 del GDPR: un medesimo fatto storico — ad esempio, lo sfruttamento di una vulnerabilità in un dispositivo medico connesso che consenta accesso a dati relativi alla salute — può integrare entrambi i presupposti, con conseguente obbligo di segnalazione doppia verso autorità diverse. I termini di decorrenza possono inoltre non coincidere: il GDPR decorre dal momento della conoscenza della violazione, il CRA dal momento della conoscenza dello sfruttamento attivo o dell’incidente grave.
Questioni critiche e profili di gestione
Alcuni nodi rimangono aperti. Il primo riguarda il momento della “conoscenza” dell’evento: la formula riecheggia l’articolo 33 del GDPR, ma il termine ridotto a ventiquattro ore (un terzo rispetto al GDPR) riduce lo spazio per la verifica preliminare. Si ritiene che la conoscenza si radichi nel momento in cui l’organizzazione ha ragionevole certezza dell’evento, non nel momento della piena contezza tecnica; ciò impone però un presidio continuativo dei canali di ricezione, con reperibilità definita anche al di fuori dell’orario ordinario.
Il secondo profilo attiene all’ampliamento della platea di soggetti informati: la diffusione automatica a tutti i CSIRT europei e ad ENISA accresce il rischio di divulgazione non voluta. Il legislatore ha previsto il differimento della diffusione, ma l’effettività dell’istituto dipenderà dalla tempestività con cui i CSIRT valutino le richieste di differimento.
Il terzo profilo riguarda la moltiplicazione degli obblighi di notifica: il CRA risolve la moltiplicazione interna (unica trasmissione verso tutti i destinatari CRA), ma non quella esterna (segnalazione CRA, NIS2, GDPR, eventualmente discipline settoriali). L’unico presidio efficace consiste in una procedura unica di gestione degli eventi che raccolga i fatti in modo standardizzato e attivi i diversi canali di notifica secondo una matrice predefinita.
Il quarto profilo attiene al contenuto delle segnalazioni: le informazioni tecniche su vulnerabilità e architetture costituiscono dati commerciali riservati, e va mantenuta la qualificazione nelle comunicazioni verso le autorità. Inoltre, le segnalazioni possono contenere dati personali (referenti del fabbricante, ricercatori, utenti compromessi); si suggerisce l’applicazione rigorosa del principio di minimizzazione, trasmettendo dati strettamente necessari e ricorrendo, ove possibile, a forme aggregate o anonime.
Cosa devono fare le imprese
Accertare l’applicabilità: verificare se l’impresa riveste la qualifica di fabbricante di prodotti con elementi digitali resi disponibili sul mercato dell’Unione, formalizzando l’esito in un documento di qualificazione prodotto per prodotto.
Censire i prodotti e i mercati: mantenere un inventario aggiornato dei prodotti con elementi digitali, delle versioni supportate, dei mercati di commercializzazione e dei componenti di terzi integrati, includendo la distinta base del software (SBOM).
Individuare il CSIRT competente: determinare preventivamente, sulla base del luogo di stabilimento principale, il CSIRT nazionale destinatario della segnalazione, formalizzando la scelta in una tabella di corrispondenza nei gruppi con più entità fabbricanti.
Registrarsi sulla piattaforma: completare la registrazione sulla Single Reporting Platform di ENISA, individuare gli utenti abilitati, definire deleghe e supplenze, verificare periodicamente le credenziali di accesso.
Formalizzare la procedura di rilevazione: definire i canali di ricezione delle segnalazioni, i tempi di escalation, i criteri di qualificazione dell’evento come vulnerabilità attiva o incidente grave, registrando il momento della prima ricezione con orario.
Costruire una matrice di gravità: tradurre i criteri dell’articolo 14, paragrafo 5, del CRA in una matrice applicabile alle caratteristiche specifiche dei prodotti dell’impresa, distinta dalle matrici di gravità aziendale e da quella del GDPR.
Predisporre modelli di segnalazione: elaborare in anticipo bozze di allerta precoce, notifica e relazione finale, in lingua inglese e nella lingua richiesta dal CSIRT, coerenti con i campi della piattaforma.
Organizzare la reperibilità: definire turni che coprano fine settimana e chiusure aziendali, meccanismi di allerta automatica e procedure di attivazione rapida del gruppo di valutazione.
Collegare il rilascio delle patch al termine di reporting: istituire un flusso di lavoro che colleghi il processo di rilascio delle correzioni al processo di compliance, generando automaticamente la relazione finale entro quattordici giorni dalla pubblicazione della patch.
Integrare il DPO nel flusso informativo: il Data Protection Officer deve valutare in parallelo se l’evento integri una violazione di dati personali ai sensi dell’articolo 4, punto 12, del GDPR, con segnalazione al Garante entro settantadue ore dal momento della conoscenza.
Rivedere la contrattualistica di fornitura: introdurre negli accordi con fornitori di componenti software e hardware obblighi di comunicazione tempestiva di vulnerabilità e incidenti, con termini interni compatibili con quelli di legge, obblighi di cooperazione informativa e presidi di riservatezza.
Definire la comunicazione agli utenti: stabilire una procedura per l’informazione degli utenti interessati dall’evento, con criteri documentati su timing e contenuto, coordinati con la strategia di disclosure coordinata.
Condurre esercitazioni: sottoporre il processo a simulazioni periodiche, verificando il rispetto del termine di ventiquattro ore anche in scenari di ricezione in orario non lavorativo, verbalizzando gli esiti e utilizzandoli per la revisione delle procedure.
Integrare nel sistema di gestione: inserire gli adempimenti CRA nel sistema di gestione della sicurezza delle informazioni, con indicatori, responsabilità formalizzate e inclusione nel piano di audit interno.
Conclusioni e prospettive
L’11 settembre 2026 rappresenta il momento in cui l’Agenzia europea per la cibersicurezza renderà operativa la Single Reporting Platform e in cui i fabbricanti dovranno iniziare a segnalare vulnerabilità attivamente sfruttate e incidenti gravi. Il factsheet di ENISA non introduce obblighi nuovi rispetto al testo del regolamento, ma conferma il cronoprogramma operativo e la centralità sistematica che il legislatore attribuisce al flusso informativo. La costruzione preventiva di procedure interne, criteri di qualificazione e presidi organizzativi è la principale attività preparatoria che le imprese possono utilmente compiere nei mesi precedenti. Restano aperte alcune questioni specifiche — il contenuto esatto dei campi della piattaforma, i criteri di valutazione del differimento della diffusione, il coordinamento operativo tra CRA e NIS2 presso il CSIRT nazionale, l’assetto istituzionale di vigilanza — sulle quali la chiarezza delle autorità competenti avrà effetto determinante sull’effettività del regime.
L’approfondimento completo di questo articolo è disponibile su 01magazine.it.
