{"id":175,"date":"2026-06-17T08:29:28","date_gmt":"2026-06-17T08:29:28","guid":{"rendered":"https:\/\/shattered.io\/it\/2026\/06\/17\/cyber-resilience-act-2026\/"},"modified":"2026-06-17T08:30:33","modified_gmt":"2026-06-17T08:30:33","slug":"cyber-resilience-act-2026","status":"publish","type":"post","link":"https:\/\/shattered.io\/it\/2026\/06\/17\/cyber-resilience-act-2026\/","title":{"rendered":"Cyber Resilience Act: 15M\u20ac e 3 Scadenze UE [2026]"},"content":{"rendered":"\n

Il Cyber Resilience Act<\/strong> entra nella sua fase operativa. Mancano meno di tre mesi alla prima scadenza vincolante: dall’11 settembre 2026<\/strong> i produttori di prodotti con elementi digitali dovranno segnalare a ENISA le vulnerabilit\u00e0 attivamente sfruttate e gli incidenti gravi. Il regolamento, formalmente Regolamento (UE) 2024\/2847<\/strong>, \u00e8 la prima legge orizzontale europea che impone requisiti di cibersicurezza obbligatori a hardware e software venduti nel mercato unico. Chi non si adegua rischia multe fino a 15 milioni di euro<\/strong> o il 2,5% del fatturato mondiale annuo.<\/p>\n\n\n\n

Per le imprese italiane ed europee non si tratta di un esercizio teorico. Il cyber resilience act<\/strong> trasforma la cibersicurezza da costo opzionale a requisito di accesso al mercato, allo stesso modo in cui la marcatura CE governa gi\u00e0 la sicurezza fisica dei prodotti. Questa analisi raccoglie le date, le categorie di rischio, gli obblighi per produttori e distributori, il regime sanzionatorio e l’impatto concreto sul tessuto produttivo del continente, con cifre verificate e fonti istituzionali.<\/p>\n\n\n\n

Cos’\u00e8 il Cyber Resilience Act e perch\u00e9 conta adesso<\/h2>\n\n\n\n

Il Cyber Resilience Act \u00e8 stato pubblicato sulla Gazzetta Ufficiale dell’Unione europea il 20 novembre 2024<\/strong> ed \u00e8 entrato in vigore il 10 dicembre 2024<\/strong>. La Commissione europea lo descrive come il quadro orizzontale che, per la prima volta, lega i requisiti di cibersicurezza alla sorveglianza del mercato e alla marcatura CE. Lo studio legale Hogan Lovells lo definisce una “normativa pionieristica che stabilisce standard di cibersicurezza obbligatori per la maggior parte dei prodotti hardware e software immessi sul mercato UE”.<\/p>\n\n\n\n

La logica \u00e8 semplice quanto dirompente: fino a oggi un router, una telecamera connessa o un’applicazione potevano essere venduti in Europa senza alcun controllo minimo di sicurezza. Il cyber resilience act<\/strong> introduce il principio del “secure by design”, obbligando i produttori a integrare la sicurezza in ogni fase, dalla progettazione alla manutenzione. La portata \u00e8 ampia: il regolamento copre i “prodotti con elementi digitali” il cui uso previsto, o ragionevolmente prevedibile, comporta una connessione dati diretta o indiretta a un dispositivo o a una rete.<\/p>\n\n\n\n

Il momento \u00e8 cruciale perch\u00e9 il calendario delle scadenze \u00e8 gi\u00e0 iniziato. La fase di preparazione si chiude e quella degli obblighi concreti comincia proprio nel 2026. Le aziende che hanno rimandato l’adeguamento contando sul 2027 scoprono ora che la prima ondata di obblighi arriva molto prima.<\/p>\n\n\n\n

Le date che contano: la scadenza dell’11 settembre 2026<\/h2>\n\n\n\n

Il legislatore europeo ha scaglionato l’applicazione del regolamento per dare tempo alle imprese di adeguarsi. Tre date scandiscono il percorso. La prima, l’11 giugno 2026<\/strong>, riguarda la notifica degli organismi di valutazione della conformit\u00e0 da parte degli Stati membri. La seconda, l’11 settembre 2026<\/strong>, attiva gli obblighi di segnalazione di vulnerabilit\u00e0 e incidenti. La terza, l’11 dicembre 2027<\/strong>, segna l’applicazione piena di tutti i requisiti essenziali.<\/p>\n\n\n\n

Un dettaglio spesso trascurato riguarda i prodotti gi\u00e0 sul mercato. Secondo l’analisi di Cycode, gli articoli immessi prima dell’11 dicembre 2027 non rientrano retroattivamente nei requisiti completi del cyber resilience act<\/strong>, a meno che non subiscano una “modifica sostanziale” dopo tale data. Gli obblighi di segnalazione previsti dall’articolo 14, per\u00f2, si applicano da settembre 2026 a tutti i prodotti, compresi quelli legacy. Una distinzione che cambia radicalmente la pianificazione delle aziende con cataloghi ampi.<\/p>\n\n\n\n

Data<\/th>Obbligo che entra in vigore<\/th>Chi \u00e8 coinvolto<\/th><\/tr><\/thead>
20 novembre 2024<\/td>Pubblicazione in Gazzetta Ufficiale UE<\/td>Tutti<\/td><\/tr>
10 dicembre 2024<\/td>Entrata in vigore del regolamento<\/td>Tutti<\/td><\/tr>
11 giugno 2026<\/td>Notifica degli organismi di valutazione della conformit\u00e0<\/td>Stati membri<\/td><\/tr>
11 settembre 2026<\/td>Obblighi di segnalazione di vulnerabilit\u00e0 e incidenti (art. 14)<\/td>Produttori<\/td><\/tr>
11 dicembre 2027<\/td>Applicazione piena: requisiti essenziali, conformit\u00e0, CE<\/td>Produttori, importatori, distributori<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Quali prodotti rientrano: i “prodotti con elementi digitali”<\/h2>\n\n\n\n

La definizione di “prodotto con elementi digitali” \u00e8 volutamente larga. Comprende qualsiasi prodotto software o hardware e le relative soluzioni di elaborazione dati a distanza, inclusi i componenti software o hardware venduti separatamente. In pratica, ricadono nel perimetro sistemi operativi, applicazioni mobili, router domestici, telecamere IP, giocattoli connessi, software gestionali, librerie commerciali e dispositivi industriali IoT.<\/p>\n\n\n\n

Il criterio chiave \u00e8 la connessione: se l’uso previsto del prodotto comporta un collegamento logico o fisico, diretto o indiretto, a un dispositivo o a una rete, il cyber resilience act<\/strong> si applica. Conta anche il principio del mercato: la normativa vale per tutti i prodotti messi a disposizione sul mercato UE, indipendentemente da dove ha sede il produttore. Un’azienda con base negli Stati Uniti o in Asia che vende in Italia deve rispettare le stesse regole di un produttore tedesco o francese.<\/p>\n\n\n\n

Restano esclusi alcuni settori gi\u00e0 regolati da normative settoriali specifiche, come dispositivi medici, veicoli e prodotti aeronautici, per evitare sovrapposizioni. Anche i servizi cloud puri, che ricadono sotto la direttiva NIS2, non rientrano direttamente nel CRA, anche se le soluzioni di elaborazione dati a distanza collegate a un prodotto s\u00ec.<\/p>\n\n\n\n

Le tre categorie di rischio: default, importante, critico<\/h2>\n\n\n\n

Il regolamento classifica i prodotti in base al rischio, modulando di conseguenza la severit\u00e0 della valutazione di conformit\u00e0. Esistono tre raggruppamenti: default<\/strong>, importante<\/strong> e critico<\/strong>. La categoria “importante” si divide a sua volta in due classi, comunemente indicate come classe I e classe II.<\/p>\n\n\n\n

La voce di Wikipedia sul regolamento stima che circa il 90% dei prodotti con elementi digitali<\/strong> ricada nella categoria default, per cui i produttori effettuano un’autovalutazione, redigono una dichiarazione di conformit\u00e0 UE e forniscono la documentazione tecnica. Questo dato proviene da una fonte enciclopedica e non dal testo legale, quindi va trattato come stima indicativa. I prodotti “critici”, invece, dovranno superare audit esterni e valutazioni di conformit\u00e0 pi\u00f9 rigorose.<\/p>\n\n\n\n

Categoria<\/th>Esempi indicativi<\/th>Tipo di valutazione<\/th><\/tr><\/thead>
Default (circa 90%)<\/td>App, software gestionali, dispositivi IoT comuni<\/td>Autovalutazione e dichiarazione UE<\/td><\/tr>
Importante classe I<\/td>Gestori di password, VPN, browser, sistemi di rete domestici<\/td>Standard armonizzati o valutazione<\/td><\/tr>
Importante classe II<\/td>Sistemi operativi, firewall, microprocessori, hypervisor<\/td>Valutazione di terza parte<\/td><\/tr>
Critico<\/td>Smart card, HSM, dispositivi sicuri a uso strategico<\/td>Audit esterni e conformit\u00e0 rafforzata<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

La classificazione determina quanto un’azienda dovr\u00e0 investire. Per un produttore di un’app commerciale il percorso resta relativamente snello. Per chi realizza sistemi operativi o firewall, la valutazione di terza parte impone costi e tempi che vanno pianificati con largo anticipo rispetto al 2027.<\/p>\n\n\n\n

Obblighi per produttori, importatori e distributori<\/h2>\n\n\n\n

Il peso maggiore ricade sui produttori. Devono rispettare i requisiti essenziali di cibersicurezza nella pianificazione, progettazione, sviluppo e manutenzione del prodotto, lungo tutta la catena del valore. Tra gli obblighi figurano la valutazione del rischio prima dell’immissione sul mercato, la gestione delle vulnerabilit\u00e0 per l’intero periodo di supporto e la fornitura di aggiornamenti di sicurezza.<\/p>\n\n\n\n

Un punto rilevante riguarda gli aggiornamenti automatici. Il software per cui ci si attende ragionevolmente l’aggiornamento automatico dovr\u00e0 distribuire le patch di sicurezza per impostazione predefinita, lasciando agli utenti la possibilit\u00e0 di disattivarle. Quando possibile, gli aggiornamenti di sicurezza vanno separati da quelli funzionali. Le aziende devono inoltre conservare documentazione e inventario dei dati per 10 anni<\/strong> dopo l’immissione sul mercato o per la durata del periodo di supporto, se pi\u00f9 lunga.<\/p>\n\n\n\n

Importatori e distributori non sono spettatori. Secondo l’analisi di Cycode, devono verificare che i prodotti siano conformi, dotati di documentazione tecnica e marcatura CE prima di immetterli in circolazione. La responsabilit\u00e0, quindi, si distribuisce lungo l’intera filiera, un meccanismo che richiama da vicino le logiche gi\u00e0 viste negli attacchi alla supply chain<\/a> che hanno colpito centinaia di aziende.<\/p>\n\n\n\n

Reporting a ENISA: la Single Reporting Platform e la regola delle 24 ore<\/h2>\n\n\n\n

Il cuore operativo del 2026 \u00e8 l’obbligo di segnalazione. A partire dall’11 settembre, i produttori dovranno notificare le vulnerabilit\u00e0 attivamente sfruttate e gli incidenti gravi che compromettono riservatezza, integrit\u00e0 o disponibilit\u00e0 del prodotto. La segnalazione passa per la Single Reporting Platform<\/strong> di ENISA, l’Agenzia dell’Unione europea per la cibersicurezza, e va trasmessa anche al CSIRT nazionale competente.<\/p>\n\n\n\n

La tempistica \u00e8 stringente. Le fonti indicano un meccanismo di allerta precoce entro 24 ore<\/strong> dalla scoperta di una vulnerabilit\u00e0 sfruttata o di un incidente grave. La voce enciclopedica sul regolamento conferma l’obbligo di notificare ENISA entro 24 ore dalla presa di consapevolezza. La formulazione esatta delle finestre temporali successive resta da consolidare nelle linee guida attuative, ma la direzione \u00e8 chiara: la trasparenza sulle vulnerabilit\u00e0 diventa obbligo di legge, non scelta volontaria.<\/p>\n\n\n\n

Questa architettura avvicina il CRA al modello di segnalazione gi\u00e0 introdotto per il settore finanziario dal Regolamento DORA<\/a> e alla logica della direttiva NIS2. La differenza \u00e8 il perimetro: il cyber resilience act<\/strong> non guarda alle organizzazioni critiche, ma ai prodotti, spostando l’obbligo direttamente sui produttori di tecnologia.<\/p>\n\n\n\n

Marcatura CE e valutazione di conformit\u00e0<\/h2>\n\n\n\n

La marcatura CE \u00e8 il simbolo pi\u00f9 visibile del regolamento. I prodotti che soddisfano i requisiti del CRA dovranno apporre la marcatura CE per indicare la conformit\u00e0, esattamente come accade da decenni per la sicurezza elettrica o meccanica. Secondo la Commissione europea, i prodotti che recano la marcatura CE garantiranno “un livello minimo di controlli di cibersicurezza”.<\/p>\n\n\n\n

Il regolamento si inserisce nel quadro della sorveglianza del mercato dell’Unione, modificando l’allegato I del Regolamento (UE) 2019\/1020 in modo che le autorit\u00e0 nazionali coordinino controlli e azioni congiunte transfrontaliere. Le verifiche, in altre parole, non saranno isolate per Stato, ma potranno tradursi in campagne coordinate a livello europeo. Per un’azienda significa che un prodotto bloccato in un Paese pu\u00f2 esserlo rapidamente in tutti gli altri.<\/p>\n\n\n\n

Autovalutazione contro valutazione di terza parte<\/h3>\n\n\n\n

Il livello di scrutinio dipende dalla categoria di rischio. Per la maggioranza dei prodotti, l’autovalutazione accompagnata dalla dichiarazione di conformit\u00e0 UE \u00e8 sufficiente. Per i prodotti importanti di classe II e per quelli critici interviene un organismo notificato. \u00c8 qui che diventa rilevante la scadenza dell’11 giugno 2026: senza organismi di valutazione notificati e operativi, l’intera macchina della conformit\u00e0 non pu\u00f2 funzionare in tempo per il 2027.<\/p>\n\n\n\n

Multe fino a 15 milioni di euro: il regime sanzionatorio<\/h2>\n\n\n\n

Le sanzioni danno mordente al regolamento. La violazione dei requisiti essenziali o degli obblighi di segnalazione pu\u00f2 comportare multe fino a 15 milioni di euro<\/strong> o al 2,5% del fatturato mondiale annuo totale<\/strong> dell’esercizio precedente, a seconda di quale importo sia pi\u00f9 elevato. La cifra colloca il CRA nella stessa fascia di severit\u00e0 del GDPR e dei principali strumenti regolatori digitali europei.<\/p>\n\n\n\n

Le sanzioni sono modulate. Le violazioni meno gravi, come la mancata collaborazione con le autorit\u00e0 o la documentazione incompleta, prevedono soglie inferiori. Resta per\u00f2 il principio: per un’azienda con fatturato miliardario, il 2,5% pu\u00f2 superare di gran lunga i 15 milioni, rendendo l’inadempienza un rischio finanziario di prima grandezza. La sorveglianza del mercato e i meccanismi nazionali di enforcement completano il quadro.<\/p>\n\n\n\n

Tipo di violazione<\/th>Sanzione massima<\/th>Base di calcolo<\/th><\/tr><\/thead>
Requisiti essenziali e obblighi produttori<\/td>15 milioni \u20ac o 2,5% fatturato<\/td>Fatturato mondiale annuo, esercizio precedente<\/td><\/tr>
Altri obblighi del regolamento<\/td>10 milioni \u20ac o 2% fatturato<\/td>Fatturato mondiale annuo<\/td><\/tr>
Informazioni inesatte o incomplete<\/td>5 milioni \u20ac o 1% fatturato<\/td>Fatturato mondiale annuo<\/td><\/tr>
Sviluppatori open source non commerciali<\/td>Nessuna multa<\/td>Esclusi dal regime sanzionatorio<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Open source: come il CRA tratta gli “steward”<\/h2>\n\n\n\n

Uno dei temi pi\u00f9 dibattuti durante l’iter legislativo \u00e8 stato il trattamento del software libero. La comunit\u00e0 open source temeva che obblighi di conformit\u00e0 pensati per i grandi produttori finissero per schiacciare i progetti volontari. Il testo finale introduce la figura dello steward open source<\/strong> e, secondo le fonti disponibili, esclude gli sviluppatori open source non commerciali dal regime sanzionatorio. La voce enciclopedica conferma che le multe non si applicano agli sviluppatori open source non commerciali.<\/p>\n\n\n\n

La portata esatta degli obblighi degli steward e la definizione giuridica della figura non sono ancora del tutto chiarite nelle fonti pubbliche, e attendono le linee guida attuative. Il principio, per\u00f2, segna un compromesso: distinguere chi sviluppa software come attivit\u00e0 economica da chi contribuisce a un bene comune digitale senza scopo di lucro. Per l’ecosistema europeo, dove molte infrastrutture poggiano su componenti open source, \u00e8 una distinzione tutt’altro che marginale.<\/p>\n\n\n\n

Impatto sul mercato e sulle aziende europee<\/h2>\n\n\n\n

L’effetto del cyber resilience act<\/strong> sul mercato \u00e8 profondo perch\u00e9 agisce sulla condizione stessa di vendita. Senza conformit\u00e0, niente marcatura CE; senza marcatura CE, niente accesso al mercato unico da quasi 450 milioni di consumatori. Questo trasforma la cibersicurezza in un fattore competitivo: chi si adegua prima conquista un vantaggio, chi resta indietro rischia l’esclusione.<\/p>\n\n\n\n

Le fonti consultate non forniscono una stima ufficiale e verificabile dei costi di conformit\u00e0 complessivi n\u00e9 del numero esatto di prodotti o aziende coinvolte. Su questo punto \u00e8 doveroso non avventurarsi in numeri non confermati. \u00c8 per\u00f2 ragionevole attendersi un impatto significativo sulle piccole e medie imprese, che dispongono di risorse limitate per documentazione tecnica, gestione delle vulnerabilit\u00e0 e valutazioni di conformit\u00e0. La gradualit\u00e0 delle scadenze nasce proprio per attenuare questo squilibrio.<\/p>\n\n\n\n

Sul fronte opposto, il regolamento crea un mercato per servizi di compliance, audit e gestione delle vulnerabilit\u00e0. Gli organismi notificati, i consulenti e i fornitori di piattaforme di sicurezza vedono aprirsi una domanda strutturale. Lo stesso vale per le competenze interne: profili capaci di gestire il ciclo di vita della sicurezza di un prodotto diventano una risorsa scarsa e contesa.<\/p>\n\n\n\n

CRA, NIS2, DORA e Cybersecurity Act 2.0: come si incastrano<\/h2>\n\n\n\n

Il CRA non vive isolato. Si inserisce in un mosaico di norme europee sulla cibersicurezza che, viste insieme, ridisegnano il rapporto tra tecnologia e responsabilit\u00e0 legale. La direttiva NIS2 regola le organizzazioni che gestiscono servizi essenziali. Il Regolamento DORA si concentra sul settore finanziario. Il cyber resilience act<\/strong>, invece, guarda ai prodotti.<\/p>\n\n\n\n

A questo quadro si aggiunge il pacchetto presentato dalla Commissione il 20 gennaio 2026, ribattezzato dagli analisti “Cybersecurity Act 2.0”, che propone di rafforzare ENISA e semplificare la certificazione. Le riforme della certificazione, secondo le analisi, mirano ad allinearsi proprio al CRA per ridurre gli oneri amministrativi e migliorare la coerenza tra le diverse leggi. Chi vuole approfondire pu\u00f2 leggere la nostra analisi sul Cybersecurity Act 2.0<\/a> e sul Regolamento DORA<\/a>.<\/p>\n\n\n\n

La sovrapposizione tra queste norme \u00e8 anche fonte di complessit\u00e0. Un’azienda finanziaria che produce software, per esempio, pu\u00f2 trovarsi a dover rispettare contemporaneamente DORA, NIS2 e CRA. La semplificazione promessa dal pacchetto di gennaio nasce per ridurre questa frammentazione, ma il percorso legislativo \u00e8 appena iniziato.<\/p>\n\n\n\n

Cosa significa per l’Italia e l’ACN<\/h2>\n\n\n\n

In Italia il regolamento si innesta su un’architettura nazionale gi\u00e0 strutturata. L’Agenzia per la Cybersicurezza Nazionale (ACN)<\/strong> coordina la strategia di sicurezza del Paese e ospita il CSIRT Italia, il punto di riferimento per la gestione degli incidenti. Con l’avvio degli obblighi di segnalazione dell’11 settembre 2026, il CSIRT nazionale diventa il canale verso cui i produttori italiani indirizzeranno le notifiche, in parallelo alla piattaforma ENISA.<\/p>\n\n\n\n

Le fonti consultate non offrono cifre specifiche e verificate sull’impatto del CRA per l’Italia o sui costi di adeguamento per l’ACN, quindi evitiamo proiezioni non confermate. Sul piano qualitativo, per\u00f2, l’effetto \u00e8 chiaro: il sistema produttivo italiano, ricco di PMI manifatturiere che integrano componenti digitali nei propri prodotti, dovr\u00e0 colmare in fretta un divario di competenze e processi. Il coordinamento tra ACN, autorit\u00e0 di sorveglianza del mercato ed ENISA sar\u00e0 decisivo per evitare che le imprese pi\u00f9 piccole restino schiacciate dagli adempimenti.<\/p>\n\n\n\n

Il tessuto industriale italiano, dalla domotica all’automazione di fabbrica, \u00e8 esposto in pieno. Un produttore di elettrodomestici connessi, di centraline industriali o di software gestionale rientra senza ambiguit\u00e0 nel perimetro del cyber resilience act<\/strong>. Per molte di queste realt\u00e0, abituate a competere sulla qualit\u00e0 del prodotto fisico, la sicurezza del software diventa un terreno nuovo.<\/p>\n\n\n\n

Contesto storico: dalla sicurezza fisica al “secure by design”<\/h2>\n\n\n\n

Per capire la portata del CRA conviene guardare indietro. La marcatura CE nasce negli anni Ottanta e Novanta per garantire che i prodotti fisici venduti in Europa rispettassero standard minimi di sicurezza, dalla compatibilit\u00e0 elettromagnetica alla resistenza meccanica. Per decenni, per\u00f2, la sicurezza informatica dei prodotti \u00e8 rimasta fuori da questo schema. Un dispositivo poteva essere perfettamente sicuro dal punto di vista elettrico e completamente vulnerabile sul piano digitale.<\/p>\n\n\n\n

Gli ultimi anni hanno reso insostenibile questa lacuna. Botnet costruite su dispositivi IoT non aggiornati, vulnerabilit\u00e0 in router e telecamere, attacchi che sfruttano software dimenticato dai produttori: la superficie d’attacco \u00e8 esplosa con la diffusione dei dispositivi connessi. Il CRA \u00e8 la risposta strutturale dell’Unione, lo stesso impulso che ha guidato l’attenzione crescente verso temi come la minaccia ransomware<\/a> e la resilienza collettiva testata in esercizi come Cyber Europe 2026<\/a>.<\/p>\n\n\n\n

Il principio del “secure by design” sposta la responsabilit\u00e0 a monte. Non \u00e8 pi\u00f9 l’utente a doversi proteggere da un prodotto insicuro, ma il produttore a dover garantire la sicurezza fin dalla progettazione. \u00c8 un cambio di paradigma che allinea la sicurezza digitale agli standard che da tempo regolano la sicurezza fisica.<\/p>\n\n\n\n

Previsioni: cosa aspettarsi entro il 2027<\/h2>\n\n\n\n

Sulla base del quadro normativo e delle dinamiche di mercato, emergono alcune previsioni ragionevoli per i prossimi diciotto mesi.<\/p>\n\n\n\n