Doppia menzione per Gyala citata da Gartner® come Sample Vendor nei Report "Hype Cycle™ for Zero-Trust Technology”, Luglio 2026 e Hype Cycle™ for CPS Security" Giugno 2026. Leggi di più

 

Regolamento Macchine e Cyber Resilience ACT 

Non la stessa compliance, ma obblighi distinti

Una macchina connessa non è conforme solo perché è meccanicamente sicura. E non è cyber-secure solo perché implementa funzioni di sicurezza funzionale.

Il Regolamento (UE) 2023/1230 e il Cyber Resilience Act — Regolamento (UE) 2024/2847 rispondono a due rischi diversi e vanno gestiti come due filoni di conformità paralleli.

Perimetro ed obiettivo

Il Regolamento Macchine 2023/1230 disciplina macchine, prodotti correlati e quasi-macchine. Il suo obiettivo è garantire sicurezza e tutela della salute nella progettazione e costruzione, affrontando i rischi derivanti dall’uso previsto e dall’uso scorretto ragionevolmente prevedibile. 
Abroga la Direttiva Macchine 2006/42/CE.

Il CRA 2024/2847 è, invece, un regolamento “orizzontale” sui prodotti con elementi digitali, immessi sul mercato UE nell’ambito di un’attività commerciale. Copre quindi prodotti connessi fisicamente o logicamente, come ad esempio: interfacce hardware, socket di rete, API, file, pipe e altre interfacce software, anche quando la connessione è solo indiretta.

Il CRA è orizzontale, ma non elimina la lex specialis, ovvero i prodotti coperti da regolamenti settoriali con requisiti di cybersecurity equivalenti, come dispositivi medici, veicoli e prodotti aeronautici, possono essere esclusi dai requisiti essenziali e dalle procedure di valutazione della conformità del CRA.

TemaRegolamento Macchine 2023/1230CRA 2024/2847
Rischio primarioDanno fisico, sanitario e funzionaleCompromissione informatica, sfruttamento di vulnerabilità, impatto su disponibilità, integrità e riservatezza
Logica normativaRequisiti essenziali di sicurezza e tutela della salute, integrati dalla valutazione dei rischiRequisiti essenziali di cibersicurezza lungo l’intero ciclo di vita del prodotto
Focus progettualeSicurezza integrata nella macchina, comportamento prevedibile, gestione dei guasti, protezione contro rischi derivanti anche da azioni dolose di terziSecure by design e by default, gestione delle vulnerabilità, aggiornamenti di sicurezza, protezione delle comunicazioni e tracciabilità
SoftwareIl software che svolge una funzione di sicurezza e viene immesso indipendentemente sul mercato è un componente di sicurezzaIl software può essere esso stesso un prodotto con elementi digitali; anche i componenti open source monetizzati e integrati in prodotti commerciali possono rientrare nel perimetro
Valutazione della conformitàFascicolo tecnico, dichiarazione UE e marcatura CE; procedure più rigorose per categorie a rischio elevato, inclusi sistemi con comportamento evolutivo che garantiscono funzioni di sicurezzaDichiarazione UE e marcatura CE; procedure più rigorose per prodotti importanti e critici

Quindi, mentre il Regolamento Macchine introduce espressamente la necessità di considerare i rischi derivanti da terzi malintenzionati, ma lo fa nella prospettiva della sicurezza della macchina, ovvero l’obiettivo è evitare che una compromissione informatica generi un pericolo fisico o funzionale; il CRA parte dalla cyber resilience del prodotto e richiede che il fabbricante gestisca la sicurezza lungo l’intero ciclo di vita, riduca le vulnerabilità e assicuri aggiornamenti di sicurezza adeguati.

La Sicurezza funzionale non è cybersecurity

Un PLC, un robot o un sistema di videoanalisi industriale possono avere: architettura di sicurezza funzionale solida; logica di arresto sicuro; ridondanza e diagnosi dei guasti; e conformità ai requisiti del Regolamento Macchine; ma presentare comunque vulnerabilità nei servizi di rete, nell’aggiornamento firmware, nelle API di integrazione o nella supply chain software.

I requisiti essenziali di cibersicurezza sono definiti nell’Allegato I del CRA e mappano l’intero ciclo di vita: 

  • configurazione sicura, 
  • protezione da accessi non autorizzati, 
  • riservatezza e integrità dei dati, 
  • gestione delle vulnerabilità,
  • aggiornamenti di sicurezza,
  • capacità di rilevare e gestire gli incidenti.

L’articolo 13 del CRA richiede esplicitamente al fabbricante di identificare e documentare i rischi di cybersecurity, mantenere la documentazione tecnica, gestire le vulnerabilità, fornire aggiornamenti di sicurezza per il periodo di supporto dichiarato e generare una SBOM (fyi: La SBOM (Software Bill of Materials, o “distinta base del software”) è l’inventario strutturato dei componenti software contenuti in un prodotto: librerie, dipendenze, componenti open source, moduli proprietari e, quando rilevanti, le relazioni tra essi. È l’equivalente software della distinta base di un macchinario meccanico) in un formato leggibile da macchina, incluso il formato CycloneDX (fyi: uno standard per descrivere in modo strutturato e leggibile dai software i componenti di un prodotto e le loro dipendenze).

Regolamenti sovrapposti, non duplicati

Quando esiste una macchina connessa non si deve scegliere quale regolamento applicare ma comprendere quali rischi copre ogni regolamento.

  • Il Regolamento Macchine richiede che la macchina sia sicura nell’uso e che i rischi derivanti da interferenze dolose siano trattati nella misura necessaria alla sicurezza
  • Il CRA richiede che il prodotto digitale sia resiliente alle minacce informatiche, indipendentemente dal settore di appartenenza. Le soluzioni di elaborazione remota sviluppate dal fabbricante – ad esempio il cloud necessario per il controllo remoto di un dispositivo – rientrano nel perimetro CRA quando sono necessarie al funzionamento del prodotto.

Scadenze e obblighi

  • Regolamento Macchine 2023/1230: applicabile dal 14 gennaio 2027.
  • CRA 2024/2847: gli obblighi principali di immissione sul mercato decorrono dall’11 dicembre 2027; gli obblighi di segnalazione partono prima, dall’11 settembre 2026.
  • Dal 11 settembre 2026, in caso di vulnerabilità sfruttabile attivamente o incidente grave, il fabbricante deve inviare una prima segnalazione precoce a ENISA/CSIRT designato entro 24 ore, una notifica entro 72 ore e un report finale entro 14 giorni, salvo proroghe previste dal regolamento. Questo implica che la finestra per integrare SBOM, threat modeling, secure development lifecycle, vulnerability management e processo di security update è parte del piano di conformità.

Cosa mettere sotto controllo

Per un fabbricante di “macchine connesse”:

  1. Mappare il prodotto rispetto a entrambi i perimetri: macchina, prodotto correlato, quasi-macchina e prodotto con elementi digitali, verificando eventuali esclusioni settoriali.
  2. Separare la risk assessment di sicurezza fisica/funzionale dalla threat modeling cybersecurity
  3. Trattare firmware, componenti di sicurezza software, API, OTA update e dipendenze open source come oggetto di conformità, non come dettagli implementativi.
  4. Definire un processo di gestione delle vulnerabilità con SLA, canale di segnalazione e capacità di rilascio patch.
  5. Costruire un fascicolo tecnico capace di sostenere sia la conformità Macchine sia quella CRA, senza confondere evidenze di sicurezza funzionale con evidenze di cybersecurity.

Il ponte operativo: dal requisito normativo alla resilienza

Il Regolamento Macchine richiede che la macchina sia sicura nell’uso e che i rischi derivanti da interferenze dolose siano trattati nella misura necessaria alla sicurezza. Il CRA richiede invece che il prodotto digitale sia resiliente alle minacce informatiche lungo l’intero ciclo di vita.

In un ambiente industriale, questi due obiettivi convergono in una domanda concreta: quando arriva un evento sospetto o un attacco, come si reagisce senza trasformare la difesa informatica in un nuovo rischio per la produzione?

È qui che Agger, la piattaforma di Gyala per la cybersecurity IT/OT/IoT, porta un approccio operativo. La piattaforma integra capacità di detection e reaction personalizzabili fino al singolo endpoint e un modulo OT Defence in grado di interrogare attivamente i dispositivi industriali connessi, anche attraverso protocolli standard come S7, MMS e SNMP.

Questo consente di contestualizzare la risposta alla sicurezza in base allo stato reale dell’infrastruttura OT – produzione, manutenzione, pulizia o altre fasi operative – e di calibrare le azioni di detection e reaction per preservare safety e continuità operativa. La piattaforma è inoltre progettata per garantire la resilienza H24 delle infrastrutture IT/OT/IoT, con regole di risposta automatizzate e personalizzabili.

In altre parole: la conformità normativa definisce cosa deve essere protetto; Agger aiuta a decidere come proteggerlo senza fermare ciò che deve continuare a funzionare.

Fonti primarie