CRA per i costruttori di macchine dopo gli orientamenti della Commissione del 27 luglio 2026. Che cosa occorre davvero attuare?

Per anni la cybersicurezza di una macchina si è lasciata riassumere in tre passaggi: PLC di marca, VPN “perché si fa così” e il classico “la rete la mette in sicurezza il cliente”. E se qualcuno aggiungeva anche un firewall nel quadro, la questione veniva spesso considerata chiusa — almeno finché nessuno provava a verificare cosa accade davvero in caso di attacco reale, e non in una presentazione.

Il punto è che la cybersicurezza non viaggia su PROFINET. I componenti possono avere certificazioni, dichiarazioni e “secure by design” nella brochure marketing, ma la macchina nel suo insieme può comunque restare prevedibile in un modo che con la sicurezza non ha nulla a che vedere. Proprio come un relè di sicurezza non rende sicuro un sistema se la logica di comando ne consente l’aggiramento, così un HMI “sicuro” non risolve i problemi di architettura, integrazione, autorizzazioni, aggiornamenti e di ciò che accade quando qualcuno smette di chiedere il permesso.

CRA (Cyber Resilience Act, Regolamento del Parlamento europeo e del Consiglio (UE) 2024/2847) non è un’aggiunta per l’IT. È una normativa di prodotto che entra nel ciclo di vita della macchina senza chiedere il permesso al reparto automazione. Riguarda la progettazione del controllo, l’analisi del rischio, la catena di fornitura, la configurazione, gli aggiornamenti e anche il mantenimento del prodotto molto tempo dopo che il FAT è stato firmato e la macchina ha lasciato lo stabilimento. E no, l’argomento “non la esponiamo a internet” non chiude la questione. In pratica basta un laptop di assistenza, una chiavetta USB, una diagnostica remota “solo per un attimo” oppure l’integrazione con un sistema di stabilimento perché il confine tra isolamento ed esposizione smetta di esistere.

Le linee guida della Commissione del 27 luglio 2026 non hanno modificato il regolamento in sé, ma hanno ristretto in modo efficace lo spazio interpretativo che prima consentiva di trattare la cybersicurezza come uno strato opzionale. Sono stati chiariti, tra l’altro, il perimetro del prodotto, il ruolo dell’elaborazione remota, la responsabilità per le modifiche dopo la consegna e il fatto che “dopo il FAT non è più un nostro problema” non è più un presupposto sicuro.

La modifica più importante, però, è ancora più radicale: il cyberattacco smette di essere un evento esclusivamente IT e diventa uno scenario che incide sulla sicurezza funzionale della macchina. Se una modifica non autorizzata del programma può provocare il movimento di un asse, l’aggiramento di un interblocco, la modifica dei parametri di processo oppure la perdita di una funzione di sicurezza, allora non stiamo più parlando di un “incidente di rete”. Stiamo parlando di un comportamento potenzialmente incontrollato della macchina — indipendentemente dal fatto che l’origine sia un errore di configurazione, una vulnerabilità software o un’interferenza intenzionale.

In questo contesto, un pentest eseguito una sola volta prima del FAT smette di essere una prova di conformità e diventa soltanto un’istantanea dello stato del sistema in un determinato momento. Il CRA richiede un approccio continuo: dalla progettazione, passando per la produzione e la messa in servizio, fino agli aggiornamenti, alla gestione delle vulnerabilità, alla risposta agli incidenti e al mantenimento per il periodo di supporto dichiarato.

In pratica, questo significa abbandonare la logica “fatto = sicuro” a favore di “mantenuto = sotto controllo”. Senza l’illusione che un firewall nel quadro, una VPN e il certificato di un componente chiudano la questione. E senza presumere che la cybersicurezza finisca nel momento in cui viene firmato il verbale di accettazione.

In questo articolo analizziamo che cosa cambiano davvero le linee guida CRA per costruttori, integratori e soggetti che eseguono revamping di macchine — senza ridurre l’intero tema allo slogan “cambiamo la password e aggiungiamo una checkbox cybersecurity”.

1. Per restare fuori dal CRA, una macchina dovrebbe essere quasi tutta a contattori

In molti progetti, il perimetro del CRA viene verificato con una sola domanda:

La macchina sarà collegata a internet?

No.

Quindi il tema è chiuso.

Nello schema ci sono un PLC, un HMI, alcuni azionamenti, ingressi e uscite distribuiti, un’isola di valvole, uno scanner di sicurezza e una porta per caricare il programma. Il controllore comunica con il pannello via PROFINET, con gli azionamenti scambia parole di comando e di stato, e i sensori trasmettono dati tramite IO-Link.

Però non c’è nessun router con scheda SIM.

Come tutti sanno, i dati diventano dati solo quando escono dal reparto produttivo.

Solo che il CRA non chiede se la macchina ha accesso a internet.

Chiede se la sua destinazione d’uso o il suo uso ragionevolmente prevedibile comprendono un collegamento dati diretto o indiretto, logico oppure fisico, con un dispositivo o una rete. Non deve trattarsi di un collegamento al cloud, a un server del produttore o a internet pubblico. Può avvenire via cavo, tramite onde radio, attraverso un’interfaccia software oppure come parte di un sistema più ampio.

E qui arriva la domanda chiave: in una macchina tipica, che cosa trasmette davvero dati?

L’HMI legge gli stati dal PLC e scrive i setpoint?

Il PLC invia all’azionamento una parola di comando e riceve in risposta velocità, stato e codice di errore?

L’isola di ingressi e uscite trasmette l’immagine del processo?

Il sensore IO-Link invia il valore di misura, l’identificativo del dispositivo e i dati diagnostici?

Il safety PLC comunica con i moduli tramite PROFIsafe?

Il programma, la configurazione hardware o il firmware vengono caricati da un laptop di assistenza?

Ricette, report o aggiornamenti possono essere trasferiti via USB?

Se anche una sola volta la risposta è “sì”, allora con ogni probabilità siamo in presenza di un collegamento dati.

E non cambia nulla il fatto che:

• la macchina opera in una rete locale,
• non dispone di un indirizzo IP pubblico,
• la porta Ethernet viene utilizzata solo durante la messa in servizio,
• il laptop viene collegato esclusivamente dal servizio di assistenza,
• la comunicazione avviene solo all’interno del sistema di controllo,
• il cliente ha promesso che non collegherà mai la macchina a internet.

Il CRA non riguarda soltanto l’uso descritto nel manuale come uso previsto, ma anche l’uso ragionevolmente prevedibile. Una porta di servizio, quindi, non smette di trasmettere dati solo perché sullo schema è stata etichettata “SERVICE ONLY”.

Le linee guida della Commissione del 27 luglio 2026 introducono però una distinzione importante.

Non ogni cavo e non ogni segnale elettrico costituisce una connessione dati.

Se un segnale serve esclusivamente ad attivare, disattivare oppure alimentare una determinata funzione e non trasmette informazioni codificate in formato digitale, la semplice presenza di due stati elettrici non basta ancora per considerarlo una connessione dati.

Un pulsante che porta tensione alla bobina di un contattore non diventa un’interfaccia digitale solo perché il suo stato può essere descritto come zero oppure uno.

Allo stesso modo, un classico finecorsa inserito in un circuito a relè e contattori può limitarsi ad aprire o chiudere il circuito. Non trasmette il numero del dispositivo, un valore di processo, un codice diagnostico, la versione del firmware né un telegramma contenente più informazioni.

Ma quando quello stesso stato arriva a un dispositivo intelligente, viene codificato, trasmesso tramite bus, associato alla diagnostica e interpretato dal ricevente come informazione, allora la situazione cambia.

Il confine, quindi, non passa tra una macchina “online” e una “offline”.

Passa tra un semplice segnale di comando e uno scambio di informazioni codificate digitalmente.

Per questo, nella pratica, una macchina che dovrebbe rimanere fuori dal campo di applicazione del CRA esclusivamente per l’assenza di una connessione dati dovrebbe assomigliare più a un impianto classico con pulsanti, finecorsa, relè e contattori che a un progetto moderno aperto in TIA Portal.

Naturalmente, questo non significa che esista un’esclusione di legge per i contattori.

Si può realizzare una macchina semplice con PLC che, dopo un’analisi dettagliata, non soddisfi il criterio di applicabilità. E si può anche aggiungere a un circuito a contattori un regolatore digitale, un’interfaccia di servizio oppure un modulo di comunicazione e ritrovarsi esattamente dall’altra parte del confine.

Il nome del componente non decide la questione.

Conta ciò che il prodotto fa realmente e con che cosa scambia dati.

Perciò, prima di rispondere alla domanda se una determinata macchina rientri nel CRA, occorre stabilire:

• dove si colloca il confine del prodotto oggetto della valutazione,
• quali dispositivi ed elementi software ne fanno parte,
• quali interfacce fisiche e logiche possiede,
• quali informazioni vengono trasmesse attraverso di esse,
• quali connessioni sono dirette e quali avvengono tramite un sistema più ampio,
• quali di esse si presentano durante il normale funzionamento, la messa in servizio, la diagnostica, l’aggiornamento oppure l’assistenza,
• quali modalità d’uso sono ragionevolmente prevedibili, anche se il fabbricante preferirebbe non prevederle.

Finché non rispondiamo a queste domande, non sappiamo se la macchina resti fuori dal campo di applicazione del CRA.

Abbiamo al massimo una formula comoda:

“La macchina non è collegata a internet”.

Il punto è che questa è la risposta a una domanda che il CRA non pone.

PROFINET non è internet. E per il CRA non è affatto necessario che lo sia.

2. La cybersicurezza non si trasmette via PROFINET

In molti progetti, il tema della conformità della macchina inizia già nella fase di acquisto.

PLC di un produttore riconosciuto.
HMI con firmware aggiornato.
Switch gestito.
Router industriale con VPN.
Azionamenti con funzioni di sicurezza.
Safety PLC con certificazione adeguata.

Per ogni dispositivo ci sono dichiarazione di conformità, istruzioni e alcuni documenti con parole come “secure”, “encrypted” e “defence in depth”.

Sullo schema, tutto appare professionale.

Ma ancora non si sa se la macchina completa sia davvero sicura dal punto di vista informatico.

Perché la cybersicurezza non “passa” attraverso PROFINET.

È un po’ come la serratura di una porta:
puoi avere un’ottima serratura in ogni stanza, certificata, collaudata, con una documentazione impeccabile e l’ologramma “secure”, ma questo non garantisce comunque la sicurezza se qualcuno ha lasciato la porta d’ingresso spalancata “perché così durante la messa in servizio si faceva prima”.

Ed è esattamente lo stesso anche qui: i componenti possono essere esemplari e il sistema può comunque risultare… creativamente aperto.

Il PLC non “trasferisce” la sicurezza all’HMI.
Il firewall non “corregge” la logica applicativa.
Lo switch non “mette ordine” negli accessi degli utenti.
E il fatto che ogni elemento abbia una certificazione non significa ancora che l’intera macchina non sia un’unica grande vulnerabilità, cortesemente ben documentata.

PROFINET trasmette dati.

Non trasmette responsabilità.
E purtroppo non trasmette nemmeno il buon senso.

Il CRA riguarda sia i prodotti completi sia i componenti immessi sul mercato separatamente. Questo significa che il controllore, il pannello operatore o il modulo di comunicazione possono essere valutati singolarmente. Ma il fabbricante della macchina deve comunque dimostrare che l’insieme funziona in modo sicuro nella configurazione reale presso il cliente — cioè in quella versione in cui qualcuno “di sicuro non ha più cambiato nulla… vero?”.

Ed è qui che compare l’errore più frequente.

È esattamente lo stesso meccanismo che da anni conosciamo dalla sicurezza delle macchine.

La barriera fotoelettrica ha PL e.
Il Safety PLC ha SIL 3.
L’azionamento dispone di STO.

Significa forse che l’intera macchina si colloca automaticamente a quel livello?

È come dire che il fatto che ogni singolo elemento di un ponteggio rispetti le norme di sicurezza non garantisce ancora che l’intera struttura sia stabile.

No.

Perché bisogna comunque verificare come tutto questo funzioni insieme: cioè quella fase poco amata del “pensare in termini di sistema”, che purtroppo non ha un pulsante “auto-certify”.

Nella cybersicurezza vale esattamente lo stesso principio.

Puoi avere componenti “sicuri”, ma nella pratica:

• l’operatore vede e può modificare più dati di quanti gliene servano davvero, perché “così era più comodo”,
• un’unica password di servizio funziona su tutte le macchine, perché “tanto l’assistenza sa quello che fa”,
• la porta di servizio resta accessibile “per ogni evenienza”, cioè per qualsiasi evenienza,
• l’accesso remoto copre l’intera rete, perché qualcuno un giorno ha detto “ma è solo diagnostica”,
• gli aggiornamenti si possono caricare senza controllo, perché “non si è mai rotto niente”,
• i dispositivi “si fidano tra loro” senza limitazioni, perché la fiducia costa meno della segmentazione,
• e l’integrazione dà per scontato che nessuno commetterà mai errori, il che è — come insegna la storia — l’ipotesi più ottimistica dell’ingegneria.

Ogni elemento, preso singolarmente, può essere corretto.

Ma il sistema nel suo insieme può combinare questi elementi corretti in qualcosa che funziona… solo non necessariamente nel modo previsto.

E questo è il punto importante: il rischio non sta nei dispositivi, ma nel loro collegamento, nella configurazione e nel leggendario accesso “lasciato aperto temporaneamente”.

Il CRA richiede al costruttore della macchina qualcosa di più che collezionare dichiarazioni come fossero trofei. Richiede di verificare se ciò che è stato assemblato a partire dai componenti resti sicuro nel suo complesso — e non solo che “faccia bella figura nella tabella di conformità”.

In pratica, questo si traduce in domande semplici, molto concrete:

• ogni utente ha solo gli accessi di cui ha realmente bisogno, oppure anche quelli “che potrebbero tornare utili un giorno”,
• l’accesso remoto è limitato al minimo indispensabile oppure al massimo della comodità,
• l’assistenza non ha “pieni diritti ovunque” solo perché qualcuno ha deciso che così si fa prima,
• la rete non è un unico spazio condiviso solo perché la segmentazione “complica il progetto”,
• gli aggiornamenti sono controllati oppure si procede con il metodo “carichiamo e speriamo”,
• si riesce a identificare rapidamente quali macchine sono esposte, oppure “verificheremo dopo l’incidente”,
• il guasto di un singolo elemento non apre l’intero sistema solo perché “in integrazione è venuta così”.

Non sono domande tecniche “per gli ingegneri delle cose difficili”.

Sono domande di rischio aziendale: fermi impianto, costi, responsabilità e quel piccolo dettaglio per cui la produzione, in fin dei conti, deve funzionare.

Per questo non basta dire:

“tutti i componenti sono conformi”

Perché così non si risponde ancora alla domanda:

l’intera macchina è sicura nell’uso reale, oppure solo nel PowerPoint della revisione di progetto?

La dichiarazione del fornitore è importante.

Ma riguarda un solo elemento — quello che è stato effettivamente provato in condizioni di laboratorio, non nell’ambiente “da qualche parte in reparto, con VPN, USB e pressione sui tempi”.

Non copre il modo in cui è stato utilizzato.
Non copre la configurazione.
Non copre l’integrazione.
Non copre le decisioni prese “al volo durante la messa in servizio, perché il cliente stava aspettando”.
Non copre ciò che accade dopo anni di esercizio, quando nessuno ricorda più perché qualcosa fosse stato “lasciato aperto temporaneamente”.

Per questo la valutazione non può fermarsi all’elenco dei dispositivi.

Bisogna guardare al sistema nel suo insieme:

• chi ha accesso e perché (non “perché l’ha sempre avuto”),
• che cosa serve davvero e che cosa invece è stato solo “lasciato lì perché non dava fastidio”,
• dove i dati possono uscire dal controllo perché qualcuno ha ritenuto che “sia solo diagnostica”,
• che cosa succede se qualcuno usa un accesso legittimo in modo illecito (cioè esattamente come avviene negli attacchi),
• con quale rapidità si può reagire quando emerge un problema, e non “dopo la revisione trimestrale”.

Finché non ci sono risposte a queste domande, abbiamo solo un insieme di componenti molto ben fatti.

Non abbiamo ancora una macchina sicura.

La conformità dei componenti non genera automaticamente la conformità del sistema. La conformità della macchina va progettata, verificata e — cosa più difficile — mantenuta nonostante la tentazione di “non toccare più nulla, perché funziona”.

3. Non aggiungere il cyberattacco all’elenco dei pericoli. Collega le due analisi nel punto giusto

Nel mercato delle macchine, un’analisi formale del rischio di cybersicurezza è ancora più un’eccezione che un elemento standard del progetto.

Di solito c’è un router industriale.

C’è una VPN.

C’è una password per il PLC.

A volte c’è uno switch gestito, che poi però nessuno gestisce più.

Nella versione più ambiziosa, il costruttore riceve dal fornitore una presentazione sulla “defence in depth” e conclude di aver appena completato l’analisi del rischio secondo la norma UNI EN ISO 12100 per l’intera macchina anche sotto il profilo della cybersicurezza.

Non l’ha completata.

Ha acquistato qualche misura tecnica.

Questa non è ancora un’analisi.

Perciò non ha senso descrivere il problema come se in ogni progetto venissero prodotte due valutazioni professionali — una secondo ISO 12100, l’altra sulla cybersicurezza — che solo per caso non sono state collegate tra loro.

Nella maggior parte dei casi se ne redige una sola.

Valutazione del rischio della macchina.

E l’analisi di cybersecurity del prodotto non viene proprio fatta.

La valutazione del rischio della macchina secondo ISO 12100 non consiste nel riportare in tabella:

guasto del sensore → movimento inatteso → schiacciamento.

Può essere un frammento di uno scenario specifico, ma non è il punto di partenza.

Per prima cosa occorre definire i limiti della macchina.

Qual è la sua destinazione d’uso?

Quali sono le fasi del ciclo di vita?

Chi la utilizzerà?

Quali attività saranno svolte durante il trasporto, il montaggio, la messa in servizio, la produzione, la regolazione, la pulizia, la rimozione degli inceppamenti, la manutenzione, la diagnostica e lo smontaggio?

In quali modi di funzionamento può operare la macchina?

Dove si trova la persona durante ciascuna di queste operazioni?

Quali parti della macchina restano sotto tensione, in pressione, sotto carico oppure in movimento?

Quali usi non sono conformi alle istruzioni, ma restano comunque ragionevolmente prevedibili?

Solo in un secondo momento, per una specifica attività o operazione, si identificano tra l’altro:

• la fonte del pericolo,
• il tipo di pericolo,
• la zona pericolosa,
• la persona esposta,
• la situazione pericolosa,
• l’evento pericoloso, se presente in quello scenario,
• le possibili conseguenze e il tipo di danno.

È così che si svolge l’analisi del rischio della macchina.

Non si parte dal componente.

Si parte dalla persona che esegue una determinata attività sulla macchina, che si trova in uno stato definito. ISO 12100 stabilisce proprio questa metodologia per l’identificazione dei pericoli, nonché per la stima e la valutazione del rischio nelle pertinenti fasi del ciclo di vita della macchina.

Prendiamo un esempio semplice.

L’operatore rimuove un pezzo inceppato dall’interno di una cella di pallettizzazione.

Abbiamo quindi:

Attività: rimozione dell’inceppamento.

Fase di utilizzo: esercizio, intervento dopo l’arresto del processo.

Modo di funzionamento: manuale oppure di servizio.

Persona esposta: operatore oppure addetto alla manutenzione.

Zona pericolosa: interno della cella, in particolare lo spazio tra il gripper, il pezzo e la struttura della macchina.

Fonte del pericolo: energia meccanica del robot, dell’asse lineare oppure del gripper pneumatico.

Situazione pericolosa: la persona si trova nella zona mentre l’esecuzione del movimento è ancora possibile.

Evento pericoloso: movimento inatteso dell’asse, chiusura del gripper oppure rilascio di energia accumulata.

Possibile conseguenza: urto, schiacciamento, frattura oppure amputazione.

Solo a questo punto è possibile valutare il rischio e definire le misure per ridurlo.

Può essere necessario un interblocco del riparo.

Può essere necessario un arresto sicuro.

Può essere necessario prevenire l’avviamento inatteso.

Può essere necessario scaricare l’energia pneumatica.

Può anche darsi che il movimento in modo manuale sia consentito esclusivamente con un dispositivo di abilitazione e a velocità limitata in sicurezza.

Questa è ancora una classica valutazione del rischio della macchina.

Dove entra in gioco la cybersecurity?

Non come nuova voce accanto al pericolo meccanico, elettrico e termico.

“L’hacker” non è una fonte di pericolo meccanico

Aggiungere nella tabella ISO 12100 la voce:

Pericolo: attacco informatico

apporta ben poco.

Un attacco informatico non è un albero rotante, uno spigolo vivo, un’alta temperatura né energia pneumatica.

Non è nemmeno una zona pericolosa a sé stante.

L’operatore non subisce uno schiacciamento a causa di una vulnerabilità CVE.

Lo subisce a causa di un elemento della macchina che ha eseguito un movimento mentre la persona si trovava nel posto sbagliato.

Un attacco informatico può però modificare lo stato del sistema di controllo, i dati, il programma, la configurazione oppure il modo di funzionamento di una misura di protezione.

Può quindi diventare:

• la causa di un evento pericoloso,
• un ulteriore percorso che conduce a una situazione pericolosa,
• la causa della perdita di efficacia di una misura di riduzione del rischio,
• oppure un modo per aggirare le ipotesi assunte nella progettazione delle funzioni di sicurezza.

Ed è questo il vero punto di contatto.

Non l’elenco dei pericoli.

Il comportamento della macchina.

L’analisi di cybersecurity dovrebbe essere redatta separatamente

Per una macchina o un sistema di automazione, l’analisi di cybersecurity avrà una struttura diversa dalla valutazione del rischio secondo ISO 12100.

Per un sistema di automazione industriale, la struttura più naturale è fornita da IEC 62443-3-2.

La norma richiede tra l’altro:

• la definizione del sistema oggetto dell’analisi, cioè il SUC,
• la suddivisione del sistema in zone e canali di comunicazione,
• la valutazione del rischio per le singole zone e i singoli canali,
• la definizione dei livelli di sicurezza obiettivo SL-T,
• la documentazione dei requisiti di sicurezza.

Si tratta di un punto di partenza completamente diverso rispetto a ISO 12100.

In IEC 62443 ci chiediamo, tra l’altro:

Che cosa rientra esattamente nel sistema analizzato?

Quali asset devono essere protetti?

Quali dispositivi, applicazioni e interfacce sono presenti nel sistema?

Quali elementi dovrebbero appartenere alla stessa zona?

Come avviene la comunicazione tra le zone?

Chi può ottenere l’accesso?

Da quale posizione?

Attraverso quale interfaccia?

Quali vulnerabilità possono essere sfruttate?

Quali dati, funzioni o componenti possono essere modificati?

Attraverso quale percorso un attaccante può passare dal router di assistenza al PLC, all’HMI, all’azionamento oppure alla stazione di ingegneria?

Quali conseguenze comporterà la perdita di riservatezza, integrità o disponibilità?

Quali misure di protezione sono necessarie?

Per il processo di sviluppo sicuro del prodotto e per i requisiti relativi ai singoli componenti, assumono rilievo anche altre parti della serie, in particolare IEC 62443-4-1 e IEC 62443-4-2. IEC 62443-3-3 organizza invece i requisiti tecnici di sicurezza a livello di sistema.

Oggi il CRA non impone al fabbricante di scrivere in copertina dell’analisi “eseguita secondo IEC 62443”.

IEC 62443 non sostituisce neppure la dimostrazione di conformità ai requisiti del CRA.

Per un sistema di automazione industriale, tuttavia, rappresenta un riferimento molto più logico che tentare di aggiungere qualche scenario di attacco informatico a una tabella della ISO 12100.

Perché le due metodologie rispondono a domande diverse.

ISO 12100:

Durante quale attività, in quale punto, a partire da quale fonte e in conseguenza di quale evento una persona può subire un danno?

IEC 62443:

Chi, attraverso quale percorso e sfruttando quale vulnerabilità può influire sul sistema, sui suoi dati o sulle sue funzioni?

Solo in un secondo momento occorre verificare se la risposta della seconda analisi modifica lo scenario individuato dalla prima.

Lo stesso scenario, due analisi diverse

Torniamo all’operatore che rimuove un pezzo incastrato.

L’analisi ISO 12100 ha evidenziato che la persona entra in una zona in cui può essere schiacciata dal movimento del robot o del gripper.

La misura di riduzione del rischio è costituita da un riparo interbloccato, da una funzione di arresto sicuro e da un reset locale collocato al di fuori della zona di pericolo.

Ora eseguiamo l’analisi di cybersicurezza del sistema.

Identifichiamo:

• il router utilizzato per l’assistenza remota,
• l’account di assistenza,
• il laptop di ingegneria,
• l’HMI,
• il PLC standard,
• il safety PLC,
• gli azionamenti,
• l’interfaccia di programmazione,
• la rete PROFINET e la comunicazione PROFIsafe,
• i meccanismi di caricamento del programma e della configurazione.

Consideriamo lo scenario seguente:

La compromissione dell’account di assistenza consente l’accesso remoto al PLC standard e l’invio di un comando di movimento mentre una persona è presente nella cella.

Questo scenario porta a un evento pericoloso?

Non è possibile rispondere basandosi soltanto sul fatto che il PLC sia stato compromesso.

Occorre verificare l’architettura delle funzioni di sicurezza.

Se l’apertura del riparo è monitorata dal safety PLC, la funzione disinserisce in sicurezza la coppia degli azionamenti, il reset è esclusivamente locale e il PLC standard non può ripristinare il movimento indipendentemente dallo stato della funzione di sicurezza, la compromissione del controllore standard può fermare la produzione oppure danneggiare il processo.

Ma non dovrebbe provocare un movimento con il riparo aperto.

In questo caso l’analisi cyber evidenzia un attacco.

La valutazione del rischio della macchina evidenzia un pericolo meccanico.

Tuttavia, una funzione di sicurezza progettata correttamente interrompe il collegamento tra i due.

Passiamo ora alla seconda variante.

La modalità di servizio viene selezionata da un normale HMI.

Il valore della velocità limitata proviene dal PLC standard.

Il tecnico remoto può eseguire il reset.

Lo stesso account di ingegneria consente di modificare il programma standard e la configurazione di sicurezza.

La copia del programma di sicurezza non è associata a una specifica versione della macchina.

Dopo l’intervento nessuno verifica il checksum.

I parametri dell’azionamento possono essere modificati da remoto.

In questa architettura, la compromissione dell’account non significa più soltanto perdita di riservatezza o un breve fermo.

Può modificare le condizioni su cui si basava la riduzione del rischio.

Può portare a:

• selezione di una modalità errata,
• modifica del parametro di movimento sicuro,
• reset non autorizzato,
• caricamento di una configurazione non approvata,
• oppure indebolimento della funzione che avrebbe dovuto impedire l’avviamento inatteso.

E allora lo scenario cyber deve essere collegato a uno specifico scenario di sicurezza della macchina:

attività di rimozione dell’inceppamento → persona nella zona di pericolo → modifica non autorizzata del sistema di controllo o della funzione di protezione → movimento inatteso → schiacciamento.

La fonte del pericolo non è cambiata.

Resta l’energia meccanica della macchina.

La zona di pericolo non è cambiata.

Si trova sempre all’interno della cella.

Non è cambiata neppure la possibile conseguenza.

Resta la lesione dell’operatore.

È cambiato il percorso che conduce all’evento pericoloso.

Non tutte le vulnerabilità rientrano nella ISO 12100

Anche questa distinzione è importante.

Supponiamo che una vulnerabilità nell’HMI consenta di leggere dati storici di produzione.

Dal punto di vista del CRA, questo può essere un problema rilevante.

Può violare la riservatezza dei dati.

Può richiedere un aggiornamento, una valutazione dell’impatto, azioni nei confronti degli utenti e, in determinate circostanze, anche una segnalazione.

Ma se non influisce sul comportamento della macchina, non modifica una misura di protezione e non può portare a una situazione di pericolo, non ha senso forzarne l’inserimento nella valutazione del rischio secondo ISO 12100.

Allo stesso modo, un attacco che provochi soltanto l’indisponibilità dei report di produzione può rappresentare un problema per il business e un problema di conformità al CRA.

Tuttavia, non è detto che generi un rischio per l’operatore.

Al contrario, la possibilità apparentemente innocua di modificare un singolo valore di setpoint può avere un impatto limitato sulla riservatezza dei dati, ma un impatto enorme sulla sicurezza fisica.

Per esempio, quando quel valore definisce:

• la velocità massima di un asse,
• la forza di serraggio,
• la temperatura di processo,
• la pressione,
• la posizione di arresto,
• il tempo di apertura di una valvola,
• oppure il limite ammesso durante il funzionamento con riparo aperto.

Per questo non classifichiamo una minaccia cyber in base a quanto “suona” tecnica.

Guardiamo invece che cosa può realmente fare alla macchina.

Il regolamento macchine impone questo collegamento

Questo collegamento non è soltanto una buona pratica ingegneristica.

Il punto 1.2.1 dell’allegato III del regolamento macchine richiede che i sistemi di comando siano progettati e costruiti in modo da prevenire situazioni di pericolo, anche come conseguenza di tentativi dolosi ragionevolmente prevedibili da parte di terzi.

Il CRA, a sua volta, indica che i suoi requisiti essenziali di cibersicurezza possono contribuire a dimostrare la conformità, tra l’altro, ai requisiti 1.1.9 e 1.2.1 del regolamento macchine.

Ma questo non avviene automaticamente.

Il fabbricante deve dimostrare tale relazione sulla base della valutazione del rischio. La valutazione della conformità secondo il CRA e la valutazione della conformità secondo il regolamento macchine restano comunque processi distinti.

Quindi non basta predisporre:

• una analisi del rischio secondo ISO 12100,
• un’analisi IEC 62443,
• due rapporti separati,
• e sperare che la somiglianza tra i numeri delle norme crei da sola una traccia di audit tra i due.

Serve un collegamento esplicito.

Per ogni scenario cyber rilevante occorre stabilire:

1. quale componente o funzione può essere preso sotto controllo oppure modificato,
2. quale comportamento della macchina ciò può provocare,
3. se tale comportamento porta a una situazione di pericolo o a un evento pericoloso,
4. a quale compito e a quale zona di pericolo si riferisce,
5. quale possibile conseguenza è stata indicata nella valutazione ISO 12100,
6. quale misura di riduzione del rischio dovrebbe interrompere lo sviluppo dello scenario,
7. se tale misura rimane efficace anche dopo la compromissione dell’elemento attaccato.

Quest’ultimo punto è il più importante.

Perché se l’attacco e la protezione dipendono da:

• lo stesso controllore,
• lo stesso account,
• la stessa rete,
• la stessa stazione di ingegneria,
• oppure lo stesso programma,

allora è possibile che non ci siano due livelli di protezione indipendenti.

Ce n’è uno solo, descritto in due documenti.

Non ci serve quindi un’unica tabella enorme intitolata:

“valutazione del rischio safety & cybersecurity”.

Ci servono due analisi corrette, svolte con metodi appropriati, e un punto di interfaccia controllato tra di esse.

La ISO 12100 deve descrivere la persona, il compito, la fonte di pericolo, la zona, la situazione di pericolo, l’evento pericoloso e il possibile danno.

La IEC 62443 deve aiutare a descrivere il sistema, le sue zone, i canali di comunicazione, le risorse, le minacce, le vulnerabilità, i percorsi di attacco e le protezioni richieste.

E il fabbricante deve dimostrare se lo scenario della seconda analisi può attivare lo scenario della prima oppure compromettere l’efficacia della misura che avrebbe dovuto arrestarlo.

Un attacco informatico non deve necessariamente creare un nuovo pericolo. È sufficiente che apra una nuova via verso un vecchio incidente.

4. Un pentest prima del FAT è una fotografia. Il CRA richiede un film

In molti progetti la cibersicurezza compare due settimane prima del FAT.

Si commissiona un pentest.

Viene redatto un rapporto.

Le vulnerabilità critiche vengono corrette, quelle medie accettate, e il documento finisce nella cartella di progetto.

La macchina è cyber sicura.

Fino al martedì successivo.

Il pentest può essere un elemento di verifica molto utile. Tuttavia mostra lo stato di una specifica versione del prodotto, in una specifica configurazione e sulla base di determinati scenari di prova.

Non risponde alla domanda su che cosa farà il fabbricante in seguito.

E il CRA riguarda l’intero ciclo di vita del prodotto. La valutazione del rischio di cibersicurezza deve incidere sulla pianificazione, sulla progettazione, sullo sviluppo, sulla produzione, sulla consegna e sulla manutenzione del prodotto. Dopo l’immissione sul mercato, il fabbricante deve gestire le vulnerabilità per il periodo di supporto dichiarato.

Torniamo alla macchina confezionatrice per ortaggi.

La macchina ha superato il FAT.

Il pentest non ha rilevato vulnerabilità critiche.

Otto mesi dopo, il produttore del router di assistenza pubblica un avviso relativo a una vulnerabilità che consente la compromissione del dispositivo.

Ed è qui che comincia il vero lavoro.

Quali macchine consegnate montano quel modello di router?

Quale versione del firmware è stata installata su ciascun esemplare?

L’accesso remoto è attivo?

La vulnerabilità è sfruttabile nella configurazione reale?

La compromissione del router consente l’accesso soltanto alla diagnostica oppure anche a HMI, PLC, azionamenti e safety PLC?

È possibile soltanto leggere i dati oppure anche modificare il programma o i parametri?

L’attacco può influire su una funzione di sicurezza?

Il fornitore ha reso disponibile una correzione?

L’aggiornamento del router modificherà i certificati, le regole di comunicazione oppure il modo in cui viene stabilito il tunnel?

Dopo un aggiornamento è necessario verificare di nuovo il servizio remoto, la comunicazione e parte delle funzioni di sicurezza?

Quali clienti devono essere informati?

E la situazione rientra nei criteri di segnalazione di una vulnerabilità attivamente sfruttata o di un incidente grave?

Il rapporto di pentest eseguito prima del FAT non risponde a nessuna di queste domande.

Descrive una macchina che non esiste più.

Perché, dal momento della verifica, sono cambiate le versioni del software, le configurazioni, l’ambiente dell’utente e le conoscenze disponibili sulle vulnerabilità.

Per questo il fabbricante non ha bisogno solo di un test, ma di un processo:

• identificazione delle versioni di hardware, firmware e software in ogni esemplare consegnato,
• monitoraggio delle informazioni sulle vulnerabilità,
• valutazione del loro possibile sfruttamento nell’architettura reale,
• verifica dei possibili effetti sul processo e sulla sicurezza della macchina,
• preparazione e test degli aggiornamenti,
• informazione agli utenti,
• documentazione delle decisioni adottate,
• gestione delle segnalazioni richieste.

Dall’11 settembre 2026 i fabbricanti hanno l’obbligo di segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza dei prodotti con elementi digitali. L’avviso preliminare deve essere trasmesso entro 24 ore e la segnalazione completa entro 72 ore.

Questo significa che, una volta individuato il problema, non ci sarà tempo per iniziare a chiedersi:

“Chi aveva fornito esattamente questo router e dove abbiamo l’elenco delle macchine in cui lo abbiamo installato?”

Il Regolamento (UE) 2024/2847 – Cyber Resilience Act (CRA) e la IEC 62443-4-1 mostrano bene la differenza tra la messa in sicurezza una tantum di un prodotto e un ciclo di sviluppo sicuro. Quest’ultimo comprende non solo progettazione e verifica, ma anche la gestione dei difetti, delle correzioni e della fine vita del prodotto.

Il FAT può quindi chiudere una fase del progetto.

Non chiude il ciclo di vita del prodotto.

Non chiude il periodo di supporto.

Non interrompe il monitoraggio delle vulnerabilità.

E non significa che la configurazione del giorno del collaudo resti congelata per i successivi quindici anni.

La macchina può confezionare verdure per i supermercati per molto tempo.

Il fabbricante, però, non può confezionare anche la sua cybersicurezza insieme al manuale, sigillarla nella pellicola e considerarla fornita una volta per tutte.

Il pentest può chiudere una voce nella checklist del FAT. Il CRA apre invece un processo che dura fino alla fine del periodo di supporto del prodotto.