Quali sono i cambiamenti concreti che il Cyber Resilience Act determina per chi progetta e vende prodotti con elementi digitali per l’industria? Facciamo chiarezza su quali sono questi prodotti, le responsabilità e gli obblighi, gli step da seguire e le scadenze.
di Micaela Caserza Magro
Chi lavora nel mondo della strumentazione industriale, dell’automazione e dei sistemi di controllo conosce bene il ritmo con cui le normative entrano nella realtà operativa del settore: direttive recepite con anni di ritardo, applicate con difformità, spesso superate dai fatti tecnologici prima ancora di essere pienamente comprese. Il Cyber Resilience Act – CRA, Regolamento (UE) 2024/2847, entrato in vigore il 10 dicembre 2024 – ha le caratteristiche per rompere questo schema, non perché sia più severo di altri strumenti normativi, ma perché interviene su una vulnerabilità strutturale che il mercato della tecnologia industriale connessa aveva sistematicamente ignorato.
L’obiettivo di questo articolo non è fornire una sintesi del testo normativo, ma ragionare su cosa il CRA cambia concretamente per chi progetta e commercializza prodotti con elementi digitali destinati all’industria. Sensori connessi, analizzatori in rete, sistemi di acquisizione dati, controller programmabili, gateway industriali, piattaforme cloud per il monitoraggio di processo: tutto ciò che incorpora un componente software e una connessione (anche passiva, anche interna) è potenzialmente soggetto al regolamento. Le implicazioni sono meno banali di quanto sembri a una prima lettura.
La responsabilità del fabbricante
Il mercato europeo ha prodotto, negli ultimi vent’anni, una quantità crescente di dispositivi connessi il cui software è stato progettato privilegiando funzionalità, time-to-market e costo, con la cybersecurity trattata come requisito secondario. Il risultato è un parco installato vastissimo di prodotti con vulnerabilità note, prive di patch, non aggiornabili o semplicemente non aggiornate. Questo non è un problema di malafede dei produttori, ma di incentivi mal calibrati: fino a oggi nessun obbligo normativo imponeva di fare diversamente. Il CRA interviene su questo punto in modo diretto: stabilisce che la responsabilità della cybersecurity ricada sul fabbricante, non sull’utilizzatore. È un cambio di paradigma che ridisegna gli equilibri di un mercato abituato a scaricare sul cliente finale il costo delle scelte progettuali del produttore.
Il punto chiave è proprio questo: fino a oggi il rischio delle vulnerabilità software veniva implicitamente trasferito all’utilizzatore finale. Il CRA inverte questa logica: è il fabbricante a dover dimostrare che il suo prodotto è sicuro, a mantenerne la sicurezza nel tempo, e a rispondere delle conseguenze se non lo fa.
Perimetro applicativo: cosa rientra e cosa no
La definizione contenuta nell’articolo 3 del regolamento è volutamente ampia: “qualsiasi prodotto software o hardware e le relative soluzioni di elaborazione dati a distanza, incluse le componenti immesse sul mercato separatamente”. Nel contesto industriale questo si traduce in una lista molto più lunga di quanto tanti si aspettino. Rientrano nel perimetro: trasmettitori di processo con connettività Ethernet o wireless; analizzatori con interfaccia OPC-UA o Modbus TCP; data logger con funzionalità di upload su cloud; PLC e DCS nella misura in cui incorporano software aggiornabile; gateway di comunicazione tra reti OT e IT; software SCADA commerciali; software di configurazione distribuito ai clienti; firmware aggiornabile via rete. Non rientrano nel perimetro i dispositivi puramente hardware senza componente software, e i prodotti sviluppati esclusivamente per uso interno non commercializzati.
La distinzione non è sempre intuitiva. Un sensore analogico con uscita 4–20 mA è hardware. Lo stesso sensore con output HART digitale e configurazione remota ha un componente software e, con esso, un vettore di attacco. Un manometro meccanico è hardware, mentre un manometro con display digitale, comunicazione Bluetooth e applicazione mobile di configurazione è un prodotto con elementi digitali. La presenza di un protocollo di comunicazione digitale aggiornabile, anche se mai usato per trasferire dati critici, è sufficiente a fare scattare gli obblighi del regolamento.
Le due classi di prodotto e gli obblighi differenziati
Il CRA distingue tra prodotti standard e prodotti importanti o critici, con livelli crescenti di rigore nella valutazione della conformità. I prodotti standard (la maggior parte dei dispositivi connessi) possono auto-dichiarare la conformità, ma questo non significa obblighi leggeri: il fabbricante deve dimostrare, con documentazione tracciabile, di aver condotto un’analisi del rischio, di aver integrato requisiti di sicurezza nella progettazione, e di disporre di un processo strutturato per gestire le vulnerabilità nel tempo.
I prodotti importanti di classe I e II (tra cui sistemi di supervisione industriale, software per PLC e DCS, componenti di automazione di rete, firewall e router industriali) richiedono il coinvolgimento di un organismo terzo notificato. La logica è che questi prodotti, se compromessi, abbiano un impatto sistemico che va ben oltre il singolo impianto.
Gli obblighi per i fabbricanti
Sei categorie di obblighi definiscono cosa il CRA richiede operativamente a chi produce tecnologia connessa per il mercato industriale. Vediamole una per una.
Sicurezza by design: i prodotti devono essere progettati con un livello adeguato di cybersecurity fin dalle prime fasi del ciclo di sviluppo, non come aggiunta successiva. Questo implica la minimizzazione della superficie di attacco, l’eliminazione delle configurazioni predefinite insicure, la protezione dell’integrità dei dati e delle comunicazioni. Per chi progetta strumentazione industriale con cicli di sviluppo lunghi e focus tradizionalmente centrato sulla funzionalità di misura, questo è un cambiamento di processo prima ancora che tecnologico.
Gestione delle vulnerabilità per tutto il ciclo di vita: il fabbricante deve disporre di un processo per identificare, valutare, divulgare e correggere le vulnerabilità per l’intera durata del supporto del prodotto. Questo include le vulnerabilità nelle componenti software di terze parti incorporate nel prodotto (librerie open source, stack di comunicazione, firmware di sottosistemi acquistati) che nel contesto industriale rappresentano spesso il vettore di rischio più rilevante e meno presidiato.
Software Bill of Materials (SBOM): il regolamento richiede un inventario dettagliato di tutti i componenti software presenti nel prodotto, incluse le dipendenze di terze parti con le relative versioni. La SBOM deve essere disponibile su richiesta delle autorità e, dove applicabile, agli utenti che ne abbiano necessità. Per molte realtà industriali, abituate a trattare il software di un dispositivo come proprietà del prodotto hardware, questo è l’obbligo più impattante dal punto di vista operativo.
Aggiornamenti di sicurezza garantiti: il CRA impone di garantire aggiornamenti di sicurezza per un periodo dichiarato esplicitamente e non inferiore a cinque anni. Questo contrasta con prassi consolidate nel mondo industriale, dove il supporto software termina spesso con la fine della produzione dell’hardware, ignorando che il ciclo di vita operativo di un sistema di processo può estendersi per quindici o vent’anni.
Notifica degli incidenti: in caso di vulnerabilità attivamente sfruttata, il fabbricante deve notificare all’ENISA entro 24 ore dalla scoperta, con un report dettagliato entro 72 ore. Questo obbligo è nuovo per la quasi totalità dei produttori di tecnologia industriale, e richiede procedure di monitoraggio e risposta agli incidenti che pochi hanno oggi formalizzato.
Documentazione tecnica e dichiarazione di conformità: il CRA richiede documentazione tecnica che dimostri la conformità ai requisiti del regolamento e la predisposizione di una dichiarazione di conformità Ue. La marcatura CE incorpora anche la conformità a questo regolamento.
Le timeline operative
Il CRA è in vigore dal 10 dicembre 2024, ma il suo dispiegamento è scaglionato nel tempo. Dal 11 settembre diventano applicabili gli obblighi di notifica degli incidenti agli organismi nazionali competenti: i fabbricanti devono avere già implementato processi di gestione degli incidenti di sicurezza prima di quella data. Dal 11 dicembre 2027 il regolamento è pienamente applicabile per tutti i prodotti immessi sul mercato da quella data in poi. I prodotti già in commercio possono continuare a essere venduti, ma i nuovi lotti di produzione dovranno essere conformi. Il tempo per adeguarsi non è illimitato, ma non è esaurito: la variabile critica non è la conoscenza del regolamento, ma la capacità organizzativa di tradurla in azione concreta.
Il nodo degli aggiornamenti in ambienti industriali
Uno degli aspetti più delicati dell’applicazione del CRA al contesto industriale riguarda la gestione degli aggiornamenti in ambienti operativi con vincoli severi sulla disponibilità del processo. In un impianto di produzione continua, aggiornare il firmware di un sistema di misura richiede pianificazione, finestre di manutenzione, validazione post-aggiornamento, e spesso l’approvazione di molteplici funzioni aziendali. In ambienti regolamentati (farmaceutico, alimentare, chimico fine), un aggiornamento può richiedere una nuova qualifica, con tempi e costi significativi. La risposta corretta non è attesa passiva: è progettare meccanismi di aggiornamento che minimizzino l’impatto operativo. Aggiornamenti atomici con rollback garantito, possibilità di aggiornare componenti software indipendentemente senza riavviare l’intero sistema: questi requisiti non sono espliciti nel CRA, ma derivano dall’obbligo di garantire aggiornamenti di sicurezza in un contesto industriale reale.
Quali sono le implicazioni per la catena di fornitura
Il CRA ha implicazioni che si propagano lungo la catena di fornitura in entrambe le direzioni. Un fabbricante che incorpora componenti software di terze parti (stack OPC-UA, librerie MQTT, sistemi operativi embedded) è responsabile della sicurezza del prodotto finale, a prescindere dall’origine dei componenti. Questo significa esercitare una due diligence sui fornitori di componenti software, verificare che dispongano di processi adeguati di gestione delle vulnerabilità, e contrattualizzare obblighi di notifica e correzione. Chi oggi integra componenti software senza una valutazione sistematica del loro profilo di rischio sta accumulando un debito tecnico che il CRA renderà molto più costoso nel tempo.
Dall’altra parte della catena, chi acquista dispositivi industriali connessi avrà strumenti normativi per richiedere ai propri fornitori garanzie oggi non esigibili. La SBOM, la dichiarazione di conformità e il periodo di supporto garantito diventeranno informazione esigibile nei processi di qualifica del fornitore. Chi non sarà in grado di fornirla, si troverà progressivamente escluso dai processi di acquisto dei clienti più strutturati.
Da dove si deve cominciare
Il primo passo è un’analisi di perimetro: identificare tutti i prodotti in commercio o in sviluppo che rientrano nella definizione di prodotto con elementi digitali, e classificarli per profilo di rischio.
Il secondo passo è un gap analysis rispetto ai requisiti: per ciascun prodotto nel perimetro, valutare lo stato attuale rispetto agli obblighi di sicurezza by design, gestione delle vulnerabilità, SBOM, meccanismo di aggiornamento e documentazione. Il terzo passo è una roadmap di adeguamento con priorità chiare: prima i prodotti con profilo di rischio più elevato, poi quelli prossimi al rilascio o a un aggiornamento importante. I processi di sviluppo sicuro, la gestione delle vulnerabilità e la costruzione della SBOM sono capacità organizzative che richiedono tempo. Chi inizia adesso ha il margine per farlo bene.
Una sfida e un’opportunità
Il Cyber Resilience Act non è l’ennesimo strato burocratico aggiunto a un settore già gravato da adempimenti normativi. È, nella sua sostanza, il riconoscimento normativo di un problema reale: il mercato della tecnologia connessa ha prodotto per anni sistemi insicuri senza che nessuno ne pagasse il costo in modo proporzionale al rischio creato. Il CRA trasferisce quel costo sul fabbricante, a cui logicamente appartiene.
Per chi progetta e vende strumentazione e sistemi di controllo, questo è sia una sfida che un’opportunità. La sfida è evidente: adeguare processi di sviluppo, costruire capacità di gestione delle vulnerabilità, documentare e mantenere la SBOM, garantire aggiornamenti nel tempo. L’opportunità è meno immediata ma altrettanto reale: il mercato industriale inizierà a selezionare i fornitori anche sulla base della loro maturità in cybersecurity, e chi si posizionerà in anticipo come fornitore affidabile avrà un vantaggio competitivo che non dipende dal prezzo.
Chi lavora nel settore della misura e del controllo conosce l’importanza della qualità dei dati come fondamento di qualsiasi decisione di processo: la catena è affidabile quanto il suo anello più debole. Lo stesso principio vale per la cybersecurity dei sistemi che quei dati raccolgono, elaborano e trasmettono. Il CRA è lo strumento normativo che inizia a far pagare un prezzo a chi vuole essere quell’anello debole.
