Un fabbricante scopre che una libreria presente nei propri apparati consente un accesso non autorizzato. Gli sviluppatori preparano la correzione, ma il responsabile dell’assistenza incontra un problema diverso: la libreria è stata usata per anni, con modifiche successive, e l’elenco dei prodotti installati presso i clienti non permette di risalire alla versione effettiva. Alcuni apparati sono stati aggiornati dal distributore; altri lavorano in stabilimenti nei quali un fermo deve essere concordato con settimane di anticipo. Il difetto tecnico è stato compreso. Per rimediare, l’impresa deve ora ricostruire la storia commerciale e operativa del prodotto.
È su questo genere di difficoltà che conviene leggere la preparazione dell’assetto italiano del Cyber Resilience Act. Il Consiglio dei ministri del 2 ottobre 2026 ha approvato in esame preliminare lo schema di decreto di adeguamento al regolamento europeo, avviando un passaggio nazionale che riguarda anche l’organizzazione della vigilanza. Alla data del 9 ottobre lo schema va trattato come tale: le disposizioni annunciate richiedono il completamento dell’iter, mentre gli obblighi del regolamento UE 2024/2847 hanno già una propria fonte e un proprio calendario. Attribuire al futuro decreto italiano la nascita di tutti questi obblighi confonderebbe due piani giuridici differenti.
Indice degli argomenti
Cyber Resilience Act in Italia: obblighi e vigilanza sui prodotti
Il CRA porta la sicurezza dentro il rapporto fra chi mette un prodotto sul mercato e chi continua a utilizzarlo. La verifica può riguardare la progettazione, ma anche il modo in cui il fabbricante affronta una vulnerabilità emersa dopo la vendita. Per le imprese abituate a considerare concluso un progetto con la consegna, è un cambiamento che tocca organizzazione, costi e contratti. Una soluzione può essere facile da vendere e molto più difficile da mantenere per il periodo promesso; il preventivo dovrebbe tenerne conto prima che il cliente firmi.
Autorità italiane, sanzioni e valutazione di conformità
La ricostruzione istituzionale dei lavori del Consiglio dei ministri indica ACN come autorità di riferimento per la vigilanza del mercato e richiama il coordinamento con le competenze finanziarie, sull’intelligenza artificiale e sulla protezione dei dati. Sono annunciati il sistema sanzionatorio, le modalità di segnalazione da parte dei consumatori e strumenti di supporto alle imprese minori, compresa una Sandbox-CRA. Il contenuto definitivo e le modalità operative dovranno essere verificati sul testo che completerà l’iter. In particolare, l’annuncio di un ambiente di sperimentazione non equivale già alla disponibilità di un percorso al quale presentare domanda.
Per il fabbricante la novità consiste nell’avvicinarsi di un interlocutore nazionale capace di esercitare i poteri previsti dal quadro europeo. Il regolamento già disciplina la vigilanza e consente di chiedere informazioni pertinenti alla valutazione del prodotto. Ne deriva un’esigenza pratica: l’ufficio che riceverà la richiesta deve poter raggiungere chi conserva la documentazione di progettazione, chi segue i rilasci e chi conosce gli apparati distribuiti. Quando queste informazioni sono separate, anche un’impresa che ha lavorato bene può incontrare difficoltà a dimostrarlo.
La designazione delle autorità e il sistema degli organismi di valutazione della conformità svolgono funzioni diverse. Il percorso di valutazione applicabile dipende dalla categoria del prodotto e dalle condizioni stabilite dal CRA; la vigilanza pubblica può poi accertare la conformità nell’esercizio dei propri poteri. Acquistare una certificazione senza aver chiarito quale oggetto copra e quali effetti produca rispetto al regolamento rischia di generare una falsa sicurezza. Prima del certificato viene la qualificazione del prodotto e della procedura necessaria.
Scadenze del Cyber Resilience Act per i prodotti già sul mercato
Il calendario europeo prevede l’applicazione generale dall’11 dicembre 2027, mentre l’articolo 14 sugli obblighi di segnalazione si applica dall’11 settembre 2026; il capo relativo alla notifica degli organismi di valutazione della conformità ha una decorrenza anteriore. Questo significa che l’impresa non può collocare indistintamente ogni attività alla fine del 2027. Deve verificare che cosa le sia già richiesto, soprattutto quando apprende di una vulnerabilità attivamente sfruttata o di un incidente grave che incida sulla sicurezza del prodotto.
L’articolo 69 contiene inoltre una disciplina transitoria per i prodotti immessi sul mercato prima dell’11 dicembre 2027. L’applicazione dei requisiti va esaminata anche in relazione a eventuali modifiche sostanziali successive, mentre gli obblighi di segnalazione indicati dal regolamento possono riguardare prodotti già immessi sul mercato. La data della prima vendita, da sola, non giustifica quindi l’esclusione di una linea dalla procedura di gestione delle segnalazioni. Occorre una valutazione riferita all’obbligo e al prodotto concreto.
Nel nostro esempio, il fabbricante dovrebbe sapere quando è venuto a conoscenza dello sfruttamento e quali versioni risultano interessate, anche se il modello di apparato è stato lanciato diversi anni prima. Se l’inventario conserva soltanto le caratteristiche dell’ultima serie, ricostruire le altre diventa urgente proprio mentre decorrono termini brevi. Il lavoro sulle versioni storiche può apparire poco redditizio finché non si manifesta il problema; nella preparazione al CRA è una delle attività che meritano di essere finanziate esplicitamente.
Prodotti digitali nel CRA: perimetro, cloud e dipendenze
Un dispositivo connesso può dipendere dal backend del fabbricante per ricevere configurazioni o svolgere una funzione. La definizione europea di prodotto con elementi digitali include le soluzioni di trattamento remoto dei dati quando ricorrono le condizioni previste. Bisogna pertanto ricostruire l’architettura e il rapporto funzionale, senza presumere che tutto il cloud rientri nel CRA o che ne resti fuori per il solo fatto di essere remoto. La qualificazione richiede di spiegare che cosa accadrebbe al prodotto se quella componente venisse meno.
Prendiamo un apparato che controlla un processo industriale e riceve parametri da una piattaforma remota. Se un attaccante altera quei parametri, la sicurezza del dispositivo può essere compromessa anche senza accedere direttamente al suo firmware. Una valutazione limitata all’oggetto fisico lascerebbe fuori il passaggio che consente l’attacco. È lo stesso errore che commetterebbe chi esaminasse la serratura di un magazzino senza considerare chi può ottenere una copia della chiave: l’oggetto visibile attira l’attenzione, mentre la decisione determinante avviene altrove.
Definire il perimetro serve anche a distribuire le responsabilità contrattuali. Il fabbricante potrebbe affidare a un partner lo sviluppo del firmware e a un altro la gestione della piattaforma. Dovrà comunque poter ricostruire come il prodotto soddisfa i requisiti applicabili e come intervenire su ciascuna componente. Se l’assistenza su una parte essenziale termina prima del periodo previsto per il prodotto, il contratto ha creato una dipendenza che la documentazione di conformità deve affrontare, anziché nascondere sotto il nome del subfornitore.
La valutazione dei rischi nelle scelte progettuali
L’articolo 13 collega la valutazione dei rischi di cibersicurezza alla finalità prevista, all’uso ragionevolmente prevedibile e alle condizioni d’impiego. Perché la valutazione sia utile, occorre poter seguire uno scenario fino alla misura adottata e alla prova eseguita. Se il rischio riguarda l’installazione di un aggiornamento contraffatto, per esempio, bisogna capire come il dispositivo verifichi l’autenticità del pacchetto, che cosa accada in caso di errore e come siano protette le credenziali o le chiavi usate per il rilascio.
Questa ricostruzione riguarda anche le limitazioni dichiarate agli utilizzatori. Un requisito ambientale può essere legittimamente rilevante, ma va formulato in modo comprensibile e coerente con l’uso proposto. Vendere un apparato come adatto a impieghi remoti molto ampi e poi fondare la sicurezza sull’assunzione che sia collocato in una rete perfettamente isolata genera una contraddizione sostanziale. Chi acquista deve poter conoscere le condizioni necessarie prima di organizzare l’installazione.
La documentazione commerciale merita dunque un controllo congiunto di chi conosce prodotto e conformità. Spesso una promessa nasce per semplificare la vendita e viene mantenuta per inerzia: compatibilità universale, assenza di manutenzione, assistenza illimitata. Sono espressioni che possono diventare costose quando occorre spiegare quale impiego fosse previsto e quale supporto fosse ragionevolmente atteso. Una descrizione accurata aiuta anche l’assistenza, perché riduce il numero di configurazioni che il cliente considera garantite mentre il fabbricante le ritiene estranee al progetto.
Vulnerabilità e versioni: gli obblighi del Cyber Resilience Act
La distinta dei componenti software, comunemente indicata come SBOM, può aiutare a individuare dove sia presente una libreria. Il CRA la colloca nel contesto della gestione delle vulnerabilità, ma la sua utilità dipende dal collegamento con i prodotti effettivamente distribuiti. Un file generato automaticamente per l’ultima compilazione non risolve il problema delle versioni mantenute in parallelo. Per ogni linea supportata occorre riuscire a individuare i componenti e valutare se una vulnerabilità conosciuta sia pertinente e sfruttabile in quella configurazione.
Neppure la presenza del nome della libreria giustifica una conclusione automatica. Il codice vulnerabile potrebbe non essere utilizzato, oppure l’architettura potrebbe esporlo in condizioni diverse da quelle inizialmente ipotizzate. La valutazione tecnica deve spiegare la decisione e restare collegata alle evidenze. Dire semplicemente «non applicabile» in un foglio di calcolo rende difficile riesaminare il caso quando arriva un’informazione nuova o cambia l’ambiente di utilizzo.
Nel caso iniziale, la prima correzione potrebbe essere disponibile per la versione recente, mentre quella precedente richiede una modifica più ampia. L’impresa dovrà decidere come ridurre temporaneamente l’esposizione, quali indicazioni fornire e con quali tempi completare il lavoro. È una decisione che coinvolge sviluppo e assistenza, ma anche chi conosce gli impegni assunti con i clienti. Se ciascun ufficio dispone di una propria cronologia, il rischio è comunicare una data di soluzione che nessuno ha davvero approvato.
L’articolo 14 prevede, per le fattispecie pertinenti, preallarme entro ventiquattro ore e notifica entro settantadue ore dalla conoscenza, senza indebito ritardo. I termini delle relazioni finali sono differenti: per una vulnerabilità attivamente sfruttata, quattordici giorni dalla disponibilità di una misura correttiva o di attenuazione; per l’incidente grave, un mese dalla notifica richiamata dalla disposizione. Sono tempi che richiedono un canale interno funzionante e persone sostituibili. L’assenza del responsabile del prodotto non può essere il criterio che determina se la segnalazione viene valutata.
Assistenza e filiera dei prodotti nel Cyber Resilience Act
La determinazione del periodo di assistenza tiene conto della durata d’uso prevista e delle ragionevoli aspettative degli utilizzatori. Il regolamento prevede in via generale almeno cinque anni, con la disciplina specifica dei prodotti per i quali la durata prevista sia inferiore. Per un bene destinato a restare in funzione molto più a lungo, il minimo non esaurisce la valutazione. L’impresa dovrebbe poter spiegare perché il periodo scelto sia adeguato al prodotto e al suo mercato.
Mantenere una linea software richiede persone, ambienti di compilazione e componenti disponibili; talvolta dipende da strumenti concessi in licenza o da competenze concentrate presso un unico partner. Se questi elementi vengono dismessi mentre l’assistenza continua a essere promessa, correggere il prodotto può diventare impraticabile. Il piano economico dovrebbe includere la manutenzione delle versioni supportate e le condizioni per conservarne la capacità di intervento. Diversamente, ogni nuova vendita estende un impegno futuro che nessuno ha quantificato.
Anche il modo di distribuire l’aggiornamento conta. In un impianto industriale, installare una correzione può richiedere prove di compatibilità e una finestra di fermo. Il fabbricante deve fornire informazioni sufficienti a consentire una decisione consapevole, segnalando rischi e misure temporanee pertinenti. Il cliente, a sua volta, deve organizzare l’intervento. Affermare che la patch esiste chiude soltanto una parte del problema, soprattutto se i destinatari non sanno di doverla applicare o non riescono a identificarne la versione corretta.
Distributori e contatto con gli utilizzatori
Importatori e distributori hanno obblighi propri e non dovrebbero essere trattati come indirizzari ai quali inoltrare un avviso. I contratti possono chiarire il percorso delle informazioni, la gestione dei reclami e la collaborazione richiesta quando il prodotto presenta un problema. Il fabbricante deve conoscere quanto riesca effettivamente a risalire agli utilizzatori attraverso la rete commerciale; promettere una comunicazione capillare senza avere un canale per effettuarla significa attribuirsi una capacità inesistente.
Un distributore potrebbe aver installato il prodotto con configurazioni diverse o con software aggiuntivo. A seconda dell’intervento, andranno esaminati anche i presupposti della modifica sostanziale e l’eventuale assunzione di obblighi ulteriori. Per prevenire controversie è utile conservare ciò che è stato consegnato, le modifiche autorizzate e le istruzioni disponibili. Questo consente di distinguere il difetto originario da ciò che è accaduto successivamente, senza affidarsi alla memoria di un tecnico o alla versione del contratto rimasta nella posta elettronica.
Documentazione e controlli sui prodotti digitali nel CRA
La gestione del prodotto deve poter sopravvivere al cambiamento delle persone che lo hanno sviluppato. Nelle imprese più piccole, un tecnico può conoscere a memoria le differenze fra le versioni e sapere quali clienti richiedano particolari accorgimenti. Questa competenza è preziosa, ma diventa una dipendenza quando non lascia traccia. Il lavoro di documentazione dovrebbe selezionare le informazioni necessarie a permettere a un collega di intervenire, collegandole agli strumenti già utilizzati per sviluppo e assistenza.
Nel caso di una vulnerabilità, la ricostruzione potrebbe partire dalla segnalazione ricevuta e seguire l’analisi delle versioni interessate, le prove sulla correzione e l’approvazione del rilascio. È utile conservare anche la ragione per cui una versione sia stata esclusa dall’intervento, perché quella decisione potrebbe essere riesaminata sulla base di nuove informazioni. La cronologia deve distinguere ciò che era noto in ciascun momento: giudicare una scelta iniziale usando conoscenze emerse soltanto dopo può alterare la comprensione dei fatti.
Questa disciplina aiuta anche quando il fabbricante decide di cessare una linea o viene acquisito da un’altra impresa. Chi assume la manutenzione deve conoscere gli impegni ancora aperti, le limitazioni dei prodotti e le dipendenze tecniche. Trasferire il codice sorgente senza gli ambienti necessari a compilarlo o senza le istruzioni per distribuire gli aggiornamenti può lasciare la continuità dell’assistenza irrisolta. La verifica di questi elementi dovrebbe entrare nella transizione, con una prova concreta della capacità di produrre e rilasciare una correzione.
Il valore di una documentazione simile emerge anche fuori da un procedimento: riduce il tempo perso a ricostruire decisioni, consente di stimare il costo delle versioni mantenute e rende più attendibili le promesse commerciali. Occorre però mantenerla collegata al lavoro quotidiano. Un fascicolo compilato una volta e abbandonato rischia di descrivere il prodotto con la stessa fedeltà di un vecchio manuale d’officina riferito a un motore successivamente sostituito.
Vigilanza, sanzioni e continuità delle vendite
L’articolo 53 consente, alle condizioni previste, l’accesso alle informazioni necessarie per valutare progettazione, sviluppo, produzione e gestione delle vulnerabilità. Gli interventi dell’articolo 54 possono comprendere misure correttive, ritiro o richiamo, oltre alle limitazioni alla messa a disposizione nei casi contemplati. Per valutare l’esposizione economica bisogna quindi considerare la continuità delle vendite, i costi dell’assistenza straordinaria e la capacità di raggiungere i prodotti distribuiti. Il massimale della sanzione rappresenta soltanto una delle possibili conseguenze.
L’articolo 64 prevede, per le principali violazioni richiamate, sanzioni fino a 15 milioni di euro o al 2,5 per cento del fatturato mondiale annuo, se superiore, con soglie e regole diverse per altre fattispecie. Il futuro assetto nazionale va letto per comprenderne l’applicazione, evitando di attribuire a qualsiasi difetto il massimo previsto. La proporzionalità non elimina però il rilievo di un prodotto che resti sul mercato senza una risposta adeguata a un rischio accertato.
Per un consiglio di amministrazione, una verifica iniziale ragionevole potrebbe consistere nel scegliere una linea di prodotto e simulare il percorso della vulnerabilità descritta all’inizio: identificarne le versioni, decidere la correzione, contattare gli utilizzatori e conservare le ragioni delle scelte. Dove la ricostruzione si interrompe, emerge un intervento da finanziare. Il decreto italiano renderà più definita l’organizzazione dei controlli; il lavoro necessario per sostenere il proprio prodotto, intanto, è già sufficientemente concreto da poter cominciare.
Partecipa alla community