Il regolamento macchine UE dal 20 gennaio 2027: cosa chiede al software delle vostre macchine

Il 20 gennaio 2027 la direttiva macchine viene sostituita dal regolamento (UE) 2023/1230, il regolamento macchine. Gran parte del testo risulterà familiare a chiunque costruisca macchine con marcatura CE. Una parte no. Per la prima volta la normativa sulle macchine impone obblighi direttamente al software: la macchina deve dire di quale software ha bisogno per funzionare in sicurezza, accorgersi quando quel software o la sua configurazione cambiano, resistere alle alterazioni e conservare per cinque anni una traccia degli aggiornamenti del software di sicurezza.

Questo articolo è scritto per i responsabili dell'ingegneria e dell'automazione dei costruttori di macchine. Se dopo quella data spedite macchine nell'UE, questi requisiti finiscono nei vostri programmi PLC, nell'HMI, nell'accesso remoto e nel back end degli aggiornamenti.

Cosa dice davvero la legge

La Commissione europea afferma che il regolamento «si applica obbligatoriamente dal 20 gennaio 2027» e che «integra disposizioni di cibersicurezza per i dati del software rilevanti ai fini della conformità e per i sistemi di comando di sicurezza». Il testo pubblicato nel 2023 indicava il 14 gennaio; una rettifica ha spostato la data.

Gli obblighi sul software stanno in due requisiti essenziali di sicurezza e di tutela della salute dell'allegato III del regolamento.

Punto 1.1.9, protezione dall'alterazione. In sintesi:

• Il collegamento di un altro dispositivo alla macchina, direttamente o a distanza, non deve determinare una situazione pericolosa.
• Software e dati critici per il rispetto dei requisiti di sicurezza devono «essere individuati come tali» e protetti da un'alterazione accidentale o intenzionale.
• Anche i componenti hardware che trasmettono segnali o dati che danno accesso a quel software (pensate a una porta di programmazione o a un'interfaccia di rete verso il controllore di sicurezza) devono essere protetti, e la macchina deve raccogliere prove degli interventi su di essi.
• La macchina deve «individuare il software installato sullo stesso, necessario per il suo funzionamento in condizioni di sicurezza, e [deve] essere in grado di fornire tali informazioni in qualsiasi momento in un formato facilmente accessibile».
• La macchina deve «raccogliere prove di un intervento legittimo o illegittimo sul software o di una modifica del software installato sulla macchina o sul prodotto correlato o della sua configurazione».

Punto 1.2.1, sicurezza ed affidabilità dei sistemi di comando. I sistemi di comando devono resistere ai «tentativi deliberati ragionevolmente prevedibili da parte di terzi che conducono a una situazione pericolosa». La lettera f) aggiunge l'obbligo di registrazione: la registrazione di tracciamento dei dati generati da un intervento, e delle versioni del software di sicurezza caricate dopo l'immissione sul mercato della macchina, deve essere «consentita per cinque anni dopo tale caricamento». La registrazione serve a dimostrare la conformità quando un'autorità nazionale presenta una richiesta motivata, e a nient'altro.

Sempre nell'elenco: la documentazione tecnica deve poter fornire, se un'autorità lo chiede, «il codice sorgente o la logica di programmazione del software relativo alla sicurezza» (allegato IV).

Quali macchine sono coinvolte

Le regole si applicano alle macchine immesse sul mercato dal 20 gennaio 2027. Le macchine immesse sul mercato con la vecchia direttiva prima di quella data si possono ancora rivendere (articolo 52), e il parco già installato non è toccato dalle nuove regole sul software.

Il punto delicato è cosa significhi «immesso sul mercato». La Guida blu della Commissione chiarisce che il concetto si riferisce a ogni singolo prodotto, non a un tipo di prodotto. Ogni unità che dal 20 gennaio 2027 lascia la vostra fabbrica per un cliente nell'UE deve rispettare i nuovi requisiti, software compreso. Una famiglia di macchine che si spedisce di continuo ha bisogno del software di controllo pronto prima della prima unità del 2027, non al prossimo cambio di modello.

Anche gli aggiornamenti successivi vanno ponderati. Una modifica apportata «mediante mezzi fisici o digitali», non prevista dal fabbricante, che crea un nuovo pericolo o aumenta un rischio può costituire una modifica sostanziale. Il considerando 32 dice che la valutazione del rischio dovrebbe coprire gli aggiornamenti software previsti al momento dell'immissione sul mercato, quindi descrivete adesso lì il vostro percorso di aggiornamento.

Cosa significa a ogni livello della macchina

Controllore di sicurezza e PLC

• Decidete cosa è rilevante per la sicurezza. Di solito è il programma di sicurezza, ma può comprendere codice PLC standard che alimenta una funzione di sicurezza, parametri di sicurezza negli azionamenti e la configurazione di scanner laser o barriere fotoelettriche. Mettetelo per iscritto per ogni famiglia di macchine; tutto il resto dipende da questo.
• Riferimento e confronto. Per ogni configurazione rilasciata, registrate un checksum o una firma di ogni elemento rilevante per la sicurezza. All'avvio e a intervalli regolari, la macchina confronta ciò che sta girando con quel riferimento e registra qualsiasi differenza. Così si intercetta l'intervento che ha aggirato il vostro controllo degli accessi, come un portatile collegato direttamente al controllore.
• Chiudete l'accesso di ingegneria. Password sul programma di sicurezza, porte e servizi inutilizzati disattivati, e accesso di ingegneria solo attraverso un percorso che autentica la persona e registra cosa ha fatto.

HMI

• Una schermata di identificazione del software che elenca il software rilevante per la sicurezza con versioni e checksum. Leggete i valori in tempo reale dai dispositivi. Una pagina compilata a mano al momento del rilascio si allontana dalla realtà, e il requisito dice «in qualsiasi momento».
• Schermate dei parametri. Il punto 1.2.1, lettera d), esclude le modifiche a impostazioni o regole che potrebbero determinare situazioni pericolose. I parametri di sicurezza vanno dietro livelli di accesso, con limiti imposti nel controllore e non solo nell'HMI, e ogni modifica va registrata con chi, quando, il valore vecchio e quello nuovo.

Accesso remoto

Il punto 1.1.9 cita esplicitamente i dispositivi remoti. In pratica:

• Le funzioni di sicurezza restano locali. Una sessione remota può leggere, diagnosticare e preparare una modifica. Non può scavalcare un arresto, un riparo o un dispositivo di abilitazione.
• Le sessioni sono autenticate per persona, non tramite un account di servizio condiviso, e il cliente può vedere quando una sessione è aperta.
• Ogni inizio di sessione, fine e modifica finisce nello stesso registro delle prove degli interventi locali.

Back end e pipeline degli aggiornamenti

Se distribuite aggiornamenti dopo la spedizione, il vostro server degli aggiornamenti rientra nel lavoro. Per ogni numero di serie dovete sapere quale versione del software di sicurezza è stata caricata, quando e da chi. Firmate gli aggiornamenti, e fate verificare la firma alla macchina prima che installi qualsiasi cosa.

La registrazione di tracciamento

Il regolamento non dice dove debba stare la registrazione. Secondo noi la copia che conta sta sulla macchina, perché molti clienti non consentiranno una connessione permanente. Una copia nel cloud è utile, ma non può essere l'unica.

Il volume è piccolo: interventi e caricamenti del software di sicurezza, non dati di processo. Cinque anni stanno nell'archiviazione locale se la dimensionate apposta. Proteggete la registrazione dalla cancellazione e assicuratevi che sopravviva alla sostituzione del controllore. Se le voci riportano il nome di un tecnico, sono dati personali presso il cliente: registrate ciò che il requisito chiede e nient'altro.

Cosa vi dà il fornitore del controllore, e cosa no

La vostra piattaforma di controllo fornirà una parte di tutto questo. Prima di costruire qualsiasi cosa, verificate cosa offre: una firma o un checksum sul programma di sicurezza, protezione con password, gestione degli utenti, un registro delle modifiche, lettura delle versioni. Usate tutto ciò che c'è.

Sono mattoni. Il fornitore non sa quali dei vostri azionamenti e scanner siano rilevanti per la sicurezza, non vede il vostro gateway remoto né il server degli aggiornamenti, e non può decidere come le prove sopravvivano cinque anni e una sostituzione del controllore. Configurare quelle funzionalità, collegarle su tutta la macchina e documentare il risultato è compito del costruttore, ed è il costruttore che firma la dichiarazione di conformità.

Il rapporto con il Cyber Resilience Act

Il Cyber Resilience Act ha un calendario proprio. I suoi obblighi di segnalazione si applicano dall'11 settembre 2026, e i requisiti completi dall'11 dicembre 2027. Il regolamento macchine arriva tra le due date.

Il CRA riconosce la sovrapposizione. Il considerando 53 del regolamento (UE) 2024/2847 dice che i fabbricanti di macchine che sono anche prodotti con elementi digitali dovrebbero rispettare entrambi, e che la conformità al CRA «potrebbe pertanto facilitare» la conformità ai punti 1.1.9 e 1.2.1. Quella sinergia deve dimostrarla il fabbricante. L'allegato I del CRA chiede di proteggere l'integrità «dei comandi, dei programmi e della configurazione» e di segnalarne le corruzioni, il che è vicino a quanto chiede il punto 1.1.9.

Una differenza conta per il progetto della vostra registrazione. Il requisito del CRA di registrare e monitorare le attività interne prevede «un meccanismo di disattivazione per l'utilizzatore». La registrazione di tracciamento del regolamento macchine deve restare attiva per cinque anni. Costruite pure un unico meccanismo di registrazione, ma non lasciate che la disattivazione prevista dal CRA spenga la registrazione richiesta per le macchine.

Costruite adesso per il regolamento macchine, perché arriva prima, e progettatelo in modo che lo stesso archivio delle prove, la stessa firma e gli stessi registri degli aggiornamenti servano al CRA a dicembre 2027.

Norme e il rinvio mancato

Non contate sul fatto che entro il 20 gennaio 2027 venga citata una norma armonizzata che copra questi requisiti. La pagina della Commissione sulle norme armonizzate, aggiornata a settembre 2026, dice che il primo elenco ai sensi del regolamento macchine è in preparazione. Riprenderà la maggior parte delle norme citate con la direttiva e le chiarirà dove queste «non coprono ancora pienamente» i nuovi requisiti, e «si può prevedere entro la fine di quest'anno».

A gennaio 2026 CEMA, CECE, CECIMO, EGMF e FEM hanno chiesto, in una posizione congiunta dell'industria, di rinviare i punti 1.1.9 e 1.2.1, lettera f), all'11 dicembre 2027, in linea con il CRA. Hanno stimato i costi di conformità in «più di 1 milione di euro per architettura di piattaforma» e hanno sostenuto che le norme attese restano molto generiche sulla registrazione dei dati del punto 1.2.1, lettera f).

La richiesta non è stata accolta. Il regolamento macchine è stato modificato a luglio 2026 dal regolamento (UE) 2026/1744, ma quella modifica riguarda i sistemi di IA ad alto rischio nelle macchine e lascia invariata la data di applicazione. Pianificate sul 20 gennaio 2027.

Quindi il primo giorno potreste non avere alcuna norma che dia presunzione di conformità per questi due requisiti. Il vostro fascicolo tecnico dovrà allora descrivere la soluzione adottata per ciascuno (allegato IV). Scrivetelo mentre sviluppate, non dopo. Per le macchine elencate nell'allegato I, parte B, c'è un passaggio in più: l'autovalutazione è possibile solo se norme armonizzate o specifiche comuni coprono tutti i requisiti pertinenti; altrimenti interviene un organismo notificato (articolo 25). Le macchine non elencate nell'allegato I si autovalutano in ogni caso.

Un piano di 15 settimane

Da lunedì 5 ottobre 2026 alla scadenza ci sono poco più di 15 settimane, con le feste nel mezzo. È stretto ma fattibile se date la priorità in base alla data di spedizione: vengono prima le famiglie con unità per l'UE in uscita a gennaio.

1. Settimane 1 e 2 (dal 5 al 16 ottobre): perimetro. Elencate ogni famiglia di macchine che spedirà unità nell'UE dopo il 20 gennaio 2027. Per ciascuna, elencate il software e i dati rilevanti per la sicurezza: programma di sicurezza, codice standard critico per la conformità, parametri di sicurezza di azionamenti e sensori, HMI, firmware, gateway remoto. Nominate un responsabile per famiglia.
2. Settimane 3 e 4 (dal 19 al 30 ottobre): valutazione del rischio e lacune. Aggiornate la valutazione del rischio per collegamenti, accesso remoto, tentativi dolosi e percorso degli aggiornamenti. Verificate cosa fornisce la vostra piattaforma di controllo e cosa è attivo.
3. Dalla settimana 5 alla 9 (dal 2 novembre al 4 dicembre): sviluppo. Schermata di identificazione del software, confronto con il riferimento, controllo degli accessi di ingegneria e remoti, registrazione di tracciamento con capacità di cinque anni, aggiornamenti firmati e registri per numero di serie nel back end.
4. Settimane 10 e 11 (dal 7 al 18 dicembre): testate come farebbero un tecnico e un attaccante. Modificate un parametro di sicurezza direttamente con lo strumento del fornitore e verificate che la macchina lo registri. Sostituite un controllore e controllate che la registrazione sopravviva. Togliete l'alimentazione durante un aggiornamento.
5. Settimane 12 e 13 (dal 21 dicembre al 1° gennaio): feste. Non pianificate lavoro di ingegneria; lasciate girare un test di durata che riempia la registrazione verso la sua dimensione di cinque anni.
6. Settimane 14 e 15 (dal 4 al 15 gennaio): documentazione e rilascio. Voci del fascicolo tecnico per i punti 1.1.9 e 1.2.1, istruzioni per l'uso che spiegano come il cliente legge l'identificazione del software e cosa l'accesso remoto può e non può fare, e un passaggio di produzione che carica il riferimento rilasciato e lo registra per numero di serie.

Se le architetture di piattaforma che ne hanno bisogno sono più di quante ne stiano in quella finestra, ditelo subito all'ufficio commerciale: un'unità non pronta non può essere legittimamente immessa sul mercato UE.

A chi non si rivolge

Le macchine immesse sul mercato prima del 20 gennaio 2027 non sono toccate da queste regole sul software, a meno che qualcuno non le modifichi in seguito in modo sostanziale. Se le macchine le acquistate anziché costruirle, l'obbligo è del vostro fornitore; la vostra parte è chiedere nei capitolati l'identificazione del software e l'accesso alla registrazione.

Dove trovare aiuto

Siamo una software house, non un organismo notificato né uno studio legale. Sviluppiamo e modifichiamo il software in cui finiscono questi requisiti: applicazioni HMI e di back end, gateway di accesso remoto, pipeline degli aggiornamenti e registrazione delle prove, lavorando accanto agli ingegneri dell'automazione che hanno in carico il programma di sicurezza. Le piattaforme più vecchie con anni di codice accumulato sono il caso più difficile, ed è lì che di solito parte il nostro lavoro di manutenzione dei sistemi legacy; il lato CRA è trattato nella nostra guida al Cyber Resilience Act. Se il vostro team ha il piano ma non le braccia per completarlo entro gennaio, scrivete a office@c9group.dev.