Capire come applicare gli standard ISA/IEC 6244 diventa una sfida concreta nel momento in cui un’azienda decide di passare dalle buone intenzioni alla sicurezza OT reale, quella che deve funzionare ogni giorno in fabbrica.
Lo standard promette un approccio strutturato, graduale e basato sul rischio, ma nella pratica emergono subito i dubbi: da dove si parte se non esiste nulla? Serve ripensare l’architettura di rete? Quanto pesa la tecnologia rispetto ai processi e alle persone? E cosa è davvero indispensabile fare subito, rispetto a ciò che può essere pianificato nel tempo?
Questa guida nasce dall’esperienza di Innovio nei progetti di cybersecurity OT e integrazione IT/OT, con l’obiettivo di riportare la ISA/IEC 6244 su un piano operativo, collegando principi, livelli di sicurezza e requisiti normativi alle decisioni quotidiane che un’azienda deve affrontare quando avvia un percorso di protezione industriale serio e sostenibile.
Cosa sono gli standard ISA/IEC 62443, spiegati semplice
Gli standard ISA/IEC 62443 (spesso citati anche solo come IEC 62443) sono una serie di “istruzioni di buon senso” messe in ordine, pensate per rendere più sicuri i sistemi industriali: reti OT, linee di produzione, macchine, PLC, HMI, SCADA e tutti quei componenti che controllano processi fisici e non possono permettersi fermi o modifiche improvvisate.
L’idea di fondo è questa: invece di parlare in astratto di cybersecurity, la IEC 62443 ti dà un modo pratico per rispondere a tre domande molto concrete:
- Cosa devo proteggere? (asset e perimetro)
- Da cosa devo proteggermi? (rischi e impatti sulla produzione/sicurezza)
- Quanto “forte” deve essere la protezione? (obiettivi e livello richiesto)
La 62443 non è un documento unico. È una famiglia di standard che parla a soggetti diversi:
- Owner / azienda manifatturiera: come organizzare ruoli, regole, processi e controlli (governance e gestione).
- System integrator: come progettare o adeguare l’architettura OT in modo sicuro (reti, segmentazione, accessi).
- Vendor / produttori: come costruire e mantenere componenti OT più robusti (requisiti di sicurezza dei prodotti e del loro ciclo di sviluppo).
Questo è utile perché, quando parti da zero, capisci subito che non “devi fare tutto tu”: alcune cose sono interne, altre vanno chieste e pretese nella relazione con fornitori e integratori.
I 3 concetti chiave che ti servono per orientarti subito
Se devi iniziare a lavorare davvero, ci sono tre concetti che ricorrono spesso e che conviene fissare subito:
- Zone e conduits: invece di una rete piatta dove “tutto parla con tutto”, si ragiona per aree omogenee (zone) e collegamenti controllati (conduits). È il modo con cui la IEC 62443 traduce la segmentazione OT in una logica comprensibile anche a chi gestisce impianti.
- Security Level (SL): non tutte le parti dell’impianto devono avere lo stesso livello di protezione. Il Security Level serve per definire “quanto deve resistere” una zona o un sistema, in base al rischio e all’impatto.
- Requisiti di sicurezza (le “aree” di controllo): la 62443 raggruppa i controlli in grandi categorie (accessi, integrità, disponibilità, tracciabilità, ecc.) così puoi trasformare obiettivi in azioni verificabili (non in dichiarazioni).
Perché la ISA/IEC 62443 è diversa dalle liste di best practice?
La differenza principale è che la ISA/IEC 62443 non ti chiede solo di installare strumenti: ti spinge a definire responsabilità, regole operative e prove (evidenze) che quei controlli esistono e vengono mantenuti.
In altre parole, ti aiuta a costruire un percorso dove:
- Le priorità sono guidate dal rischio (non dalla moda del momento),
- La sicurezza si adatta ai vincoli OT (continuità, safety, legacy),
- Quello che implementi si può misurare e difendere anche quando cambiano impianti, fornitori o persone.
Come applicare la ISA/IEC 62443 partendo da zero: 6 step
Quando un’azienda parte da zero, l’errore più comune è provare a “mettere sicurezza” aggiungendo tecnologia qua e là, senza una base: perimetro, responsabilità, inventario e priorità. Il risultato è quasi sempre lo stesso: controlli incoerenti, eccezioni continue, progetti che si arenano perché impattano la produzione o perché nessuno sa davvero “chi decide cosa”.
Se ti stai chiedendo come applicare gli standard ISA/IEC 6244 in modo pratico, questi sei passi sono un ordine di lavoro realistico (e replicabile), pensato per arrivare rapidamente a scelte sensate e difendibili.
1) Definisci obiettivo e perimetro (prima di parlare di rete)
Qui serve una scelta netta: dove inizi? Un impianto intero, una linea critica, una singola cella, un’area con accessi remoti? Parti da un perimetro piccolo ma significativo, dove puoi ottenere risultati in poche settimane.
Output minimo (semplice, ma fondamentale):
- Perimetro OT iniziale (linea/cella/area/impianto)
- Obiettivi pratici (es. ridurre accessi non tracciati, limitare propagazione ransomware, aumentare visibilità, rendere più sicuri i fornitori in teleassistenza)
- Vincoli noti (fermi macchina, finestre di manutenzione, sistemi legacy “intoccabili”, certificazioni/safety)
2) Metti in chiaro ruoli e regole base (governance “leggera”)
In fabbrica, la cybersecurity OT fallisce spesso per un motivo banale: nessuno ha davvero la responsabilità operativa. Non serve creare burocrazia; serve un minimo di struttura.
Output minimo:
- Un referente OT (impianto/produzione/manutenzione) e un referente IT/security
- Una regola semplice su: accessi, cambi di configurazione, gestione fornitori, gestione incidenti
- Una modalità di approvazione rapida per le eccezioni (perché in OT ci saranno)
Questa è la differenza tra “policy che restano su SharePoint” e controlli che restano vivi nel tempo.
3) Fai l’inventario essenziale: asset, software e connessioni (non perfetto, utile)
Qui non devi “censire tutto il mondo”. Devi ottenere visibilità sufficiente per capire rischi e priorità.
Output minimo:
- Lista asset OT critici (PLC, HMI, SCADA, historian, gateway, switch industriali, server di reparto)
- Versioni/OS dove possibile (anche parziale)
- Mappa delle connessioni principali (chi parla con chi, e perché)
- Accessi remoti esistenti (VPN, gateway, desktop remoto, modem, tool vendor)
Se non sai cosa hai e come comunica, ogni step successivo sarà basato su supposizioni.
4) Identifica “cosa può succedere” e cosa fa più male (mini risk assessment OT)
Qui basta un esercizio molto concreto: per ogni asset/area critica chiediti:
- Se si ferma, che impatto ha su produzione, qualità, sicurezza delle persone, consegne?
- Se viene compromesso, può propagarsi ad altre zone?
- Quali sono i punti di fragilità evidenti (password condivise, accessi sempre aperti, sistemi non patchabili, backup assenti)?
Output minimo:
- 5–10 scenari realistici (non 50)
- Priorità in ordine (top 3 aree/impianti da mettere in sicurezza per prime)
5) Disegna zone & conduits “minime” e imposta un Security Level di partenza
Questo è il passaggio che trasforma i problemi in architettura. Senza diventare ingegneria pesante, definisci:
- Zone: gruppi di asset che devono stare insieme (es. cella robot, supervisione, rete macchine, DMZ OT, accesso remoto fornitori)
- Conduits: collegamenti ammessi tra zone, con regole chiare (porte/servizi necessari, logging, autenticazione)
Poi scegli un security level iniziale realistico per le zone più critiche: non serve “il massimo per tutto”. Serve un livello coerente con rischio e impatto, che guiderà quali controlli implementare prima.
Output minimo:
- Schema logico zone/conduits su 1 pagina
- Lista dei flussi necessari (pochi e giustificati)
- Security Level iniziale per 2–3 zone critiche
6) Traduci tutto in un piano 90 giorni: controlli concreti + evidenze minime
È qui che la teoria diventa operativa: scegli pochi controlli ad alto impatto e rendili verificabili.
Esempi (tipicamente ottimi “first wave”):
- Accessi nominativi e privilegi minimi (stop account condivisi dove possibile)
- Inventario + baseline configurazioni (almeno per gli asset critici)
- Backup e restore testato (non solo “abbiamo i backup”)
- Segmentazione minima (anche solo separare supervisione, macchine e accesso remoto)
- Teleassistenza fornitori: accesso “a richiesta”, tracciato, con regole chiare
Evidenze minime (quelle che ti salvano quando cambiano persone/fornitori):
- Elenco asset e mappa rete aggiornata
- Registro accessi remoti e approvazioni
- Procedure brevi (1 pagina) per change, incident, backup/restore
- Lista eccezioni + motivazione + data di revisione
ISA/IEC 62443 in pratica: zone & conduits e Security Level (SL)
Quando si prova davvero a capire come applicare gli standard ISA/IEC 6244, uno dei primi nodi da sciogliere è questo: come portare ordine in un ambiente OT senza trasformare la sicurezza in un progetto iper-tecnico, difficile da spiegare e ancora più difficile da mantenere nel tempo.
È qui che la ISA/IEC 62443 mostra il suo lato più concreto.
Il principio è semplice: non tutto l’impianto ha lo stesso ruolo, lo stesso impatto sul processo e lo stesso livello di esposizione. Trattare tutto allo stesso modo non solo è inefficiente, ma spesso controproducente.
La logica delle zone serve proprio a questo: raggruppare asset e sistemi che svolgono funzioni simili e che condividono un livello di rischio comparabile. In pratica si passa da una rete “piatta”, dove tutto comunica con tutto, a un impianto suddiviso in aree più comprensibili e gestibili: macchine, supervisione, sistemi centrali, accessi dall’esterno. Questo non richiede rivoluzioni architetturali immediate, ma soprattutto chiarezza.
I collegamenti tra le zone non vengono eliminati, ma resi intenzionali. La 62443 chiede di porsi una domanda molto concreta: questa comunicazione è davvero necessaria al funzionamento dell’impianto? Se la risposta è sì, il collegamento resta; se è no, diventa un rischio inutile. In questo modo si riduce la possibilità che un problema locale si propaghi a cascata su tutto il sistema produttivo.
A guidare queste scelte c’è il concetto di Security Level. Non è un punteggio né un traguardo da esibire, ma un obiettivo di robustezza: quanto deve essere protetta una certa area in base all’impatto che avrebbe un incidente. Le zone più critiche o più esposte richiedono misure più forti; le altre possono essere gestite in modo proporzionato. Questo approccio aiuta a concentrare sforzi e investimenti dove contano davvero.
IEC 62443: dai requisiti ai controlli OT
Una volta chiariti perimetro, zone e priorità, la domanda diventa inevitabile: da quali controlli si parte davvero? La forza degli standard ISA/IEC 62443 è proprio questa: non ti lascia nel vago, ma ti aiuta a trasformare obiettivi di sicurezza in requisiti e poi in attività verificabili.
In altre parole, ti accompagna nel passaggio più delicato di tutti: da “dobbiamo essere più sicuri” a “questa settimana facciamo X, il mese prossimo facciamo Y”.
Se il tuo obiettivo è capire come applicare gli standard ISA/IEC 6244 in modo pratico, qui la regola è una sola: scegli controlli che riducano rischio subito e che siano mantenibili nel tempo, senza dipendere dall’eroe di turno o da procedure impossibili da rispettare in produzione.
1) Gestione accessi: meno eccezioni, più tracciabilità
In OT il problema raramente è “non c’è nessuna password”. Il problema è che gli accessi sono spesso:
- Condivisi (account generici),
- Difficili da revocare (fornitori, ex collaboratori),
- Poco tracciati (non è chiaro chi ha fatto cosa e quando).
Le prime azioni concrete, quasi sempre ad alto impatto, sono:
- Introdurre accessi nominativi dove possibile (almeno sui sistemi più critici),
- Separare i privilegi (chi usa l’impianto ≠ chi configura),
- Definire una regola chiara per gli accessi dei fornitori (chi li autorizza, quando, e con quali vincoli).
Non serve “perfezione”, serve ridurre velocemente le aree grigie.
2) Integrità e hardening: rendere i sistemi meno “fragili”
Molti ambienti OT sono vulnerabili non perché qualcuno abbia fatto errori grossi, ma perché nel tempo si accumulano eccezioni, configurazioni non documentate e componenti mai aggiornati “perché funziona”.
Qui, i controlli davvero pratici sono:
- Stabilire una configurazione di riferimento per i sistemi più importanti (una baseline),
- Limitare ciò che non serve (servizi inutili, software superfluo, porte aperte “per comodità”),
- Impostare un ciclo realistico di aggiornamento: anche se non puoi patchare tutto, puoi almeno decidere cosa patchare, quando e con che test minimi.
È l’approccio opposto al “non aggiorniamo mai”: si passa a un modello gestito, proporzionato e controllato.
3) Backup, ripristino e continuità: la domanda che nessuno vuole fare
Uno dei punti più sottovalutati, ma più determinanti, è questo: sei in grado di ripartire davvero se un sistema OT critico si blocca o si corrompe?
Qui non basta dire “abbiamo i backup”. La IEC 62443 spinge verso controlli che, nella pratica, significano:
- Sapere cosa va salvato (configurazioni, ricette, parametri, progetti),
- Sapere dove sono i backup e chi può recuperarli,
- Aver testato almeno una volta un ripristino, anche in modo semplice.
Questo è uno dei controlli che più rapidamente trasforma la sicurezza da prevenzione a resilienza.
4) Monitoraggio e gestione degli incidenti: vedere prima, reagire meglio
Non serve partire con un SOC complesso. Ma se non hai visibilità, ti accorgi dei problemi quando è troppo tardi (o quando la produzione è già ferma).
Per iniziare in modo realistico:
- Raccogli log e eventi dai sistemi più importanti (anche solo quelli centrali),
- Definisci chi guarda cosa e con quale frequenza,
- Prepara una mini-procedura di gestione incidente OT: poche azioni chiare, ruoli chiari, contatti pronti.
Anche qui la parola chiave è mantenibilità: meglio poco ma fatto bene, che un sistema sofisticato che nessuno usa.
Certificazione IEC 62443: cosa si certifica davvero (e quando ha senso inseguirla)?
Quando si parla di certificazione IEC 62443, molte aziende si immaginano un traguardo unico e totale: o sei conforme, o non lo sei.
In realtà la serie 62443 è strutturata in modo più pragmatico: puoi certificare componenti, sistemi e (in alcuni casi) anche processi. Capire che cosa è certificabile e perché ti serve è fondamentale, soprattutto se stai iniziando da zero e vuoi evitare di impostare un progetto OT con l’obiettivo sbagliato.
Il punto chiave è questo: la certificazione non sostituisce il lavoro pratico di messa in sicurezza. Piuttosto, lo disciplina. Ti obbliga a definire requisiti chiari, raccogliere evidenze e dimostrare che i controlli non sono “dichiarazioni”, ma attività ripetibili e mantenute nel tempo. È anche il motivo per cui, per alcune aziende, la certificazione può diventare un acceleratore (perché mette ordine), mentre per altre può essere un vincolo prematuro (perché richiede maturità organizzativa minima).
Cosa può essere certificato: prodotti, sistemi, processi (e perché cambia tutto)
In modo semplice, si possono distinguere tre livelli tipici:
- Prodotti e componenti: riguarda dispositivi e software industriali (per esempio apparati di rete, gateway, soluzioni di accesso remoto, alcuni componenti OT) e dimostra che quel prodotto rispetta specifici requisiti di sicurezza. Qui la certificazione è spesso guidata dal produttore o dal fornitore.
- Sistemi: riguarda l’insieme “architettura + configurazioni + regole” con cui quel contesto OT è progettato e gestito. Qui entrano in gioco segmentazione, gestione accessi, logging, procedure operative e responsabilità.
- Processi: in alcuni casi l’attenzione si sposta su come un’organizzazione (o un vendor) sviluppa e mantiene i propri prodotti e controlli: gestione delle vulnerabilità, aggiornamenti, test, documentazione, ecc.
Per un’azienda manifatturiera che vuole capire come applicare la ISA/IEC 62443 in modo pratico, questo significa una cosa molto concreta: spesso non serve “certificare tutto subito”, ma scegliere dove la certificazione porta valore misurabile (o dove è richiesta dal mercato).
Quando la certificazione ha senso: i 4 casi più comuni
La certificazione IEC 62443 tende ad avere davvero senso quando almeno una di queste condizioni è vera:
- Richiesta di clienti o supply chain
Se operi in filiere dove i requisiti OT sono stringenti (automotive, pharma, energia, impianti critici), può diventare una richiesta esplicita o implicita per continuare a lavorare con certi partner. - Gare, bandi, qualifiche e audit
La certificazione può semplificare la vita quando devi dimostrare “in modo standard” un livello di maturità, riducendo discussioni infinite su cosa significhi “sicurezza adeguata”. - Riduzione del rischio operativo (downtime) come obiettivo business
Se l’impatto di un fermo impianto è molto alto, l’approccio “certificabile” ti aiuta a rendere sistematici alcuni pilastri (accessi, backup/restore, change management) che sono spesso la differenza tra incidente gestibile e stop lungo. - Riorganizzazione OT/IT e necessità di mettere ordine
In alcune aziende la certificazione è utile perché costringe a chiarire ruoli, perimetri, regole con i fornitori e responsabilità interne. Non è solo “bollino”: è un modo per evitare che la sicurezza dipenda da abitudini informali.
Cosa serve davvero per non trasformarla in un progetto infinito?
Qui è dove molte iniziative si bloccano: si parte parlando di certificazione, ma mancano le basi per produrre evidenze coerenti. CI sono 3prerequisiti pratici che fanno la differenza:
- Perimetro chiaro: cosa stai certificando, esattamente? Una linea? Un impianto? Un sistema specifico?
- Evidenze minime: inventario essenziale, regole di accesso, gestione fornitori, gestione cambi e un minimo di tracciabilità.
- Piano di mantenimento: non basta “arrivarci”. Devi dimostrare che i controlli restano attivi nel tempo.
In altre parole: la certificazione diventa sostenibile solo quando la 62443 è già stata trasformata in un programma operativo, anche snello, e non è ancora “solo un documento”.
Roadmap realistica: primi 90 giorni, poi 12 mesi (priorità, KPI, errori tipici)
Se un’azienda parte da zero, la cosa più pericolosa non è “non essere a norma”, ma iniziare un percorso troppo grande, troppo tecnico o troppo teorico e perdere slancio dopo poche settimane. Una roadmap coerente con la IEC 62443 funziona quando è fatta di passi piccoli, verificabili e con impatto reale: meno promesse, più evidenze.
Di seguito trovi una traccia concreta per capire come applicare gli standard ISA/IEC 6244 con un approccio sostenibile: prima costruisci le basi che riducono il rischio subito, poi consolidi ciò che rende la sicurezza OT stabile nel tempo.
Primi 90 giorni: mettere ordine e ridurre il rischio “visibile”
In questa fase l’obiettivo non è “essere perfetti”, ma creare una base di controllo su cui potrai costruire tutto il resto.
Cosa fare (priorità tipiche):
- Perimetro e responsabilità: definisci la prima area OT su cui lavori (impianto/linea) e assegna referenti chiari (anche se non sono figure dedicate).
- Inventario essenziale: elenco dei sistemi OT critici + mappa molto semplice delle principali connessioni. Se non sai cosa hai, non puoi decidere cosa proteggere.
- Accessi e fornitori: elimina gli accessi più rischiosi (account condivisi sui sistemi critici, accessi remoti non autorizzati o non tracciati) e introduci una regola “a richiesta” per la teleassistenza, con approvazione e log minimo.
- Backup e ripristino: identifica cosa va salvato davvero (configurazioni e dati chiave) e fai almeno un test di ripristino su un sistema rappresentativo.
- Segmentazione minima: senza rivoluzioni, crea una separazione logica tra ciò che controlla le macchine, ciò che supervisiona e ciò che scambia dati con l’esterno. Anche un passo piccolo può ridurre molto la propagazione dei problemi.
KPI semplici (utili per capire se stai migliorando):
- % asset OT critici censiti (non serve 100% subito, serve crescita costante)
- Numero di accessi remoti non tracciati (obiettivo: verso zero)
- Presenza di backup verificati per sistemi critici (sì/no + data ultimo test)
- Numero di “connessioni non necessarie” eliminate o ristrette (anche poche, ma documentate)
Entro 12 mesi: consolidare, rendere stabile e prepararsi anche alla certificazione
Quando hai creato visibilità e prime regole, il secondo step è trasformare le attività in un programma ripetibile (la parte che spesso distingue un progetto riuscito da uno che non ha futuro).
Cosa consolidare:
- Zone & conduits più mature: definisci meglio le aree OT e i passaggi consentiti tra loro, riducendo eccezioni e flussi “storici” non giustificati.
- Change management OT: regola semplice ma ferrea per cambi di configurazione, aggiornamenti e interventi dei fornitori (chi approva, come si documenta, cosa si testa).
- Gestione vulnerabilità e patch “ragionate”: non patchare tutto subito, ma avere un criterio (criticità, esposizione, finestre manutenzione, test minimi).
- Logging e gestione incidenti OT: stabilisci cosa monitorare, chi riceve gli alert e come si reagisce senza improvvisare.
- Requisiti ai fornitori: inserisci criteri di sicurezza minimi in contratti e procedure (accessi, tempi di risposta, modalità di intervento, gestione credenziali).
È anche la fase in cui puoi decidere con più lucidità se puntare alla certificazione IEC 62443: non come “bollino”, ma come conseguenza naturale di un sistema già governato, con evidenze e processi che reggono.
3 errori tipici che fanno perdere mesi (senza aumentare davvero la sicurezza)
- Partire dalla tecnologia prima del perimetro: comprare strumenti senza aver chiarito cosa proteggere e come è fatto l’impianto porta a soluzioni “scollegate” e poco usate.
- Voler fare tutto ovunque: in OT la sicurezza funziona per priorità. Se provi a uniformare tutto subito, ti schianti su vincoli produttivi e resistenze interne.
- Non definire regole per i fornitori: la teleassistenza e gli interventi esterni sono spesso l’area più “reale” e più fragile. Se non la governi, il resto vale poco.
ISA/IEC 62443 nella pratica quotidiana: il passaggio chiave dalla teoria alla fabbrica
Capire come applicare gli standard ISA/IEC 6244 significa, concretamente, mettere in fila poche decisioni corrette: definire un perimetro, dare responsabilità chiare, creare visibilità sugli asset, ridurre le comunicazioni inutili e rendere accessi, cambi e ripristini attività gestite e verificabili.
La vera differenza la fa la continuità: una roadmap sostenibile, controlli che restano attivi nel tempo e priorità guidate dal rischio reale dell’impianto. È così che la IEC 62443 diventa un metodo pratico per aumentare resilienza e affidabilità della produzione, e non un esercizio teorico.
Se vuoi tradurre questi principi in un piano concreto per il tuo contesto OT (da “zero” a un percorso strutturato, con priorità ed evidenze), Innovio può supportarti nel definire perimetro, roadmap e azioni operative coerenti con la ISA/IEC 62443: contattaci e raccontaci com’è fatto il tuo impianto e da dove vuoi iniziare.
