prEN 50742: come proteggere le macchine connesse dalla corruzione di dati e software

Perché prEN 50742 è una norma da adottare fin da subito

Il Regolamento (UE) 2023/1230 ha introdotto nel settore macchine un cambio di impostazione netto, le macchine moderne non sono più solo cinematismi, ripari, sensori e attuatori. Sono sistemi digitali, spesso connessi, aggiornabili, configurabili e integrati in reti di stabilimento. Una macchina può ricevere dati da un MES, scambiare informazioni con uno SCADA, essere raggiunta da remoto per assistenza, usare un modem industriale, leggere ricette da una rete, salvare log su un server, comunicare con un cloud o essere configurata tramite tool software.

In questo contesto, la sicurezza non può più essere trattata solo con la logica classica del guasto casuale. Un sensore può guastarsi, ma anche un parametro di controllo dello stesso sensore può essere modificato. Un PLC può avere un errore hardware, ma un programma può anche essere aggiornato con una versione non autorizzata. Un riparo può essere interbloccato correttamente, ma la logica che interpreta il segnale può essere alterata. Un asse può rispettare una velocità sicura, ma il limite può essere modificato se la configurazione non è protetta.

prEN 50742 sarà importante perché prova a trasformare questo problema in un metodo. Non chiede al costruttore di diventare un reparto IT ma chiede di ragionare, in modo documentato, su interfacce, software, dati critici, modifiche, evidenze, livelli di protezione e informazioni per l’uso. È esattamente il tipo di approccio che mancava tra la cybersecurity e la sicurezza delle macchine secondo EN ISO 12100.

La norma è ancora un progetto e deve essere letta con prudenza, ad oggi il tema della cybersicurezza è un tema importante, chi produce macchine con accesso remoto, diagnostica online, PLC programmabili, safety controller, HMI evolute, ricette di processo, sistemi di visione, robot, azionamenti intelligenti o interfacce verso reti esterne dovrebbe iniziare ora.

Il Regolamento Macchine e la protezione contro la corruzione

La Direttiva Macchine 2006/42/CE è nata in un'epoca in cui la connettività industriale aveva un peso molto diverso: il cuore della conformità era l’analisi dei rischi meccanici ed elettrici; la cybersecurity non era espressa come requisito tecnico per la sicurezza della macchina. Con l’evoluzione dell'automazione, questa impostazione è diventata via via insufficiente: linee produttive, macchine packaging, impianti farmaceutici, macchine alimentari, robotica e sistemi di movimentazione sono oggi integrati in architetture digitali complesse.

Il Regolamento Macchine 2023/1230 interviene proprio su questo punto. L’Allegato III contiene il requisito 1.1.9, dedicato esclusivamente alla protezione dall'alterazione, e collega il tema anche alla sicurezza e affidabilità dei sistemi di comando del requisito 1.2.1. Il senso tecnico è molto chiaro: il collegamento di un dispositivo, fisico o remoto, alla macchina non deve portare la macchina in una condizione pericolosa; hardware, software e dati critici per la conformità ai requisiti essenziali devono essere identificati, protetti e tracciabili (asset).

Il progetto normativo prEN 50742 si inserisce in questa tematica per essere armonizzato al Regolamento Macchine. Esso non sostituisce EN ISO 12100, non sostituisce EN ISO 13849-1 o IEC 62061 per la sicurezza funzionale; piuttosto, costruisce un ponte: parte dai pericoli macchina, considera le minacce che possono corrompere dati e software e definisce misure di protezione quando tale corruzione può incidere sulla sicurezza.

Questa è la vera novità: non si parla di cybersecurity come requisito astratto, ma di protezione della sicurezza funzionale contro alterazioni accidentali o intenzionali. Per un fabbricante, la domanda non è più solo: il circuito raggiunge il Performance Level richiesto? Ma diventa anche: il software, i dati, le interfacce e le configurazioni che permettono a quella funzione di sicurezza di lavorare sono protetti contro modifiche che possono renderla inefficace?

Che cosa significa corruzione in una macchina

Nel linguaggio comune, corruzione può sembrare una parola generica, nel progetto normativo prEN 50742 assume invece un significato tecnico preciso: una modifica accidentale, legittima o illegittima di dati della macchina che può portare a una situazione pericolosa. Il punto non è solo l’attacco informatico intenzionale. È qualsiasi alterazione rilevante di software, parametri, configurazioni o dati critici che possa compromettere la riduzione del rischio.

Esempi concreti sono facili da immaginare: modifica di una soglia di velocità sicura, caricamento di una versione software non corretta, alterazione di un parametro di safety, aggiornamento non validato di firmware, cambiamento di configurazione HMI che abilita una funzione pericolosa, manipolazione di una ricetta con impatto sulla cinematica, sostituzione di un modulo con configurazione diversa, cancellazione di log, collegamento di un tool di manutenzione non controllato, bypass di un riparo ecc.

Le macchine moderne hanno in genere molte porte di ingresso; la corruzione può avvenire tramite rete Ethernet, Wi-Fi, USB, schede di memoria, card reader, accessi remoti, bus di campo, connessioni a sistemi esterni, tool di service, laptop di manutenzione, dispositivi temporanei o componenti installati in modo permanente. Alcune vulnerabilità sono evidenti, altre sono considerate banali finché non diventano il punto attraverso cui passa una modifica critica.

Questo è il motivo per cui prEN 50742 insiste sul concetto di interfaccia. Una porta fisica, un protocollo applicativo, un collegamento logico, una connessione temporanea di manutenzione o una comunicazione verso un servizio esterno possono diventare rilevanti se permettono di influenzare una funzione legata alla sicurezza. La valutazione non deve fermarsi al quadro elettrico: deve seguire il percorso reale del dato e del comando.

Campo di applicazione: macchine, prodotti correlati e quasi-macchine

Il progetto normativo prEN 50742 è stato scritto per le macchine, prodotti correlati e quasi-macchine quando hardware, software o dati possono influenzare la sicurezza. La logica è coerente con il Regolamento Macchine: non conta solo il prodotto finito, ma anche i componenti e i sistemi che, una volta integrati, partecipano alla riduzione del rischio.

Rientrano quindi nel ragionamento i componenti hardware che trasmettono segnali o dati, le interfacce verso dispositivi remoti, i sistemi di comando, il software embedded, il software applicativo di sicurezza, le configurazioni, le parametrizzazioni, i dati critici e le informazioni che consentono alla macchina di funzionare in condizioni sicure.

Tutte le interfacce della macchina verso sistemi e servizi esterni possono diventare un punto critico anche se il sistema esterno, preso in sé è fuori dal campo della macchina; l’interfaccia attraverso cui la macchina scambia dati o comandi deve essere sempre valutata. È un aspetto decisivo per macchine integrate in linee complesse, sistemi MES/SCADA, assistenza remota o altre tipologie di connessione esterna.

Il progetto normativo non deve essere interpretato come obbligo di blindare ogni macchina nello stesso modo, per esempio una macchina semplice, priva di connessioni e senza software o dati capaci di influenzare funzioni di sicurezza, avrà un profilo diverso rispetto a una linea automatica con accesso remoto e safety PLC parametrizzabile. Il metodo serve proprio a proporzionare le misure al contesto e all’impatto sulla safety.

Safety e cybersecurity: due temi diversi con un unico risultato

Il percorso corretto parte sempre dall’analisi dei rischi secondo EN ISO 12100. Prima si identificano i pericoli della macchina, si stimano i rischi e si definiscono le misure di riduzione; solo dopo ha senso valutare quali vulnerabilità o minacce possono corrompere quelle misure. Se non è chiaro quali funzioni siano legate alla sicurezza, la cybersecurity resta generica e non produce evidenze utili per la marcatura CE.

Il progetto normativo introduce il concetto di “security context”, cioè il contesto di sicurezza previsto per l’uso della macchina. È una parte che non deve essere sottovalutata. Una macchina destinata a funzionare in una rete segregata, senza Internet e con accesso fisico controllato, non ha lo stesso profilo di una macchina con modem sempre attivo, cloud diagnostico e service remoto da parte di terzi. Il costruttore deve dichiarare e documentare le condizioni previste, non lasciarle implicite.

Il “threat assessment” si affianca all’analisi secondo EN ISO 12100 proprio per individuare le minacce rilevanti per la macchina. Questa analisi deve concentrarsi sulle minacce che possono portare a situazioni pericolose: spoofing di identità, manipolazione di configurazioni, alterazione di memoria, cancellazione delle evidenze, escalation di privilegi, denial of service con effetto safety, collegamento a reti non previste, uso improprio di credenziali, aggiornamenti non controllati.

In pratica, il costruttore dovrebbe costruire una catena logica: pericolo macchina, funzione o misura di riduzione, asset digitale collegato, interfaccia o percorso di modifica, minaccia, vulnerabilità, conseguenza sulla safety, misura di protezione, evidenza di verifica. Questa catena è il cuore tecnico del fascicolo.

I due percorsi del progetto prEN 50742

Uno degli aspetti più interessanti del progetto è la presenza di due percorsi applicativi. Questa scelta è pragmatica, è possibile seguire la serie EN IEC 62443 oppure un’impostazione più classica da sicurezza macchine che integra il tema cyber senza costruire da zero un sistema completo IEC 62443.

Approccio A: metodo diretto con SRSL

L’Approccio A è pensato per i costruttori che vogliono applicare un metodo specifico per la macchina senza basarsi integralmente sulla serie EN IEC 62443. Il percorso parte dall’analisi dei rischi macchina, definisce il contesto di sicurezza, valuta le minacce, identifica le interfacce rilevanti e determina livelli di protezione collegati alle funzioni di sicurezza.

Il concetto centrale è lo SRSL, Safety-Related Security Level. Non è un Performance Level e non è un SIL. È un livello di protezione security collegato a una funzione o misura di riduzione del rischio. Serve a decidere quali requisiti minimi applicare in termini di autenticazione, autorizzazione, integrità, autenticità, validazione input, protezione dal tampering e tracciabilità.

L’Approccio A è molto interessante per i costruttori di macchine speciali, linee automatiche, macchine packaging, macchine alimentari e impianti industriali in cui la parte safety è già gestita con EN ISO 13849-1 o IEC 62061, ma il tema security non è ancora strutturato secondo IEC 62443. Consente di costruire un fascicolo tecnico più difendibile senza trasformare ogni progetto in una certificazione cyber complessa.

Approccio B: integrazione con EN IEC 62443

L’Approccio B è pensato per chi sviluppa macchine, sistemi o componenti nel contesto della serie EN IEC 62443. In questo caso il progetto collega il tema della protezione contro la corruzione a requisiti di processo e requisiti tecnici già presenti in EN IEC 62443-4-1, EN IEC 62443-3-3 e EN IEC 62443-4-2.

La logica è utile soprattutto per costruttori strutturati, produttori di componenti di automazione, system integrator con processi cyber maturi e macchine destinate a settori ad alta richiesta contrattuale: farmaceutico, infrastrutture, energia, grandi impianti, multinazionali, linee ad alta automazione e contesti soggetti a requisiti cliente molto stringenti.

Attenzione però: applicare IEC 62443 in modo generico non basta. Il punto richiesto dal progetto normativo prEN 50742 è collegare i requisiti security alle funzioni della macchina che incidono sulla sicurezza. L’obiettivo non è dimostrare che il prodotto è "cybersicuro" in senso assoluto, ma che la corruzione di software, dati e interfacce non degrada la sicurezza della macchina entro lo scenario previsto.

SRSL: Safety-Related Security Level applicato alle funzioni di sicurezza

Il concetto di SRSL merita attenzione, perché probabilmente entrerà nel linguaggio tecnico dei prossimi anni. Per ogni funzione di sicurezza o misura di riduzione del rischio rilevante, il progettista deve valutare quale livello di protezione sia necessario contro la corruzione. Il livello nasce dal fatto che non tutte le funzioni richiedono lo stesso livello di contenimento, non tutte le interfacce hanno la stessa esposizione e non tutti i dati hanno lo stesso impatto.

Il parametro SRSL deve essere il risultato di una valutazione. Per stabilirlo servono almeno tre elementi: impatto sulla safety, esposizione dell’interfaccia e potenziale di attacco o modifica. Una stessa macchina può avere funzioni diverse con livelli diversi. Ad esempio, una diagnostica senza effetto sulla safety può essere trattata in modo differente rispetto a un parametro che modifica una soglia di velocità sicura.

La forza del metodo è la tracciabilità. Il fascicolo tecnico deve poter mostrare perché una funzione è stata considerata SRSL1, SRSL2 o SRSL3, quali misure sono state applicate e come sono state verificate. Senza questa catena documentale, il livello resta solo una dichiarazione.

Tracing log e tracciabilità nel Regolamento Macchine

La registrazione delle evidenze sarà uno dei temi più critici. Il Regolamento Macchine chiede che la macchina sia in grado di raccogliere prove relative a interventi legittimi o illegittimi su hardware, software e configurazioni quando questi elementi sono rilevanti per la conformità ai requisiti essenziali. Il progetto normativo prEN 50742 traduce questo principio in requisiti tecnici di tracciabilità.

Non si tratta di registrare ogni evento della macchina, l’obbligo è raccogliere le evidenze degli interventi che possono modificare o interrompere comportamento, stato o funzionamento della macchina quando tali modifiche riguardano software, dati o configurazioni con impatto sulla sicurezza.

Per un costruttore significa ragionare su quattro aspetti: quali eventi sono da tracciare, dove sono conservati, per quanto tempo rimangono disponibili e come sono protetti contro manomissione o cancellazione non autorizzata; il formato deve essere leggibile o almeno documentato e sempre disponibile.

Il tema dei cinque anni è particolarmente rilevante, la tracciabilità delle versioni software e degli interventi safety-related deve essere progettata prima, non aggiunta dopo. Se il sistema non ha memoria sufficiente, se i log vengono sovrascritti troppo presto, se non esiste una procedura di esportazione o se la cancellazione non è controllata, il costruttore avrà difficoltà a dimostrare la conformità in caso di richiesta dell’autorità o contestazione post-installazione.

Fascicolo tecnico e manuale istruzioni

Il fascicolo tecnico della macchina dovrà integrare l’analisi secondo prEN 50742. Di seguito è visibile lo schema logico proposto dal progetto normativo.

Come si vede dal workflow, il manuale istruzioni deve essere coerente con il fascicolo. Se la valutazione assume che la macchina sia connessa solo a una rete fidata, questa condizione deve essere indicata. Se un accesso remoto è ammesso solo tramite procedura autorizzata, va descritto. Se alcune modifiche sono vietate, il divieto deve essere chiaro. Se l’utilizzatore deve gestire password, backup o aggiornamenti, deve ricevere istruzioni tecniche sufficienti.

Questo non riguarda solo l’utilizzatore, significa distinguere correttamente ciò che è incorporato nella macchina da ciò che dipende dal contesto di installazione e uso. Una macchina progettata per una rete segregata non deve essere venduta con istruzioni vaghe che permettono qualunque collegamento. Le assunzioni progettuali devono diventare condizioni d’uso.

Rapporto con CRA, NIS2, RED e AI Act

Il progetto normativo prEN 50742 è realizzato per una futura armonizzazione al Regolamento macchine e fa parte di un quadro europeo più ampio in cui la sicurezza dei prodotti digitali, la resilienza cyber e la sicurezza delle macchine stanno convergendo:

• Il Cyber Resilience Act riguarda i prodotti con elementi digitali e introduce requisiti di cybersecurity lungo il ciclo di vita.
• La NIS2 riguarda la resilienza delle organizzazioni e delle supply chain in settori importanti o essenziali.
• La RED può diventare rilevante per moduli radio, Wi-Fi, Bluetooth, LTE/5G e dispositivi radio integrati.
• L’AI Act entra in gioco se la macchina incorpora sistemi di intelligenza artificiale in ambiti regolati, soprattutto se collegati alla sicurezza.

Questo framework renderà più frequenti le richieste dei clienti su software bill of materials, vulnerabilità, accessi remoti, patch, logging, gestione versioni, segregazione di rete e procedure di aggiornamento. Il costruttore che avrà già integrato prEN 50742 nel proprio metodo di analisi dei rischi sarà più credibile anche nelle trattative commerciali e negli audit tecnici.

Errori possibili dei fabbricanti

• Dire che la cybersecurity è un problema del cliente utilizzatore e non del prodotto macchina.
• Considerare solo la rete Ethernet e dimenticare USB, laptop di service, schede di memoria, HMI, accessi locali e tool di programmazione.
• Dichiarare una macchina isolata senza considerare manutenzione, collaudo, aggiornamenti e assistenza da remoto.
• Non distinguere dati produttivi da dati critici per la sicurezza.
• Lasciare credenziali condivise, password standard o ruoli HMI troppo ampi.
• Permettere la modifica di parametri safety-related senza autorizzazione, log o verifica di integrità.
• Non registrare interventi su software, configurazioni o versioni rilevanti per la safety.
• Non proteggere i log dalla cancellazione o dalla manipolazione.
• Applicare misure crittografiche senza verificarne l’impatto su tempi di risposta e comportamento della funzione di sicurezza.
• Scrivere nel manuale istruzioni frasi generiche come "collegare solo a reti sicure" senza definire il contesto di sicurezza previsto.
• Non conservare evidenze nel fascicolo tecnico: mappe interfacce, threat assessment, criteri SRSL, test, procedure, log e versioni.
• Trattare IEC 62443 come certificato generico, senza collegarla alle funzioni di sicurezza della macchina.

Come Waves Engineering supporta i fabbricanti

Waves Engineering supporta i costruttori nell’integrazione della protezione contro la corruzione all’interno della sicurezza delle macchine. Il lavoro parte dall’analisi dei rischi EN ISO 12100 e arriva al fascicolo tecnico: mappa delle interfacce, identificazione degli asset safety-related, threat assessment, valutazione dello SRSL, verifica delle misure tecniche, coerenza con EN ISO 13849-1, manuale istruzioni e documentazione per marcatura CE.

L’obiettivo è rendere dimostrabile che la macchina è stata progettata considerando i rischi di alterazione di software, dati e configurazioni quando questi possono incidere sulla sicurezza. Questo approccio riduce contestazioni, migliora la qualità del fascicolo tecnico e prepara il costruttore all'applicazione del Regolamento Macchine 2023/1230.

FAQ

Che cos’è prEN 50742?

prEN 50742 è un progetto di norma europea sulla sicurezza delle macchine dedicato alla protezione contro la corruzione. Tratta alterazioni accidentali o intenzionali di software, dati, configurazioni, interfacce e componenti quando possono generare situazioni pericolose o degradare funzioni di sicurezza.

prEN 50742 è già obbligatoria?

No. Al momento va trattata come progetto normativo e non come standard definitivo. Tuttavia, il tema è già rilevante perché deriva dai requisiti del Regolamento Macchine 2023/1230. Dopo l’eventuale pubblicazione e citazione in Gazzetta Ufficiale UE, la norma potrà diventare un riferimento molto importante per la presunzione di conformità nei limiti del suo campo di applicazione.

Qual è la differenza tra prEN 50742 e IEC 62443?

IEC 62443 è una serie di norme per la cybersecurity dei sistemi di automazione e controllo industriale. prEN 50742 è focalizzata sulla sicurezza delle macchine e sulla protezione contro la corruzione quando la modifica di dati o software può avere conseguenze sulla safety. Il progetto prevede anche un percorso che consente di usare IEC 62443 in modo coerente con le funzioni di sicurezza delle macchine.

La norma riguarda solo le macchine collegate a Internet?

No. Internet è solo uno degli scenari. Possono essere rilevanti anche reti locali, porte USB, schede SD, tool di manutenzione, laptop di service, HMI, bus di campo, RFID, accessi temporanei e collegamenti a sistemi esterni. Conta la possibilità di influenzare software, dati o parametri legati alla sicurezza.

Che cosa significa SRSL?

SRSL significa Safety-Related Security Level. È un livello di protezione security collegato a una funzione o misura di riduzione del rischio. Serve a decidere quali requisiti applicare per proteggere quella funzione dalla corruzione di dati, software, configurazioni o comunicazioni.

prEN 50742 sostituisce EN ISO 12100 o EN ISO 13849-1?

No. EN ISO 12100 resta il riferimento per l’analisi dei rischi macchina. EN ISO 13849-1 resta il riferimento per le parti dei sistemi di comando legate alla sicurezza quando applicabile. prEN 50742 si aggiunge a questi riferimenti per trattare le minacce di corruzione che possono degradare la sicurezza.

Cosa deve cambiare nel fascicolo tecnico?

Devono comparire evidenze più robuste su interfacce, software, dati critici, minacce, security context, log, versioni, aggiornamenti, accessi e misure di integrità. Il fascicolo deve dimostrare il collegamento tra rischio macchina e protezione dalla corruzione, non limitarsi a una frase generica sulla cybersecurity.

Vale anche per macchine già installate?

Il progetto indica un’applicazione alle macchine rispetto alla propria data di pubblicazione e non deve essere letto come obbligo retroattivo automatico. Tuttavia, per modifiche, revamping, aggiornamenti software, accessi remoti o nuove integrazioni, il tema può diventare rilevante nella valutazione tecnica e contrattuale.