Cybersecurity & Compliance
Cyber Resilience Act, dall’11 settembre 2026 le vulnerabilità vanno segnalate entro 24 ore
Il Cyber Resilience Act è il regolamento europeo che introduce requisiti obbligatori di cybersicurezza per tutti i prodotti hardware e software venduti nell’Unione. La sua piena applicazione è fissata a dicembre 2027, ma l’11 settembre 2026 arriva il primo appuntamento operativo. Da quella data i fabbricanti devono segnalare a ENISA e al CSIRT nazionale le vulnerabilità attivamente sfruttate e gli incidenti gravi, con un preallarme entro 24 ore. In questa guida spieghiamo che cos’è il regolamento, che cosa cambia da settembre, a chi si applica e quali passi compiere, con uno sguardo al contesto italiano e alle ricadute per chi acquista tecnologia, dalle imprese alla Pubblica Amministrazione.
Che cos’è il Cyber Resilience Act
Il Cyber Resilience Act, o CRA, è il nome con cui si identifica il 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. Pubblicato nella Gazzetta ufficiale dell’Unione europea il 20 novembre 2024, è entrato in vigore il 10 dicembre 2024 e si applica in modo scaglionato fino all’11 dicembre 2027.
È il primo quadro normativo europeo di natura orizzontale che disciplina la sicurezza dei prodotti digitali in quanto tali, a prescindere dal settore di impiego. Per prodotto con elementi digitali il regolamento intende qualsiasi software o hardware, comprese le soluzioni di elaborazione dati a distanza che ne fanno parte, la cui connessione diretta o indiretta a un dispositivo o a una rete sia prevista. Rientrano quindi router, telecamere, sensori, centralini, applicativi gestionali, sistemi operativi, librerie software e molto altro.
Trattandosi di un regolamento e non di una direttiva, il CRA è direttamente applicabile in tutti gli Stati membri. Come per la marcatura CE dei prodotti tradizionali, il principio è che un prodotto digitale possa circolare nel mercato unico solo se progettato, sviluppato e mantenuto in modo sicuro lungo tutto il suo ciclo di vita.
I due pilastri, sicurezza by design e ciclo di vita
Il regolamento poggia su due idee di fondo. La prima è la security by design e by default. La sicurezza non può essere aggiunta alla fine dello sviluppo, ma va integrata dalla fase di progettazione, con una valutazione dei rischi cyber documentata e una configurazione predefinita sicura, senza credenziali di fabbrica note, con le interfacce non necessarie disattivate e con la cifratura attiva.
La seconda è la responsabilità sull’intero ciclo di vita. L’impegno del fabbricante non termina con la vendita. Per tutto il periodo di supporto, che di norma non può essere inferiore a cinque anni e deve riflettere la vita utile attesa del prodotto, il fabbricante deve gestire le vulnerabilità, rilasciare aggiornamenti di sicurezza gratuiti e tempestivi e mantenere un canale per la divulgazione coordinata delle vulnerabilità.
Che cosa cambia dall’11 settembre 2026
L’articolo 14 del regolamento, dedicato agli obblighi di segnalazione dei fabbricanti, si applica con oltre un anno di anticipo rispetto al resto del testo. Dall’11 settembre 2026 chi immette sul mercato europeo un prodotto con elementi digitali deve notificare due tipi di eventi.
- Le vulnerabilità attivamente sfruttate, cioè quelle per cui esistono prove concrete che un soggetto malevolo le abbia già utilizzate contro un sistema.
- Gli incidenti gravi che incidono sulla sicurezza del prodotto, per esempio una compromissione della rete di sviluppo o dei server di distribuzione degli aggiornamenti che possa riflettersi sugli utenti.
Le notifiche seguono uno schema a cascata che riprende volutamente quello della direttiva NIS2.
- Preallarme entro 24 ore da quando il fabbricante viene a conoscenza dell’evento, con le informazioni essenziali disponibili e l’indicazione degli Stati membri in cui il prodotto è distribuito.
- Notifica completa entro 72 ore, con informazioni generali sul prodotto, natura dello sfruttamento o dell’incidente, gravità, impatto e misure correttive o di mitigazione già adottate.
- Relazione finale, entro 14 giorni dalla disponibilità di una misura correttiva nel caso delle vulnerabilità ed entro un mese dalla notifica a 72 ore nel caso degli incidenti gravi.
Le segnalazioni passano dalla piattaforma unica di segnalazione gestita da ENISA, che l’Agenzia europea rende operativa proprio l’11 settembre. A fine luglio ENISA ha pubblicato le istruzioni passo passo per registrarsi e inviare le notifiche, da cui emerge un dettaglio utile per chi organizza il processo. Il preallarme a 24 ore richiede solo poche informazioni essenziali, chi segnala, quale prodotto è interessato e che tipo di evento si è verificato, mentre la descrizione della vulnerabilità e le misure correttive diventano obbligatorie con la notifica a 72 ore. Le prime 24 ore servono per avvisare, non per indagare. Il fabbricante trasmette una sola volta e la piattaforma inoltra la notifica al CSIRT designato come coordinatore nello Stato membro in cui ha la sede principale, agli altri CSIRT interessati e a ENISA stessa. In Italia il CSIRT di riferimento è il CSIRT Italia, istituito presso l’Agenzia per la Cybersicurezza Nazionale. In circostanze eccezionali, per esempio quando è in corso una divulgazione coordinata o una correzione sta per essere rilasciata, il CSIRT coordinatore può differire la diffusione della segnalazione agli altri Stati membri.
C’è poi un obbligo spesso trascurato. Il fabbricante deve informare gli utenti colpiti, e dove opportuno tutti gli utenti, della vulnerabilità o dell’incidente e delle misure per ridurne il rischio. È il punto che tocca più da vicino le aziende e gli enti che acquistano tecnologia, perché cambia la qualità e la tempestività delle informazioni che riceveranno dai fornitori.
Vale anche per i prodotti già in commercio. Gli obblighi di segnalazione dell’articolo 14 si applicano anche ai prodotti immessi sul mercato prima dell’11 dicembre 2027, purché ancora supportati. Non è quindi un adempimento riservato ai prodotti futuri. Le micro e piccole imprese godono di un’attenuazione specifica, non sono sanzionabili per il solo mancato rispetto del termine di 24 ore del preallarme, ma restano soggette a tutti gli altri obblighi.
A chi si applica
Il regolamento distingue diversi ruoli lungo la catena di fornitura e a ciascuno assegna obblighi propri.
- Fabbricanti, ovvero chi sviluppa o fa sviluppare un prodotto con elementi digitali e lo commercializza con il proprio nome o marchio. È il ruolo con il maggior numero di obblighi ed è l’unico interessato dalla scadenza dell’11 settembre. Rientra anche chi integra componenti di terzi o open source in un prodotto commerciale.
- Importatori e distributori, che devono verificare che i prodotti immessi sul mercato siano conformi e informare il fabbricante e le autorità delle vulnerabilità e dei rischi di cui vengono a conoscenza. I loro obblighi scattano con la piena applicazione del 2027.
- Gestori di software open source, che beneficiano di un regime alleggerito ma sono chiamati a collaborare alla gestione e alla segnalazione delle vulnerabilità nei componenti che curano.
Un chiarimento importante riguarda i servizi cloud. Il software erogato in modalità SaaS in senso puro non rientra nel CRA e resta disciplinato dalla NIS2. Rientrano invece le funzioni di elaborazione a distanza senza le quali un prodotto non potrebbe svolgere le proprie funzionalità, come l’app o il cloud che governano un dispositivo connesso. Le linee guida della Commissione dedicano una sezione proprio a questo confine.
Le categorie di prodotto e il percorso di conformità
Non tutti i prodotti sono trattati allo stesso modo. Il regolamento li divide in categorie in base alla funzionalità principale e al rischio che comportano, e dalla categoria dipende il percorso di valutazione della conformità.
- Prodotti standard, la grande maggioranza del mercato, per i quali sono sufficienti l’autovalutazione del fabbricante e la dichiarazione di conformità UE.
- Prodotti importanti di classe I, come browser, gestori di password, VPN, sistemi di gestione delle identità, router, modem e switch, che richiedono l’applicazione di norme armonizzate oppure la valutazione di un organismo terzo.
- Prodotti importanti di classe II, come firewall, sistemi di rilevamento e prevenzione delle intrusioni, hypervisor e microprocessori con protezione contro le manomissioni, per i quali la valutazione di terza parte è obbligatoria.
- Prodotti critici, come moduli di sicurezza hardware, gateway per contatori intelligenti e smart card, che potranno essere sottoposti a certificazione europea obbligatoria.
Il calendario completo
| Data | Che cosa si applica |
|---|---|
| 10 dic 2024 | Entrata in vigore del Regolamento (UE) 2024/2847. |
| 11 giu 2026 | Capo IV sulla notifica degli organismi di valutazione della conformità (articoli da 35 a 51). Gli enti che vogliono certificare prodotti devono essere notificati dalle autorità nazionali. |
| 11 set 2026 | Articolo 14, obblighi di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi tramite la piattaforma unica ENISA. Vale anche per i prodotti già in commercio. |
| 11 dic 2027 | Piena applicazione. Requisiti essenziali dell’Allegato I, documentazione tecnica, valutazione di conformità, marcatura CE, obblighi di importatori e distributori, periodo di supporto con aggiornamenti di sicurezza. |
Le linee guida della Commissione europea
Il 27 luglio 2026 la Commissione europea ha pubblicato, con la Comunicazione C(2026) 5252, le linee guida sull’applicazione del regolamento, rilanciate in Italia da ACN il 1° settembre. Si tratta di un documento non vincolante, articolato in nove sezioni con esempi pratici e casi d’uso, nato dal lavoro del CRA Expert Group a cui partecipano le autorità nazionali, ACN compresa. Le linee guida non creano nuovi obblighi ma indicano come le autorità di vigilanza interpreteranno il testo, e per questo hanno un peso concreto in sede di controllo. I punti più rilevanti sono i seguenti.
- Periodo di supporto. I cinque anni sono un riferimento minimo, non un tetto. Per apparati destinati a durare dieci o quindici anni, come dispositivi medicali o sistemi industriali, il supporto deve coprire l’intera vita utile attesa.
- Software open source. Chi sviluppa e condivide codice senza scopo di lucro resta fuori dal regolamento. Chi integra quel codice in un prodotto commerciale ne assume per intero la responsabilità.
- Distinta base del software (SBOM). Il fabbricante deve mantenere un elenco leggibile da strumenti automatici dei componenti, delle librerie e delle dipendenze del prodotto, almeno al primo livello. È lo strumento che permette di capire in poche ore se una nuova vulnerabilità pubblica riguarda il proprio prodotto.
- Modifiche sostanziali. Un prodotto già sul mercato entra nel perimetro completo del regolamento quando subisce una modifica sostanziale, cioè un cambiamento che incide sulla conformità o sull’uso previsto. Gli aggiornamenti di sicurezza, di per sé, non lo sono.
- Elaborazione a distanza. Vengono chiariti i criteri per distinguere il servizio cloud escluso dal regolamento dalla componente cloud che fa parte del prodotto.
La dimensione italiana, il ruolo di ACN
Pur essendo direttamente applicabile, il CRA richiede a ogni Stato membro di individuare le autorità competenti, disciplinare i procedimenti e definire l’apparato sanzionatorio. In Italia questo passaggio è affidato alla legge di delegazione europea, legge 17 marzo 2026, n. 36, che all’articolo 15 delega il Governo ad adeguare l’ordinamento nazionale al regolamento e individua nell’Agenzia per la Cybersicurezza Nazionale sia l’autorità di notifica degli organismi di valutazione della conformità sia l’autorità di vigilanza del mercato, con risorse dedicate dal 2026 in avanti. Il decreto legislativo di adeguamento è atteso nei prossimi mesi.
ACN riunisce così in un unico soggetto i tre presidi che il regolamento chiama in causa, il CSIRT che riceve le segnalazioni, l’autorità che vigila sui prodotti e quella che accredita gli enti certificatori. La legge delega chiede inoltre di raccordare il futuro decreto con il Perimetro di sicurezza nazionale cibernetica e con il decreto legislativo 138/2024 di recepimento della NIS2, in modo da costruire un sistema unitario. Per le imprese che sono già soggetti NIS2 il vantaggio è evidente, perché le procedure di notifica degli incidenti verso ACN seguono la stessa logica e possono essere in larga parte riutilizzate.
Le sanzioni
L’impianto sanzionatorio dell’articolo 64 è graduato su tre livelli. La violazione dei requisiti essenziali di cybersicurezza e degli obblighi degli articoli 13 e 14, quindi anche delle segnalazioni che scattano a settembre, può comportare sanzioni fino a 15 milioni di euro o al 2,5 per cento del fatturato mondiale annuo, se superiore. Le altre violazioni, per esempio quelle relative a marcatura CE, documentazione tecnica e obblighi di importatori e distributori, arrivano a 10 milioni di euro o al 2 per cento del fatturato. Fornire informazioni inesatte o fuorvianti alle autorità costa fino a 5 milioni di euro o all’1 per cento del fatturato. Le autorità di vigilanza possono inoltre ordinare il ritiro o il richiamo del prodotto e vietarne la distribuzione. Per le micro e piccole imprese le autorità devono tenere conto della dimensione e della capacità economica, senza che questo equivalga a un’esenzione.
Come mettersi in regola, i passi operativi
Chi sviluppa software o hardware ha davanti due orizzonti, quello immediato della segnalazione e quello del 2027 per la conformità completa. Conviene lavorare in parallelo, perché la parte più impegnativa non è la documentazione ma la conoscenza puntuale dei propri prodotti.
- Censire e classificare i prodotti a catalogo e in sviluppo, compresi firmware e componenti integrati, determinando per ciascuno la categoria di rischio e il ruolo ricoperto.
- Attivare subito la procedura di segnalazione, con criteri chiari per riconoscere una vulnerabilità sfruttata o un incidente grave, un responsabile designato, i modelli di notifica per le tre fasi e l’accesso alla piattaforma ENISA.
- Pubblicare una policy di divulgazione coordinata delle vulnerabilità, con un punto di contatto raggiungibile da ricercatori e clienti.
- Costruire e mantenere la SBOM, integrando nella pipeline di sviluppo strumenti che la generino automaticamente e la confrontino con i database delle vulnerabilità note.
- Adottare un ciclo di sviluppo sicuro, con analisi dei rischi in fase di progettazione, test di sicurezza periodici e configurazioni predefinite sicure, allineandosi a standard come ISO/IEC 27001 e IEC 62443.
- Definire il periodo di supporto di ogni prodotto e comunicarlo ai clienti insieme alla data di fine supporto.
- Preparare la documentazione tecnica e la dichiarazione di conformità UE in vista del dicembre 2027, individuando per i prodotti importanti l’organismo notificato con cui lavorare.
- Riesaminare i contratti con fornitori e clienti, inserendo clausole su aggiornamenti, tempi di notifica e responsabilità lungo la filiera.
Che cosa cambia per chi acquista tecnologia
Il Cyber Resilience Act viene spesso letto come una norma per i produttori, ma i suoi effetti si scaricano rapidamente su chi la tecnologia la compra e la gestisce. Per le imprese, gli enti pubblici e le strutture sanitarie il regolamento porta tre novità concrete.
La prima riguarda l’informazione. Da settembre i fornitori sono tenuti ad avvisare gli utenti delle vulnerabilità sfruttate e delle contromisure, e questo rende più solido il ciclo di gestione delle patch, in particolare per apparati di rete, sistemi di comunicazione e dispositivi connessi che spesso restano in produzione per molti anni.
La seconda riguarda gli acquisti. Dal 2027 la marcatura CE dei prodotti digitali attesterà anche la conformità cyber, e nelle gare pubbliche la richiesta di prodotti conformi al CRA, con un periodo di supporto dichiarato e una SBOM disponibile, diventerà un criterio di selezione naturale. Chi acquista può cominciare da subito a chiedere ai fornitori a che punto sono con l’adeguamento.
La terza riguarda l’integrazione. In un’infrastruttura moderna convivono decine di prodotti di fabbricanti diversi, e le segnalazioni previste dal regolamento vanno raccolte, valutate e tradotte in interventi. Per un system integrator questo significa presidiare le comunicazioni dei vendor, mantenere aggiornato l’inventario degli asset installati presso i clienti e garantire che ogni avviso si trasformi in tempi brevi in una patch applicata o in una mitigazione. Nei settori dove il CRA si intreccia con la NIS2, come sanità, energia e Pubblica Amministrazione, questa capacità operativa è ciò che separa la conformità sulla carta dalla sicurezza reale.
In sintesi. Dall’11 settembre 2026 i fabbricanti di prodotti con elementi digitali devono segnalare a ENISA e al CSIRT nazionale le vulnerabilità sfruttate e gli incidenti gravi, con preallarme entro 24 ore, notifica entro 72 ore e relazione finale, e informare gli utenti colpiti. L’obbligo vale anche per i prodotti già in commercio. La piena applicazione del regolamento arriva l’11 dicembre 2027, ma censimento dei prodotti, procedura di segnalazione, distinta base del software e ciclo di sviluppo sicuro vanno impostati adesso. Chi acquista tecnologia ha finalmente uno standard a cui ancorare le proprie richieste ai fornitori.
Contenuto a scopo informativo, aggiornato a settembre 2026. Il quadro normativo è in evoluzione, in particolare per quanto riguarda il decreto legislativo italiano di adeguamento al regolamento e gli atti di esecuzione della Commissione europea. Per gli adempimenti specifici si raccomanda di fare riferimento ai testi ufficiali e di consultare un consulente qualificato. Fonti principali, Regolamento (UE) 2024/2847, Comunicazione della Commissione europea C(2026) 5252 del 27 luglio 2026, ENISA, Agenzia per la Cybersicurezza Nazionale, legge 17 marzo 2026, n. 36.

