Dall’11 settembre 2026 è divenuto applicabile uno dei primi blocchi di obblighi sostanziali previsti dal Regolamento (UE) 2024/2847 – Cyber Resilience Act (CRA): i fabbricanti di prodotti con elementi digitali devono ora notificare le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza dei prodotti secondo le tempistiche e le modalità previste dall’art. 14 del Regolamento. Contestualmente, ENISA ha reso operativa la CRA Single Reporting Platform (SRP), il punto unico europeo attraverso il quale devono essere effettuate le notifiche.
Si tratta di una tappa particolarmente rilevante nell’attuazione progressiva del CRA. Il Regolamento è entrato in vigore il 10 dicembre 2024 e sarà pienamente applicabile dall’11 dicembre 2027, ma il legislatore europeo ha anticipato l’applicazione di alcune disposizioni: dopo le norme relative agli organismi di valutazione della conformità, applicabili dall’11 giugno 2026, dall’11 settembre 2026 sono operative le disposizioni dell’art. 14 sugli obblighi di reporting.
La novità riguarda direttamente i fabbricanti di prodotti con elementi digitali, vale a dire, in termini generali, i soggetti che immettono sul mercato dell’Unione con il proprio nome o marchio prodotti hardware o software dotati di una connessione logica o fisica, diretta o indiretta, a un dispositivo o a una rete. Il campo di applicazione comprende quindi un panorama estremamente ampio: dispositivi IoT, apparecchiature connesse, software, applicazioni, sistemi operativi, componenti hardware e software, dispositivi industriali e numerose altre categorie di prodotti digitali.
Un elemento di particolare rilievo è che gli obblighi di notifica si applicano anche ai prodotti con elementi digitali già messi a disposizione sul mercato dell’Unione prima dell’11 dicembre 2027. Non è quindi corretto ritenere che le imprese possano attendere la piena applicabilità del CRA prima di adeguare le proprie procedure di vulnerability e incident management: per il reporting previsto dall’art. 14, l’obbligo è già operativo.
Quali eventi devono essere notificati
Il CRA distingue due categorie di eventi soggetti a notifica obbligatoria.
La prima è costituita dalle “vulnerabilità attivamente sfruttate” (actively exploited vulnerabilities). Non è sufficiente, pertanto, la mera esistenza di una vulnerabilità o la sua astratta possibilità di sfruttamento. Ai sensi del Regolamento, è attivamente sfruttata la vulnerabilità rispetto alla quale esistano evidenze affidabili che un soggetto malevolo l’abbia effettivamente sfruttata in un sistema senza l’autorizzazione del titolare del sistema.
La seconda categoria riguarda gli incidenti gravi che incidono sulla sicurezza di un prodotto con elementi digitali. L’incidente è considerato grave quando incide negativamente, o è in grado di incidere negativamente, sulla capacità del prodotto di proteggere la disponibilità, autenticità, integrità o riservatezza di dati o funzioni sensibili o importanti; oppure quando ha comportato, o può comportare, l’introduzione o l’esecuzione di codice malevolo nel prodotto o nei sistemi informativi e di rete di un suo utilizzatore.
La distinzione è importante anche sotto il profilo operativo: non ogni vulnerabilità deve essere notificata obbligatoriamente ai sensi dell’art. 14, ma occorre che ricorrano i requisiti dell’“active exploitation”; analogamente, non ogni anomalia o evento di sicurezza integra automaticamente un “severe incident”. Le imprese devono quindi essere in grado di qualificare rapidamente l’evento alla luce delle definizioni regolamentari.
Le notifiche seguono una tempistica particolarmente stringente
Il sistema delineato dal CRA prevede una sequenza di comunicazioni successive.
Per una vulnerabilità attivamente sfruttata, il fabbricante deve trasmettere:
un early warning entro 24 ore dal momento in cui ne viene a conoscenza;
una notifica della vulnerabilità entro 72 ore, contenente, ove disponibili, informazioni generali sul prodotto interessato, sulla natura dell’exploit e della vulnerabilità, nonché sulle misure correttive o di mitigazione già adottate e su quelle che possono essere adottate dagli utenti;
una relazione finale entro 14 giorni dalla disponibilità di una misura correttiva o di mitigazione, contenente almeno la descrizione della vulnerabilità, la sua gravità e il relativo impatto, le eventuali informazioni disponibili sull’attore malevolo e i dettagli dell’aggiornamento di sicurezza o delle altre misure correttive predisposte.
Per gli incidenti gravi, il fabbricante deve invece inviare:
un early warning entro 24 ore dalla conoscenza dell’incidente, indicando almeno se vi sia il sospetto che esso derivi da condotte illecite o malevole;
una notifica entro 72 ore, comprendente, ove disponibili, informazioni sulla natura dell’incidente, una prima valutazione e le misure correttive o di mitigazione;
una relazione finale entro un mese dalla notifica delle 72 ore, con una descrizione dettagliata dell’incidente, della sua gravità e del suo impatto, la probabile tipologia di minaccia o root cause e le misure di mitigazione adottate o ancora in corso.
Il momento della “awareness” del fabbricante assume quindi un ruolo decisivo, poiché da esso iniziano a decorrere termini molto brevi. Le imprese devono essere in grado non soltanto di individuare gli eventi rilevanti, ma anche di documentare quando l’organizzazione ne abbia acquisito conoscenza e di attivare immediatamente il processo interno di escalation.
Un’unica notifica attraverso la piattaforma europea di ENISA
Per evitare la frammentazione delle comunicazioni tra più autorità nazionali, l’art. 16 del CRA ha previsto una Single Reporting Platform, sviluppata, gestita e mantenuta da ENISA e operativa dall’11 settembre 2026.
Il fabbricante presenta la notifica attraverso l’endpoint del CSIRT designato come coordinatore nello Stato membro in cui si trova il proprio stabilimento principale nell’Unione; la notifica è contemporaneamente accessibile a ENISA e viene successivamente condivisa, secondo il sistema previsto dal Regolamento, con gli altri CSIRT interessati. La SRP realizza quindi un meccanismo di “report once”, evitando che l’impresa debba effettuare separatamente la medesima notifica in tutti gli Stati membri nei quali il prodotto è disponibile.
Ai fini del CRA, lo stabilimento principale è individuato nello Stato membro nel quale sono prevalentemente assunte le decisioni relative alla cybersecurity dei prodotti con elementi digitali. Se tale Stato non può essere individuato, rileva lo stabilimento con il maggior numero di dipendenti nell’Unione. Il Regolamento stabilisce inoltre specifici criteri per i fabbricanti che non dispongano di uno stabilimento principale nell’UE, facendo riferimento, in successione, allo Stato membro del rappresentante autorizzato, dell’importatore, del distributore o, in ultima istanza, a quello nel quale si trova il maggior numero di utenti dei prodotti interessati.
Non basta notificare le autorità: devono essere informati anche gli utenti
L’art. 14 prevede un ulteriore obbligo di particolare rilevanza. Quando viene a conoscenza di una vulnerabilità attivamente sfruttata o di un incidente grave, il fabbricante deve informare gli utenti interessati e, ove opportuno, tutti gli utenti del prodotto, comunicando anche, quando necessario, le misure correttive o di mitigazione che essi possono adottare per ridurne l’impatto.
La gestione dell’evento non può quindi essere considerata un processo esclusivamente interno o limitato alle interlocuzioni con le autorità. Occorre predisporre procedure che coordinino technical incident response, valutazione legale, reporting regolamentare e comunicazione agli utenti, assicurando al contempo coerenza e tempestività delle informazioni diffuse.
Attenzione anche a importatori, distributori e modifiche sostanziali
Gli obblighi dell’art. 14 sono indirizzati in primo luogo ai fabbricanti. Tuttavia, il CRA prevede situazioni nelle quali importatori o distributori assumono essi stessi la posizione del fabbricante: ciò accade, ad esempio, quando immettono il prodotto sul mercato con il proprio nome o marchio oppure effettuano una modifica sostanziale di un prodotto già immesso sul mercato. Analoga conseguenza è prevista per altri soggetti che effettuino una modifica sostanziale e rendano successivamente disponibile il prodotto sul mercato.
Le imprese che operano lungo la supply chain dovrebbero quindi verificare attentamente la propria qualificazione giuridica, senza presumere che gli obblighi di reporting riguardino esclusivamente il produttore tecnologico originario.
Un regime specifico è invece previsto per gli open-source software stewards: gli obblighi di reporting ad essi riferiti dall’art. 24, par. 3, diventeranno applicabili dall’11 dicembre 2027 e non dall’11 settembre 2026.
Cosa devono fare ora le imprese
L’entrata in applicazione dell’art. 14 richiede un adeguamento organizzativo immediato. I fabbricanti interessati dovrebbero anzitutto mappare i prodotti con elementi digitali ricadenti nel perimetro del CRA e individuare con certezza il soggetto responsabile del reporting all’interno del gruppo societario.
Sul piano operativo, è opportuno predisporre o aggiornare una specifica CRA vulnerability and incident reporting procedure, integrandola con i processi esistenti di vulnerability management, product security e incident response. Tale procedura dovrebbe consentire di:
individuare rapidamente quando una vulnerabilità possa qualificarsi come “actively exploited” e quando un incidente raggiunga la soglia di “severe incident”;
registrare con precisione il momento in cui il fabbricante acquisisce conoscenza dell’evento;
garantire un’escalation immediata verso le funzioni cybersecurity, legal, compliance e product;
raccogliere entro termini estremamente brevi le informazioni necessarie per le notifiche a 24 e 72 ore;
individuare preventivamente i soggetti autorizzati a operare sulla Single Reporting Platform;
coordinare le notifiche alle autorità con le comunicazioni agli utenti interessati;
assicurare la tracciabilità delle misure correttive, degli aggiornamenti di sicurezza e delle attività di mitigazione adottate.
Particolare attenzione deve essere riservata anche ai rapporti contrattuali lungo la supply chain. Un fabbricante può infatti dipendere da fornitori di componenti hardware e software per venire tempestivamente a conoscenza di una vulnerabilità o per acquisire le informazioni tecniche necessarie alla notifica. Contratti, vulnerability disclosure clauses, obblighi di cooperation ed escalation dovrebbero pertanto essere riesaminati alla luce delle tempistiche imposte dal CRA.
Occorre inoltre coordinare il nuovo processo con gli eventuali obblighi paralleli di notifica derivanti da altre normative, quali la Direttiva NIS2 e le relative norme nazionali di attuazione, il GDPR in presenza di una violazione di dati personali e, per i soggetti del settore finanziario, il DORA. La qualificazione dell’evento, i destinatari, le soglie e le tempistiche possono differire: l’esistenza della Single Reporting Platform del CRA non elimina automaticamente gli obblighi previsti da altri regimi normativi.
L’11 settembre 2026 segna quindi il passaggio del Cyber Resilience Act da un quadro normativo ancora prevalentemente preparatorio a un sistema che impone obblighi immediatamente operativi e caratterizzati da termini di reazione estremamente brevi. Per i fabbricanti di hardware e software, la capacità di rilevare, qualificare, documentare e notificare tempestivamente vulnerabilità e incidenti diventa già oggi una componente essenziale della compliance europea in materia di cybersecurity, oltre un anno prima della piena applicabilità del CRA.
