In sintesi
Cos’è. L’obbligo, previsto dall’articolo 14 del Regolamento (UE) 2024/2847, di segnalare a ENISA e al CSIRT nazionale le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza di prodotti con elementi digitali.
Chi riguarda. I fabbricanti di prodotti hardware e software connessi o connettibili a un dispositivo o a una rete, compresi i componenti immessi sul mercato separatamente.
Cosa cambia. Dall’11 settembre 2026 valgono tempi di notifica a cascata: allarme rapido entro 24 ore, notifica completa entro 72 ore, relazione finale entro 14 giorni dalla misura correttiva. L’obbligo copre anche i prodotti già venduti.
Cosa fare. Verificare se i propri prodotti rientrano nell’ambito, attivare un canale di ricezione delle segnalazioni di vulnerabilità, costruire la SBOM, nominare chi decide e chi notifica nelle prime 24 ore.
Il Cyber Resilience Act ha tre date di applicazione. Quella che pesa sulla maggior parte delle imprese manifatturiere italiane arriva fra cinque settimane, non nel 2027.
Dall’11 settembre 2026 un fabbricante che viene a conoscenza di una vulnerabilità attivamente sfruttata in un proprio prodotto ha 24 ore per lanciare l’allarme. L’articolo 64 del regolamento colloca la violazione degli obblighi di segnalazione nella fascia sanzionatoria più alta: fino a 15 milioni di euro o il 2,5% del fatturato mondiale annuo, se superiore.
Da quando si applica il Cyber Resilience Act?
Il Regolamento (UE) 2024/2847 è entrato in vigore il 10 dicembre 2024 e si applica dall’11 dicembre 2027. L’articolo 71 prevede due deroghe a quella data.
La prima è già scattata. Dall’11 giugno 2026 si applica il Capo IV, articoli da 35 a 51, sulla notifica degli organismi di valutazione della conformità. Riguarda gli enti certificatori e le autorità nazionali che li designano.
La seconda deroga è l’11 settembre 2026, data da cui si applica l’articolo 14 sugli obblighi di segnalazione.
C’è poi un terzo elemento che pesa più di quanto sembri. L’articolo 69, paragrafo 2, stabilisce che i prodotti immessi sul mercato prima dell’11 dicembre 2027 rientrano nei requisiti del regolamento solo se dopo quella data subiscono una modifica sostanziale. Il paragrafo 3 dello stesso articolo deroga a questa regola proprio per l’articolo 14: l’obbligo di segnalazione copre tutti i prodotti in ambito, compresi quelli venduti anni fa.
Su quei prodotti il CRA chiede la notifica e si ferma lì. Gli altri obblighi, dalla gestione strutturata delle vulnerabilità alla documentazione tecnica, restano fuori finché non interviene una modifica sostanziale. È una distinzione utile quando si decide dove mettere il budget nei prossimi mesi.
Quali prodotti rientrano nel Cyber Resilience Act?
Il regolamento definisce prodotto con elementi digitali ogni prodotto software o hardware, e le relative soluzioni di elaborazione dati a distanza, la cui destinazione d’uso prevede una connessione dati diretta o indiretta, logica o fisica, a un dispositivo o a una rete. Ci rientrano sia i prodotti finiti sia i componenti immessi sul mercato separatamente.
Per un’impresa manifatturiera questo significa PLC, sistemi di supervisione e controllo, sensori IoT, gateway di campo, firmware a bordo macchina. Se la macchina scambia dati con qualcosa, il software che la governa va valutato.
Il 27 luglio 2026 la Commissione europea ha pubblicato la Comunicazione C(2026) 5252 con l’allegato di linee guida applicative: 67 esempi pratici su ambito di applicazione, modifiche sostanziali, periodi di supporto e obblighi di segnalazione. Non è un testo vincolante, ma è l’interpretazione ufficiale della Commissione, e chi deve stabilire se un prodotto è dentro o fuori ora ha casi concreti su cui appoggiarsi.
Va guardato anche il Regolamento di esecuzione (UE) 2025/2392, pubblicato il 1° dicembre 2025, che descrive tecnicamente le categorie di prodotti importanti (Allegato III) e critici (Allegato IV). Per quelle categorie la conformità non si autocertifica: serve un organismo notificato terzo.
Entro quanto tempo va segnalata una vulnerabilità attivamente sfruttata?
La cascata dell’articolo 14 ha tre passaggi.
- Allarme rapido entro 24 ore dal momento in cui il fabbricante viene a conoscenza del fatto.
- Notifica completa entro 72 ore.
- Relazione finale entro 14 giorni dalla disponibilità di una misura correttiva per le vulnerabilità attivamente sfruttate, entro un mese per gli incidenti gravi.
Il canale è la piattaforma unica di segnalazione prevista dal regolamento. La notifica arriva al CSIRT dello Stato membro in cui il fabbricante ha lo stabilimento principale e, salvo circostanze eccezionali, a ENISA nello stesso momento.
L’articolo 16 consente al CSIRT che riceve la segnalazione di ritardarne la diffusione verso gli altri Stati membri per motivi di sicurezza, per esempio quando è in corso una divulgazione coordinata. Il Regolamento delegato (UE) 2026/881, adottato l’11 dicembre 2025, elenca i motivi ammessi per quel ritardo.
Il cronometro parte dalla conoscenza del fatto, non dalla fine dell’analisi tecnica. Perché 24 ore siano un termine rispettabile servono tre cose già in piedi: un canale di ricezione presidiato, un criterio scritto per stabilire se una vulnerabilità è attivamente sfruttata, una catena decisionale con nomi e sostituti. Chi comincia a costruirle il giorno della prima segnalazione ha già bruciato metà del tempo disponibile.
Perché senza SBOM le 24 ore non bastano
La SBOM (Software Bill of Materials) è l’inventario delle dipendenze software di un prodotto. L’Allegato I del CRA la richiede almeno per le dipendenze di primo livello.
Quando esce un avviso su una libreria diffusa, la domanda operativa è sempre la stessa: quali dei nostri prodotti la contengono, e in quale versione. Senza inventario quella risposta si costruisce a mano, chiamando chi ha scritto il codice e sperando che lavori ancora in azienda.
C’è poi il periodo di assistenza, che il regolamento fissa ad almeno 5 anni o alla durata d’uso prevista se inferiore. Nell’automazione industriale, dove un impianto resta in linea 15 o 20 anni, l’inventario va tenuto aggiornato su generazioni di prodotto che il reparto sviluppo ha smesso di seguire da tempo.
Cosa fare entro l’11 settembre 2026
Cinque passaggi, in quest’ordine.
- Test di ambito. Elencare i prodotti venduti nell’UE, componenti compresi, e stabilire quali hanno elementi digitali. Le linee guida C(2026) 5252 servono qui.
- Canale di ricezione. Attivare un indirizzo pubblico dove chiunque, dal cliente al ricercatore indipendente, possa segnalare una vulnerabilità. E assegnarlo a qualcuno che lo legge davvero, anche ad agosto.
- Criterio di sfruttamento attivo. Mettere per iscritto quali evidenze fanno scattare l’obbligo (exploit in circolazione, indicatori di compromissione su un’installazione, avviso di un CERT) e chi le valuta.
- SBOM. Partire dai prodotti a più alta diffusione e dalle dipendenze di primo livello, poi estendere al resto del catalogo.
- Ruoli. Nominare chi decide che si notifica, chi compila materialmente la notifica sulla piattaforma, e chi lo fa se il primo è in ferie.
Nessuno di questi passaggi richiede un progetto da sei mesi. Richiedono una decisione e una firma.
Come innestare il reporting CRA su un sistema di gestione esistente
Chi ha un sistema di gestione della sicurezza delle informazioni documentato secondo ISO/IEC 27001 non parte da zero. La norma chiede già un processo di gestione delle vulnerabilità tecniche e una procedura di gestione degli incidenti, con ruoli definiti, registrazione e tempi. Il reporting CRA si aggancia lì. Cambia il destinatario, che diventa il CSIRT ed ENISA, e cambia l’oggetto, che è il prodotto venduto e non l’infrastruttura interna.
RDC segue il percorso verso la ISO/IEC 27001:2024 con estensione ISO/IEC 27017:2015, dalla stesura del manuale di sicurezza alla definizione delle policy, fino agli audit interni preliminari e all’affiancamento in certificazione. Sul piano operativo, i servizi di consulenza informatica e digitalizzazione comprendono la redazione dei piani di sicurezza, il manuale GDPR e la fornitura della figura del DPO.
Con decreto direttoriale del 29 luglio 2026 il MIMIT ha inserito RDC nell’elenco dei soggetti abilitati alla fornitura di servizi e prodotti di cloud computing e cyber security, lo stesso elenco a cui devono attingere le PMI che vogliono usare il voucher dedicato.
Domande Frequenti
Il Regolamento (UE) 2024/2847 si applica dall’11 dicembre 2027. L’articolo 71 prevede due eccezioni: il Capo IV sulla notifica degli organismi di valutazione della conformità dall’11 giugno 2026, e l’articolo 14 sugli obblighi di segnalazione dall’11 settembre 2026.
Ogni prodotto hardware o software, e le relative soluzioni di elaborazione dati a distanza, la cui destinazione d’uso prevede una connessione dati diretta o indiretta a un dispositivo o a una rete. Sono inclusi i prodotti finiti e i componenti immessi sul mercato separatamente, come firmware, PLC e sensori IoT.
Entro 24 ore dalla conoscenza del fatto va inviato un allarme rapido, entro 72 ore la notifica completa. La relazione finale va presentata entro 14 giorni dalla disponibilità di una misura correttiva per le vulnerabilità, entro un mese per gli incidenti gravi.
Per gli obblighi di segnalazione sì. L’articolo 69, paragrafo 3, estende l’articolo 14 a tutti i prodotti in ambito immessi sul mercato prima dell’11 dicembre 2027. Gli altri obblighi del regolamento scattano su quei prodotti solo in caso di modifica sostanziale successiva.
Un test di ambito sul catalogo prodotti, un canale presidiato per ricevere le segnalazioni di vulnerabilità, un criterio scritto per riconoscere lo sfruttamento attivo, la SBOM almeno sulle dipendenze di primo livello e i ruoli nominati per decidere e notificare entro 24 ore.