Cybersecurity OT: progettare macchine connesse per NIS2 e Cyber Resilience Act

Una macchina connessa non è soltanto un insieme di PLC, robot, sensori e pannelli operatore. Comprende account di manutenzione, workstation di engineering, accessi remoti, librerie software, firmware, switch, gateway e collegamenti verso sistemi di fabbrica o servizi esterni.

La cybersecurity OT deve quindi essere progettata come parte dell’architettura della cella. Aggiungere una VPN o un firewall alla fine non risolve credenziali condivise, componenti non censiti, aggiornamenti non governati o backup che nessuno ha mai provato a ripristinare.

Nel 2026 questa disciplina è anche al centro di due quadri europei distinti: NIS2 disciplina la resilienza delle organizzazioni comprese nel suo ambito; il Cyber Resilience Act introduce requisiti per prodotti hardware e software con elementi digitali immessi sul mercato.

NIS2 in Italia: obblighi dell’organizzazione

L’Italia ha recepito NIS2 con il decreto legislativo 4 settembre 2024, n. 138, entrato in vigore il 16 ottobre 2024. La normativa riguarda soggetti essenziali e importanti individuati secondo settori, dimensioni e criteri previsti dal decreto. Tra i settori considerati dalla direttiva europea rientrano anche specifici comparti manifatturieri, ma questo non significa che qualunque officina o costruttore di macchine sia automaticamente soggetto NIS.

Per i soggetti inclusi, l’articolo 24 richiede misure tecniche, operative e organizzative adeguate e proporzionate. Il perimetro comprende analisi del rischio, gestione degli incidenti, continuità operativa e backup, sicurezza della supply chain, sviluppo e manutenzione sicuri, gestione delle vulnerabilità, controllo degli accessi, formazione e, ove opportuno, autenticazione multifattore.

Gli organi di amministrazione devono approvare e sovrintendere l’attuazione delle misure e seguire formazione in materia. La sicurezza OT non può quindi rimanere una questione affidata informalmente al manutentore o al solo reparto IT.

Le notifiche degli incidenti

Per un incidente significativo, il decreto italiano prevede:

pre-notifica al CSIRT Italia entro 24 ore dalla conoscenza;
notifica entro 72 ore, con valutazione iniziale di gravità e impatto;
eventuali aggiornamenti intermedi richiesti dal CSIRT;
relazione finale entro un mese dalla notifica;
ulteriori aggiornamenti se l’incidente è ancora in corso.

L’attuazione italiana segue un calendario graduale definito da ACN. Per i soggetti della prima tornata gli obblighi di base di notifica sono operativi dal gennaio 2026, mentre le misure di sicurezza hanno termini collegati alla comunicazione di inserimento nell’elenco. La scadenza concreta deve quindi essere verificata sulla comunicazione ricevuta e sulle determinazioni ACN applicabili, non dedotta da una data generica trovata online.

La sezione normativa del Portale NIS di ACN raccoglie i riferimenti operativi nazionali.

Cyber Resilience Act: obblighi del prodotto

Il Cyber Resilience Act, Regolamento (UE) 2024/2847, è entrato in vigore il 10 dicembre 2024. Si applica ai prodotti con elementi digitali messi a disposizione sul mercato europeo, inclusi hardware, software e componenti commercializzati separatamente, fatte salve esclusioni e normative settoriali.

Le date vanno distinte con precisione:

dall’11 giugno 2026 si applicano le disposizioni sulla notifica degli organismi di valutazione della conformità;
dall’11 settembre 2026 si applica l’articolo 14 sulla segnalazione di vulnerabilità attivamente sfruttate e incidenti gravi;
dall’11 dicembre 2027 si applicherà in via generale il resto del regolamento.

Alla data di pubblicazione di questo articolo, quindi, gli obblighi principali di progettazione e conformità non sono ancora pienamente applicabili, mentre la prima scadenza sul reporting è imminente.

Per i produttori interessati, la Commissione europea indica una segnalazione iniziale entro 24 ore e una notifica completa entro 72 ore. Il rapporto finale è previsto entro quattordici giorni dalla disponibilità della misura correttiva per una vulnerabilità attivamente sfruttata, oppure entro un mese per un incidente grave. Le comunicazioni passano attraverso la Single Reporting Platform prevista dal CRA.

Una macchina, un gateway, un HMI o un componente software possono ricadere nel regolamento in modi differenti. Ruolo dell’operatore, modalità di commercializzazione, marchio, modifiche sostanziali ed eventuali esclusioni devono essere valutati sul prodotto concreto.

Perché l’OT richiede un approccio specifico

In ambiente IT può essere accettabile riavviare rapidamente un servizio dopo una patch. In una cella robotizzata, un aggiornamento può modificare comunicazioni, tempi, compatibilità dei driver o disponibilità della macchina. Sicurezza informatica, continuità e sicurezza funzionale devono quindi essere considerate insieme.

La guida NIST SP 800-82 Rev. 3 tratta la protezione dell’OT tenendo conto proprio di prestazioni, affidabilità e safety. Un controllo di sicurezza efficace non deve introdurre un rischio operativo maggiore di quello che intende ridurre.

Checklist secure-by-design per una macchina o cella

1. Definire perimetro e responsabilità

Identificare chi è responsabile di PLC, robot, IPC, telecamere, switch, accesso remoto e software applicativo. Va chiarito anche chi riceve una segnalazione di vulnerabilità e chi decide l’eventuale fermata o aggiornamento.

2. Mantenere un inventario tecnico

Registrare modello, firmware, librerie, porte, protocolli, dipendenze e stato di supporto. Per i prodotti software è utile una distinta base dei componenti, o SBOM, collegata alle versioni realmente distribuite.

3. Separare reti e flussi

Collocare la cella in una zona OT definita, limitando i flussi verso reti aziendali, assistenza e servizi esterni. Le regole devono consentire soltanto protocolli, direzioni e sistemi necessari al processo.

4. Eliminare identità condivise

Ogni tecnico e fornitore dovrebbe disporre di un’identità riconoscibile. Account predefiniti, password comuni e credenziali incorporate nel software vanno rimossi. Privilegi elevati devono essere limitati nel tempo e alle attività necessarie.

5. Governare l’accesso remoto

L’assistenza remota deve essere disattivata quando non serve oppure attivata su autorizzazione, con autenticazione forte, tracciamento della sessione e percorso controllato. Il collegamento diretto e permanente del fornitore alla cella amplia inutilmente la superficie di attacco.

6. Ridurre i servizi esposti

Porte, server web, protocolli legacy e funzioni diagnostiche non utilizzate devono essere disabilitati quando tecnicamente possibile. La configurazione sicura deve essere documentata e riproducibile dopo una sostituzione.

7. Pianificare aggiornamenti e vulnerabilità

Per ogni componente occorre conoscere canale di aggiornamento, firma o verifica dell’autenticità, compatibilità, procedura di test e possibilità di rollback. Il contratto con il fornitore dovrebbe indicare durata del supporto e modalità di comunicazione delle vulnerabilità.

8. Raccogliere log utili

Accessi, modifiche di configurazione, aggiornamenti, allarmi di sicurezza e anomalie di comunicazione devono avere orari coerenti e una destinazione protetta. Conservare grandi quantità di log senza responsabilità di analisi non equivale a monitorare.

9. Preparare e provare il ripristino

Backup di programmi PLC, progetti robot, configurazioni di visione, ricette e dispositivi di rete devono essere protetti e versionati. La prova decisiva è il ripristino su una procedura documentata, non la sola presenza del file.

10. Collegare risposta tecnica e notifica

Il piano di incidente deve stabilire contatti, criteri di severità, modalità di isolamento della cella, raccolta delle evidenze e valutazione degli obblighi NIS2 o CRA. Le finestre di 24 e 72 ore richiedono ruoli definiti prima dell’evento.

Un piano concreto per iniziare

Nei primi trenta giorni è realistico completare quattro attività:

censire macchine, connessioni e accessi remoti;
identificare account condivisi, sistemi fuori supporto e collegamenti non necessari;
verificare backup e ripristino di almeno una cella rappresentativa;
assegnare proprietari, contatti di incidente e percorso di escalation.

Il passo successivo è integrare questi requisiti nelle specifiche di acquisto e nei collaudi. Una cella sicura non nasce dall’hardening finale: nasce quando interfacce, aggiornamenti, identità, logging e ciclo di supporto vengono definiti insieme all’automazione.

Questo articolo offre un inquadramento tecnico generale aggiornato al 4 settembre 2026 e non costituisce consulenza legale. Ambito NIS2, ruolo ai fini del CRA e scadenze applicabili vanno verificati sul caso concreto.