Cybersecurity per i costruttori di macchine

Dal 2027, una macchina dotata di controllore, display operatore o connessione dati risponde a due regolamenti UE. Entrambi partono dalla stessa domanda: quale software c'è su questa macchina, versione per versione, e che cosa contiene?

1. 11 settembre 2026Si applicano gli obblighi di segnalazione del Cyber Resilience Act per le vulnerabilità attivamente sfruttate e gli incidenti gravi.
2. 20 gennaio 2027Si applica il regolamento macchine, (UE) 2023/1230, che sostituisce la direttiva macchine.
3. 11 dicembre 2027Il Cyber Resilience Act, (UE) 2024/2847, si applica integralmente.

Regolamento macchine

Due requisiti essenziali di sicurezza e di tutela della salute dell'allegato III riguardano la cybersecurity:

• 1.1.9, protezione dall'alterazione. Il collegamento di un altro dispositivo alla macchina, direttamente o da remoto, non deve dare luogo a una situazione pericolosa. Il software e i dati critici per la conformità della macchina ai requisiti essenziali di sicurezza e di tutela della salute devono essere identificati e protetti dall'alterazione accidentale o intenzionale. La macchina deve identificare il software installato di cui ha bisogno per funzionare in sicurezza e fornire tale informazione in qualsiasi momento. Deve inoltre raccogliere prove degli interventi legittimi o illegittimi su tale software o sulla sua configurazione.
• 1.2.1, sicurezza e affidabilità dei sistemi di comando. I sistemi di comando devono resistere a tentativi dolosi ragionevolmente prevedibili da parte di terzi che portano a una situazione pericolosa. Ai sensi del punto 1.2.1(f), devono tenere un registro di tracciabilità degli interventi e delle versioni del software di sicurezza caricate dopo l'immissione sul mercato della macchina, per cinque anni dal caricamento.

Cyber Resilience Act

Una macchina con una connessione dati, o una sua parte venduta separatamente, è un prodotto con elementi digitali. Il fabbricante deve esercitare la dovuta diligenza sui componenti di terzi che integra, redigere una SBOM che copra almeno le dipendenze di primo livello, gestire le vulnerabilità per tutto il periodo di assistenza, che è di almeno cinque anni salvo che si preveda un uso del prodotto più breve, e conservare la documentazione tecnica per almeno dieci anni o per il periodo di assistenza, se più lungo.

Non automaticamente. Il Cyber Resilience Act non conferisce alcuna presunzione di conformità al regolamento macchine. Il suo considerando 53 afferma che il rispetto dei requisiti essenziali del CRA potrebbe agevolare la conformità ai requisiti del regolamento macchine in materia di protezione dall'alterazione e di sicurezza e affidabilità dei sistemi di comando. Afferma anche che il fabbricante deve dimostrarlo, ad esempio applicando norme armonizzate dopo una valutazione dei rischi, e che le procedure di valutazione della conformità di entrambi i regolamenti continuano ad applicarsi.

La norma armonizzata in preparazione per il punto 1.1.9 è la EN 50742, Safety of machinery – Protection against corruption. A novembre 2026 era un progetto finale, FprEN 50742, che copre il punto 1.1.9 e i punti collegati dell'1.2.1; finché il riferimento di una versione definitiva non è pubblicato nella Gazzetta ufficiale dell'UE, non conferisce alcuna presunzione di conformità. Unisce la valutazione del rischio della EN ISO 12100 ai concetti di sicurezza della IEC 62443 e riconosce l'applicazione coerente di IEC 62443-4-1, IEC 62443-3-3 e IEC 62443-4-2 come via equivalente per raggiungere i suoi obiettivi di protezione. La IEC 62443-4-2 stabilisce i requisiti tecnici di sicurezza per i componenti dei sistemi di controllo, graduati per livello di capacità di sicurezza. In Germania i principi di prova GS-IFA-M25 di luglio 2026 traducono la protezione dall'alterazione in 66 criteri di prova, con la terminologia della prEN 50742. Uno di essi, T46, chiede che il prodotto possa fornire su richiesta la versione e la configurazione del software installato. Per rispondere per ogni configurazione serve una registrazione di ciò che contiene ogni versione del software.

Il regolamento macchine prevede una presunzione propria, che passa per un'altra via: i sistemi europei di certificazione della cibersicurezza adottati ai sensi del regolamento sulla cibersicurezza, il regolamento (UE) 2019/881. Un certificato o una dichiarazione di conformità rilasciati nell'ambito di tale sistema fanno presumere la conformità ai punti 1.1.9 e 1.2.1, nella misura in cui coprono tali requisiti.

Una sola valutazione dei rischi e un solo insieme di evidenze possono quindi servire entrambi i regolamenti, ma la conformità va dimostrata per ciascuno. Se la Sua macchina ha una connessione dati, pianifichi per entrambi. Le evidenze sul software, cioè SBOM, registri delle vulnerabilità e storico degli aggiornamenti, sono la parte che hanno in comune.

Nel gennaio 2026 alcune associazioni del settore delle macchine hanno chiesto il rinvio dei punti 1.1.9 e 1.2.1(f) e, nel marzo 2026, la loro applicazione dalla data del CRA, l'11 dicembre 2027. È una richiesta, non una legge: a novembre 2026 non era stato adottato alcun rinvio. Le date di questa pagina sono quelle dei regolamenti.

• Le macchine da costruzione, per la movimentazione dei materiali, per l'industria mineraria e industriali rientrano nel regolamento macchine, e anche nel CRA quando la macchina o le sue parti hanno una connessione dati.
• I trattori agricoli e forestali disciplinati dal regolamento (UE) n. 167/2013 sono esclusi dal regolamento macchine, salvo le macchine montate su di essi. L'elenco delle esclusioni del CRA non cita quel regolamento, quindi un trattore connesso può rientrare nell'ambito del CRA.
• I veicoli stradali omologati ai sensi del regolamento (UE) 2019/2144 sono esclusi dal CRA.
• Componenti venduti separatamente. Il CRA si applica anche ai componenti software e hardware immessi sul mercato separatamente. Un fornitore che vende una ECU o un'unità telematica da sola è a pieno titolo un fabbricante ai sensi del CRA. Quando l'unità è solo integrata nella macchina, il fabbricante della macchina porta l'obbligo per l'intera macchina e deve esercitare la dovuta diligenza sul componente del fornitore.

Si tratta di informazioni generali, non di una consulenza legale. Verifichi la classificazione del Suo prodotto.

All'interno di una stessa macchina il software proviene da fonti diverse, e solo il team che costruisce un software può dire in modo affidabile che cosa contiene. Da quanto ci riferiscono i costruttori di macchine, le ECU bare-metal contengono poco open source, mentre il software Linux, Android e Windows ne contiene molto.

Bassi volumi, alta varietà. Un costruttore di macchine può avere centinaia di piattaforme sul mercato, venderne poche unità all'anno ciascuna e configurare molte macchine su ordinazione. Ogni configurazione è un insieme diverso di software, quindi una SBOM per ogni build conta più di una SBOM per ogni linea di prodotto.

Cicli di vita lunghi. Le macchine restano in servizio per un decennio o più, mentre i fornitori cambiano o cessano l'attività. Il record di ciò che è entrato in una versione del software va creato al momento della build, perché non può essere ricostruito anni dopo.

Il software dei fornitori prevale, e le loro SBOM sono spesso scadenti. Ci vengono segnalate SBOM di fornitori con componenti mancanti, senza package URL né CPE, senza licenze e senza hash, alcune scritte a mano e che non superano la convalida dello schema. L'analisi binaria di una ECU già programmata è un ripiego: ne indovina il contenuto invece di registrarlo.

Il rischio sta negli strati connessi. Gran parte della logica delle ECU è generata da modelli e contiene poco open source. L'open source e l'esposizione alla rete si concentrano negli strati Linux, di connettività e delle app, quindi concentri lì per primi i Suoi sforzi.

Un esempio illustrativo: lo stack software di una piattaforma fittizia di pala gommata, dal cloud fino alle ECU.

1. Back end cloud e app companionInterni. Prevalentemente open source ed esposti alla rete. Cyber Resilience Act.
2. Gateway telematicoLinux embedded, prevalentemente open source, connesso alla rete mobile. Cyber Resilience Act, e 1.1.9 per la connessione remota.
3. Display operatoreImmagine Linux embedded con un framework UI, prevalentemente open source, connessa al bus della macchina e agli strumenti di assistenza. Cyber Resilience Act e 1.1.9.
4. Controllore della macchinaApplicazione interna su una piattaforma del fornitore, rilevante per la sicurezza. 1.1.9 e 1.2.1, e il Cyber Resilience Act quando è raggiungibile tramite una connessione.
5. ECU idrauliche, dello sterzo e del motoreFirmware del fornitore, proprietario e generato da modelli, poco open source, rilevante per la sicurezza. 1.1.9 e 1.2.1; il Cyber Resilience Act attraverso la macchina.

L'open source e l'esposizione alla rete si trovano nei tre strati superiori, che sono anche quelli in cui di solito si trovano le Sue pipeline di build. Cominci da lì.

I costruttori di macchine fissano ora requisiti di SBOM per il software che acquistano, come package URL o CPE, licenze, hash e un formato che superi la convalida, e rimandano indietro i file che non li soddisfano. Se Lei costruisce su GitHub Actions, CRACI produce la SBOM dalla build stessa, quindi elenca ciò che è effettivamente entrato nella release, compresi i componenti che nessun lockfile nomina, con un package URL e la licenza dichiarata di ogni componente. Verifichi l'export rispetto all'elenco completo dei campi richiesti dal Suo cliente. Approfondisca come rispondere alle richieste di SBOM dai clienti.