Segnalare senza esporre. Il Cyber Resilience Act e la nuova governance europea delle vulnerabilità
Abstract
Dall’11 settembre 2026 trova applicazione l’articolo 14 del Regolamento (UE) 2024/2847, il Cyber Resilience Act (CRA), che introduce specifici obblighi di segnalazione a carico dei fabbricanti di prodotti con elementi digitali in presenza di vulnerabilità attivamente sfruttate o di incidenti gravi.
As of 11 September 2026, Article 14 of Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), becomes applicable, introducing specific reporting obligations for manufacturers of products with digital elements in the event of actively exploited vulnerabilities or severe incidents.
Sommario. 1. Introduzione – 2. Non tutte le vulnerabilità devono essere segnalate – 3. Le ventiquattro ore che collegano tecnica e diritto – 4. La Single Reporting Platform non è soltanto un portale – 5. Il problema della disclosure: informare può rendere più vulnerabili – 6. Una nuova forma di accountability della sicurezza.
1. Introduzione
Non si tratta ancora della piena applicazione del Regolamento, prevista per l’11 dicembre 2027. Il legislatore europeo ha però scelto di anticipare proprio il meccanismo di reporting. È un dato che merita attenzione perché mostra una precisa priorità regolatoria: prima che l’intera disciplina diventi operativa, deve già esistere una rete capace di far circolare rapidamente le informazioni relative ai rischi più rilevanti.
La novità non si esaurisce quindi nell’introduzione di un nuovo adempimento. Il vulnerability management, attività tradizionalmente affidata soprattutto a procedure tecniche e organizzative interne, entra in una sequenza disciplinata dal diritto. Diventa rilevante stabilire quando nasce l’obbligo, chi deve attivarsi, entro quale termine, verso quali soggetti e con quale livello di dettaglio. Perfino la scelta di diffondere o temporaneamente trattenere alcune informazioni viene sottoposta a regole.
2. Non tutte le vulnerabilità devono essere segnalate
Il punto di partenza è la definizione dell’evento che fa scattare l’obbligo.
Il CRA non impone al fabbricante di comunicare ogni vulnerabilità individuata nel prodotto. La soglia normativa è diversa. Una vulnerabilità è «attivamente sfruttata» quando esistono elementi attendibili che dimostrano come un soggetto malevolo l’abbia effettivamente utilizzata in un sistema senza il consenso del relativo proprietario.
La semplice scoperta di una falla, pertanto, non è sufficiente. Lo stesso Regolamento chiarisce che l’individuazione della vulnerabilità nel corso di attività svolte in buona fede (ad esempio testing, ricerca, correzione o disclosure coordinate) non deve essere automaticamente equiparata allo sfruttamento malevolo.
Diversa è la nozione di incidente grave, che guarda agli effetti prodotti sulla capacità del prodotto di proteggere disponibilità, autenticità, integrità o riservatezza di dati e funzioni sensibili o importanti. Vi rientra anche l’ipotesi in cui l’incidente consenta l’introduzione o l’esecuzione di codice malevolo nel prodotto o nei sistemi dell’utente.
La distinzione è tutt’altro che teorica. Un’organizzazione può disporre di strumenti efficaci per individuare anomalie o vulnerabilità e, nondimeno, non essere ancora in grado di stabilire rapidamente se l’evento rilevato rientri nella fattispecie normativa che impone la segnalazione. Dal punto di vista della compliance, il problema non è soltanto vedere ciò che sta accadendo, ma qualificarlo correttamente e farlo in tempi molto brevi.
3. Le ventiquattro ore che collegano tecnica e diritto
Una volta acquisita consapevolezza di una vulnerabilità attivamente sfruttata o di un incidente grave, il tempo diventa una componente essenziale dell’obbligo.
Entro 24 ore deve essere trasmesso un early warning. Entro 72 ore deve seguire una notifica contenente informazioni più complete. Le fasi successive differiscono poi a seconda che si tratti di una vulnerabilità o di un incidente: nel primo caso il rapporto finale deve essere presentato entro quattordici giorni dalla disponibilità di una misura correttiva o di mitigazione; nel secondo, entro un mese dalla notifica delle 72 ore.
L’obbligo interessa anche prodotti con elementi digitali immessi sul mercato prima dell’11 dicembre 2027. L’articolo 69 del CRA, nel disciplinare il regime transitorio, riserva infatti un trattamento specifico proprio all’articolo 14.
Non deriva invece dal Regolamento un obbligo generalizzato di riportare retroattivamente ogni vulnerabilità conosciuta prima dell’11 settembre 2026. Ciò che rileva è il momento nel quale si realizza quella consapevolezza dell’evento che il Regolamento assume come presupposto della notifica.
È soprattutto in questa scansione temporale che il diritto entra nell’incident response. Il momento in cui tecnicamente viene riconosciuto un evento potenzialmente rilevante può coincidere con l’inizio di una finestra normativa di sole ventiquattro ore. Detection, analisi tecnica, qualificazione giuridica, escalation interna e rapporto con le autorità non possono più essere trattati come compartimenti separati.
Una procedura interna che funzioni bene sul piano tecnico ma che non consenta di individuare tempestivamente chi deve assumere la decisione sulla notifica rischia, in concreto, di essere insufficiente.
4. La Single Reporting Platform non è soltanto un portale
Le notifiche vengono gestite attraverso la Single Reporting Platform (SRP) prevista dall’articolo 16 del CRA e affidata all’European Union Agency for Cybersecurity (ENISA).
Il fabbricante utilizza il punto elettronico del CSIRT designato come coordinatore nello Stato membro della propria sede principale. L’ENISA accede contestualmente alle informazioni, fatte salve le eccezioni previste dal Regolamento, mentre il CSIRT destinatario assicura la successiva circolazione verso gli altri CSIRT interessati e rende disponibili alle Autorità di Vigilanza del mercato le informazioni necessarie all’esercizio delle loro competenze.
Anche la nozione di «sede principale» è costruita in modo funzionale. Non coincide necessariamente con la sede legale dell’impresa: assume rilievo, anzitutto, lo Stato membro nel quale vengono prevalentemente adottate le decisioni relative alla cybersicurezza dei prodotti.
Ridurre la SRP a un nuovo portale europeo per le notifiche sarebbe quindi fuorviante. La piattaforma costituisce il punto di accesso a una rete istituzionale nella quale un’informazione nata all’interno dell’organizzazione del fabbricante viene resa disponibile, secondo regole prestabilite, al CSIRT, all’ENISA e all’Autorità di Vigilanza.
La vulnerabilità continua ad essere un problema tecnico da correggere, ma diventa contemporaneamente un’informazione regolata. E la disciplina non si limita a imporne la comunicazione: ne governa anche la circolazione.
5. Il problema della disclosure: informare può rendere più vulnerabili
È proprio qui che emerge uno degli aspetti più interessanti del nuovo sistema.
La conoscenza di una vulnerabilità consente di predisporre contromisure, avvisare i soggetti interessati e coordinare la risposta. La stessa informazione, tuttavia, se circola troppo presto o raggiunge destinatari non adeguatamente protetti, può rendere più semplice lo sfruttamento della falla.
Il CRA affronta espressamente questa tensione. L’articolo 16 consente, in circostanze eccezionali e per giustificati motivi di cybersicurezza, di ritardare la diffusione della notifica.
Il Regolamento delegato (UE) 2026/881 precisa i criteri da considerare. Il ritardo può essere giustificato, ad esempio, quando le informazioni contenute nella notifica sarebbero sufficienti per costruire una tecnica di exploit, soprattutto se utilizzabile anche da soggetti dotati di capacità e risorse limitate. Assume rilievo anche l’eventuale disponibilità, entro un breve arco temporale, di una misura efficace di mitigazione. Il Regolamento delegato prende inoltre in considerazione il coordinamento con procedure di coordinated vulnerability disclosure.
La questione non può essere liquidata come una semplice eccezione procedurale. Il sistema europeo deve fare due cose contemporaneamente: diffondere l’informazione necessaria a ridurre il rischio e impedire che la stessa informazione generi un rischio ulteriore.
La disclosure diventa così una forma di circolazione governata della conoscenza. Non conta soltanto ciò che viene comunicato. Contano anche il destinatario, il momento, la necessità di conoscere l’informazione e lo stato delle eventuali misure correttive.
Il problema riguarda inevitabilmente anche la piattaforma. L’articolo 16 impone all’ENISA l’adozione di misure tecniche, operative e organizzative adeguate e proporzionate per proteggere la SRP e i dati trattati. Il Regolamento delegato contempla persino la possibilità di sospendere la diffusione quando un incidente che colpisca la piattaforma faccia dubitare della riservatezza delle notifiche.
L’infrastruttura costruita per governare le vulnerabilità deve, essa stessa, essere trattata come una possibile superficie di rischio.
6. Una nuova forma di accountability della sicurezza
Vista da questa prospettiva, la novità dell’11 settembre riguarda soprattutto l’organizzazione interna del fabbricante.
Occorre poter ricostruire quando l’organizzazione ha avuto conoscenza dell’evento, come lo ha qualificato, quali informazioni erano disponibili in quel momento, chi ha assunto le decisioni e quali comunicazioni sono state effettuate. La cybersecurity viene così accompagnata da una crescente esigenza di documentabilità del processo decisionale.
Anche l’informazione agli utenti fa parte della stessa catena. Il fabbricante deve informare i soggetti interessati della vulnerabilità o dell’incidente e, quando opportuno, indicare le misure che possono adottare per mitigarne gli effetti.
Al tempo stesso, il CRA precisa che il semplice fatto di effettuare una notifica ai sensi degli articoli 14 e 15 non comporta, di per sé, un incremento della responsabilità del soggetto notificante. Una previsione comprensibile: un sistema di reporting destinato a far emergere rapidamente gli eventi più gravi non potrebbe funzionare efficacemente se la segnalazione fosse percepita essa stessa come una fonte automatica di aggravamento della posizione giuridica dell’impresa.
Le FAQ pubblicate dall’ENISA alla vigilia dell’avvio della Single Reporting Platform mostrano quanto il profilo organizzativo sia già concreto. La documentazione specifica le modalità di registrazione, i ruoli degli Assigned Representatives e il flusso delle notifiche. Nella prima versione del sistema non è inoltre disponibile un’API per automatizzare direttamente l’invio alla piattaforma, mentre le notifiche volontarie previste dall’articolo 15 saranno implementate in una fase successiva.
Il rispetto dell’articolo 14, insomma, non comincia quando qualcuno apre la Single Reporting Platform. Comincia molto prima, nella struttura interna dell’organizzazione: nelle procedure, nella distribuzione delle responsabilità e nella capacità di far dialogare competenze tecniche e giuridiche entro una finestra temporale estremamente ridotta.
L’11 settembre 2026 rappresenta perciò un passaggio rilevante nell’attuazione del Cyber Resilience Act. La gestione delle vulnerabilità viene progressivamente sottratta a una dimensione esclusivamente tecnico-organizzativa e inserita in una catena europea di conoscenza, comunicazione e responsabilizzazione.
Il successo del meccanismo non dipenderà soltanto dal numero o dalla rapidità delle notifiche. Dipenderà dalla qualità delle informazioni che circoleranno, dalla capacità degli operatori di riconoscere correttamente gli eventi rilevanti e, soprattutto, dalla possibilità di condividere la conoscenza necessaria senza amplificare il rischio che quella stessa conoscenza dovrebbe contribuire a contenere.
È su questo equilibrio operativo, più che sulla piattaforma in sé, che il nuovo sistema sarà chiamato a misurarsi.
Fonti e riferimenti essenziali
- Regolamento (UE) 2024/2847 del Parlamento europeo e del Consiglio, del 23 ottobre 2024, relativo a requisiti orizzontali di cybersicurezza per i prodotti con elementi digitali – Cyber Resilience Act, in particolare artt. 14-17, 69 e 71.
https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:32024R2847 - Commissione europea, Cyber Resilience Act – Reporting obligations, quadro degli obblighi di reporting applicabili dall’11 settembre 2026.
https://digital-strategy.ec.europa.eu/en/policies/cra-reporting - Commissione europea, Guidance on the application of the Cyber Resilience Act, C(2026) 5252, 27 luglio 2026.
https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation - ENISA, Frequently Asked Questions – CRA Single Reporting Platform, aggiornate il 10 settembre 2026.
https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions - ENISA, CRA SRP Glossary, versione 1.1, 5 settembre 2026.
https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-glossary - Regolamento delegato (UE) 2026/881 della Commissione, dell’11 dicembre 2025, relativo ai motivi di cybersicurezza che consentono di ritardare la diffusione delle notifiche.
https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:32026R0881
Di Massimo Farina
Professore Associato di Informatica Giuridica presso il Dipartimento di Ingegneria Elettrica e Elettronica (DIEE) dell’Università di Cagliari. Responsabile della protezione dei dati personali (RPD), ai sensi dell’articolo 37 del Regolamento UE 2016/679, dell’Ateneo Cagliaritano e Coordinatore del “ICT4Law&Forensics Lab”. Abilitato alle funzioni di Professore di prima fascia per il settore concorsuale 12 H3 (Filosofia del diritto – GIUR-17/A ). Avvocato del Foro di Cagliari abilitato al patrocinio davanti alle Giurisdizioni Superiori.