Il Cyber Resilience Act introduce una serie rilevante di obblighi per chi progetta, produce e vende prodotti con componenti digitali. Regole chiare, requisiti di sicurezza obbligatori, responsabilità che non si possono scaricare verso il basso nella filiera.
L’impostazione è nel complesso attesa. Tuttavia, l’analisi dell’art. 2(6) solleva un elemento critico: il regolamento non si applica, dice la disposizione, ai pezzi di ricambio immessi sul mercato per sostituire componenti identici in prodotti con elementi digitali, purché fabbricati secondo le stesse specifiche dei componenti che sono destinati a sostituire.
La logica di questa esenzione è intuitiva: non si può pretendere che ogni vite di ricambio, ogni modulo sostitutivo, ogni componente elettronico di scorta diventi un nuovo prodotto soggetto a nuove procedure di conformità. Il mercato delle riparazioni collasserebbe, così come la gestione complessiva della durabilità dei prodotti.
L’esenzione, però, ha senso per un sensore di temperatura, per un modulo di alimentazione, per un connettore industriale.
Il problema emerge nel momento in cui quel sensore di temperatura contiene un microprocessore. In cui quel modulo di alimentazione gestisce la comunicazione via rete. In cui il connettore industriale dialoga con un sistema di controllo remoto.
Nel mondo connesso di oggi, quasi tutto ha “elementi digitali” e quasi tutto ciò che ha elementi digitali porta con sé, inevitabilmente, uno strato di software.
Indice degli argomenti
Il software che nessuno vede
Un gateway industriale che raccoglie dati da sensori di fabbrica e li trasmette a sistemi di supervisione è, a tutti gli effetti, un prodotto con elementi digitali soggetto al CRA. Fisicamente è una scatola con qualche porta di connessione; internamente contiene un sistema operativo, protocolli di comunicazione, meccanismi di cifratura.
Tutto questo non è scritto da zero dal produttore: è costruito su librerie software, molte delle quali open source, sviluppate da comunità globali di programmatori e mantenute da fondazioni o da singoli sviluppatori.
Lo stesso vale per un contatore elettronico intelligente, per un pannello di controllo di un impianto, per un router industriale.
In ognuno di questi prodotti, il firmware incorpora componenti software di terzi che gestiscono funzioni critiche: la crittografia delle comunicazioni, la gestione dei protocolli di rete, l’autenticazione degli aggiornamenti. Questi componenti sono spesso librerie open source diffuse, usate da milioni di prodotti in tutto il mondo.
Le vulnerabilità non restano ferme, i ricambi sì
Ogni libreria software ha una storia di vulnerabilità. Non perché i suoi sviluppatori siano incompetenti, ma perché il software complesso è inevitabilmente imperfetto e perché gli attaccanti trovano continuamente nuovi modi di sfruttare imperfezioni già presenti.
Le vulnerabilità note vengono catalogate e pubblicate in database aperti con un identificatore standardizzato (CVE[1]) e un punteggio di gravità. Quando una vulnerabilità viene scoperta, il maintainer della libreria rilascia una correzione. I produttori che hanno integrato quella libreria devono aggiornare il proprio firmware per incorporare la correzione.
Fin qui, il sistema funziona. Il produttore aggiorna il firmware, i clienti installano l’aggiornamento, il prodotto rimane sicuro.
Il CRA rafforza questo ciclo imponendo obblighi espliciti[2]: il produttore deve gestire le vulnerabilità per tutta la vita utile del prodotto, deve notificare quelle attivamente sfruttate, deve rilasciare aggiornamenti di sicurezza senza costi aggiuntivi.
Ma il ciclo degli aggiornamenti riguarda i prodotti in uso. Non necessariamente i pezzi di ricambio.
La falla nella logica dell’esenzione
Immaginiamo un pannello di controllo industriale installato nel 2021. Al momento dell’installazione, il firmware incorporava una versione di una libreria di comunicazione considerata sicura. Tempo dopo viene scoperta una vulnerabilità critica in quella libreria: il produttore rilascia un aggiornamento del firmware, il cliente lo installa, il prodotto rimane conforme. Due anni dopo il pannello subisce un guasto fisico: lo schermo non risponde, la scheda madre è danneggiata. Il cliente contatta il produttore per il ricambio.
Il produttore ha due opzioni. Può spedire un pannello di ricambio con il firmware aggiornato, che ha le stesse specifiche hardware ma incorpora la libreria corretta. Oppure può spedire un pannello fabbricato secondo le stesse specifiche originali del 2021, con il firmware cristallizzato alla versione di partenza, vulnerabilità inclusa.
L’art. 2(6) del CRA sull’esenzione per i pezzi di ricambio parla di componenti “fabbricati secondo le stesse specifiche” di quelli da sostituire. Se le specifiche vengono intese come progetto originale (fissato al momento della produzione), il pezzo di ricambio con il firmware vulnerabile è conforme alla disposizione e gode dell’esenzione. Il produttore non deve dimostrare che rispetta i requisiti essenziali di cybersecurity dell’Allegato I del CRA, perché quel pezzo di ricambio non è un nuovo prodotto soggetto al regolamento.
Questo è il paradosso. Il CRA vuole che i prodotti digitali non contengano vulnerabilità note al momento dell’immissione sul mercato. Ma l’art. 2(6) esonera dal CRA i pezzi di ricambio identici e un pezzo di ricambio identico, in un prodotto con elementi digitali, può contenere per definizione quelle stesse vulnerabilità che il regolamento vuole eliminare.
Il software libero rende il problema strutturale
Le linee guida della Commissione[3] sul FOSS nel CRA descrivono in dettaglio il sistema degli “steward”: persone giuridiche che forniscono supporto continuativo allo sviluppo di componenti open source destinati ad attività commerciali.
Gli steward hanno obblighi specifici di notifica delle vulnerabilità. Quando uno steward viene a conoscenza di una vulnerabilità attivamente sfruttata in una libreria che mantiene, deve notificarla all’ENISA e ai CSIRT e in alcuni casi informare direttamente gli utenti del componente.
Questo significa che le vulnerabilità nelle librerie open source più diffuse non sono eventi rari: sono eventi frequenti, pubblici, documentati, notificati alle autorità competenti.
I produttori che integrano quelle librerie lo sanno, perché sono obbligati a monitorarle. Il mercato della sicurezza informatica lo sa, perché le CVE sono pubbliche. Anche gli attaccanti lo sanno, perché leggono gli stessi database.
L’esenzione prevista dall’art. 2(6) interrompe questa catena di responsabilità proprio nel punto in cui dovrebbe restare più solida: il pezzo di ricambio che incorpora la libreria vulnerabile può essere immesso sul mercato senza che il produttore debba dimostrare di aver valutato e mitigato le vulnerabilità note.
La patch esiste, lo steward l’ha pubblicata, il produttore la conosce e l’ha già integrata nel firmware aggiornato del prodotto in linea. Ma nel pezzo di ricambio, quel firmware aggiornato non ci deve necessariamente essere, perché le “stesse specifiche” garantiscono l’esenzione[4].
Che questo non sia uno scenario teorico lo conferma già il comportamento di alcuni produttori di componentistica industriale, che hanno costruito categorie commerciali esplicite attorno all’esenzione: ricambi denominati “conformi al CRA” proprio perché identici all’originale, consigliati per le riparazioni di macchine esistenti e distinti dai prodotti aggiornati raccomandati per le nuove installazioni.
La separazione tra i due mondi, quello del ricambio esente e quello del prodotto conforme, è già nella comunicazione di prodotto. Il tema della vulnerabilità firmware non compare in quella comunicazione.
Chi si trova davanti a questo problema
Non si tratta quindi di una questione teorica riservata ai giuristi. Riguarda in modo diretto almeno tre categorie di operatori.
I produttori di apparecchiature industriali con cicli di vita lunghi, tipicamente di diversi anni, si trovano a gestire un catalogo di ricambi che può contenere decine di versioni firmware. Decidere quale versione mettere nel ricambio e se e come documentarla, è già oggi un problema operativo. Il CRA non lo risolve.
I distributori di ricambi di terze parti, il cosiddetto mercato aftermarket, si trovano in una posizione ancora più delicata. Producono ricambi compatibili basandosi sulle specifiche hardware originali. Non hanno accesso al codice sorgente del firmware originale e in molti casi non hanno la capacità tecnica di valutare lo stato di sicurezza delle librerie che quel firmware incorpora. L’esenzione art. 2(6) li protegge dagli obblighi del CRA, ma non li protegge dalla responsabilità civile se un loro ricambio con firmware vulnerabile viene sfruttato per compromettere un impianto.
I responsabili della sicurezza (CISO, responsabili IT) delle organizzazioni che utilizzano prodotti industriali connessi devono considerare che il loro piano di gestione delle vulnerabilità non si ferma agli aggiornamenti software: deve includere anche la valutazione dei ricambi hardware. Un componente sostitutivo installato dopo anni dall’acquisto originale può riportare indietro la postura di sicurezza dell’intero impianto a uno stato che si riteneva superato.
Un’asimmetria non risolta
Chi progetta la politica di gestione dei ricambi si trova davanti a una scelta normativa scomoda e la ragione è più sottile di quanto sembri.
Il CRA disciplina la cosiddetta modifica sostanziale all’art. 16, rimandando per la definizione all’art. 3(30): è sostanziale la modifica che incide sulla conformità del prodotto ai requisiti essenziali di cybersecurity, oppure che ne muta la destinazione d’uso già valutata.
La Commissione[5] ha precisato che il criterio discriminante è l’effetto sul profilo di rischio del prodotto, non la scala o la complessità tecnica dell’intervento. Un aggiornamento che elimina vulnerabilità note senza introdurre nuove funzionalità, nuovi vettori di minaccia o nuovi scenari di attacco non è, in linea generale, una modifica sostanziale: il produttore che lo rilascia non è obbligato a ripetere l’intera procedura di conformità. Il sistema, su questo punto, funziona nel modo giusto: l’incentivo a correggere le vulnerabilità non viene penalizzato da oneri normativi aggiuntivi.
Questa logica, però, vale per i prodotti già nell’ambito del CRA. I pezzi di ricambio esenti ex art. 2(6) sono fuori da quel perimetro: non c’è modifica sostanziale da valutare perché non c’è mai stata una valutazione di conformità iniziale. Il produttore che aggiorna il firmware del ricambio deve rispondere a una domanda preliminare e più netta: il ricambio aggiornato è ancora “identico” all’originale ai sensi dell’art. 2(6)? Se cade l’identità, cade l’esenzione e il CRA tratta il ricambio modificato come un prodotto nuovo, soggetto all’intera procedura di conformità iniziale.
La Commissione ha costruito, per i prodotti nel perimetro del regolamento, una distinzione ragionevole: un aggiornamento che migliora la sicurezza senza aggiungere rischi non è problematico. Non ha però trasferito quella stessa logica alla norma sull’esenzione dei ricambi, dove “identico” e “stesse specifiche” restano privi di una gradazione che tenga conto della direzione della modifica.
Per coerenza, un security patch che riduce il profilo di rischio senza alterare funzionalità o destinazione d’uso non dovrebbe rendere il ricambio “non identico”. Ma, in mancanza di indicazioni esplicite, il produttore che aggiorna il firmware del ricambio naviga in un’area interpretativa ancora incerta.
Il risultato sembra dunque essere quello di un sistema in cui il comportamento più prudente, lasciare il firmware invariato per non rischiare di perdere l’esenzione, non coincide con quello più sicuro.
La domanda aperta
La Commissione non ha ancora chiarito se “stesse specifiche” per un prodotto con elementi digitali includa o escluda lo stato di sicurezza del software incorporato. Le linee guida, peraltro, offrono un argomento che va nella direzione opposta alla tesi del paradosso e che merita di essere affrontato.
Esse stabiliscono, infatti, che il pezzo di ricambio non identico al componente originale costituisce un prodotto a sé stante, soggetto al CRA e che la sua conformità va valutata alla luce della destinazione d’uso.
Da questo si potrebbe ricavare che il ricambio con firmware aggiornato, se mantiene inalterata la funzionalità e non altera la destinazione d’uso rispetto al componente originale, non perde il requisito di identità ex art. 2(6): la patch di sicurezza modifica le specifiche software interne senza toccare ciò che il componente fa e per cui è stato progettato.
L’argomento potrebbe essere coerente. Resta il fatto che in tal modo si sposta la qualificazione di “identico” da un criterio tecnico oggettivo, dato dal progetto originale, a un criterio funzionale e teleologico, ossia cosa il componente fa e a quale scopo.
Ci sembra quindi una lacuna che andrebbe colmata.
Note
[2] Cfr. Art. 13 C.R.A.
[4] A titolo esemplificativo, si veda la comunicazione commerciale di almeno un produttore europeo di componentistica per automazione industriale, che distingue esplicitamente tra “pezzi di ricambio conformi al CRA” destinati alla riparazione di impianti esistenti e gateway con capacità di aggiornamento sul campo destinati alle nuove installazioni. La categoria “ricambio conforme al CRA” è già presente nei cataloghi online con riferimento esplicito all’art. 2(6) del regolamento (https://www.bihl-wiedemann.de/it/supporto/pezzo-di-ricambio-conformi-al-cra; ultima visualizzazione 28/05/2026, ore 15:45).
[5] https://www.cybersecurity360.it/legal/cyber-resilience-act-ecco-come-le-imprese-dovranno-adeguarsi/
Partecipa alla community