News - 15/09/2026

Cyber Resilience Act: dall’11 settembre 2026 sono scattati gli obblighi di segnalazione

Il Regolamento (UE) 2024/2847 anticipa una parte essenziale dei propri obblighi, tra cui il termine di 24 ore per vulnerabilità attivamente sfruttate, nuova piattaforma unica europea per incidenti gravi, la sicurezza informatica come qualità del prodotto

Dall’11 settembre 2026 è diventata applicabile una delle componenti più significative del Cyber Resilience Act – CRA, il Regolamento (UE) 2024/2847 sui requisiti orizzontali di cybersicurezza per i prodotti con elementi digitali.

Il Regolamento sarà pienamente applicabile dall’11 dicembre 2027, ma il legislatore europeo ha previsto un’applicazione anticipata degli obblighi di segnalazione disciplinati dall’articolo 14, relativi alle vulnerabilità attivamente sfruttate e agli incidenti gravi aventi un impatto sulla sicurezza dei prodotti con elementi digitali.  

Per le imprese, la capacità di notificare tempestivamente presuppone già oggi conoscenza dei prodotti, delle componenti e della supply chain, procedure di vulnerability management e una chiara attribuzione delle responsabilità.

La scadenza dell’11 settembre assume una rilevanza che va oltre l’introduzione di un nuovo adempimento. Il termine di 24 ore dalla conoscenza dell’evento previsto per la prima segnalazione costituisce infatti una verifica concreta della capacità dell’impresa di conoscere ciò che accade ai propri prodotti, ricostruirne tempestivamente le componenti interessate, acquisire informazioni dalla propria catena di fornitura, classificare l’evento e attivare una procedura decisionale sufficientemente rapida. In altri termini, non è possibile notificare in 24 ore ciò che l’organizzazione non è strutturata per conoscere in 24 ore. 

È questa una delle trasformazioni più rilevanti introdotte dal CRA: la cybersicurezza tende progressivamente a uscire dalla dimensione della funzione tecnica separata per entrare nella qualità industriale del prodotto e nei processi attraverso i quali esso viene progettato, sviluppato, immesso sul mercato e mantenuto durante il proprio ciclo di vita.

2. Il quadro temporale: cosa cambia dall’11 settembre 2026

Il Cyber Resilience Act è entrato in vigore il 10 dicembre 2024. La disciplina segue tuttavia un calendario progressivo.

Dall’11 giugno 2026 sono divenute applicabili le disposizioni del Capo IV relative alla notifica degli organismi di valutazione della conformità; dall’11 settembre 2026 trovano applicazione gli obblighi dell’articolo 14; dall’11 dicembre 2027 troverà applicazione, salvo le disposizioni anticipate, il complesso della disciplina. La distinzione è importante: dall’11 settembre 2026 non entra ancora integralmente in applicazione il CRA, ma diventa già operativo il suo sistema obbligatorio di reporting dell’art. 14; la piena applicazione resta fissata all’11 dicembre 2027. 

Inoltre, secondo i chiarimenti della Commissione europea, gli obblighi di segnalazione riguardano tutti i prodotti con elementi digitali messi a disposizione sul mercato dell’Unione, compresi quelli immessi sul mercato prima dell’11 dicembre 2027.  

3. Vulnerabilità attivamente sfruttate: 24 ore, 72 ore e rapporto finale

L’articolo 14, paragrafi 1 e 2, del Regolamento (UE) 2024/2847 disciplina la notifica delle vulnerabilità attivamente sfruttate.

Quando viene a conoscenza di una vulnerabilità di questo tipo, il fabbricante deve effettuare una sequenza articolata di comunicazioni. Le 24 ore non esauriscono la notifica. Sono il termine dell’early warning; seguono la notifica delle 72 ore e il rapporto finale. 

La prima è un early warning, da trasmettere senza indebito ritardo e comunque entro 24 ore dal momento in cui il fabbricante è venuto a conoscenza della vulnerabilità.

Segue, salvo che le informazioni siano già state fornite, una notifica entro 72 ore, contenente le informazioni disponibili sul prodotto interessato, sulla natura generale dell’exploit e della vulnerabilità, nonché sulle misure correttive o di mitigazione adottate e su quelle eventualmente utilizzabili dagli utenti.

Infine, deve essere presentato un rapporto finale entro 14 giorni dalla disponibilità di una misura correttiva o di mitigazione, comprendente, tra l’altro, la descrizione della vulnerabilità, la sua gravità e il relativo impatto, le eventuali informazioni disponibili sull’attore malevolo e i dettagli relativi all’aggiornamento di sicurezza o alle altre misure adottate.  

La sequenza temporale può quindi essere sintetizzata come segue:

Il sistema è costruito, dunque, per consentire una progressiva acquisizione delle informazioni: il fabbricante non deve necessariamente conoscere ogni elemento dell’evento entro le prime 24 ore, ma deve essere organizzativamente in grado di riconoscerne tempestivamente l’esistenza e di avviare il processo di segnalazione.

4. Gli incidenti gravi aventi impatto sulla sicurezza del prodotto

Un analogo meccanismo è previsto dall’articolo 14, paragrafi 3 e 4, per gli incidenti gravi aventi un impatto sulla sicurezza di un prodotto con elementi digitali.

Anche in questo caso è previsto un primo avviso entro 24 ore dalla conoscenza dell’incidente e una successiva notifica entro 72 ore. Per gli incidenti gravi, il rapporto finale deve essere presentato entro un mese dalla notifica delle 72 ore.  

La differenza tra vulnerabilità e incidente è quindi rilevante anche sotto il profilo della scansione temporale del reporting finale.

Il termine delle 24 ore deve soprattutto essere letto come un requisito organizzativo. La tempestività della comunicazione dipende infatti dalla capacità di fare arrivare l’informazione dal livello tecnico al soggetto incaricato di valutarla e, da questo, al processo di notifica.

Una vulnerabilità conosciuta da uno sviluppatore, da un fornitore o da una funzione tecnica, ma che non entra tempestivamente nel circuito decisionale dell’impresa, rischia di trasformarsi in un problema di governance prima ancora che di cybersecurity.

5. La Single Reporting Platform di ENISA

Le notifiche sono effettuate attraverso la Single Reporting Platform – SRP, istituita ai sensi dell’articolo 16 del CRA e gestita da ENISA.

La piattaforma diviene operativa in concomitanza con l’applicazione degli obblighi di reporting dell’11 settembre 2026 ed è destinata a costituire il punto unico attraverso il quale i fabbricanti adempiono agli obblighi relativi alle vulnerabilità attivamente sfruttate e agli incidenti gravi.  

Single Reporting Platform – ENISA⁠

La notifica viene indirizzata al CSIRT designato come coordinatore dello Stato membro nel quale il fabbricante ha il proprio stabilimento principale nell’Unione ed è resa simultaneamente accessibile a ENISA, secondo il sistema previsto dagli articoli 14 e 16 e fatte salve le particolari circostanze eccezionali disciplinate dal Regolamento.  

ENISA ha inoltre pubblicato indicazioni operative, FAQ e documentazione tecnica per l’utilizzo della piattaforma.

FAQ ENISA sulla Single Reporting Platform⁠

6. Termine di 24 ore e “stress test” della governance aziendale

L’elemento maggiormente significativo della nuova disciplina è probabilmente proprio la brevità del primo termine.

Ventiquattro ore sono sufficienti per effettuare una segnalazione preliminare, ma possono essere pochissime per un’organizzazione che non abbia preventivamente costruito i propri flussi informativi.

Per rispettare il termine occorre infatti essere almeno in grado di:

• identificare i prodotti interessati e le relative versioni;
• conoscere, con un livello adeguato di dettaglio, le componenti software e hardware rilevanti;
• ricevere tempestivamente informazioni dai fornitori;
• disporre di processi per l’individuazione e la gestione delle vulnerabilità;
• stabilire chi debba qualificare l’evento e chi sia responsabile della notifica;
• assicurare l’escalation delle informazioni rilevanti verso le funzioni aziendali competenti e, quando necessario, verso il vertice;
• documentare le decisioni assunte e assicurare continuità tra rilevazione, mitigazione, comunicazione e remediation.

Il CRA, pertanto, non richiede soltanto velocità, ma presuppone conoscenza. La possibilità di ricostruire le dipendenze tecnologiche del prodotto e di individuare rapidamente una componente vulnerabile diventa parte integrante della capacità di resilienza dell’organizzazione.

7. Cybersecurity aziendale e cybersecurity del prodotto

Il CRA introduce inoltre una trasformazione prospettica rispetto alla tradizionale gestione della sicurezza informatica.

Il suo oggetto non è principalmente la sicurezza dell’organizzazione in quanto tale, ma la sicurezza dei prodotti con elementi digitali.

L’Allegato I del Regolamento stabilisce, tra l’altro, che i prodotti debbano essere progettati, sviluppati e prodotti in modo da garantire un livello di cybersicurezza adeguato ai rischi e disciplina specificamente la gestione delle vulnerabilità dei prodotti e delle relative componenti.  

Con la piena applicazione del Regolamento, quindi, la sicurezza dovrà essere considerata lungo il ciclo di vita del prodotto.

È il passaggio dalla cybersecurity considerata prevalentemente come protezione dell’infrastruttura aziendale alla security by design e by default incorporata nel prodotto.

La vulnerabilità non costituisce più soltanto un problema tecnico da correggere dopo la commercializzazione: la capacità di prevenirla, individuarla, gestirla e comunicarla diventa progressivamente una caratteristica della qualità stessa del prodotto.

8. CRA, NIS2, AI Act e governance integrata della tecnologia

La nuova disciplina deve essere considerata anche nel più ampio processo europeo di regolazione del rischio tecnologico.

Cyber Resilience Act, NIS2 e AI Act hanno oggetti, destinatari e presupposti differenti e non possono essere sovrapposti, ma possono incidere contemporaneamente sulla medesima organizzazione, sulla medesima catena di fornitura e, in determinate circostanze, sul medesimo evento.

La NIS2 concentra l’attenzione sulla resilienza delle organizzazioni operanti nei settori rientranti nel proprio campo di applicazione; il CRA introduce requisiti orizzontali di cybersicurezza dei prodotti con elementi digitali; l’AI Act costruisce una disciplina fondata sul rischio per i sistemi e i modelli di intelligenza artificiale.

La convergenza emerge sul piano organizzativo.

Gestire separatamente queste discipline attraverso procedure prive di collegamento può determinare duplicazioni, ritardi e soprattutto zone di responsabilità non presidiate. La risposta più efficace consiste invece nella costruzione di una governance capace di collegare sicurezza informatica, product security, gestione dei fornitori, continuità operativa, gestione dell’intelligenza artificiale, compliance e reporting.

Anche la NIS2 utilizza, per gli incidenti significativi, una scansione che comprende un early warning entro 24 ore e una notifica entro 72 ore.  

Ciò non significa che i due regimi di notifica coincidano, ma rafforza l’esigenza di predisporre un processo interno coordinato di incident e vulnerability management, dal quale possano poi derivare i differenti adempimenti richiesti dalle normative applicabili.

9. Intelligenza artificiale e ampliamento della superficie di rischio

L’intelligenza artificiale rende questo modello ancora più rilevante.

I sistemi di AI possono aumentare la capacità di individuazione delle anomalie, accelerare l’analisi delle vulnerabilità e supportare attività di monitoraggio e risposta. Allo stesso tempo, l’introduzione di modelli, servizi cloud, API, componenti software, dataset e fornitori ulteriori può aumentare il numero e la complessità delle dipendenze tecnologiche da governare.

In sistemi digitali sempre più composti da elementi provenienti da soggetti differenti, la domanda non è soltanto se il singolo componente sia sicuro, ma se l’impresa sia in grado di ricostruire rapidamente le relazioni tra componenti, fornitori, servizi e prodotti quando emerge una vulnerabilità o si verifica un incidente.

La gestione della supply chain digitale diventa così uno dei punti nei quali cybersecurity, resilienza e governance dell’AI tendono maggiormente a convergere.

10. Verifiche delle imprese

In vista dell’applicazione dell’articolo 14, per le imprese interessate è opportuno verificare almeno il perimetro dei prodotti con elementi digitali messi a disposizione sul mercato UE, l’esistenza di un inventario sufficientemente aggiornato dei prodotti e delle relative componenti, i processi di vulnerability e incident management, i flussi informativi con sviluppatori e fornitori, l’attribuzione delle responsabilità interne e le modalità operative per effettuare le comunicazioni attraverso la Single Reporting Platform.

Particolare attenzione dovrebbe inoltre essere dedicata al raccordo tra funzioni tecniche, sicurezza, legale/compliance, product management e vertice aziendale.

Una procedura formalmente corretta ma non sperimentata rischia infatti di rivelarsi insufficiente quando il termine disponibile è di sole 24 ore. L’adempimento dovrebbe pertanto essere verificato anche attraverso simulazioni e test organizzativi, individuando preventivamente eventuali colli di bottiglia nei processi di escalation e decisione.

11. Compliance e qualità industriale

Il Cyber Resilience Act esprime, in definitiva, un principio più ampio rispetto al singolo obbligo di notifica, in quanto la sicurezza dei prodotti digitali diventa una componente della qualità industriale.

Non è realistico costruire prodotti rispetto ai quali possa essere garantita l’assenza assoluta e permanente di vulnerabilità. La resilienza si misura invece anche nella capacità del fabbricante di conoscere il proprio prodotto e le relative dipendenze, ricercare e ricevere informazioni sulle vulnerabilità, riconoscerle tempestivamente, valutarne l’impatto, intervenire e comunicare.

La fiducia nel prodotto digitale non deriva quindi dalla promessa dell’assenza di vulnerabilità, ma dalla capacità dimostrabile dell’organizzazione di governarle durante il ciclo di vita del prodotto.

Da questo punto di vista, l’11 settembre 2026 costituisce una prima importante prova della maturità delle imprese europee. Quelle che interpreteranno la scadenza come un mero esercizio formale proveranno a comprimere il problema all’interno delle 24 ore previste dalla norma. Quelle che ne comprenderanno la portata utilizzeranno invece quelle 24 ore come stress test della propria organizzazione. È in questa seconda prospettiva che la resilienza può cessare di rappresentare esclusivamente un costo regolatorio e trasformarsi in patrimonio industriale, fattore di fiducia e vantaggio competitivo.

Riferimenti e documentazione

Regolamento (UE) 2024/2847 – Cyber Resilience Act:
Testo del Regolamento su EUR-Lex⁠

Commissione europea – Cyber Resilience Act:
Pagina istituzionale sul Cyber Resilience Act⁠

Commissione europea – obblighi di reporting CRA:
Cyber Resilience Act – Reporting obligations⁠

Commissione europea – Guidance del 27 luglio 2026:
Guidance sull'attuazione del Cyber Resilience Act⁠

ENISA – Single Reporting Platform:
CRA Single Reporting Platform⁠

ENISA – FAQ operative aggiornate al 10 settembre 2026:
Frequently Asked Questions sulla CRA Single Reporting Platform⁠