Aggiornato a settembre 2026. La prEN 50742 è ancora un progetto e il suo stato di armonizzazione è in evoluzione: verifica la versione e lo stato più recenti prima di un uso formale.
Dal 20 gennaio 2027 la marcatura CE di una macchina include, per la prima volta, requisiti di cybersecurity. Il Regolamento (UE) 2023/1230 porta nell’Allegato III due sezioni, protezione contro la corruzione (1.1.9) e sicurezza dei sistemi di comando (1.2.1), che chiedono cose finora estranee alla safety meccanica. La reazione più comune, quando un costruttore le legge, è pensare “devo mettere in sicurezza tutta la macchina”. È una reazione sbagliata, e costosa.
Il compito è più circoscritto di così, e (questa è la buona notizia) si innesta su cose che il produttore già fa: l’analisi del rischio, il fascicolo tecnico, la dichiarazione di conformità. Questo articolo non ripete cosa dice la norma (per il quadro completo, gli allegati e il rapporto con CRA, NIS2 e IEC 62443 c’è la guida Regolamento Macchine (UE) 2023/1230), ma prova a rispondere alla domanda successiva: e adesso, in pratica, da dove parto e cosa metto in campo?
Prima mossa: delimitare il perimetro “rilevante per la sicurezza”
Il singolo errore che fa lievitare il lavoro è trattare l’1.1.9 come “fai cybersecurity a tutto campo sulla macchina”. Non è quello che chiede. Il requisito è mirato: una corruzione (accidentale o dolosa) di hardware, software o dati rilevanti per la sicurezza non deve tradursi in una situazione pericolosa. È cybersecurity al servizio della safety, non sicurezza informatica in senso ampio.
La differenza è concreta. La riservatezza dei dati di produzione, la continuità del servizio, il furto di know-how sono problemi reali, ma non sono l’oggetto dell’1.1.9: appartengono semmai al CRA o alla sicurezza dell’organizzazione. Qui conta solo la porzione in cui una manomissione produce un pericolo fisico per le persone.
Da qui il primo passo concreto, prima di qualsiasi misura tecnica: fare l’inventario di ciò che è rilevante per la sicurezza. Quali funzioni della macchina, se alterate, generano un pericolo? Quali componenti hardware le realizzano? Quale software e (punto spesso dimenticato) quali dati (parametri, soglie, set-point, logiche di sicurezza) le governano? Ciò che finisce in questo elenco è il perimetro dei requisiti cyber del Regolamento. Tutto il resto, ai fini dell’1.1.9, è fuori.
Un esempio di righe compilate, per fissare le colonne:
| Funzione rilevante per la sicurezza | Componente hardware | Software | Dati critici | Pericolo se alterato |
|---|---|---|---|---|
| Arresto in stato sicuro dell’asse | Modulo/PLC di sicurezza | Firmware safety, logica di sicurezza | Tempi di reazione, soglie di velocità, limiti di corsa | Mancato arresto: schiacciamento o urto dell’operatore |
| Sorveglianza di un riparo interbloccato | Sensore di sicurezza + relè | Logica di monitoraggio degli ingressi | Configurazione degli ingressi safety | Riparo aperto non rilevato: accesso a organi in movimento |
Ogni riga di questa tabella è un candidato agli scenari di rischio del passo successivo: se non è nell’elenco, non è un requisito del Regolamento.
Nota operativa (mia lettura, non testo di legge). Questo inventario è il documento più prezioso dell’intero esercizio, perché è anche ciò che ti difende dall’over-engineering: quando qualcuno propone di cifrare tutto o di irrobustire un sottosistema che non tocca la safety, la domanda è una sola: quel componente è nell’elenco dei “rilevanti per la sicurezza”? Se no, non è un requisito del Regolamento Macchine.
Estendi l’analisi del rischio che già fai
L’analisi e la riduzione del rischio restano il pilastro della conformità, come nella Direttiva 2006/42/CE. La novità non è aggiungere un documento separato: è estendere l’analisi che già conduci con scenari che prima non consideravi, quelli di manomissione.
Concretamente, accanto ai guasti e agli usi scorretti che già valuti, entrano scenari di corruzione, accidentale e intenzionale, di ciò che hai messo nell’inventario. Alcuni esempi da mettere a tabella:
- alterazione del firmware del sistema di comando (flash locale, aggiornamento non autenticato, downgrade a una versione vulnerabile);
- manomissione dei parametri di sicurezza (soglie, tempi di reazione, limiti di funzionamento) da interfaccia di servizio;
- comando iniettato attraverso una connessione remota, un bus di campo o una porta di diagnostica lasciata aperta;
- corruzione dei dati in transito tra sensore di sicurezza e logica di comando.
Per ogni scenario, la domanda del Regolamento è sempre la stessa: questa corruzione può portare a una situazione pericolosa? Dove la risposta è sì, serve una misura. Dove è no, si documenta il perché e ci si ferma. È lo stesso schema mentale della valutazione del rischio meccanico, applicato a una nuova classe di cause.
Messo a tabella, uno scenario compilato ha questa forma:
| Scenario di corruzione | Può generare un pericolo? | Misura | Rif. |
|---|---|---|---|
| Aggiornamento del firmware del safety PLC non autenticato | Sì, un firmware alterato può disattivare l’arresto | Firma digitale e secure boot, blocco del downgrade a versioni vulnerabili | 1.2.1 |
| Modifica dei tempi di reazione da interfaccia di servizio senza autenticazione | Sì, soglie alterate ritardano l’arresto | Autenticazione sulle funzioni che toccano parametri safety, log della modifica | 1.1.9 |
| Lettura dei dati di produzione da porta di diagnostica | No, nessun effetto sulla safety | Nessuna ai fini dell’1.1.9 (semmai è un tema CRA) | - |
L’ultima riga conta quanto le prime due: documentare perché uno scenario non richiede misure è ciò che tiene il fascicolo difendibile e il lavoro proporzionato.
Scegli il percorso di conformità: prEN 50742, approccio A o B
I requisiti essenziali dicono cosa ottenere, non come. Il “come” lo fornirà la norma tecnica di supporto: la prEN 50742 (“Safety of machinery - Protection against corruption”), candidata a diventare la norma armonizzata di riferimento per l’1.1.9. Attenzione: alla data di questo articolo è ancora un progetto (prEN 50742), non pubblicata come armonizzata. Puoi (e conviene) impostare il lavoro su di essa fin da ora, ma lo stato di armonizzazione va verificato prima di invocarne la presunzione di conformità.
La norma prevede due percorsi alternativi, ed è una scelta che vale la pena fare presto perché indirizza tutto il resto:
- Approccio A, basato sulla valutazione del rischio. Pensato per le macchine non progettate in origine secondo la IEC 62443. Parti dagli scenari di corruzione della tua analisi del rischio e adotti le misure proporzionate, senza dover prima abbracciare l’intero impianto dell’industrial security.
- Approccio B, basato sulla IEC 62443. Adotta i requisiti della serie IEC 62443 (gestione delle vulnerabilità, controllo degli accessi, integrità di software e dati, protezione delle interfacce), adattati al settore dei macchinari.
Il criterio di scelta è quasi sempre uno: da dove parti. Se lavori già in ottica IEC 62443, perché servi clienti OT (le tecnologie operative) o perché ti stai preparando al CRA, l’Approccio B è la via diretta: quel lavoro non è solo evidenza riusabile, è la strada maestra verso la presunzione di conformità. Se invece parti da una macchina “tradizionale”, l’Approccio A ti fa arrivare al risultato senza il costo di adottare tutto il framework 62443 solo per l’occasione. Una precisazione di ruoli da non perdere: la norma che dà la presunzione di conformità è la prEN 50742, non la 62443 in quanto tale; la 62443 è l’impianto tecnico su cui uno dei due percorsi poggia.
Le misure tecniche, mappate ai requisiti
Chiarito il perimetro e scelto il percorso, le misure concrete si raggruppano in quattro famiglie, tutte ancorate a ciò che chiedono l’1.1.9 e l’1.2.1.
| Famiglia di misure | Cosa chiede il Regolamento | Misure tipiche | Rif. |
|---|---|---|---|
| Integrità di software e dati critici | Software e dati rilevanti per la sicurezza “identificati come tali e adeguatamente protetti contro la corruzione accidentale o intenzionale” | Verifica di integrità e autenticità del firmware (firma digitale, secure boot dove il sistema di comando lo consente), aggiornamenti solo autenticati, blocco del downgrade a versioni vulnerabili | 1.2.1 |
| Controllo accessi e protezione delle interfacce | La connessione a un altro dispositivo “di qualunque tipo” non deve poter generare un pericolo | Autenticazione per accedere alle funzioni che toccano parametri di sicurezza, chiusura di default delle porte non necessarie, segmentazione tra rete di controllo della safety e resto | 1.1.9 |
| Evidenza della manomissione | Deve esistere evidenza di un intervento (legittimo o illegittimo) sui componenti critici per la sicurezza | Log degli accessi e delle modifiche ai parametri di sicurezza, tamper-evidence hardware dove ha senso, tracce che dopo un evento dicano se qualcosa è stato toccato | 1.1.9 |
| Sistemi di comando che resistono alla corruzione | I sistemi di comando devono “resistere agli effetti previsti di una corruzione” | Segregazione della funzione di sicurezza dal resto della logica, stato sicuro di ripiego se viene rilevata un’alterazione, nessun percorso diretto dalla parte “connessa e comoda” verso ciò che ferma o mette in moto in sicurezza | 1.2.1 |
Due chiavi di lettura che la tabella da sola non dà. La prima: l’obiettivo è preciso, impedire che il codice e i parametri che governano la safety siano alterati senza che la macchina se ne accorga. La seconda riguarda l’evidenza della manomissione, il requisito più spesso trascurato perché non è “impedire” ma “rendere accertabile”: non serve un sistema di gestione degli eventi di sicurezza (SIEM) industriale, serve che una manomissione non passi invisibile.
Per ciascuna famiglia, la calibrazione la dà l’analisi del rischio: la misura è adeguata quando riduce lo scenario pericoloso a un livello accettabile, non quando esaurisce lo stato dell’arte della cybersecurity. Questo è, di nuovo, ciò che tiene il costo sotto controllo.
Non duplicare: riusa il lavoro fatto per il CRA
Una macchina moderna con elementi digitali e connessioni è quasi sempre, insieme, un “prodotto con elementi digitali” ai sensi del CRA (Regolamento (UE) 2024/2847) e una macchina ai sensi del 2023/1230. Non scegli: soddisfi entrambi. Ma i due atti non chiedono di fare due volte lo stesso lavoro.
La conformità ai requisiti di cybersecurity del CRA può coprire i requisiti 1.1.9 e 1.2.1 del Regolamento Macchine, a condizione che tu lo dimostri. Dove il CRA ti ha già portato a costruire integrità del software, gestione degli accessi, gestione delle vulnerabilità, buona parte dell’evidenza per l’Allegato III è già prodotta. La cosa efficiente è un’unica base di evidenze e una sola dichiarazione di conformità che cita entrambi i regolamenti, non due filoni paralleli.
Resta una distinzione di scopo da tenere esplicita: il CRA guarda alla resilienza cyber del prodotto nel suo complesso, per tutta la vita utile; il Regolamento Macchine guarda solo alla manomissione che genera un pericolo fisico. Il lavoro CRA agevola quello Macchine, ma non lo esaurisce, e viceversa. Per il quadro del CRA c’è la guida CRA in un’ora; su quanto lavoro del CRA valga anche altrove, Sei un produttore soggetto al CRA. NIS2 ti riguarda anche come azienda?.
Il caso speciale: una funzione di sicurezza affidata all’AI
Un’avvertenza per chi mette machine learning dentro una funzione di sicurezza. Se una funzione di safety è realizzata da un sistema con comportamento evolutivo o auto-adattivo basato su ML, la macchina entra tra quelle ad alto rischio dell’Allegato I. Per queste categorie la valutazione di conformità (art. 25) si irrigidisce: il controllo interno con autocertificazione non è più la via ordinaria e, per le funzioni di sicurezza basate su ML auto-evolutivo, serve tipicamente l’intervento di un organismo notificato. Una sfumatura da non dare per scontata: l’esatto percorso applicabile dipende dalla categoria dell’Allegato I e dall’esistenza e piena applicazione di norme armonizzate, quindi va verificato sull’art. 25. In ogni caso cambia la procedura, non solo i requisiti tecnici, e va messo in conto nei tempi.
Sul piano tecnico il riferimento in maturazione è la ISO/IEC TS 22440 (sicurezza funzionale dei sistemi di AI), nata proprio per il problema che gli standard classici non gestivano: un comportamento che cambia nel tempo. E c’è un secondo cappello: la stessa funzione ricade tipicamente anche sotto l’AI Act, che qualifica come ad alto rischio i sistemi di AI che sono componenti di sicurezza di prodotti armonizzati. Non sono alternative: sono due lenti sullo stesso componente, da mappare in parallelo fin dalla progettazione. Se non stai affidando funzioni di sicurezza all’AI, questa sezione non ti riguarda e il perimetro resta quello dei paragrafi precedenti.
Documentazione e istruzioni all’utilizzatore
Le misure vanno raccontate dove la conformità si dimostra. Nel fascicolo tecnico entrano l’inventario dei componenti rilevanti per la sicurezza, l’analisi del rischio estesa agli scenari di corruzione, le misure adottate e la loro giustificazione, il percorso prEN 50742 seguito. La dichiarazione di conformità UE cita le norme applicate e, quando pertinente, sia il Regolamento Macchine sia il CRA.
C’è poi un pezzo che tocca l’utilizzatore. Molte misure funzionano solo se la macchina è installata e gestita correttamente: le istruzioni per l’uso devono dire come configurarla in modo sicuro (credenziali da cambiare, porte da non esporre, aggiornamenti da applicare) e dove finisce la responsabilità del costruttore e comincia quella dell’integratore o dell’utilizzatore. Una macchina consegnata sicura ma con la porta di diagnostica aperta e la password di default è un rischio che si può, e si deve, chiudere con le istruzioni, non solo con l’hardware.
Cosa fare ora
Il 20 gennaio 2027 sembra lontano, ma non lo è per chi progetta macchine con un ciclo di sviluppo pluriennale: le macchine in progettazione oggi sono quelle che verranno immesse sul mercato sotto il nuovo regime. La cybersecurity delle macchine si progetta dall’inizio, non si aggiunge alla fine: un secure-by-design costa una frazione di un retrofit su una macchina già chiusa.
In sintesi, i passi concreti:
- Inventaria i componenti, il software e i dati rilevanti per la sicurezza. È il perimetro, ed è ciò che ti difende dall’over-engineering.
- Estendi l’analisi del rischio con gli scenari di corruzione accidentale e intenzionale di quel perimetro.
- Scegli il percorso prEN 50742: Approccio A (risk-based) o B (IEC 62443), in base a da dove parti.
- Applica le misure su quattro fronti: integrità di software e dati, controllo degli accessi e interfacce, evidenza della manomissione, sistemi di comando che resistono alla corruzione.
- Riusa il lavoro CRA: una base di evidenze, una dichiarazione di conformità che cita entrambi.
- Se una funzione di sicurezza usa AI evolutiva, metti in conto l’organismo notificato e la doppia lente con l’AI Act.
- Documenta nel fascicolo tecnico e traduci in istruzioni d’uso ciò che dipende da chi installa e gestisce.
Il filo che tiene insieme tutto è la delimitazione iniziale: questi requisiti non ti chiedono di diventare un’azienda di cybersecurity, ti chiedono di garantire che nessuna manomissione dei componenti giusti si trasformi in un pericolo per le persone. Fatto bene, è un lavoro proporzionato, e in buona parte già iniziato, se stai lavorando al CRA.
Se stai progettando ora una macchina che verrà immessa sul mercato sotto il nuovo regime, il punto difficile non è leggere l’Allegato III: è delimitare il perimetro “rilevante per la sicurezza” nel tuo prodotto specifico, senza allargarlo (costoso) né stringerlo troppo (non conforme).
Il Regulatory Spark è una call di 45 minuti per fare esattamente questo: dove la manomissione dei componenti giusti può generare un pericolo nella tua macchina, quale percorso prEN 50742 conviene e quanto del lavoro CRA puoi riusare. Esci con una sintesi scritta, una direzione e, se ti serve, il template dell’inventario dei componenti rilevanti per la sicurezza, la tabella qui sopra pronta da compilare. Senza fuffa.
Riferimenti: Regolamento (UE) 2023/1230 (Regolamento Macchine), Allegato I sulle categorie ad alto rischio e Allegato III, sezioni 1.1.9 (protezione contro la corruzione) e 1.2.1 (sicurezza e affidabilità dei sistemi di comando); applicazione dal 20 gennaio 2027. Regolamento (UE) 2024/2847 (CRA). prEN 50742 “Safety of machinery - Protection against corruption” (progetto, non ancora armonizzata). ISO/IEC TS 22440 (sicurezza funzionale e sistemi di AI). Serie IEC 62443. Le note segnalate come operative sono mie interpretazioni, non testo normativo; i numeri di sezione e lo stato di pubblicazione delle norme tecniche vanno verificati sull’atto e sull’elenco ufficiale della Commissione prima di un uso formale. Il quadro completo è nella guida Regolamento Macchine (UE) 2023/1230.