di Micaela Caserza Magro<\/em><\/p>\n\n\n\n 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\u00e0 operativa del settore: direttive recepite con anni di ritardo, applicate con difformit\u00e0, 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<\/strong> – ha le caratteristiche per rompere questo schema, non perch\u00e9 sia pi\u00f9 severo di altri strumenti normativi, ma perch\u00e9 interviene su una vulnerabilit\u00e0 strutturale che il mercato della tecnologia industriale connessa aveva sistematicamente ignorato. Il mercato europeo ha prodotto, negli ultimi vent’anni, una quantit\u00e0 crescente di dispositivi connessi il cui software \u00e8 stato progettato privilegiando funzionalit\u00e0, time-to-market e costo, con la cybersecurity <\/strong>trattata come requisito secondario. Il risultato \u00e8 un parco installato vastissimo di prodotti con vulnerabilit\u00e0 note, prive di patch, non aggiornabili o semplicemente non aggiornate. Questo non \u00e8 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\u00e0 della cybersecurity ricada sul fabbricante, non sull’utilizzatore. \u00c8 un cambio di paradigma che ridisegna gli equilibri di un mercato abituato a scaricare sul cliente finale il costo delle scelte progettuali del produttore. La definizione contenuta nell’articolo 3 del regolamento \u00e8 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\u00f9 lunga di quanto tanti si aspettino. Rientrano nel perimetro: trasmettitori di processo con connettivit\u00e0 Ethernet o wireless; analizzatori con interfaccia OPC-UA o Modbus TCP; data logger con funzionalit\u00e0 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. Il CRA distingue tra prodotti standard e prodotti importanti o critici, con livelli crescenti di rigore nella valutazione della conformit\u00e0. I prodotti standard (la maggior parte dei dispositivi connessi) possono auto-dichiarare la conformit\u00e0, 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\u00e0 nel tempo. Sei categorie di obblighi definiscono cosa il CRA richiede operativamente a chi produce tecnologia connessa per il mercato industriale. Vediamole una per una. Il CRA \u00e8 in vigore dal 10 dicembre 2024, ma il suo dispiegamento \u00e8 scaglionato nel tempo. Dal 11 settembre diventano applicabili gli obblighi di notifica degli incidenti agli organismi nazionali competenti: i fabbricanti devono avere gi\u00e0 implementato processi di gestione degli incidenti di sicurezza prima di quella data. Dal 11 dicembre 2027 il regolamento \u00e8 pienamente applicabile per tutti i prodotti immessi sul mercato da quella data in poi. I prodotti gi\u00e0 in commercio possono continuare a essere venduti, ma i nuovi lotti di produzione dovranno essere conformi. Il tempo per adeguarsi non \u00e8 illimitato, ma non \u00e8 esaurito: la variabile critica non \u00e8 la conoscenza del regolamento, ma la capacit\u00e0 organizzativa di tradurla in azione concreta.<\/p>\n\n\n\n Uno degli aspetti pi\u00f9 delicati dell’applicazione del CRA al contesto industriale riguarda la gestione degli aggiornamenti in ambienti operativi con vincoli severi sulla disponibilit\u00e0 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\u00f2 richiedere una nuova qualifica, con tempi e costi significativi. La risposta corretta non \u00e8 attesa passiva: \u00e8 progettare meccanismi di aggiornamento che minimizzino l’impatto operativo. Aggiornamenti atomici con rollback garantito, possibilit\u00e0 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.<\/p>\n\n\n\n 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) \u00e8 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\u00e0, 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\u00e0 molto pi\u00f9 costoso nel tempo. Il primo passo \u00e8 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 Cyber Resilience Act non \u00e8 l’ennesimo strato burocratico <\/strong>aggiunto a un settore gi\u00e0 gravato da adempimenti normativi. \u00c8, 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. 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\u00e0 e gli obblighi, gli step da seguire e le scadenze.<\/p>\n","protected":false},"author":6,"featured_media":16340,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_seopublitec_title":"","_seopublitec_meta_desc":"","_seopublitec_keyphrases":"","_seopublitec_canonical":"","_seopublitec_noindex":false,"_seopublitec_nofollow":false,"_seopublitec_og_title":"","_seopublitec_og_desc":"","_seopublitec_twitter_title":"","_seopublitec_twitter_desc":"","_seopublitec_twitter_image":"","_seopublitec_og_image":"","_seopublitec_twitter_card":"","_seopublitec_cornerstone":false,"_seopublitec_score":""},"categories":[27],"tags":[1886,1768,1887,1888,1889],"class_list":["post-16339","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tecnologie","tag-cyber-resilience-act","tag-cybersecurity","tag-opc-ua","tag-regolamento-ue-2024-2847","tag-software-bill-of-materials-sbom"],"openstation_lock":null,"openstation_contributors":[],"openstation_attached_media":[16340],"_links":{"self":[{"href":"https:\/\/www.publiteconline.it\/controlloemisura\/wp-json\/wp\/v2\/posts\/16339","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.publiteconline.it\/controlloemisura\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.publiteconline.it\/controlloemisura\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.publiteconline.it\/controlloemisura\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/www.publiteconline.it\/controlloemisura\/wp-json\/wp\/v2\/comments?post=16339"}],"version-history":[{"count":2,"href":"https:\/\/www.publiteconline.it\/controlloemisura\/wp-json\/wp\/v2\/posts\/16339\/revisions"}],"predecessor-version":[{"id":16342,"href":"https:\/\/www.publiteconline.it\/controlloemisura\/wp-json\/wp\/v2\/posts\/16339\/revisions\/16342"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.publiteconline.it\/controlloemisura\/wp-json\/wp\/v2\/media\/16340"}],"wp:attachment":[{"href":"https:\/\/www.publiteconline.it\/controlloemisura\/wp-json\/wp\/v2\/media?parent=16339"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.publiteconline.it\/controlloemisura\/wp-json\/wp\/v2\/categories?post=16339"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.publiteconline.it\/controlloemisura\/wp-json\/wp\/v2\/tags?post=16339"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
L’obiettivo di questo articolo non \u00e8 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\u00f2 che incorpora un componente software e una connessione (anche passiva, anche interna) \u00e8 potenzialmente soggetto al regolamento. Le implicazioni sono meno banali di quanto sembri a una prima lettura.<\/p>\n\n\n\nLa responsabilit\u00e0 del fabbricante<\/strong><\/h3>\n\n\n\n
Il punto chiave \u00e8 proprio questo: fino a oggi il rischio delle vulnerabilit\u00e0 software veniva implicitamente trasferito all’utilizzatore finale. Il CRA inverte questa logica: \u00e8 il fabbricante a dover dimostrare che il suo prodotto \u00e8 sicuro, a mantenerne la sicurezza nel tempo, e a rispondere delle conseguenze se non lo fa.<\/p>\n\n\n\nPerimetro applicativo:<\/strong> cosa rientra e cosa no<\/strong><\/h3>\n\n\n\n
La distinzione non \u00e8 sempre intuitiva. Un sensore analogico con uscita 4\u201320 mA \u00e8 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 \u00e8 hardware, mentre un manometro con display digitale, comunicazione Bluetooth e applicazione mobile di configurazione \u00e8 un prodotto con elementi digitali. La presenza di un protocollo di comunicazione digitale aggiornabile, anche se mai usato per trasferire dati critici, \u00e8 sufficiente a fare scattare gli obblighi del regolamento.<\/p>\n\n\n\nLe due classi di prodotto<\/strong> e gli obblighi differenziati<\/strong><\/h3>\n\n\n\n
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 \u00e8 che questi prodotti, se compromessi, abbiano un impatto sistemico che va ben oltre il singolo impianto.<\/p>\n\n\n\nGli obblighi per i fabbricanti<\/strong><\/h3>\n\n\n\n
Sicurezza by design<\/strong>: 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\u00e0 dei dati e delle comunicazioni. Per chi progetta strumentazione industriale con cicli di sviluppo lunghi e focus tradizionalmente centrato sulla funzionalit\u00e0 di misura, questo \u00e8 un cambiamento di processo prima ancora che tecnologico.
Gestione delle vulnerabilit\u00e0 per tutto il ciclo di vita<\/strong>: il fabbricante deve disporre di un processo per identificare, valutare, divulgare e correggere le vulnerabilit\u00e0 per l’intera durata del supporto del prodotto. Questo include le vulnerabilit\u00e0 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\u00f9 rilevante e meno presidiato.
Software Bill of Materials (SBOM)<\/strong>: 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\u00e0 e, dove applicabile, agli utenti che ne abbiano necessit\u00e0. Per molte realt\u00e0 industriali, abituate a trattare il software di un dispositivo come propriet\u00e0 del prodotto hardware, questo \u00e8 l’obbligo pi\u00f9 impattante dal punto di vista operativo.
Aggiornamenti di sicurezza garantiti<\/strong>: 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\u00f2 estendersi per quindici o vent’anni.
Notifica degli incidenti: <\/strong>in caso di vulnerabilit\u00e0 attivamente sfruttata, il fabbricante deve notificare all’ENISA entro 24 ore dalla scoperta, con un report dettagliato entro 72 ore. Questo obbligo \u00e8 nuovo per la quasi totalit\u00e0 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\u00e0<\/strong>: il CRA richiede documentazione tecnica che dimostri la conformit\u00e0 ai requisiti del regolamento e la predisposizione di una dichiarazione di conformit\u00e0 Ue. La marcatura CE incorpora anche la conformit\u00e0 a questo regolamento.<\/p>\n\n\n\nLe timeline operative<\/strong><\/h3>\n\n\n\n
Il nodo degli aggiornamenti<\/strong> in ambienti industriali<\/strong><\/h3>\n\n\n\n
Quali sono le implicazioni<\/strong> per la catena di fornitura<\/strong><\/h3>\n\n\n\n
Dall’altra parte della catena, chi acquista dispositivi industriali connessi avr\u00e0 strumenti normativi per richiedere ai propri fornitori garanzie oggi non esigibili. La SBOM, la dichiarazione di conformit\u00e0 e il periodo di supporto garantito diventeranno informazione esigibile nei processi di qualifica del fornitore. Chi non sar\u00e0 in grado di fornirla, si trover\u00e0 progressivamente escluso dai processi di acquisto dei clienti pi\u00f9 strutturati.<\/p>\n\n\n\nDa dove si deve cominciare<\/strong><\/h3>\n\n\n\n
Il secondo passo \u00e8 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\u00e0, SBOM, meccanismo di aggiornamento e documentazione. Il terzo passo \u00e8 una roadmap di adeguamento con priorit\u00e0 chiare: prima i prodotti con profilo di rischio pi\u00f9 elevato, poi quelli prossimi al rilascio o a un aggiornamento importante. I processi di sviluppo sicuro, la gestione delle vulnerabilit\u00e0 e la costruzione della SBOM sono capacit\u00e0 organizzative che richiedono tempo. Chi inizia adesso ha il margine per farlo bene.<\/p>\n\n\n\nUna sfida e un’opportunit\u00e0<\/strong><\/h3>\n\n\n\n
Per chi progetta e vende strumentazione e sistemi di controllo, questo \u00e8 sia una sfida che un’opportunit\u00e0. La sfida \u00e8 evidente: adeguare processi di sviluppo, costruire capacit\u00e0 di gestione delle vulnerabilit\u00e0, documentare e mantenere la SBOM, garantire aggiornamenti nel tempo. L’opportunit\u00e0 \u00e8 meno immediata ma altrettanto reale: il mercato industriale inizier\u00e0 a selezionare i fornitori anche sulla base della loro maturit\u00e0 in cybersecurity, e chi si posizioner\u00e0 in anticipo come fornitore affidabile avr\u00e0 un vantaggio competitivo che non dipende dal prezzo.
Chi lavora nel settore della misura e del controllo conosce l’importanza della qualit\u00e0 dei dati come fondamento di qualsiasi decisione di processo: la catena \u00e8 affidabile quanto il suo anello pi\u00f9 debole. Lo stesso principio vale per la cybersecurity dei sistemi che quei dati raccolgono, elaborano e trasmettono. Il CRA \u00e8 lo strumento normativo che inizia a far pagare un prezzo a chi vuole essere quell’anello debole.<\/p>\n","protected":false},"excerpt":{"rendered":"