Cyber Resilience Act per costruttori di macchine: chi riguarda e cosa fare

Il Cyber Resilience Act (CRA), Regolamento (UE) 2024/2847, è stato pubblicato nella Gazzetta Ufficiale dell'Unione Europea il 20 novembre 2024. Non è una direttiva da recepire: è un regolamento, quindi direttamente applicabile in tutti gli Stati membri. Il suo oggetto sono i prodotti con elementi digitali immessi sul mercato UE, e il suo scopo è garantire che questi prodotti siano progettati, sviluppati e mantenuti con requisiti minimi di cybersecurity lungo tutto il loro ciclo di vita.

Per chi costruisce macchine industriali, impianti, quadri di automazione o sistemi OT destinati al mercato europeo, il CRA introduce obblighi concreti che si aggiungono a quelli già noti della Direttiva Macchine (e del nuovo Regolamento Macchine 2023/1230). La differenza è che stavolta l'attenzione non è sulla safety meccanica o elettrica, ma sulla sicurezza informatica del prodotto e dei suoi componenti digitali.

Cosa si intende per "prodotto con elementi digitali"

Il CRA definisce come "prodotto con elementi digitali" qualsiasi prodotto software o hardware — e le relative soluzioni di elaborazione dati da remoto — che include una connessione dati diretta o indiretta a un dispositivo o a una rete. La definizione è ampia e intenzionalmente tecnologicamente neutra.

Per un costruttore di macchine, questo significa che rientrano nel perimetro del regolamento, tra gli altri:

• PLC e controllori con interfaccia di rete (Ethernet, Profinet, EtherNet/IP, Modbus TCP, OPC UA)
• HMI e pannelli operatore con connessione di rete o porte USB
• Gateway IoT industriali, edge controller, dispositivi di raccolta dati
• Sensori e attuatori connessi (IO-Link, sensori con interfaccia Ethernet)
• Software embedded e firmware dei componenti sopra elencati
• Software stand-alone fornito con la macchina: applicativi SCADA, interfacce di configurazione, tool di diagnostica
• Componenti di rete integrati nella macchina: switch industriali, access point, firewall dedicati

Non rientrano invece i ricambi identici per prodotti già immessi sul mercato prima dell'applicazione del regolamento, e sono esclusi i prodotti già coperti da regolamentazione settoriale specifica (dispositivi medici, aviazione, veicoli a motore), a condizione che quella regolamentazione imponga requisiti di cybersecurity equivalenti.

Classificazione dei prodotti: default, classe I e classe II

Il CRA prevede tre livelli di classificazione, con procedure di valutazione della conformità differenziate:

I prodotti industriali più comuni — PLC di fascia generale, HMI standard, switch industriali non critici — ricadono nella maggior parte dei casi nella categoria default o in classe I. I prodotti che svolgono funzioni critiche di sicurezza o di controllo di infrastrutture essenziali possono rientrare in classe II, ma la classificazione va verificata caso per caso in base agli allegati del regolamento.

Per i costruttori di macchine, il punto pratico è che la procedura di conformità dipende dalla classificazione dei componenti digitali integrati. Un PLC general-purpose, ad esempio, non è automaticamente un prodotto di classe II, ma un sistema di controllo industriale destinato a infrastrutture critiche potrebbe esserlo.

Requisiti essenziali di cybersecurity

L'Allegato I del CRA elenca i requisiti essenziali che ogni prodotto con elementi digitali deve soddisfare. Non si tratta di specifiche tecniche puntuali, ma di obiettivi di sicurezza che il fabbricante deve raggiungere con mezzi appropriati. I principali:

Requisiti sul prodotto (Allegato I, Parte I)

• Sicurezza by design: il prodotto deve essere progettato e sviluppato con un livello di sicurezza appropriato al rischio, inclusa la riduzione della superficie di attacco
• Configurazione sicura di default: niente password di fabbrica uguali per tutti i dispositivi, servizi non necessari disabilitati, impostazioni restrittive come stato iniziale
• Protezione da accessi non autorizzati: meccanismi di autenticazione, controllo degli accessi, protezione dei dati memorizzati e trasmessi
• Integrità del software: il prodotto deve garantire l'integrità del proprio firmware e software, compresi gli aggiornamenti
• Minimizzazione dei dati: il prodotto deve elaborare solo i dati necessari al suo funzionamento
• Disponibilità: il prodotto deve essere progettato per limitare l'impatto negativo sulla disponibilità dei servizi forniti da altri dispositivi o reti
• Aggiornabilità: il prodotto deve poter ricevere aggiornamenti di sicurezza, preferibilmente in modo automatico o con meccanismi semplici per l'utente

Requisiti sulla gestione delle vulnerabilità (Allegato I, Parte II)

• Identificazione e documentazione delle vulnerabilità e dei componenti del prodotto, compreso un SBOM (Software Bill of Materials)
• Gestione e correzione tempestiva delle vulnerabilità note, con distribuzione di aggiornamenti di sicurezza
• Test di sicurezza regolari e revisione del codice
• Pubblicazione coordinata delle informazioni sulle vulnerabilità corrette
• Meccanismo di segnalazione per consentire a terzi di comunicare vulnerabilità al fabbricante

Per chi costruisce macchine, questi requisiti cambiano il modo di pensare al ciclo di vita del prodotto. Non basta consegnare la macchina funzionante e chiudere la commessa: serve un processo per gestire vulnerabilità, distribuire patch e mantenere la trasparenza sulla composizione software del prodotto.

Il SBOM: perché è centrale e cosa comporta

Tra gli obblighi più concreti del CRA c'è la redazione e il mantenimento di un Software Bill of Materials (SBOM), cioè un inventario strutturato di tutti i componenti software presenti nel prodotto, comprese librerie di terze parti, moduli open source e dipendenze indirette.

Per un costruttore di macchine, questo significa che serve una mappa chiara di tutto il software che gira sulla macchina e sui suoi componenti digitali: dal firmware del PLC alle librerie del pannello HMI, dal sistema operativo del gateway ai pacchetti usati nel software di diagnostica.

Nella pratica, produrre un SBOM accurato è tutt'altro che banale. Molti costruttori non hanno piena visibilità sul software embedded dei componenti che acquistano da terzi. Un PLC di un vendor globale contiene un sistema operativo real-time, stack di comunicazione, librerie crittografiche e middleware di cui il costruttore della macchina spesso non conosce i dettagli. Lo stesso vale per HMI con sistema operativo Windows o Linux embedded, gateway con stack software complessi, sensori con firmware proprietario.

Il CRA non chiede al costruttore della macchina di smontare il firmware del PLC, ma chiede di documentare i componenti software noti e di avere un processo per raccogliere le informazioni rilevanti dai propri fornitori. Questo implica un cambio nei rapporti con i vendor di componenti: servono SBOM dai fornitori, oppure almeno dichiarazioni strutturate sulla composizione del software.

Obblighi di segnalazione delle vulnerabilità

Il CRA introduce un obbligo di notifica delle vulnerabilità attivamente sfruttate. Il fabbricante deve segnalare al CSIRT designato (e all'ENISA) entro 24 ore dalla conoscenza di una vulnerabilità attivamente sfruttata che interessa il proprio prodotto. Una notifica più dettagliata va trasmessa entro 72 ore.

Questo obbligo ha conseguenze operative dirette per chi costruisce macchine. Richiede:

• un processo strutturato di monitoraggio delle vulnerabilità sui componenti del prodotto
• una capacità interna (o esterna ma contrattualizzata) di analisi e triage delle vulnerabilità
• un canale di comunicazione con i CSIRT nazionali, definito prima che serva
• una procedura per determinare se una vulnerabilità scoperta in un componente terzo (ad esempio nel firmware di un PLC integrato nella macchina) è rilevante e va segnalata

Per molte PMI del settore macchine, queste capacità oggi non esistono o sono embrionali. Il CRA chiede di costruirle prima dell'applicazione effettiva degli obblighi.

Tempistiche di applicazione

Il regolamento è entrato in vigore il 10 dicembre 2024, venti giorni dopo la pubblicazione in GUUE. L'applicazione degli obblighi è però scaglionata:

Questo significa che per i prodotti immessi sul mercato UE a partire dall'11 dicembre 2027, il fabbricante dovrà dimostrare la conformità ai requisiti del CRA. Per i prodotti già sul mercato prima di quella data, il regolamento si applica solo se il prodotto viene modificato in modo sostanziale.

La finestra non è ampia quanto sembra. Adeguare processi di sviluppo, gestione delle vulnerabilità, documentazione e supply chain richiede tempo, soprattutto per chi parte da zero o quasi.

Rapporto con il Regolamento Macchine 2023/1230

Il nuovo Regolamento Macchine (UE) 2023/1230, che sostituisce la Direttiva 2006/42/CE, introduce per la prima volta requisiti espliciti di cybersecurity per le macchine con funzioni di sicurezza che dipendono da software o connettività. Il CRA si affianca al Regolamento Macchine, senza sostituirlo.

Nella pratica, per un costruttore di macchine industriali la situazione è questa:

• Il Regolamento Macchine si occupa di safety e, dal 2027, include la protezione contro la corruzione delle funzioni di sicurezza causata da attacchi informatici
• Il CRA si occupa della cybersecurity del prodotto digitale nel suo complesso: progettazione sicura, gestione delle vulnerabilità, aggiornamenti, SBOM, segnalazioni

Le due normative hanno perimetri diversi ma si sovrappongono dove la macchina integra componenti digitali con funzioni di sicurezza. Chi costruisce macchine dovrà gestire entrambi i filoni normativi in modo coordinato.

Va detto che l'articolo 2(2) del CRA esclude espressamente dal suo ambito i prodotti già soggetti a regolamentazione settoriale che preveda requisiti di cybersecurity almeno equivalenti. Tuttavia, il Regolamento Macchine non è considerato tra queste esclusioni, perché i suoi requisiti di cybersecurity sono limitati alla protezione delle funzioni di sicurezza e non coprono l'intero spettro del CRA. Di conseguenza, i prodotti digitali integrati in una macchina restano soggetti anche al CRA.

Cosa deve fare concretamente un costruttore di macchine

Tradurre il CRA in azioni operative richiede un lavoro su più fronti. Non tutto va fatto subito, ma conviene avere un quadro chiaro di cosa serve e dove si parte.

1. Mappare i componenti digitali della macchina

Il primo passo è sapere quali componenti della macchina rientrano nella definizione di "prodotto con elementi digitali". Per ogni componente connesso — PLC, HMI, gateway, switch, software — serve una scheda che documenti: funzione, interfacce di rete, software presente, fornitore, classificazione CRA (default, classe I, classe II).

Questo lavoro va fatto su tutta la gamma di macchine in produzione, non solo sui modelli nuovi. Se un modello viene modificato in modo sostanziale dopo l'11 dicembre 2027, potrebbe rientrare nel campo di applicazione del CRA anche se il progetto originale è precedente.

2. Verificare la conformità dei componenti acquistati

Molti costruttori non producono internamente i PLC, gli HMI o i gateway. Li acquistano da vendor di automazione e li integrano nella macchina. Il CRA impone che anche i componenti destinati all'integrazione siano conformi. Questo significa che il costruttore dovrà:

• verificare che i vendor di componenti stiano lavorando alla conformità CRA
• richiedere dichiarazioni di conformità, SBOM e informazioni sulle policy di aggiornamento
• valutare i tempi di risposta dei vendor per gli aggiornamenti di sicurezza
• definire contrattualmente le responsabilità in caso di vulnerabilità nei componenti

Non tutti i vendor saranno pronti allo stesso modo. Alcuni grandi produttori di PLC e HMI hanno già avviato percorsi di conformità; altri, soprattutto su componenti di nicchia o firmware embedded, potrebbero essere in ritardo. Conviene iniziare a porre le domande adesso.

3. Integrare la cybersecurity nel processo di sviluppo

Il CRA richiede che la cybersecurity sia parte del ciclo di sviluppo del prodotto, non un controllo aggiunto alla fine. Per un costruttore di macchine, questo si traduce in:

• valutazione dei rischi di cybersecurity in fase di progettazione (threat modeling, anche semplificato)
• scelta dei componenti anche in base a criteri di sicurezza (aggiornabilità, configurazione di default, supporto del vendor)
• configurazione sicura della macchina prima della consegna: password individuali, servizi non necessari disabilitati, porte di rete chiuse dove non servono
• documentazione delle scelte di sicurezza e delle configurazioni di default

Per molti costruttori, soprattutto PMI, questa è la parte più impegnativa. Oggi la progettazione della macchina si concentra su meccanica, elettrica, pneumatica, logica PLC e funzionalità. La cybersecurity, quando presente, è tipicamente delegata all'integratore o al cliente finale. Con il CRA, diventa una responsabilità del fabbricante.

4. Costruire un processo di gestione delle vulnerabilità

Dopo la consegna della macchina, il fabbricante deve essere in grado di:

• monitorare le vulnerabilità note nei componenti software del prodotto
• produrre e distribuire aggiornamenti di sicurezza per tutta la durata attesa del prodotto (o almeno 5 anni)
• gestire le segnalazioni di vulnerabilità ricevute da terzi
• notificare al CSIRT le vulnerabilità attivamente sfruttate entro 24 ore

In un settore dove le macchine hanno cicli di vita di 15-20 anni e dove l'aggiornamento del software è spesso legato a una fermata programmata, questi obblighi richiedono un ripensamento dei modelli di assistenza e manutenzione. Non significa che il costruttore debba aggiornare il firmware del PLC da remoto ogni settimana, ma deve avere un processo per identificare quando un aggiornamento è necessario, renderlo disponibile e documentare la gestione nel tempo.

5. Preparare la documentazione tecnica e la dichiarazione di conformità

Il CRA richiede una documentazione tecnica che comprenda almeno:

• descrizione del prodotto e del suo uso previsto
• valutazione dei rischi di cybersecurity
• elenco degli standard armonizzati applicati (quando disponibili)
• SBOM
• descrizione delle misure di sicurezza implementate
• risultati dei test di sicurezza
• informazioni sul processo di gestione delle vulnerabilità

La documentazione tecnica deve essere conservata per almeno 10 anni dall'immissione sul mercato. La dichiarazione UE di conformità deve accompagnare il prodotto, con riferimento esplicito al Regolamento (UE) 2024/2847.

Le difficoltà pratiche per le PMI del settore macchine

Gran parte del tessuto industriale europeo nel settore macchine è composto da PMI. Il CRA ne tiene conto in parte, ma gli obblighi restano sostanziali. Le difficoltà prevedibili sono diverse:

• Competenze interne limitate: poche aziende meccaniche o meccatroniche hanno personale formato in cybersecurity di prodotto. Spesso manca anche la distinzione chiara tra IT aziendale e sicurezza del prodotto.
• Dipendenza dai vendor: il costruttore che integra PLC e HMI di terzi dipende dalla cooperazione dei vendor per ottenere SBOM, informazioni sulle vulnerabilità e aggiornamenti. Se il vendor non collabora, il costruttore ha un problema di conformità.
• Cicli di vita lunghi: una macchina industriale resta in esercizio per decenni. Garantire aggiornamenti di sicurezza per almeno 5 anni è fattibile; per 15 o 20 anni è una sfida aperta, soprattutto per i componenti software embedded.
• Assenza di standard armonizzati consolidati: al momento della stesura di questo articolo, gli standard armonizzati per il CRA sono ancora in fase di sviluppo. La serie IEC 62443 copre molti aspetti rilevanti per i sistemi di automazione industriale, ma il suo utilizzo come riferimento per la conformità al CRA dipenderà dalla futura armonizzazione formale.
• Costo dell'adeguamento: documentazione, test, SBOM, gestione delle vulnerabilità, eventuale intervento di organismi notificati — tutto questo ha un costo che per una PMI può essere significativo.

Nessuna di queste difficoltà è insormontabile, ma sottovalutarle sarebbe un errore. Conviene affrontarle per gradi, partendo dalle attività che richiedono più tempo: mappatura dei componenti, relazione con i vendor e costruzione del processo di gestione delle vulnerabilità.

IEC 62443 e il CRA: un riferimento naturale, non ancora formale

La serie di standard IEC 62443 è il riferimento tecnico più consolidato per la cybersecurity dei sistemi di automazione e controllo industriale (IACS). Copre aspetti come la sicurezza del ciclo di sviluppo (IEC 62443-4-1), i requisiti tecnici dei componenti (IEC 62443-4-2), la gestione del rischio (IEC 62443-3-2) e i requisiti per i system integrator (IEC 62443-2-4).

Molti dei requisiti essenziali del CRA trovano una corrispondenza diretta nei controlli della IEC 62443. Chi ha già adottato questa serie di standard per i propri prodotti o processi parte con un vantaggio concreto.

Tuttavia, alla data attuale, la IEC 62443 non è ancora formalmente armonizzata con il CRA. Il processo di armonizzazione è in corso, ma fino a quando non sarà completato, l'applicazione della IEC 62443 non garantisce automaticamente la presunzione di conformità al regolamento. È un riferimento tecnico solido, non ancora un passaporto normativo.

Checklist operativa per iniziare

Errori da evitare

• Aspettare gli standard armonizzati per iniziare: il processo di armonizzazione richiede tempo, ma i requisiti essenziali del CRA sono già definiti. Aspettare la pubblicazione degli standard per muoversi significa partire tardi.
• Delegare tutto al vendor del PLC: il CRA responsabilizza il fabbricante del prodotto finale. Anche se il PLC o l'HMI sono conformi, il costruttore della macchina deve dimostrare la conformità dell'insieme, comprese configurazione, integrazione e documentazione.
• Confondere cybersecurity IT con cybersecurity di prodotto: proteggere la rete aziendale è diverso dal progettare un prodotto sicuro. Il CRA riguarda il secondo aspetto. Avere un buon firewall in ufficio non aiuta a rendere conforme la macchina.
• Ignorare il software stand-alone: applicativi di configurazione, tool di diagnostica, interfacce di supervisione forniti con la macchina sono prodotti con elementi digitali a tutti gli effetti.
• Sottovalutare l'obbligo di aggiornamento: il CRA richiede aggiornamenti di sicurezza gratuiti per tutta la durata attesa del prodotto. Questo ha implicazioni sui costi di assistenza e sulla sostenibilità dei modelli di business.

Il nostro punto di vista

Il CRA è il primo regolamento europeo che porta la cybersecurity dentro la marcatura CE dei prodotti digitali. Per il settore delle macchine industriali, l'impatto sarà graduale ma sostanziale. Chi produce macchine con PLC, HMI, gateway e software connessi dovrà aggiungere la cybersecurity alla lista delle responsabilità di progettazione, accanto a meccanica, elettrica e safety.

Non serve partire da un progetto faraonico. Serve partire. Mappare i componenti, parlare con i vendor, iniziare a documentare, capire dove si è e dove si deve arrivare. Le scadenze non sono lontane come sembrano, soprattutto per chi deve costruire competenze e processi che oggi non ha.

Risorse ufficiali e riferimenti

• Regolamento (UE) 2024/2847 — testo ufficiale EUR-Lex
• Cyber Resilience Act — European Commission
• ENISA — Cyber Resilience Act
• Regolamento (UE) 2023/1230 — Regolamento Macchine
• IEC 62443 — Industrial communication networks, Network and system security