Il Cyber Resilience Act cambia il modo in cui produttori, importatori e vendor devono gestire la sicurezza dei prodotti con elementi digitali. Il caso di un router vulnerabile e mai aggiornato mostra perché il nuovo quadro europeo punta a spostare la responsabilità verso chi progetta e immette questi dispositivi sul mercato.
Indice degli argomenti
Un router, una vulnerabilità e nessuno a risponderne
Nei primi mesi del 2025 è stata pubblicata la CVE-2025-29635, relativa al router D-Link DIR-823X. La vulnerabilità è una command injection che consente di eseguire comandi arbitrari sul dispositivo con privilegi di root, inviando una richiesta appositamente costruita all’interfaccia di gestione del router.
Formalmente classificata come ad alto rischio, nella pratica si è rivelata sfruttabile anche senza credenziali di accesso valide. La patch non è mai arrivata.
Il DIR-823X era già in fase di dismissione quando la vulnerabilità è stata scoperta e resa pubblica. D-Link ha dichiarato il dispositivo End of Life nel settembre 2025, pochi mesi dopo la divulgazione della CVE, rendendo definitivo ciò che molti utenti non avevano ancora realizzato: nessuna patch sarebbe mai arrivata. Nel frattempo il dispositivo continuava a essere ampiamente utilizzato, in reti domestiche e piccole realtà aziendali che non avevano motivo di sostituire un apparato funzionante. È in questo vuoto, tra una vulnerabilità nota e un produttore che aveva già voltato pagina, che lo sfruttamento attivo si è fatto strada. Traduzione pratica: il tuo router, che funzionava perfettamente, era diventato un nodo di attacco distribuito e la soluzione offerta era comprarne uno nuovo.
Questa storia non è eccezionale. Era il funzionamento ordinario di un mercato in cui il costo dell’insicurezza informatica ricadeva sistematicamente su chi acquista, non su chi produce: non per scelta deliberata, ma perché nessuna norma imponeva diversamente.
La domanda scomoda: chi era responsabile?
La risposta obiettiva è che, nella pratica, non lo era quasi nessuno. Non per malafede, ma per struttura.
Il quadro normativo precedente al CRA non prevedeva alcun obbligo di supporto minimo post-vendita per i prodotti con elementi digitali (PED) destinati al mercato consumer. Un produttore poteva decidere autonomamente quando terminare il supporto a un dispositivo, senza alcun obbligo di notifica preventiva agli utenti e senza conseguenze giuridiche dirette derivanti da vulnerabilità non corrette.
Per un utente che avesse voluto agire in giudizio, la situazione era ancora più complicata: la responsabilità del prodotto ex Direttiva 85/374/CEE richiedeva di dimostrare che il prodotto fosse difettoso al momento della messa in commercio, non che lo fosse diventato successivamente per mancanza di aggiornamenti. Il software non rientrava esplicitamente nell’ambito della direttiva nella sua formulazione originale. Le vulnerabilità scoperte anni dopo la vendita erano difficilmente qualificabili come difetti originari[1]. Le autorità di sorveglianza del mercato non avevano strumenti normativi per intervenire sulla gestione post-vendita della sicurezza.
Il risultato era prevedibile: il costo di una vulnerabilità non corretta ricadeva sull’utente finale, sulla sua rete domestica o aziendale e, quando i dispositivi compromessi venivano arruolati in botnet, sulla collettività. Il produttore che aveva risparmiato sul ciclo di sviluppo sicuro non pagava nessun prezzo direttamente misurabile.
Quando la sicurezza non ha prezzo, il costo lo paga qualcun altro
Il mercato consumer dei dispositivi IoT non premia adeguatamente la sicurezza: i confronti tra prodotti si fanno su prezzo, funzionalità e design, raramente sulla qualità del programma di aggiornamenti.
C’è un principio economico elementare sotto questa dinamica, ed è utile esplicitarlo, perché spiega molto bene il “motivo” dell’adozione del CRA.
Quando il costo di un’esternalità negativa, come il danno causato da un dispositivo compromesso, non ricade su chi produce ma su chi usa o sulla collettività, il produttore non ha incentivi economici adeguati a investire in sicurezza oltre la soglia minima percepita dal mercato. E il mercato consumer dei dispositivi non premia adeguatamente la sicurezza: i confronti tra prodotti si fanno su prezzo, funzionalità e design, raramente sulla qualità del programma di aggiornamenti o sulla durata garantita del supporto.
Il risultato storico è stato un ecosistema di miliardi di dispositivi connessi con firmware non aggiornato, vulnerabilità note non corrette e nessun meccanismo di mercato che spingesse a cambiarlo. Mirai[2] nel 2016 ne ha fatto un caso mondiale, trasformando telecamere IP e router domestici in un’infrastruttura di attacco distribuito capace di mettere in ginocchio larga parte dell’internet statunitense. La struttura del problema è rimasta intatta per anni dopo.
Il CRA è un intervento correttivo di questa distorsione. Non è una questione di burocrazia aggiuntiva: è la decisione politica di spostare il baricentro del rischio verso chi è nella posizione migliore per gestirlo, ossia chi progetta e produce il prodotto.
Il produttore non può più voltarsi dall’altra parte
Il Cyber Resilience Act stabilisce requisiti essenziali di sicurezza per tutti i prodotti con elementi digitali immessi sul mercato UE. La formulazione è volutamente ampia: copre router, smart TV, termostati connessi, NAS domestici, dispositivi industriali con componenti software. Non copre i prodotti già disciplinati da regimi settoriali specifici, come i dispositivi medici o i sistemi avionici, che hanno regimi propri.
Quattro obblighi in particolare ridisegnano il quadro degli obblighi e delle responsabilità[3].
Sicurezza by default: un requisito essenziale, non una “semplice” best practice volontaria. Il prodotto deve essere progettato, sviluppato e prodotto in modo da garantire un livello appropriato di sicurezza rispetto ai rischi che può presentare; ciò include superfici di attacco ridotte, autenticazione predefinita sicura, protezione da accessi non autorizzati. Se il prodotto non soddisfa questi requisiti, non può essere immesso sul mercato UE.
Obbligo di aggiornamenti di sicurezza per tutta la durata di vita attesa del prodotto: il Regolamento impone ai produttori di garantire che le vulnerabilità vengano affrontate tramite aggiornamenti di sicurezza per tutta la durata di vita attesa del prodotto, con un minimo di cinque anni. Gli aggiornamenti devono poter essere installati automaticamente entro un termine appropriato, abilitati per impostazione predefinita, con la possibilità per l’utente di disattivarli o posticiparne l’installazione tramite un meccanismo chiaro e accessibile. Un produttore non può più decidere unilateralmente di terminare il supporto sei mesi dopo la vendita. Deve garantire che le vulnerabilità vengano corrette per il periodo minimo stabilito e deve comunicare in modo trasparente quando questo periodo termina.
Notifica obbligatoria delle vulnerabilità attivamente sfruttate entro 24 ore da quando se ne viene a conoscenza: un elemento che cambia radicalmente la gestione interna delle vulnerabilità: non basta descrivere i processi di detection e escalation in una policy, occorre che esistano e funzionino davvero[4].
Gestione della Software Bill of Materials (SBOM): i produttori devono essere in grado di identificare e documentare le componenti software presenti nel prodotto, incluse quelle open source, per poter verificare e comunicare quando una vulnerabilità colpisce una componente specifica. Questa “distinta” non è solo un documento: è la precondizione tecnica per rispettare gli obblighi di notifica e aggiornamento.
Il CRA crea responsabilità civile? La risposta è: dipende
Una domanda che talvolta viene elusa o sottostimata è questa: la non conformità al CRA crea responsabilità civile in capo al produttore nei confronti dell’utente danneggiato?
La risposta è che il CRA non crea direttamente un diritto di agire per il singolo consumatore. Le sanzioni per non conformità sono pubbliche, irrogate dalle market surveillance authorities (MSA) e possono arrivare fino a 15 milioni di euro o al 2,5% del fatturato globale annuo.
Il meccanismo di responsabilità civile passa per un percorso indiretto: entra qui in gioco la Direttiva 2024/2853/UE sulla responsabilità del prodotto[5], che ha sostituito la Direttiva 85/374/CEE con modifiche sostanziali. La direttiva, infatti, include esplicitamente il software tra i prodotti, estende il concetto di difettosità a quelli che non ricevono aggiornamenti di sicurezza necessari e introduce meccanismi di disclosure che rendono più accessibili le prove che il consumatore normalmente non riesce a ottenere.
Un produttore con una non conformità accertata ai requisiti CRA si trova in una posizione processuale significativamente più esposta rispetto a quella che aveva sotto il vecchio regime.
Il punto di connessione è: un prodotto che non rispetta i requisiti essenziali del CRA è, per definizione, un prodotto che non garantisce il livello di sicurezza che ci si poteva legittimamente aspettare alla luce della normativa vigente. Questa non conformità, una volta accertata, diventa un elemento probatorio rilevante, forse decisivo, in un’azione di responsabilità del prodotto fondata sulla direttiva 2024/2853/UE.
Tre avvertenze sono però necessarie. Prima: la prassi giurisprudenziale su questo meccanismo non esiste ancora, perché il CRA entra in piena applicazione nel dicembre 2027 e la nuova direttiva Product Liability è di recepimento recente. Non si può affermare con sicurezza come i tribunali nazionali applicheranno questo collegamento. Seconda: il nesso causale tra non conformità al CRA e danno specifico dovrà comunque essere dimostrato e non è automatico. Terza: la direttiva 2024/2853/UE prevede una distribuzione dell’onere probatorio più favorevole al danneggiato rispetto alla disciplina precedente, ma non elimina la necessità di provare il danno.
Ciò che si può dire con ragionevole certezza è che un produttore con una non conformità accertata ai requisiti CRA si trova in una posizione processuale significativamente più esposta di quella che aveva sotto il vecchio regime.
Hai comprato un router cinese su Amazon: chi risponde adesso?
Il CRA non distribuisce la responsabilità in modo binario tra chi produce e chi usa. Prevede una catena articolata di soggetti obbligati che include produttori, importatori, distributori e, per il software open source, una figura normativa inedita come quella dello steward[6]. Ma la logica è sempre la stessa: l’obbligo ricade su chi è nella posizione concreta di garantirne il rispetto.
Questa logica produce conseguenze immediate per chiunque immetta sul mercato italiano prodotti con elementi digitali fabbricati fuori dall’Unione. Il CRA si applica a tutti i prodotti con elementi digitali commercializzati nel mercato UE, indipendentemente dall’origine del produttore. Un router prodotto in Cina e venduto in Italia è soggetto agli stessi requisiti di uno prodotto in Germania. La differenza sta in chi risponde quando il produttore non è raggiungibile.
Quando il produttore extra-UE non ha un rappresentante autorizzato designato nell’Unione, il CRA individua nell’importatore il soggetto obbligato in via sussidiaria che, in questo contesto, non è necessariamente il grande distributore: può essere anche il rivenditore che acquista prodotti consumer da fornitori asiatici e li rivende sul mercato italiano, anche tramite marketplace, se lo fa in modo continuativo e professionale.
Questo significa che chi vende router, telecamere IP, hub smart home di marca extra-UE sul mercato italiano, senza che il produttore abbia un rappresentante europeo designato, assume rispetto a quel prodotto una serie di obblighi che prima erano solo del produttore. Deve verificare che il prodotto soddisfi i requisiti essenziali. Deve essere in grado di tracciare il prodotto e comunicare con l’autorità di sorveglianza. Deve segnalare le vulnerabilità. Non può mettere sul mercato un prodotto non conforme solo perché il produttore ha sede fuori dall’UE.
Le implicazioni contrattuali sono, di conseguenza, dirette: chi importa PED da fornitori extra-UE deve rivedere i contratti di fornitura per includere obblighi di conformità CRA in capo al fornitore, clausole di indennizzo per non conformità accertata e meccanismi che garantiscano l’accesso alle informazioni tecniche necessarie per rispettare gli obblighi di notifica. Un contratto di fornitura standard costruito prima del CRA, con clausole generiche sulla qualità del prodotto, non offre nessuna protezione adeguata in questo scenario.
Le domande che i vendor dovrebbero già porsi
Il CRA è già in vigore. La piena applicazione scatta nel dicembre 2027, con alcuni obblighi di notifica delle vulnerabilità che entrano in vigore anticipatamente nel settembre 2026. Il tempo non è abbondante, quindi, e le valutazioni da fare non sono solo tecniche.
La supply chain del software: un produttore che utilizza componenti open source o librerie di terze parti nel proprio firmware e non ha un inventario aggiornato di queste componenti, difficilmente può rispettare l’obbligo di notifica nei tempi richiesti. Arduo sapere in 24 ore se una vulnerabilità appena scoperta colpisce il proprio prodotto, se non si sa con precisione cosa c’è dentro. La “distinta” SBOM non è quindi un documento burocratico, ma un prerequisito tecnico di compliance.
La contrattualistica con i fornitori: i contratti con i fornitori di componenti hardware e software devono includere obblighi di notifica delle vulnerabilità, diritti di audit sulla sicurezza e clausole di responsabilità per non conformità ai requisiti CRA che si ripercuotano sul prodotto finale. Un produttore conforme che compra componenti da un fornitore non conforme ha comunque un problema e la responsabilità finale di fronte all’autorità di sorveglianza è sua.
La comunicazione verso gli utenti finali: il CRA richiede che il produttore metta a disposizione degli utenti informazioni chiare sul ciclo di vita del supporto, sulle modalità di ricezione degli aggiornamenti e su cosa fare quando il supporto termina. Questa comunicazione non può essere relegata a una riga nelle condizioni generali: deve essere accessibile, verificabile e aggiornata. Un’informazione inadeguata sul fine vita del prodotto è una non conformità certa.
Quello che il CRA non dice ancora
Alcune questioni rimangono aperte, a nostro avviso.
La prima riguarda la definizione operativa di “vita attesa del prodotto” per categorie merceologiche prive di standard consolidati. Il Regolamento stabilisce che il periodo minimo di supporto è cinque anni, salvo che la vita attesa del prodotto sia inferiore e che si applica il periodo maggiore tra quello dichiarato dal produttore e il minimo legale. Ma chi determina la vita attesa di un hub domotico consumer, di uno smartwatch, di un router di fascia bassa? Le organizzazioni europee di standardizzazione stanno lavorando su standard tecnici armonizzati, ma non sono ancora disponibili per tutte le categorie rilevanti. Nel frattempo, i produttori devono fare valutazioni caso per caso con un livello di certezza normativa limitato, sapendo che dichiarare volontariamente un periodo di supporto superiore ai cinque anni li vincola a rispettarlo
La seconda riguarda il coordinamento tra autorità nazionali di sorveglianza del mercato. Per l’Italia, l’autorità competente in via principale per i prodotti generali è il MIMIT, ma le strutture dedicate alla gestione dei prodotti con elementi digitali non sono ancora pienamente operative. I tempi reali di enforcement sono conseguentemente incerti.
La terza, che interessa le organizzazioni che sono contemporaneamente produttrici di prodotti con elementi digitali e soggetti NIS2, è il coordinamento tra i due regimi. Ci sono sovrapposizioni negli obblighi di notifica degli incidenti e delle vulnerabilità e la relazione tra i due sistemi non è ancora chiarita in modo definitivo nelle linee guida applicative.
Il CRA è un regolamento con una logica interna coerente e un obiettivo chiaramente identificabile. Ma entra in vigore in un ecosistema produttivo, normativo e istituzionale che non era pronto ad applicarlo il giorno della pubblicazione. La distanza tra il testo normativo e la sua applicazione concreta si misurerà nei prossimi anni. Chi ha già cominciato a costruire i processi si troverà in una posizione molto più gestibile di chi aspetta che le autorità inizino a sanzionare[7].
Note
[1] L’impianto normativo era pensato per i beni analogici (ad esempio un’auto che esce dalla fabbrica con i freni difettosi). Applicato al software, questo paradigma creava un paradosso: se una vulnerabilità zero-day veniva scoperta due anni dopo il rilascio, per la normativa precedente il prodotto era “nato sano” e si era “deteriorato” (o diventato insicuro) solo successivamente: il produttore andava quindi esente da responsabilità. Non solo, perché dottrina e giurisprudenza prevalenti consideravano “prodotto” solo il software embedded (es. il firmware di una lavatrice) o quello venduto su supporto fisico (i vecchi CD-ROM). Il software scaricato digitalmente, i siti web, le app o le architetture SaaS fluttuavano in un limbo in cui si applicava, al massimo, la responsabilità contrattuale per vizi della cosa o inadempimento, ma non la tutela rigorosa della responsabilità oggettiva da prodotto difettoso a favore del consumatore.
[2] https://www.cloudflare.com/it-it/learning/ddos/glossary/mirai-botnet/
[3] Vedi, in particolare, l’Annex I, Essential cybersecurity requirements.
[4] Cfr. Art. 14 CRA
[5] Product Liability Directive (PLD):https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202402853.
[6] https://www.cybersecurity360.it/legal/cyber-resilience-act-ecco-come-le-imprese-dovranno-adeguarsi/
[7] Il CRA (Regolamento UE 2024/2847) è in vigore dall’undici dicembre 2024. Gli obblighi di notifica delle vulnerabilità si applicano dal 11 settembre 2026. La piena applicazione degli obblighi per i produttori decorre dall’undici dicembre 2027. La Direttiva 2024/2853/UE sulla responsabilità del prodotto ha aggiornato il regime precedente includendo esplicitamente il software e i prodotti con componenti digitali. La prassi applicativa di entrambi gli strumenti è ancora in fase di formazione.
