Controllo e Monitoraggio della Rete: la Nuova Postura di Sicurezza degli Impianti Connessi

Gli aggiornamenti Terna agli Allegati A.13, A.69 e A.52 nel quadro europeo di resilienza cyber, NIS2, CRA e Perimetro di Sicurezza Nazionale Cibernetica

Questo articolo interpreta gli aggiornamenti Terna agli Allegati A.13, A.69 e A.52 del Codice di Rete come un segnale di rafforzamento strutturale della postura di sicurezza richiesta agli impianti connessi alla rete elettrica. La tesi centrale è che tali aggiornamenti non siano una semplice revisione documentale, ma il passaggio verso un modello in cui controllo, monitoraggio, telecomunicazioni, disponibilità operativa e cybersecurity diventano dimensioni inseparabili dell’architettura di impianto. I tre allegati intervengono su oggetti formalmente distinti ma sostanzialmente convergenti: l’Allegato A.13 disciplina la connessione al sistema di controllo di Terna; l’Allegato A.69 regola la connessione degli impianti di produzione al sistema di difesa; l’Allegato A.52 definisce le caratteristiche funzionali e di comunicazione dell’UPDM. Considerati insieme, essi descrivono l’impianto non più come infrastruttura elettrica con un canale dati aggiunto, ma come sistema cyber-fisico governato end-to-end, nel quale apparati, reti, misure, comandi, collaudi, manutenzione e sicurezza devono essere coerenti con il ruolo sistemico dell’impianto. La prima direttrice di cambiamento riguarda il perimetro tecnico: il livello a 36 kV assume una rilevanza esplicita, soprattutto per impianti di produzione, accumulo e consumo/autoconsumo connessi direttamente o indirettamente alla RTN. Questo incide in modo particolare su BESS, impianti rinnovabili e configurazioni ibride, perché porta dentro la disciplina Terna impianti che non possono più essere trattati come casi minori o assimilati per analogia agli impianti AT tradizionali. La seconda direttrice riguarda la rete di comunicazione: gli allegati spostano il baricentro da una nozione generica di collegamento dati a una nozione più rigorosa di infrastruttura TLC/OT soggetta a requisiti architetturali, prestazionali e di governance. MPLS, router conformi all’architettura Terna, funzione di switching integrata, BGP, IPSec ove previsto, indirizzamento governato, assenza di switch esterni intermedi e connessioni fisiche dedicate in fibra ottica diventano elementi di progetto, non dettagli esecutivi. La terza direttrice riguarda la conduzione operativa: gli aggiornamenti introducono requisiti di ciclo di vita, inclusi adeguamento degli impianti esistenti, finestre transitorie, migrazione tecnologica, esenzioni condizionate, collaudi tecnici, documentazione, monitoraggio proattivo, gestione dei guasti, H24 e responsabilità verso provider, O&M contractor, telco, integratori e fornitori di apparati. La conformità Terna non si esaurisce quindi nel commissioning, ma deve essere mantenuta, verificata e documentata durante l’intero esercizio. L’articolo legge l’Allegato A.13 come passaggio dal telecontrollo alla connessione operativa dell’impianto, l’Allegato A.69 come formalizzazione del sistema di difesa quale catena OT/TLC/cyber, e l’Allegato A.52 come trasformazione dell’UPDM in componente cyber-fisico critico, con doppia Ethernet, alta affidabilità, IEC 61850, segregazione, secure boot, firma del firmware, RADIUS, RBAC, logging, patching e gestione delle vulnerabilità. La lettura viene poi estesa agli altri allegati aggiornati nello stesso ciclo: A.17 per le centrali eoliche, A.68 per le centrali fotovoltaiche e A.18 per la verifica della conformità. Questi allegati non introducono un capitolo cybersecurity organico paragonabile a quello di A.13, A.52 e A.69, ma incidono comunque sull’architettura IT/OT perché rendono controllabili, misurabili, verificabili e documentabili le prestazioni tecniche dell’impianto. In particolare, portano i requisiti Terna dentro i sistemi di controllo centrale dell’impianto, i PPC o controllori di centrale, gli inverter, gli aerogeneratori, le protezioni, le telemisure, i telesegnali, l’integrazione UPDM, i file di setting, le versioni firmware, i modelli dinamici, le prove di conformità e la gestione del ciclo di vita. Per le centrali eoliche e fotovoltaiche, gli Allegati A.17 e A.68 rafforzano il nesso fra regolazione, monitoraggio dei servizi, modulazione, teledistacco, limitazione della produzione, scambio dati e priorità fra azioni di controllo e protezione. Ne deriva che l’impianto non può più essere progettato come una semplice catena locale chiusa dentro il perimetro del fornitore, ma come un sistema OT integrato nel quale controllore centrale, SCADA, RTU, UPDM, apparati di campo e interfacce verso Terna hanno ruoli distinti ma coordinati. L’Allegato A.18 completa il quadro trasformando i requisiti in verifiche, rapporti, prove strumentali, monitoraggio continuo, prove in autonomia, controlli periodici, registrazioni e documentazione probatoria. La conformità diventa quindi una proprietà da dimostrare nel tempo, non una dichiarazione iniziale. Questa evoluzione viene collocata nella traiettoria regolatoria europea definita da NIS2, DORA, Cyber Resilience Act e Perimetro di Sicurezza Nazionale Cibernetica, che convergono verso una stessa direzione: la cybersecurity non è più un presidio specialistico esterno ai processi industriali, ma un requisito ordinario di continuità operativa, governance, responsabilità e resilienza delle filiere critiche. In un contesto in cui automazione, crime-as-a-service, AI generativa, supply chain attack e sfruttamento di sistemi legacy abbassano il costo unitario dell’attacco, anche operatori e fornitori un tempo sotto la soglia di interesse diventano bersagli rilevanti. L’appendice traduce infine questa lettura in una guida pratica di design per Titolari e BoP: segmentazione in zone e conduits secondo la logica IEC 62443, separazione fra campo, controllo locale, dominio Terna, servizi OT, OT DMZ, IT/SOC, terze parti e servizi ausiliari, uso proporzionato di firewall, jump host, VPN con MFA, logging, SIEM, IDS/NDR passivo, backup, patching e procedure di accesso remoto. La conclusione operativa è che il perimetro Terna deve essere portato dentro il progetto dell’impianto fin dall’inizio. La domanda non è più se l’impianto disponga di un canale verso Terna, ma se possieda una catena end-to-end, fisica, logica, funzionale e cyber, capace di sostenere controllo, monitoraggio, difesa, collaudo, manutenzione, auditabilità e continuità per tutto il ciclo di vita.
cybersecurity
essay
🇮🇹
Author
Affiliation

Antonio Montano

4M4

Published

May 16, 2026

Modified

May 17, 2026

Keywords

Terna, Italian power grid, grid code, electricity transmission, critical infrastructure, OT cybersecurity, IT/OT architecture, operational technology, industrial control systems, cyber-physical systems, grid monitoring, grid control, power system security, energy infrastructure, renewable energy, BESS, battery energy storage systems, photovoltaic plants, wind farms, high-voltage substations, 36 kV connection, RTN, UPDM, RTU, SCADA, EMS, BMS, PCS, PPC, MPLS, IEC 60870-5-104, IEC 61850, IEC 62443, NIS2, CRA, PSNC, OT DMZ, jump host, network segmentation, zones and conduits, firewall, SIEM, IDS, NDR, remote access, asset inventory, compliance, resilience, grid observability, telemetry, protection systems, conformance testing, lifecycle governance

Questo articolo interpreta gli aggiornamenti Terna agli Allegati A.13, A.69 e A.52 del Codice di Rete come un segnale di rafforzamento strutturale della postura di sicurezza richiesta agli impianti connessi alla rete elettrica. La tesi centrale è che tali aggiornamenti non siano una semplice revisione documentale, ma il passaggio verso un modello in cui controllo, monitoraggio, telecomunicazioni, disponibilità operativa e cybersecurity diventano dimensioni inseparabili dell’architettura di impianto. I tre allegati intervengono su oggetti formalmente distinti ma sostanzialmente convergenti: l’Allegato A.13 disciplina la connessione al sistema di controllo di Terna; l’Allegato A.69 regola la connessione degli impianti di produzione al sistema di difesa; l’Allegato A.52 definisce le caratteristiche funzionali e di comunicazione dell’UPDM. Considerati insieme, essi descrivono l’impianto non più come infrastruttura elettrica con un canale dati aggiunto, ma come sistema cyber-fisico governato end-to-end, nel quale apparati, reti, misure, comandi, collaudi, manutenzione e sicurezza devono essere coerenti con il ruolo sistemico dell’impianto. La prima direttrice di cambiamento riguarda il perimetro tecnico: il livello a 36 kV assume una rilevanza esplicita, soprattutto per impianti di produzione, accumulo e consumo/autoconsumo connessi direttamente o indirettamente alla RTN. Questo incide in modo particolare su BESS, impianti rinnovabili e configurazioni ibride, perché porta dentro la disciplina Terna impianti che non possono più essere trattati come casi minori o assimilati per analogia agli impianti AT tradizionali. La seconda direttrice riguarda la rete di comunicazione: gli allegati spostano il baricentro da una nozione generica di collegamento dati a una nozione più rigorosa di infrastruttura TLC/OT soggetta a requisiti architetturali, prestazionali e di governance. MPLS, router conformi all’architettura Terna, funzione di switching integrata, BGP, IPSec ove previsto, indirizzamento governato, assenza di switch esterni intermedi e connessioni fisiche dedicate in fibra ottica diventano elementi di progetto, non dettagli esecutivi. La terza direttrice riguarda la conduzione operativa: gli aggiornamenti introducono requisiti di ciclo di vita, inclusi adeguamento degli impianti esistenti, finestre transitorie, migrazione tecnologica, esenzioni condizionate, collaudi tecnici, documentazione, monitoraggio proattivo, gestione dei guasti, H24 e responsabilità verso provider, O&M contractor, telco, integratori e fornitori di apparati. La conformità Terna non si esaurisce quindi nel commissioning, ma deve essere mantenuta, verificata e documentata durante l’intero esercizio. L’articolo legge l’Allegato A.13 come passaggio dal telecontrollo alla connessione operativa dell’impianto, l’Allegato A.69 come formalizzazione del sistema di difesa quale catena OT/TLC/cyber, e l’Allegato A.52 come trasformazione dell’UPDM in componente cyber-fisico critico, con doppia Ethernet, alta affidabilità, IEC 61850, segregazione, secure boot, firma del firmware, RADIUS, RBAC, logging, patching e gestione delle vulnerabilità. La lettura viene poi estesa agli altri allegati aggiornati nello stesso ciclo: A.17 per le centrali eoliche, A.68 per le centrali fotovoltaiche e A.18 per la verifica della conformità. Questi allegati non introducono un capitolo cybersecurity organico paragonabile a quello di A.13, A.52 e A.69, ma incidono comunque sull’architettura IT/OT perché rendono controllabili, misurabili, verificabili e documentabili le prestazioni tecniche dell’impianto. In particolare, portano i requisiti Terna dentro i sistemi di controllo centrale dell’impianto, i PPC o controllori di centrale, gli inverter, gli aerogeneratori, le protezioni, le telemisure, i telesegnali, l’integrazione UPDM, i file di setting, le versioni firmware, i modelli dinamici, le prove di conformità e la gestione del ciclo di vita. Per le centrali eoliche e fotovoltaiche, gli Allegati A.17 e A.68 rafforzano il nesso fra regolazione, monitoraggio dei servizi, modulazione, teledistacco, limitazione della produzione, scambio dati e priorità fra azioni di controllo e protezione. Ne deriva che l’impianto non può più essere progettato come una semplice catena locale chiusa dentro il perimetro del fornitore, ma come un sistema OT integrato nel quale controllore centrale, SCADA, RTU, UPDM, apparati di campo e interfacce verso Terna hanno ruoli distinti ma coordinati. L’Allegato A.18 completa il quadro trasformando i requisiti in verifiche, rapporti, prove strumentali, monitoraggio continuo, prove in autonomia, controlli periodici, registrazioni e documentazione probatoria. La conformità diventa quindi una proprietà da dimostrare nel tempo, non una dichiarazione iniziale. Questa evoluzione viene collocata nella traiettoria regolatoria europea definita da NIS2, DORA, Cyber Resilience Act e Perimetro di Sicurezza Nazionale Cibernetica, che convergono verso una stessa direzione: la cybersecurity non è più un presidio specialistico esterno ai processi industriali, ma un requisito ordinario di continuità operativa, governance, responsabilità e resilienza delle filiere critiche. In un contesto in cui automazione, crime-as-a-service, AI generativa, supply chain attack e sfruttamento di sistemi legacy abbassano il costo unitario dell’attacco, anche operatori e fornitori un tempo sotto la soglia di interesse diventano bersagli rilevanti. L’appendice traduce infine questa lettura in una guida pratica di design per Titolari e BoP: segmentazione in zone e conduits secondo la logica IEC 62443, separazione fra campo, controllo locale, dominio Terna, servizi OT, OT DMZ, IT/SOC, terze parti e servizi ausiliari, uso proporzionato di firewall, jump host, VPN con MFA, logging, SIEM, IDS/NDR passivo, backup, patching e procedure di accesso remoto. La conclusione operativa è che il perimetro Terna deve essere portato dentro il progetto dell’impianto fin dall’inizio. La domanda non è più se l’impianto disponga di un canale verso Terna, ma se possieda una catena end-to-end, fisica, logica, funzionale e cyber, capace di sostenere controllo, monitoraggio, difesa, collaudo, manutenzione, auditabilità e continuità per tutto il ciclo di vita.

Introduzione: tre allegati, una sola direzione architetturale

L’avviso di aggiornamento del Codice di Rete pubblicato da Terna nel maggio 2026 non va letto come una normale manutenzione documentale.1 Gli Allegati A.13, A.69 e A.52 intervengono su oggetti formalmente distinti: il sistema di controllo, il sistema di difesa e l’unità periferica dei sistemi di difesa e monitoraggio. Tuttavia, se osservati dal punto di vista del disegno e della conduzione degli impianti, i tre aggiornamenti convergono verso lo stesso modello: un impianto connesso alla RTN non è più descrivibile come un insieme di componenti elettrici a cui si aggiunge un canale di comunicazione, ma come un sistema cyber-fisico governato end-to-end.

Il primo elemento comune è l’abbassamento e la precisazione del perimetro tecnico. Il livello a 36 kV diventa un confine operativo esplicito per impianti RTN o funzionali alla RTN, impianti di produzione, inclusi gli accumuli, e impianti di consumo/autoconsumo; per le reti di distribuzione il riferimento dell’Allegato A.13 resta invece legato alla soglia pari o superiore a 50 kV. Questo è particolarmente rilevante per impianti rinnovabili, sistemi di accumulo e configurazioni connesse a sezioni 36 kV di stazioni Terna.

Il secondo elemento comune è la convergenza fra controllo, difesa, monitoraggio e telecomunicazioni. Gli allegati non disciplinano più soltanto il contenuto informativo da scambiare, ma anche i vettori, i router, le interfacce, le fibre ottiche, il collaudo, il monitoraggio locale, la manutenzione, la disponibilità e la gestione del guasto. La rete di comunicazione diventa parte integrante della funzionalità elettrica.

Il terzo elemento comune è la trasformazione della cybersecurity da principio generale a requisito verificabile. Asset inventory, segregazione, logging, autenticazione, patching, hardening, gestione vulnerabilità, audit, supply chain e incident response entrano nel lessico ordinario degli allegati tecnici. Il punto fondamentale è che la sicurezza non è più una clausola esterna all’impianto: diventa una proprietà richiesta della catena di controllo, difesa e monitoraggio.

Il quarto elemento comune riguarda il ciclo di vita. I nuovi requisiti non valgono solo per i nuovi impianti. In forme diverse, gli allegati introducono obblighi di adeguamento, finestre temporali, esenzioni condizionate per rifacimenti, repowering o dismissioni, e responsabilità esplicite del Titolare anche quando l’esercizio tecnico è affidato a terzi. La compliance non coincide quindi con il progetto iniziale, ma con la capacità di mantenere nel tempo una configurazione coerente, documentata e collaudabile.

Questa lettura porta a una conclusione operativa: gli aggiornamenti Terna non sono soltanto prescrizioni per il gestore di rete, né soltanto requisiti per il fornitore BoP o per il vendor degli apparati. Sono requisiti di architettura di impianto che incidono su layout, BoM, connessioni di comunicazione, cavidotti, apparati di networking, RTU, UPDM, EMS/BMS, interfacce di campo, contratti O&M, procedure operative di esercizio, governance della cybersecurity e commissioning.

Come leggere gli allegati: dal requisito Terna al requisito di architettura

Prima di entrare nei singoli allegati, è utile esplicitare il metodo di lettura adottato. Gli aggiornamenti Terna possono essere letti a tre livelli:

  1. Documentale: che cosa cambia nel testo degli allegati, quali soglie vengono modificate, quali apparati sono richiesti, quali tempi di adeguamento vengono introdotti.

  2. Funzionale: quali nuove capacità deve avere l’impianto, ad esempio osservabilità, teledistacco, modulazione, limitazione della produzione, monitoraggio, registrazione degli eventi, verifica dei flussi e mantenimento della disponibilità.

  3. Architetturale: quali conseguenze producono questi requisiti su reti, apparati, zone OT, router, RTU, UPDM, SCADA, EMS/BMS/PCS, accessi remoti, logging, backup, O&M, fornitori e ciclo di vita.

Questo articolo adotta soprattutto il terzo livello di lettura. Non considera gli allegati come prescrizioni isolate, ma come requisiti che devono essere tradotti in scelte di disegno, configurazione, procurement, commissioning e conduzione. È in questo passaggio che il tema Terna diventa tema IT/OT.

Allegato A.13: dal telecontrollo alla connessione operativa dell’impianto

L’Allegato A.13 disciplina i criteri di connessione al sistema di controllo di Terna. La revisione 2026 sposta l’asse del documento da una logica di telecontrollo e acquisizione dati verso una logica più ampia di infrastruttura operativa. Il documento continua a trattare supervisione, teleregolazione e monitoraggio delle grandezze elettriche, ma la parte realmente nuova sta nel fatto che tali funzioni vengono legate a una rete dati più prescrittiva, a una disciplina specifica per il 36 kV, a requisiti di disponibilità, collaudo, monitoraggio, segregazione e cybersecurity.

In termini di design, l’Allegato A.13 incide soprattutto su cinque dimensioni architetturali e operative:

  1. Perimetro: gli impianti connessi a 36 kV, inclusi gli impianti di accumulo, vengono ricondotti a una disciplina esplicita, superando la possibilità di trattarli come casi marginali o assimilati per analogia agli impianti AT tradizionali.

  2. Target tecnologico: i collegamenti nuovi o oggetto di adeguamento convergono verso un modello MPLS, mentre le tecnologie legacy vengono progressivamente confinate a condizioni transitorie, da gestire nell’ambito di un piano di migrazione.

  3. Boundary di rete: la connessione verso Terna costituisce un dominio dedicato, non una semplice estensione della rete OT di impianto. Il punto di attestazione deve essere realizzato su router conformi all’architettura Terna, con funzione di switching integrata, routing BGP, cifratura IPSec ove prevista, indirizzamento definito da Terna e assenza di switch esterni intermedi. Le RTU e, nel caso delle configurazioni a 36 kV, gli apparati di campo devono essere attestati direttamente alle porte dell’apparato, con identificazione puntuale degli endpoint.

  4. Connessione fisica per impianti a 36 kV: nel caso di connessione a sezioni 36 kV di stazioni Terna, l’architettura richiede una soluzione fisica dedicata, fondata su doppia fibra ottica monomodale, pannello di terminazione, cassetta di giunzione, router dedicati e chiara individuazione del punto di confine tra infrastruttura del Titolare e infrastruttura Terna.

  5. Conduzione operativa: il Titolare non deve limitarsi a predisporre il collegamento, ma deve garantirne la gestione nel tempo, includendo contatti H24, governo dei provider, coordinamento con l’O&M, aggiornamento dei riferimenti operativi delle terze parti, segregazione tra Titolari gestiti dallo stesso fornitore, monitoraggio dei collegamenti, gestione dei guasti, cambio provider, documentazione tecnica e collaudo con Terna.

La tabella seguente riassume solo le differenze sostanziali, cioè quelle che modificano il disegno o la conduzione dell’impianto.

Ambito sostanziale Differenza sostanziale Impatto su disegno e conduzione impianto
Perimetro 36 kV e storage La soglia rilevante viene estesa agli impianti RTN, di produzione, consumo e autoconsumo con tensione pari o superiore a 36 kV; gli impianti di accumulo sono richiamati esplicitamente. Gli impianti BESS/PV connessi a 36 kV devono essere progettati come impianti pienamente soggetti ai requisiti A.13, non come casi minori o assimilati.
Adeguamento degli esistenti La revisione introduce una disciplina di adeguamento per impianti esistenti e una finestra temporale per i nuovi impianti. Serve un piano di retrofit TLC/OT per impianti già progettati o in esercizio, con migrazione condivisa con Terna e continuità dei flussi.
MPLS come target Le tecnologie non-MPLS sono trattate come legacy; i nuovi collegamenti sono disciplinati in tecnologia MPLS. Le RFQ TLC devono chiedere MPLS Layer 3 VPN, QoS, MCR, SLA, latenza, provider end-to-end, BGP e compatibilità con router Terna.
Provider e catena tecnica Viene rafforzato il requisito di collegamento end-to-end senza provider intermediari. In fase di procurement va chiarita la catena reale del carrier, comprese tratte wholesale, sub-provider, demarcazioni e percorsi fisici.
Localizzazione dell’infrastruttura L’intera infrastruttura funzionale alla connessione al sistema di controllo, comprendente sistemi e telecomunicazioni, deve essere localizzata sul territorio nazionale italiano. Vanno verificati NOC, SOC, servizi gestiti, componenti cloud, sistemi di monitoraggio, jump host, O&M e terze parti che intervengono sulla catena di connessione verso Terna.
Router e LAN Terna Il router deve integrare la funzione di switching Ethernet; non è ammesso uno switch esterno; routing e indirizzamento sono governati da Terna. La BoM deve prevedere router dedicati e compatibili, con porte sufficienti, supporto BGP, abilitazione/licenze per IPSec ove necessarie e connessione diretta degli apparati di campo.
Connessione 36 kV in fibra ottica Per impianti connessi a sezioni 36 kV di stazioni Terna sono richiesti due cavi FO monomodale G.652D, pannello FO, cassetta di giunzione e router dedicati. Layout, cavidotti, terminazioni, locali tecnici, manutenzione FO e responsabilità di confine diventano parte del disegno di impianto.
Monitoraggio e collaudo Sono richiesti monitoraggio proattivo, segnalazione guasto, collaudo tecnico remoto, documentazione tecnica e gestione delle riserve. Il commissioning deve includere una milestone TLC Terna autonoma, distinta dal solo SAT funzionale dell’impianto.
Cybersecurity operativa Il capitolo cyber richiede inventari, flussi, terze parti, logging, patching, backup, autenticazione, segregazione, assessment e diritto di audit. L’impianto deve essere gestito come ambiente OT cyber-controllato, con evidenze mantenute nel tempo e non solo prodotte al collaudo.

La lettura architetturale è quindi chiara: A.13 non è più soltanto il documento che dice come portare misure e segnali al sistema di controllo. È il documento che impone una forma tecnica alla relazione fra impianto, rete dati Terna, O&M, cybersecurity e continuità operativa.

Allegato A.69: il sistema di difesa come catena OT/TLC/cyber

L’Allegato A.69 disciplina la connessione degli impianti di produzione al sistema di difesa di Terna. La revisione 2026 è particolarmente rilevante perché tocca sia la comunicazione sia la funzione elettrica. Il sistema di difesa non è trattato come un semplice canale di teledistacco, ma come una catena distribuita capace di acquisire misure, ricevere messaggi, attuare comandi di distacco, modulazione o limitazione, interagire con UPDM e apparati di campo, e mantenere continuità e osservabilità nel tempo.

Il cambio di prospettiva è più evidente su tre assi:

  1. Il 36 kV: anche qui viene introdotta una disciplina dedicata, coordinata con l’Allegato A.13, basata su fibra ottica diretta fra impianto e stazione Terna.

  2. L’accumulo: la revisione introduce una sezione specifica per impianti elettrochimici di accumulo, con comandi e misure coerenti con il comportamento bidirezionale del BESS.

  3. L’UPDM come asset operativo: non basta installare l’apparato; occorre monitorarlo, mantenerlo, testarlo, conservarne i flussi, rispondere ai guasti e garantirne la conformità nel tempo.

Il punto fisico più importante è che, per le configurazioni a 36 kV, il sistema di difesa entra nel layout della stazione e dell’impianto: due cavi fisici distinti in fibra ottica monomodale G.652D verso la stazione Terna, pannello, cassetta di giunzione, router, manutenzione, monitoraggio, collaudo e prove di continuità diventano elementi di progetto. Il punto funzionale più importante è che il BESS viene trattato come risorsa attiva di difesa: non solo erogazione o assorbimento misurati, ma capacità energetica disponibile, potenza massima raggiungibile e comandi di azzeramento, massimo assorbimento, massima erogazione, ripristino ed emergenza.

Ambito sostanziale Differenza sostanziale Impatto su disegno e conduzione impianto
Perimetro >36 kV e 36 kV La revisione distingue espressamente impianti connessi a tensione superiore a 36 kV e impianti connessi a 36 kV. Gli impianti a 36 kV devono seguire una disciplina propria, non una trasposizione semplificata delle configurazioni AT tradizionali.
Adeguamento e transizione Vengono introdotti termini per impianti nuovi ed esistenti, con specifico riferimento all’installazione UPDM e alla migrazione verso MPLS. Serve una gap analysis su impianti esistenti: connessione, router, UPDM, interfaccia locale, collaudi e cybersecurity devono essere verificati.
MPLS e router di difesa MPLS diventa il riferimento per nuovi collegamenti e adeguamenti; sono richiesti due router dedicati al Sistema di Difesa, gestiti da Terna. La BoM deve prevedere router compatibili con l’architettura Terna, BGP, IPSec, funzione di switching integrata nel router, porte sufficienti e connessione diretta degli apparati di campo.
FO per impianti 36 kV La connessione 36 kV richiede due cavi FO monomodale G.652D verso la stazione Terna, pannello FO, cassetta di giunzione e router dedicati. Cavidotti, percorsi FO, terminazioni, accessibilità, manutenzione e prove di continuità diventano parte del progetto elettro-strumentale.
Collaudo FO/TLC Per 36 kV sono richiesti collaudo remoto, documentazione tecnica, prove di continuità FO, riferimento tecnico e tracciato del percorso ottico. Il commissioning deve prevedere un pacchetto di test TLC/FO separato dal solo test funzionale dell’UPDM.
Integrazione A.69/A.13/A.7 È possibile usare un’unica infrastruttura TLC, ma con proposta preventiva, riconfigurazione IP se necessaria, continuità dei flussi e revisione architetturale con Terna. La convergenza TLC è ammessa solo se governata; non è un semplice riuso opportunistico della stessa linea.
UPDM come asset operativo La revisione rafforza responsabilità su installazione, esercizio, test periodici, manutenzione, ripristino e conformità dell’UPDM. L’O&M deve includere procedure specifiche per UPDM, guasti, test, evidenze, escalation e interfaccia con Terna.
Monitoraggio UPDM e retention Sono richiesti monitoraggio locale, rilevazione anomalie, porta mirror, memorizzazione dei flussi per almeno 60 giorni e ripristino entro tre giorni lavorativi. L’impianto deve avere capacità di osservabilità tecnica della catena UPDM, non solo un apparato installato e sigillato.
BESS e impianti elettrochimici Vengono introdotti comandi e misure dedicate per accumulo elettrochimico: potenza, capacità disponibile, massimo assorbimento, massima erogazione, azzeramento scambio, emergenza e ripristino. EMS, BMS e PCS devono essere integrati con logiche e misure coerenti con i requisiti del sistema di difesa.
Siti multi-tecnologia Per siti comprendenti impianti di diverse tipologie devono essere rispettati i requisiti applicabili a ciascuna tipologia di impianto; inoltre, il Titolare deve comunicare a Terna il limite di scambio di potenza del sito con la rete. Per impianti ibridi, ad esempio PV+BESS o configurazioni con più tecnologie nello stesso sito, il progetto non può limitarsi a trattare separatamente le singole unità: deve essere governata anche la configurazione complessiva di sito e il relativo limite di scambio con la rete.
Tempi di attuazione dei comandi I comandi di apertura devono rispettare il tempo di attuazione assegnato da Terna alla tipologia di impianto; i comandi di modulazione devono essere cablati direttamente all’ingresso del circuito di pilotaggio dell’inverter. Per massimo assorbimento e massima erogazione/produzione deve essere raggiunto il 90% della potenza indicata entro Ts ≤ 180 ms e il 100% entro 4 secondi; per l’azzeramento scambio, l’azzeramento della potenza deve avvenire entro Ts ≤ 180 ms. La verifica dell’integrazione EMS/BMS/PCS non può essere soltanto funzionale: deve includere il rispetto dei tempi di attuazione, il cablaggio diretto dei comandi, l’assenza di temporizzazioni o apparecchiature interposte non ammesse e la capacità dell’impianto di mantenere lo stato richiesto per tutta la durata dell’emergenza.
Certificazione e sigillatura La certificazione si estende dalla catena di comando alla catena di acquisizione e comando, includendo apparati di comunicazione e componenti intermedi. La progettazione deve rendere sigillabili, verificabili e tracciabili dispositivi, morsettiere, relè, convertitori, router e componenti TLC.
Cybersecurity Il capitolo cyber diventa organico: asset, terze parti, eventi, protezione malware, isolamento, autenticazione, firewall, patching, logging e audit. La difesa elettrica e la cyber-resilience diventano parte dello stesso dominio operativo.

L’Allegato A.69 è quindi il punto in cui l’evoluzione Terna diventa più evidente dal punto di vista funzionale. L’impianto non deve soltanto farsi vedere da Terna. Deve essere in grado di partecipare a una logica di difesa distribuita, con canali resilienti, comandi deterministici, misure affidabili, BESS integrato e capacità di dimostrare che la catena rimane conforme durante l’esercizio.

Allegato A.52: l’UPDM come componente cyber-fisico critico

L’Allegato A.52 è la specifica funzionale e di comunicazione dell’UPDM. La revisione 2026 aggiorna un documento nato in un contesto tecnologico molto diverso, nel quale l’UPDM era descritto soprattutto come apparato periferico dedicato a I/O, logiche, diagnostica e protocollo IEC 60870-5-104 multicast per difesa e monitoraggio. La nuova impostazione mantiene la funzione originaria, ma la colloca dentro un mondo fatto di doppie interfacce Ethernet, alta affidabilità, IEC 61850, segregazione, identity management, secure boot, logging, patching, supply chain e requisiti cyber che richiamano NIS2, linee guida ACN e IEC 62443.

Il cambiamento più forte è che l’UPDM non è più soltanto un apparato di elettro-automazione. Diventa un componente cyber-fisico critico. Deve eseguire comandi rapidi e deterministici, ma deve anche resistere a congestioni multicast, gestire due interfacce, filtrare connessioni TCP autorizzate, mantenere log, proteggere firmware e configurazioni, usare utenze individuali e supportare un ciclo di vita sicuro.

Un altro elemento rilevante è la distinzione fra UPDM standard e UPDM semplificata per impianti fino a 6 MW. Questa distinzione introduce un principio di proporzionalità tecnica, ma non elimina il vincolo funzionale: anche la soluzione semplificata deve consentire la corretta attuazione dei comandi di teledistacco e limitazione previsti dall’Allegato A.69.

Ambito sostanziale Differenza sostanziale Impatto su disegno e conduzione impianto
Adeguamento UPDM esistenti La revisione si applica anche alle UPDM già installate, imponendo adeguamenti entro 12 mesi su seconda Ethernet, cybersecurity, capacità UDP, whitelist TCP e matrice evento/azione. Serve censire il parco UPDM, verificare firmware, hardware, doppia Ethernet, prestazioni protocollo e capability cyber.
UPDM semplificata ≤6 MW È ammessa una UPDM semplificata per impianti con potenza efficiente netta minore o uguale a 6 MW. Per piccoli impianti la BoM può essere meno onerosa, ma va dimostrata la corretta attuazione dei comandi A.69.
Modulazione Lo scopo dell’UPDM include esplicitamente la modulazione oltre a distacco automatico, telescatto e monitoraggio. L’apparato va valutato anche per comandi di regolazione o limitazione, non solo per apertura/intervento.
Doppia Ethernet Sono richieste due interfacce Ethernet indipendenti verso la rete Terna, con architettura a due CPU o singola CPU a doppia interfaccia. L’UPDM deve gestire flussi doppi e comandi ricevuti da entrambe le interfacce senza duplicazioni o rallentamenti.
Prestazioni UDP/TCP Ogni interfaccia deve gestire almeno 200 messaggi UDP/s; l’UPDM deve accettare connessioni TCP unicast solo da una lista configurabile di almeno 10 centri remoti Terna autorizzati, identificati tramite indirizzi IP comunicati da Terna. I test devono verificare carico multicast/UDP, filtro IP dei centri autorizzati e comportamento sotto traffico anomalo.
Multicast storm La singola CPU con due interfacce deve gestire congestioni tipo multicast storm senza degrado. In procurement va richiesta evidenza tecnica di resilienza a scenari di rete degradati.
Bus di campo Il bus di campo deve usare IEC 61850; Modbus è ammesso solo per UPDM esistenti e solo per telemisure. Nuove integrazioni verso IED, moduli remoti, protezioni o sistemi ausiliari devono essere progettate in IEC 61850.
Segregazione La rete del bus di campo UPDM deve essere isolata dalla restante rete dati d’impianto e segregata dalla rete Terna. Nei diagrammi devono comparire zone separate per rete Terna, bus di campo UPDM e LAN OT generale.
Sincronizzazione Sono ammessi GPS o PTPv2/1588v2; nell’ambito della sincronizzazione tramite GPS o PTPv2/1588v2, l’apparato deve garantire un errore massimo del clock interno pari a 1 ms; in assenza di sincronizzazione esterna resta tollerato un errore massimo di 1 s ogni 24 h. L’impianto deve avere una strategia di time synchronization coerente, inclusi apparati di rete idonei se si usa PTP.
Configurazione e rollback La configurazione richiede autenticazione, ruoli, CRC-16 inviato al centro Terna e ripristino della configurazione precedente in caso di errore. La configurazione UPDM diventa un oggetto governato, versionato e verificabile, non un setting locale informale.
Cybersecurity embedded Sono richiesti secure development lifecycle, patch, gestione vulnerabilità, conformità NIS2, IEC 62443, linee guida ACN e tracciabilità supply chain. La scelta dell’UPDM deve includere evidenze cyber di prodotto, supporto vendor e ciclo di vita della sicurezza.
Identità e accessi Sono richieste utenze individuali, RADIUS, RBAC, least privilege, limitazione degli account generici e blocco dopo tentativi falliti. La manutenzione non può basarsi su password condivise o account di fabbrica; serve identity governance.
Secure boot e firmware Il firmware deve essere protetto con secure boot, firma digitale e verifica dell’integrità dei pacchetti di aggiornamento. Gli apparati legacy privi di catena di trust firmware diventano difficilmente compatibili con la nuova baseline.
Logging Sono richiesti log di sicurezza, retention minima di sei mesi, protezione anti-manomissione e tracciamento di attività utente/amministratore. Il commissioning deve verificare anche audit trail, esportabilità e conservazione dei log, non solo I/O e protocollo.
Comandi armati L’UPDM deve prevedere la predisposizione, o armamento, di azioni di controllo da attivare alla ricezione di specifici messaggi di scatto; tutti i comandi armati sul medesimo messaggio devono essere attuati contemporaneamente, senza effettuare la supervisione prevista per i comandi ordinari. L’apparato deve inoltre rispettare il tempo di attuazione Ta tra ricezione del messaggio di scatto e chiusura dei contatti dei relè di output: Ta < 10 ms per apparati A+ e Ta < 20 ms per apparati A, secondo certificazione emessa da Istituti o Laboratori Accreditati. La qualifica dell’UPDM non può limitarsi alla compatibilità IEC 60870-5-104 o alla corretta gestione della matrice di armamento: deve includere la classe prestazionale dell’apparato, la verifica certificata dei tempi Ta e l’assenza di logiche locali, interlock o supervisioni che ritardino l’attuazione simultanea dei comandi armati.
Matrice evento/azione La matrice dinamica passa ad almeno 100 eventi per azione di controllo e per interfaccia. Va verificata la scalabilità firmware/configurazione dell’UPDM rispetto a impianti più complessi.

La conseguenza pratica è che l’UPDM diventa il punto in cui la disciplina elettrica, la disciplina OT e la disciplina cyber si incontrano. In un impianto moderno, specialmente se connesso a 36 kV o comprendente accumulo, la scelta dell’UPDM non può essere demandata alla sola compatibilità storica con IEC 104. Deve essere trattata come una scelta architetturale: interfacce, protocolli di campo, tempi, logiche, accessi, firmware, logging, supply chain, manutenzione e integrazione con A.69 devono essere verificati già in fase di selezione tecnica e approvvigionamento dell’apparato, e poi mantenuti durante l’esercizio.

La matrice comune: controllo, difesa, monitoraggio e cybersecurity

I tre allegati possono essere letti come tre prospettive sulla stessa catena tecnica:

  • L’Allegato A.13 guarda la catena dal lato del sistema di controllo: connessione, monitoraggio, telecomunicazioni, boundary, provider, localizzazione dell’infrastruttura e cybersecurity operativa.

  • L’Allegato A.69 guarda la catena dal lato del sistema di difesa: distacco, modulazione, accumulo, UPDM, tempi di attuazione, monitoraggio locale, retention dei flussi e continuità della funzione.

  • L’Allegato A.52 guarda la catena dal lato dell’apparato critico: UPDM, doppia Ethernet, IEC 61850, segregazione, autenticazione, logging, secure boot, firmware, patching e gestione vulnerabilità.

La conseguenza è che nessuno dei tre allegati può essere soddisfatto in modo robusto se viene trattato isolatamente. Il router Terna, l’UPDM, la RTU, il controllore centrale di impianto, lo SCADA, l’EMS/BMS/PCS, le protezioni, i log, gli accessi remoti e le procedure O&M devono essere progettati come parti di una catena unica. La conformità nasce dalla coerenza della catena, non dalla presenza nominale dei singoli componenti.

Il nuovo perimetro Terna dentro la traiettoria regolatoria europea

Gli aggiornamenti degli Allegati A.13, A.69 e A.52 vanno letti dentro una traiettoria regolatoria più ampia: l’Europa sta progressivamente trasformando la cybersecurity da presidio tecnico-specialistico a requisito ordinario di continuità operativa, governance industriale e responsabilità degli organi di gestione. La logica non è più soltanto proteggere i sistemi informativi, ma garantire che i soggetti economici rilevanti, energia, trasporti, finanza, sanità, infrastrutture digitali, pubblica amministrazione, fornitori ICT e filiere critiche, siano in grado di prevenire, assorbire, notificare e recuperare da eventi cyber che possono compromettere servizi essenziali o funzioni di sistema.

La NIS2 rappresenta il riferimento generale di questa evoluzione: la Commissione europea la descrive come un quadro giuridico unitario per la cybersicurezza in 18 settori critici, mentre il testo della direttiva stabilisce una baseline comune di misure di gestione del rischio e obblighi di notifica per i settori inclusi nel suo campo di applicazione. In Italia, la direttiva è stata recepita con il D.Lgs. 4 settembre 2024, n. 138, e l’ACN è l’autorità competente NIS e punto di contatto unico.2 Questo significa che la sicurezza non è più demandata alla buona pratica tecnica del singolo operatore, ma diventa un obbligo organizzativo verificabile.3

Accanto alla NIS2 si collocano regimi più verticali o complementari. DORA porta la stessa logica nel settore finanziario, con un quadro europeo per la resilienza operativa digitale, la gestione del rischio ICT, il testing, l’incident reporting e il controllo dei fornitori ICT critici.4 Il Cyber Resilience Act sposta invece il vincolo verso il prodotto: prodotti con elementi digitali, inclusi hardware e software, devono incorporare requisiti essenziali di cybersicurezza lungo progettazione, sviluppo, produzione, manutenzione e gestione delle vulnerabilità.5 In Italia, il Perimetro di Sicurezza Nazionale Cibernetica aveva già introdotto una disciplina specifica per beni ICT rilevanti per funzioni e servizi essenziali, con obblighi di sicurezza e notifica degli incidenti al CSIRT.6

Questa convergenza normativa ha una ragione economica e tecnica precisa: il rischio cyber si è industrializzato. ENISA, nel Threat Landscape 2025, analizza le minacce e i trend più rilevanti per l’ecosistema cyber europeo su 4.875 incidenti osservati tra luglio 2024 e giugno 2025; nei propri esercizi di foresight include inoltre la compromissione della supply chain software, l’errore umano e lo sfruttamento di sistemi legacy negli ecosistemi cyber-fisici, i fornitori ICT transfrontalieri come single point of failure e l’abuso dell’AI tra le minacce emergenti al 2030.7 Europol, nell’IOCTA 2026, descrive a sua volta AI, automazione, proxy ed ecosistemi criminali come fattori che aumentano velocità, efficienza e portata delle attività cybercriminali.8

Il punto manageriale è che cambia l’economia dell’attacco. In passato molti operatori industriali o infrastrutturali minori erano sotto la soglia di interesse di attori sofisticati: troppo piccoli, troppo locali, troppo costosi da studiare. Con crime-as-a-service, automazione, phishing generativo, deepfake, scanning continuo, riuso di credenziali, exploitation di sistemi non aggiornati e attacchi alla supply chain, il costo unitario di targeting si abbassa. Diventano appetibili anche soggetti intermedi: manutentori, O&M contractor, piccoli produttori connessi, fornitori di apparati, società di ingegneria, operatori locali, operatori con portafogli distribuiti, e soggetti che non sono grandi in termini societari ma sono rilevanti perché connessi a un’infrastruttura critica.

In questo scenario gli attori di minaccia non sono solo esterni. Il modello corretto include attori criminali, hacktivisti, gruppi con legami statuali, fornitori compromessi, account amministrativi abusati, operatori interni negligenti, errori di configurazione, sistemi legacy non aggiornati e dipendenze software o hardware non governate. ENISA colloca infatti tra le minacce emergenti al 2030 la compromissione della supply chain software, l’errore umano e lo sfruttamento di sistemi legacy in ecosistemi cyber-fisici, oltre alla dipendenza da fornitori ICT transfrontalieri come single point of failure.9

Letti in questa prospettiva, gli Allegati Terna non sono un’anomalia settoriale, ma una traduzione elettrica e OT della stessa direzione regolatoria europea. L’Allegato A.13 porta nel sistema di controllo requisiti su rete, localizzazione, provider, monitoraggio, collaudo, terze parti e cybersecurity. L’Allegato A.69 fa lo stesso per il sistema di difesa, aggiungendo la dimensione funzionale del distacco, della modulazione, dell’accumulo e della continuità della catena UPDM. L’Allegato A.52 entra ancora più a monte, trasformando l’UPDM in un componente cyber-fisico: doppia interfaccia Ethernet, segregazione, IEC 61850, secure boot, firma del firmware, autenticazione individuale, RADIUS, RBAC, logging, retention e gestione delle vulnerabilità.

La conseguenza per un Titolare di impianto è netta: la conformità Terna non può essere gestita come una checklist documentale separata dal progetto. Deve diventare parte del modello operativo dell’impianto. Questo modello deve coprire architettura di rete, boundary fisici, fibra ottica, router, UPDM, RTU, EMS/BMS/PCS, asset inventory, gestione identità, logging, patching, backup, incident response, contratti O&M, obblighi H24, segregazione delle terze parti, auditabilità e conservazione delle evidenze.

In sintesi, il trend europeo dice che la resilienza non è più una qualità opzionale dei grandi operatori critici. Sta diventando una proprietà richiesta di qualunque nodo economicamente o tecnicamente rilevante dentro una filiera essenziale. Gli aggiornamenti Terna applicano questa logica alla rete elettrica: se un impianto può influire sul controllo, sulla difesa, sull’osservabilità o sulla stabilità del sistema, allora deve essere progettato e condotto come parte di un ecosistema regolato, interconnesso e attaccabile a scala.

Che cosa deve decidere il Titolare

Il punto più delicato non è tecnico, ma di responsabilità. Molti requisiti possono essere implementati dal BoP o da fornitori specialistici, ma non possono essere lasciati alla loro discrezione. Il Titolare deve decidere quale modello di governo adottare, perché è il soggetto che rimane responsabile verso Terna, verso il regolatore e verso la continuità operativa dell’impianto.

Decisione Domanda pratica Rischio se non governata
Ownership IT/OT Chi approva architettura, accessi, modifiche e configurazioni critiche? Il BoP o i vendor decidono implicitamente l’architettura di sicurezza.
Boundary Terna Qual è il perimetro fisico e logico della catena verso Terna? Router, RTU, UPDM e apparati di campo vengono trattati come normale LAN OT.
Accessi remoti Chi può accedere, da dove, quando e con quale tracciamento? VPN permanenti, account condivisi e accessi vendor non verificabili.
Logging e monitoraggio Quali eventi vengono raccolti e chi li guarda? Gli incidenti vengono scoperti solo quando diventano guasti funzionali.
Change management Chi autorizza modifiche a firewall, UPDM, RTU, SCADA, EMS/BMS/PCS e protezioni? La configurazione reale diverge dall’as-built e dalle evidenze di collaudo.
Fornitori Quali obblighi cyber, documentali e operativi sono nei contratti? La sicurezza resta una buona pratica non esigibile.
Evidenze Dove sono conservati asset inventory, flussi, setting, firmware, prove e rapporti? La conformità non è dimostrabile durante audit, guasti o contestazioni.

Conclusione

Gli aggiornamenti agli Allegati A.13, A.69 e A.52 seguono una logica comune. Terna sta spostando il baricentro del Codice di Rete da un insieme di prescrizioni per collegare apparati e scambiare dati a un modello di interoperabilità operativa, nel quale l’impianto deve essere controllabile, difendibile, monitorabile, collaudabile e cyber-resiliente.

Per chi progetta o governa impianti BESS, fotovoltaici, eolici, ibridi o comunque connessi alla RTN, la conseguenza è diretta. Il perimetro Terna deve essere portato dentro il progetto fin dalle prime fasi: layout, cavidotti, fibra ottica, router con funzione di switching integrata, RTU, UPDM, EMS/BMS, PCS, interfacce IEC 61850, piani IP, logiche di difesa, monitoraggio, cybersecurity, O&M e test di commissioning devono essere pensati come un unico sistema.

In termini operativi, la domanda corretta non è più: l’impianto ha un canale verso Terna?. La domanda corretta diventa: l’impianto possiede una catena end-to-end, fisica, logica, funzionale e cyber, capace di sostenere controllo, difesa e monitoraggio secondo i requisiti Terna per tutto il suo ciclo di vita?.

La stessa direzione è confermata dagli Allegati A.17, A.68 e A.18. Anche dove non compare un capitolo cyber organico, i requisiti su monitoraggio dei servizi, modulazione, limitazione, UPDM, teleinformazioni, prove, setting, firmware, modelli e verifiche di conformità estendono il perimetro IT/OT della compliance Terna. Il sistema di controllo dell’impianto diventa quindi un oggetto tecnico da governare e dimostrare, non una scatola nera affidata al fornitore.

Appendice — Impatti IT/OT degli altri allegati Terna aggiornati

Gli Allegati A.13, A.52 e A.69 contengono il nucleo più esplicito della nuova postura Terna su connessione dati, UPDM, sistema di difesa, telecomunicazioni e cybersecurity. Gli altri allegati pubblicati nello stesso ciclo di aggiornamento non sono però neutri rispetto all’architettura IT/OT dell’impianto.

Gli Allegati A.17, A.68 e A.18 non introducono, per quanto emerge dai testi esaminati, un capitolo cybersecurity organico paragonabile a quello presente negli Allegati A.13, A.52 e A.69. Tuttavia, incidono comunque sull’architettura IT/OT dell’impianto, perché non si limitano a prescrivere prestazioni elettriche astratte: richiedono che tali prestazioni siano controllabili, misurabili, verificabili e documentabili.

In particolare, introducono requisiti funzionali, documentali e di verifica che coinvolgono direttamente i sistemi di controllo di impianto, inclusi i PPC o controllori centrali, gli apparati UPDM, le protezioni, le telemisure, i telesegnali, i file di setting, le versioni firmware, i modelli dinamici, le prove di conformità e la gestione del ciclo di vita dell’impianto.

La lettura corretta è quindi questa: A.17 e A.68 portano i requisiti Terna dentro il comportamento operativo degli impianti eolici e fotovoltaici; A.18 rende quel comportamento verificabile, misurabile e documentabile nel tempo.

Allegato A.17 — Centrali eoliche

L’Allegato A.17 disciplina le condizioni generali di connessione delle centrali eoliche alle reti AAT e AT, con riferimento ai sistemi di protezione, regolazione e controllo. La revisione 2026 dichiara espressamente l’aggiornamento dei requisiti tecnici connessi al monitoraggio dei servizi e alla modulazione o distacco della generazione.10

Questo elemento è rilevante perché colloca l’allegato dentro il dominio IT/OT. Non si tratta solo di requisiti elettrici statici, ma di funzioni di controllo, attuazione, monitoraggio, scambio dati e verificabilità. La centrale eolica deve essere in grado di regolare, limitare, distaccare, comunicare stati e misure, inviare dati di controllo e dimostrare il proprio comportamento durante l’esercizio e durante eventi di rete.

L’allegato distingue le connessioni di Tipo 1, relative a livelli di tensione pari o superiori a 110 kV, e le connessioni di Tipo 2, relative alle sezioni 36 kV di stazioni elettriche del Gestore.11 Questa distinzione conferma che il tema 36 kV non è confinato agli Allegati A.13 e A.69, ma entra anche nei requisiti specifici delle centrali eoliche. Il disegno dei sistemi di protezione, regolazione e controllo deve quindi essere coerente con il boundary Terna, con le modalità di connessione, con lo scambio dati e con gli apparati di difesa e monitoraggio previsti dagli allegati trasversali.

Per gli impianti eolici esistenti, A.17 introduce obblighi con impatto diretto sulla catena OT. In particolare, per impianti con potenza efficiente netta maggiore o uguale a 1 MW, è prevista l’installazione dell’UPDM conforme all’Allegato A.52 e la connessione dello stesso al Sistema di Difesa del Gestore secondo le modalità dell’Allegato A.69. Inoltre, ove il sistema di controllo dell’impianto lo consenta, deve essere attivata la funzionalità di limitazione tramite segnale da UPDM.12

L’UPDM non può quindi essere considerato un apparato periferico isolato. Deve essere integrato con il sistema di controllo della centrale eolica, con le logiche di limitazione, con i segnali di stato, con le misure, con gli eventuali comandi di distacco e con le procedure di verifica. Il rinnovo dei sistemi di controllo di impianto è inoltre indicato fra gli esempi di modifica significativa; questo conferma che il sistema di controllo non è un accessorio del progetto, ma una parte strutturale della conformità tecnica dell’impianto.

A.17 definisce anche un ordine di priorità fra azioni di protezione e azioni di controllo. Tale priorità riguarda, fra le altre cose, le protezioni di impianto, le protezioni di rete, i sistemi di difesa, il teledistacco, il supporto alla tensione durante i guasti, le funzioni di regolazione della frequenza, la limitazione della produzione, i piani di produzione e la regolazione della potenza reattiva.13

Questa priorità non è solo una regola elettrica, ma una regola di architettura del controllo. In un impianto eolico le funzioni richiamate dall’allegato possono essere distribuite fra aerogeneratori, controllore centrale di impianto, SCADA, sistemi di protezione, RTU e UPDM. Il BoP deve quindi dimostrare che, quando più funzioni possono agire contemporaneamente sulla produzione o sullo stato dell’impianto, esiste una gerarchia deterministica di intervento.

Il punto critico è evitare che protezioni, comandi di teledistacco, limitazioni di produzione, regolazioni di frequenza, regolazioni di tensione e logiche locali del controllore di centrale si comportino come funzioni indipendenti e potenzialmente conflittuali. Deve essere chiaro quale funzione prevale, quale viene sospesa, quale viene limitata, quale viene ripristinata e con quali tempi.

In termini IT/OT, questo richiede gestione controllata delle configurazioni, test integrati fra apparati, versionamento delle logiche di controllo, tracciabilità dei setting, registrazione degli eventi e documentazione as-built coerente con l’impianto realmente messo in esercizio.

L’allegato prevede inoltre monitoraggio e scambio dati con il sistema di controllo di Terna. La centrale deve essere integrata nei processi di controllo in tempo reale e in tempo differito tramite telemisure, telesegnali, sistemi di monitoraggio, analisi guasti e verifica del comportamento della centrale durante perturbazioni di rete.14

Area Impatto IT/OT per A.17
UPDM Installazione, connessione ad A.69, conformità ad A.52, integrazione con il sistema di controllo di impianto.
Sistema di controllo eolico Supporto a limitazione, teledistacco, regolazione, monitoraggio, priorità fra funzioni e interazione con UPDM.
Connessione 36 kV Coordinamento con il boundary fisico e logico previsto dagli allegati di connessione Terna.
Monitoraggio Telemisure, telesegnali, analisi guasti e verifica del comportamento durante perturbazioni diventano requisiti di esercizio.
Documentazione OT Setting, firmware, logiche di controllo, prove, modelli e as-built devono essere mantenuti sotto controllo.
Fornitori Vendor aerogeneratori, controllore centrale di impianto, SCADA, BoP e O&M devono essere governati contrattualmente e tecnicamente.

La conseguenza pratica è che un impianto eolico soggetto ad A.17 deve essere progettato come una catena OT completa: aerogeneratori, controllore centrale di impianto, protezioni, SCADA, RTU, UPDM, apparati di comunicazione e interfacce verso Terna devono essere coerenti, testabili e mantenuti nel tempo.

Allegato A.68 — Centrali fotovoltaiche

L’Allegato A.68 svolge per le centrali fotovoltaiche una funzione analoga a quella svolta dall’Allegato A.17 per le centrali eoliche. La revisione 2026 dichiara l’aggiornamento dei requisiti tecnici connessi al monitoraggio dei servizi e alla modulazione o distacco della generazione.15

Anche in questo caso, l’oggetto non è solo la connessione elettrica dell’impianto fotovoltaico. L’allegato disciplina prestazioni, protezioni, regolazione, controllo, visibilità sul sistema di controllo del Gestore, monitoraggio della conformità e scambio dati. Il controllore centrale di impianto fotovoltaico, gli inverter, le protezioni, le misure e l’interfaccia con UPDM diventano quindi elementi della catena IT/OT rilevante per Terna.

Come A.17, anche A.68 distingue connessioni di Tipo 1 e connessioni di Tipo 2, includendo le sezioni 36 kV di stazioni elettriche del Gestore.16 Questo rafforza il principio secondo cui il 36 kV è diventato un perimetro tecnico esplicito. La progettazione fotovoltaica deve quindi considerare il punto di connessione, il dominio Terna, gli apparati di protezione e controllo, i flussi informativi, le limitazioni e il monitoraggio come parti di uno stesso sistema.

L’allegato precisa inoltre che, per impianti fotovoltaici con sistemi di accumulo, A.68 tratta i requisiti relativi alla centrale fotovoltaica, mentre i requisiti relativi ai Sistemi di Accumulo sono rinviati all’Allegato A.79.17 Questo è rilevante per i progetti PV+BESS: il fotovoltaico resta disciplinato da A.68, lo storage richiede il coordinamento con il proprio allegato specifico e con gli allegati trasversali A.13, A.52 e A.69.

Per gli impianti fotovoltaici esistenti, A.68 prevede l’obbligo di installazione dell’UPDM per impianti con potenza efficiente netta maggiore o uguale a 1 MW, con conformità all’Allegato A.52 e connessione al Sistema di Difesa secondo l’Allegato A.69. Inoltre, ove il sistema di controllo d’impianto lo consenta, deve essere attivata la funzionalità di limitazione tramite segnale da UPDM.18

Questo produce un impatto concreto sul controllore centrale di impianto e sugli inverter. La limitazione della produzione non è più solo una funzione locale, commerciale o di dispacciamento. Diventa una funzione integrata nella catena di controllo e difesa: il sistema deve poter ricevere segnali, tradurli in limiti di potenza, attuarli nei tempi richiesti, monitorarne l’effetto e fornire evidenze coerenti verso Terna.

A.68 definisce anche una priorità fra azioni di protezione e azioni di controllo, includendo protezione dell’impianto, protezione della rete, teledistacco, supporto alla tensione durante i guasti, regolazione FSM/LFSM, limitazione della produzione, regolazione secondaria o ILF, piani di produzione e regolazione della potenza reattiva.19

Dal punto di vista IT/OT, il punto critico è la coerenza fra inverter, controllore centrale di impianto, EMS, SCADA, protezioni, UPDM e RTU. Se il sistema di controllo fotovoltaico resta una scatola nera del vendor, il Titolare rischia di non poter dimostrare il rispetto dei requisiti, né diagnosticare correttamente anomalie, ritardi, mancata attuazione dei comandi o incongruenze fra setpoint, stato e misura.

L’Allegato A.68 richiede inoltre monitoraggio e scambio dati con il sistema di controllo di Terna. In Appendice C sono elencate informazioni per il telecontrollo in tempo reale: telemisure, telesegnali, setpoint e comandi relativi, fra l’altro, a potenza attiva, potenza reattiva, tensioni, capability reattiva, rilettura dei setpoint, stati di regolazione, anomalie di setpoint, anomalie di misura e comandi di regolazione.20

Questa parte ha un impatto IT/OT diretto. Non basta avere il dato nel sistema locale: il dato deve essere corretto, coerente, indirizzato, aggiornato, disponibile e interpretabile da Terna. La qualità della telemetria diventa parte della compliance. Devono quindi essere governati mapping, naming, sorgenti dati, setpoint, stati, anomalie, versioning delle configurazioni e sincronizzazione temporale.

Area Impatto IT/OT per A.68
Controllore centrale di impianto / PPC Supporto a regolazione, limitazione, setpoint, stati, misure e interazione con UPDM.
Inverter Attuazione di comandi coerenti con limiti, priorità e logiche di controllo definite dall’allegato.
UPDM Componente trasversale anche per impianti fotovoltaici esistenti ≥1 MW.
Telecontrollo Telemisure, telesegnali, setpoint e comandi devono essere disponibili in tempo reale e coerenti con Terna.
PV+BESS Il fotovoltaico resta disciplinato da A.68; lo storage richiede coordinamento con A.79 e con A.13, A.52 e A.69.
Modelli e configurazioni Setpoint, stati, capability, regolazioni e anomalie devono essere documentati, verificabili e mantenuti.

La conseguenza è che l’architettura fotovoltaica non può essere progettata come una semplice catena locale inverter → PPC → SCADA, chiusa dentro il perimetro del fornitore. Deve essere progettata come un sistema OT integrato, nel quale inverter, PPC o controllore centrale di impianto, SCADA, UPDM, RTU e interfacce verso Terna hanno ruoli distinti ma coordinati: gli inverter attuano la regolazione elettrica, il PPC coordina il comportamento aggregato della centrale, lo SCADA rende osservabile e gestibile l’impianto, l’UPDM abilita le funzioni di difesa e limitazione, la RTU espone telemisure e telesegnali, e l’interfaccia Terna rende tali funzioni verificabili e governabili. Questo richiede regole di priorità, mapping dei dati, logging, accessi controllati, gestione delle versioni e test di funzionamento integrato.

Allegato A.18 — Verifica della conformità degli impianti di produzione

L’Allegato A.18 ha natura diversa rispetto ad A.17 e A.68. Non definisce i requisiti funzionali specifici di una tecnologia di generazione, ma disciplina la verifica della conformità degli impianti di produzione alle prescrizioni tecniche del Gestore. La revisione 2026 dichiara una revisione del campo di applicazione e precisazioni sulle modalità di gestione delle prove in autonomia.21

Dal punto di vista IT/OT, A.18 è rilevante perché trasforma i requisiti tecnici in verifiche, evidenze, rapporti di prova, controlli periodici e documentazione. Il documento distingue verifiche di conformità con ispezioni strumentali, verifiche su specifiche regolazioni e caratteristiche tecniche, monitoraggio continuo strumentale, prove in autonomia e ispezioni visive/documentali.22

Questo produce un effetto pratico: la compliance non può essere solo dichiarata. Deve essere misurabile. L’impianto deve essere predisposto per registrare grandezze, acquisire dati, installare strumentazione esterna, simulare condizioni di rete, raccogliere evidenze, processare risultati, produrre rapporti e dimostrare che regolazioni, protezioni e sistemi di controllo si comportano come richiesto.

A.18 entra direttamente nei sistemi di controllo e regolazione. Per esempio, per i PPM le prove possono riguardare sia il sistema di controllo complessivo dell’impianto sia il sistema di parallelo di un singolo modulo di generazione, simulando condizioni della rete e verificando che parallelo e sincronizzazione avvengano solo entro i valori previsti di tensione e frequenza.23

Questo significa che PPC o controllore centrale di impianto, SCADA, sistemi di parallelo, logiche di protezione, misure di frequenza e tensione, sistemi di acquisizione dati e registrazioni di prova devono essere progettati per supportare test, analisi e ricostruzione degli eventi. Anche qui il requisito non è cybersecurity in senso stretto, ma genera esigenze tipicamente IT/OT: integrità dei dati, tracciabilità della configurazione, gestione dei setting, versionamento firmware, controllo delle modifiche e conservazione dei rapporti di prova.

A.18 richiama inoltre verifiche su apparati UPDM e UVRP, sui rapporti degli ultimi controlli, sul piano dei controlli periodici e sulle funzionalità. Richiede anche verifiche su protezioni, tarature, rapporti di prova, piano delle tarature periodiche, conformità metrologica della strumentazione e registrazioni oscilloperturbografiche degli eventi di parallelo.24

Questa parte è particolarmente importante per il Titolare. Se il BoP consegna l’impianto ma non consegna configurazioni, tarature, report, firmware, file di setting, modelli, registrazioni e procedure di prova, il Titolare non è in grado di sostenere nel tempo la conformità richiesta da A.18. La documentazione non è quindi un allegato amministrativo: è un asset operativo.

A.18 rileva anche per PPM e BESS di taglia rilevante, con verifiche sotto sorveglianza e responsabilità di un organismo certificatore accreditato secondo CEI UNI EN ISO/IEC 17065, emissione di certificati, rapporti di prova, possibilità di prove in autonomia in determinate condizioni e autocertificazioni verso Terna.25

Questo implica una governance strutturata delle evidenze. Il Titolare deve sapere quali prove sono state effettuate, con quale configurazione, con quali firmware, con quali setting, con quale strumentazione, con quali risultati e con quali eventuali eccezioni. Se nel frattempo cambiano controllore centrale di impianto, inverter, aerogeneratori, firmware, protezioni, UPDM, RTU, router, SCADA o logiche di controllo, deve essere chiaro se la precedente evidenza è ancora valida o se serve una nuova verifica.

Area Impatto IT/OT per A.18
Verificabilità Le funzioni OT devono essere testabili, registrabili e documentabili, non solo operative.
Sistemi di controllo Controllore centrale di impianto, SCADA, parallelo, regolatori, protezioni e UPDM devono supportare prove e raccolta dati.
Data integrity I dati di prova, le registrazioni e i report devono essere conservati e riconciliabili con la configurazione dell’impianto.
Configuration management Firmware, setting, tarature, modelli e logiche devono essere tracciati nel tempo.
UPDM / UVRP Non basta l’installazione: servono prove, controlli periodici, rapporti e verifiche funzionali.
Organismi certificatori Per alcuni casi, le verifiche devono essere presidiate e certificate secondo regole definite.
Ciclo di vita Modifiche significative, retrofit e aggiornamenti devono essere valutati anche rispetto alla validità delle prove esistenti.

L’Allegato A.18 completa quindi il quadro. A.17 e A.68 definiscono come eolico e fotovoltaico devono comportarsi; A.13, A.52 e A.69 definiscono come devono essere connessi, monitorati e integrati nei sistemi Terna; A.18 stabilisce come questa conformità deve essere verificata e mantenuta con evidenze.

Implicazione comune per Titolare e BoP

La conseguenza congiunta degli Allegati A.17, A.68 e A.18 è che il Titolare non può più trattare l’IT/OT di impianto come una responsabilità implicita del BoP o del vendor tecnologico. Anche dove non compare un capitolo cybersecurity esplicito, i requisiti Terna obbligano a governare sistemi, dati, comunicazioni, setting, firmware, prove e documentazione.

Per il BoP, questo significa che la fornitura deve includere non solo l’impianto funzionante, ma anche una catena documentale e tecnica completa: architettura di rete, matrice dei flussi, integrazione UPDM, mapping teleinformazioni, logiche di limitazione, priorità di controllo, file di setting, versioni firmware, configurazioni esportate, rapporti di prova, modelli, as-built e procedure di manutenzione.

Per il Titolare, significa che devono essere presidiati almeno cinque domini.

Dominio Presidio richiesto
Architettura OT Separazione fra campo, controllo locale, dominio Terna, servizi OT, DMZ, IT/SOC e terze parti.
Configurazioni Versionamento di firmware, setting, tarature, modelli, logiche di controllo e configurazioni di rete.
Teleinformazioni Mapping e qualità di telemisure, telesegnali, setpoint, comandi, anomalie e stati di regolazione.
Prove e verifiche Rapporti di prova, certificazioni, controlli periodici, prove in autonomia, evidenze di funzionamento.
Fornitori Obblighi contrattuali verso BoP, O&M, vendor inverter/aerogeneratori, controllore centrale di impianto, EMS/BMS, telco e manutentori.

La conclusione è che gli allegati non esplicitamente cyber estendono comunque il perimetro IT/OT della compliance Terna. Essi trasformano il sistema di controllo dell’impianto in un oggetto verificabile e governato: ciò che prima poteva essere lasciato alla logica interna del fornitore diventa parte di una catena osservabile da Terna, integrata con UPDM e soggetta a prove, monitoraggio e responsabilità documentale.

Appendice — Architettura minima per soddisfare i requisiti Terna e difendere l’investimento

Gli aggiornamenti agli Allegati A.13, A.69 e A.52 non richiedono necessariamente di trasformare ogni impianto in una grande infrastruttura SOC industriale. Richiedono però una cosa precisa: che la connessione verso Terna, gli apparati RTU/UPDM, le reti locali, i fornitori, gli accessi remoti, i log, il monitoraggio e la manutenzione siano progettati come una catena governata, non come un insieme di componenti assemblati dal BoP caso per caso.

Il principio corretto è quello della proporzionalità. Un impianto BESS, fotovoltaico, eolico o ibrido non deve replicare l’architettura cyber di una grande utility multi-sito, ma non può nemmeno avere una rete piatta in cui SCADA, EMS, BMS, router Terna, accessi remoti dei fornitori, telecamere, laptop di manutenzione e sistemi IT ausiliari convivono nello stesso dominio. La misura minima ragionevole è una segmentazione chiara in zone e conduits, con controlli di frontiera, monitoraggio passivo, gestione degli accessi e raccolta dei log.

NIST SP 800-82 Rev. 3 imposta la sicurezza OT tenendo conto delle esigenze specifiche di prestazione, affidabilità e safety degli ambienti operational technology; CISA raccomanda esplicitamente segmentazione e DMZ per proteggere ambienti ICS e ridurre l’esposizione dei sistemi critici.2627

Obiettivo pratico

L’obiettivo non è installare prodotti cyber, ma ottenere quattro risultati verificabili:

  1. Controllo della propagazione: impedire che un problema su IT, accesso remoto, videosorveglianza, rete del fornitore o laptop di manutenzione possa propagarsi verso SCADA, EMS/BMS/PCS, RTU o UPDM.

  2. Controllo dei flussi: consentire solo i flussi strettamente necessari tra zone, con regole esplicite, approvate e documentate.

  3. Osservabilità della catena critica: rendere osservabile la catena critica, almeno attraverso log centralizzati, monitoraggio dei collegamenti, allarmi degli apparati principali e sensori passivi nei punti di confine.

  4. Dimostrabilità della conformità: rendere dimostrabile la conformità, mediante inventario asset, matrice dei flussi, firewall rulebase, piani IP, procedure di accesso remoto, backup, patching, incident response e documentazione as-built.

Questo approccio è coerente con la logica delle zone e dei conduits: una zona raggruppa asset con requisiti di sicurezza simili; un conduit definisce il canale controllato attraverso cui due zone comunicano. ENISA, in una guida architetturale basata anche su IEC 62443, descrive proprio l’assegnazione degli asset a zone coerenti collegate da conduits, in modo che gli asset della stessa zona e i dati trasmessi sullo stesso conduit condividano requisiti di cybersecurity simili.28

Zone minime da prevedere

Per un impianto di taglia ordinaria, il modello minimo dovrebbe distinguere almeno le seguenti zone.

Zona Contenuto tipico Regola pratica
Z0 - Campo e dispositivi elettrici IED, protezioni, contatori, inverter/PCS, moduli I/O, sensori, attuatori, eventuali apparati IEC 61850. Non deve essere raggiungibile direttamente da IT, Internet, accessi remoti o reti di servizio non OT.
Z1 - Controllo locale di impianto SCADA, EMS, BMS supervisory layer, server di controllo, HMI, engineering workstation strettamente OT. È il dominio operativo principale. Deve comunicare solo con campo, servizi OT necessari e apparati Terna secondo flussi autorizzati.
Z2 - Dominio Terna / controllo, monitoraggio e difesa RTU, UPDM, router compatibili con l’architettura Terna, eventuali apparati direttamente richiesti dagli Allegati A.13, A.69 e A.52. Deve essere trattato come dominio dedicato, non come normale VLAN della LAN OT. Flussi e accessi devono essere strettamente limitati.
Z3 - Servizi OT locali Historian locale, server backup OT, server antivirus/patch staging se presente, NTP/PTP/GPS, syslog collector locale, repository configurazioni. Deve supportare l’OT senza diventare ponte incontrollato verso IT.
Z4 - OT DMZ Jump host, bastion host, relay file, proxy aggiornamenti, concentratore log verso IT/SOC, eventuale broker dati verso sistemi enterprise. È la zona cuscinetto tra OT e IT. Nessun accesso diretto IT → OT.
Z5 - IT / corporate / SOC SIEM aziendale, SOC, sistemi documentali, ticketing, asset management enterprise, utenti corporate. Deve ricevere solo dati necessari dalla OT DMZ; non deve amministrare direttamente gli asset OT critici.
Z6 - Accessi terze parti Vendor O&M, BoP, EMS/BMS supplier, telco, manutentori specialistici. Accesso solo tramite VPN controllata, MFA, jump host, approvazione temporanea, logging e session recording ove proporzionato.
Z7 - Servizi ausiliari non OT Videosorveglianza, controllo accessi fisico, Wi-Fi di servizio, building management, rete ospiti, eventuale IT locale non industriale. Deve essere separata dalla rete OT e non deve diventare scorciatoia verso SCADA, EMS, BMS, RTU, UPDM o dominio Terna.

La distinzione fra Z1 e Z2 è fondamentale. La rete Terna non deve essere una sottorete indistinta della LAN OT. Gli apparati richiesti per controllo, monitoraggio e difesa devono essere attestati su un dominio dedicato, con router e configurazioni conformi ai requisiti Terna. Analogamente, la zona di campo non deve essere usata come rete generale per tutti i servizi di impianto.

Conduits minimi e regole di traffico

Ogni comunicazione tra zone deve essere descritta in una matrice dei flussi. La matrice deve indicare almeno sorgente, destinazione, protocollo, porta, direzione, frequenza, owner, motivo funzionale, criticità, regola firewall associata e modalità di monitoraggio.

Conduit Flusso ammesso Controllo minimo
C1 - Campo ↔︎ Controllo locale IEC 61850, Modbus solo dove ammesso, protocolli vendor strettamente necessari, segnali verso SCADA/EMS/BMS. VLAN dedicate, ACL/firewall dove possibile, nessun routing non necessario, documentazione dei protocolli.
C2 - Controllo locale ↔︎ Dominio Terna Flussi verso RTU, UPDM e router secondo A.13, A.69 e A.52. Firewall/ACL dedicati, piano IP approvato, regole whitelisting, nessun traffico generico.
C3 - OT ↔︎ OT DMZ Log, backup, file transfer controllato, dati historian, aggiornamenti approvati. Firewall stateful, deny-by-default, logging delle regole, nessun accesso diretto da IT agli asset OT.
C4 - OT DMZ ↔︎ IT/SOC Esportazione log, eventi, allarmi, dati aggregati, ticketing. Connessioni iniziate dalla DMZ o da componenti controllati, segregazione forte, monitoraggio SIEM.
C5 - Terze parti ↔︎ OT DMZ Accesso manutentivo tramite jump host. VPN con MFA, accesso temporaneo, account nominativi, approvazione del Titolare, logging completo.
C6 - Monitoraggio passivo Copia traffico da TAP/SPAN verso IDS/NDR OT. Sensori passivi, non inline sulla catena di comando critica, nessuna capacità di blocco che possa disturbare l’impianto.
C7 - Servizi ausiliari ↔︎ OT DMZ Solo flussi eccezionali e motivati, ad esempio invio log o eventi da videosorveglianza verso sistemi centralizzati. Nessun accesso da videosorveglianza, Wi-Fi, building management o IT ausiliario verso asset OT critici.

La regola di base deve essere deny by default: ciò che non è esplicitamente richiesto da una funzione elettrica, operativa o di compliance non deve essere permesso. CISA definisce la segmentazione come partizionamento della rete e la segregazione come applicazione di regole per controllare le comunicazioni tra host e servizi; il valore pratico è ridurre il movimento laterale e rendere il traffico malevolo più rilevabile.29

OT DMZ e jump host

La OT DMZ è la zona cuscinetto tra il mondo esterno all’impianto, IT corporate, SOC, fornitori, O&M contractor, telco, vendor EMS/BMS/PCS, BoP e le reti OT interne. La sua funzione non è semplicemente fare passare le connessioni, ma impedire che esistano accessi diretti verso SCADA, EMS, BMS, PCS, RTU, UPDM, router Terna o apparati di campo.

Il principio architetturale è semplice: nessun soggetto esterno alla rete OT deve collegarsi direttamente agli asset OT critici. Ogni accesso deve terminare prima nella OT DMZ, essere autenticato, autorizzato, tracciato e poi, solo se necessario, proseguire verso lo specifico asset interno attraverso un jump host o un bastion host.

In un impianto a costi contenuti non serve necessariamente una piattaforma PAM complessa o un SOC locale dedicato. Serve però almeno un punto tecnico controllato da cui passano tutte le sessioni amministrative e manutentive. Quel punto è il jump host.

Componente Funzione Requisito pratico minimo
OT DMZ Zona di separazione tra IT, terze parti e OT. Deve essere una zona di rete separata, protetta da firewall, senza accesso diretto agli asset OT critici.
VPN gateway Terminazione degli accessi remoti. Deve terminare in DMZ, non direttamente nella LAN OT. Accesso temporaneo, approvato e revocabile.
Jump host / bastion host Punto unico di accesso amministrativo verso gli asset OT. Accesso nominativo, MFA per accessi remoti, logging, sessioni autorizzate, nessuna navigazione libera, nessun account condiviso.
File transfer gateway Scambio controllato di file, patch, configurazioni e log. Deve evitare scambio diretto di file tra laptop/vendor e server OT. I file devono essere controllati prima dell’introduzione in OT.
Log forwarder / syslog relay Raccolta e inoltro log verso SIEM/SOC. Deve esportare i log verso IT/SOC senza aprire accessi amministrativi inversi verso OT.
Patch staging Punto di appoggio per aggiornamenti approvati. Deve separare il download o caricamento delle patch dalla loro applicazione sugli asset OT.

Il jump host deve essere trattato come un asset critico, perché diventa il punto da cui un manutentore autorizzato può raggiungere sistemi sensibili. Per questo non deve essere un normale PC condiviso, né una workstation usata anche per email, navigazione web o attività amministrative generiche. Deve essere un sistema dedicato, hardenizzato, monitorato e soggetto a change management.

Area Requisito minimo
Identità Account nominativi per ogni utente o fornitore; divieto di account condivisi salvo emergenza documentata.
Autenticazione MFA obbligatoria per accessi remoti; password robuste; disabilitazione delle credenziali di default.
Autorizzazione Accesso consentito solo agli asset necessari per quello specifico intervento.
Temporalità Accessi terze parti abilitati solo per finestre temporali approvate.
Tracciamento Logging di login, logout, login falliti, indirizzo sorgente, utente, asset raggiunto e durata sessione.
Session recording Raccomandato per impianti critici o multi-sito; opzionale ma utile per fornitori esterni.
File transfer Copia/incolla e trasferimento file diretto disabilitati, salvo canale controllato e tracciato.
Internet access Nessuna navigazione libera dal jump host; eventuali accessi esterni devono essere eccezioni motivate.
Hardening Servizi non necessari disabilitati, patching controllato, EDR/antimalware, firewall locale attivo.
Backup Configurazione del jump host e policy di accesso incluse nel piano di backup.

Il flusso corretto per un fornitore è un accesso terminato e controllato in DMZ, non una VPN che entra direttamente nella LAN OT. Il diagramma seguente mostra la differenza tra il flusso ammesso e quello da evitare.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%

flowchart LR

    subgraph OK["Flusso corretto"]
        V1["Fornitore / O&M / Vendor"]
        VPN1["VPN con MFA"]
        DMZ1["OT DMZ"]
        JH1["Jump Host"]
        ASSET1["Asset OT specifico"]
        LOG1["Logging / sessione tracciata"]

        V1 --> VPN1 --> DMZ1 --> JH1 --> ASSET1 --> LOG1
    end

    subgraph KO["Flusso da evitare"]
        V2["Fornitore / O&M / Vendor"]
        VPN2["VPN"]
        LANOT["LAN OT"]
        CRIT["SCADA / EMS / BMS / PCS / RTU / UPDM"]

        V2 --> VPN2 --> LANOT --> CRIT
    end
Figure 1: Flusso corretto e flusso vietato per l’accesso remoto di fornitori e manutentori

La differenza è sostanziale. Nel primo caso il Titolare mantiene un punto di controllo, può revocare l’accesso, ricostruire l’attività svolta e limitare il perimetro raggiungibile. Nel secondo caso l’accesso remoto diventa una porta laterale dentro l’impianto, spesso permanente, difficile da monitorare e dipendente dalle pratiche del singolo vendor.

La OT DMZ deve inoltre impedire le connessioni dirette IT → OT. I sistemi corporate, il SOC o il SIEM possono ricevere log ed eventi dall’impianto, ma non devono amministrare direttamente SCADA, EMS, BMS, PCS, RTU o UPDM. Se un operatore IT o cyber deve intervenire, deve passare dallo stesso modello di accesso controllato previsto per i fornitori.

In termini di firewalling, le regole devono essere poche e leggibili.

Sorgente Destinazione Protocollo Regola
Vendor VPN Jump host RDP/HTTPS/SSH secondo soluzione adottata Consentito solo con MFA e finestra temporale approvata.
Jump host Engineering workstation OT RDP/SSH/HTTPS necessari Consentito solo verso asset autorizzati.
Jump host SCADA/EMS/BMS server Solo protocolli amministrativi necessari Consentito solo per manutenzione approvata.
Asset OT Log forwarder Syslog/agent/log protocol Consentito in uscita verso DMZ.
Log forwarder SIEM/SOC Syslog/TLS o protocollo SIEM Consentito dalla DMZ verso IT/SOC.
File gateway Asset OT File transfer controllato Consentito solo per patch/configurazioni approvate.
IT corporate Asset OT Qualsiasi Vietato.
Vendor VPN Asset OT diretto Qualsiasi Vietato.

Per contenere i costi, il Titolare può evitare soluzioni eccessive, ma non può rinunciare al concetto di DMZ. Una soluzione minima accettabile può essere realizzata anche con un firewall industriale ben configurato, una zona DMZ dedicata, un solo jump host hardenizzato, MFA, log centralizzati e procedure chiare. Se il Titolare ha più impianti, può centralizzare SIEM, SOC, identity management e gestione fornitori, mantenendo però in ciascun impianto una separazione locale tra OT, Terna, DMZ e servizi ausiliari.

La regola finale è questa: ogni accesso remoto deve essere un evento autorizzato, tracciato e revocabile, non una possibilità permanente lasciata aperta al fornitore. Senza OT DMZ e jump host, la segmentazione resta teorica; con una DMZ ben progettata, anche un impianto relativamente piccolo può ottenere un livello di governo coerente con il nuovo perimetro Terna senza introdurre complessità sproporzionata.

Architettura logica minima

Una rappresentazione semplificata dell’architettura minima può essere la seguente. Il diagramma non va letto come una distinta base obbligatoria, né come uno schema fisico di dettaglio. Serve a mostrare la separazione logica fra domini che non devono essere confusi: campo, controllo locale, dominio Terna, servizi OT, OT DMZ, IT/SOC, terze parti e servizi ausiliari.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%

flowchart LR

    subgraph Z6["Z6 - Terze Parti"]
        VENDOR["BoP / O&M / Vendor"]
        TELCO["Telco / Manutentori"]
    end

    subgraph Z5["Z5 - IT / SOC / Corporate"]
        SIEM["SIEM / SOC"]
        ITSM["Ticketing / Asset Register"]
        IAM["Identity / MFA"]
    end

    subgraph Z7["Z7 - Servizi ausiliari non OT"]
        CCTV["Videosorveglianza"]
        BMSAUX["BMS edificio / controllo accessi"]
        WIFI["Wi-Fi / rete ospiti"]
    end

    FWEXT["Firewall esterno / VPN policy"]

    subgraph Z4["Z4 - OT DMZ"]
        VPNGW["VPN Gateway"]
        JH["Jump Host / Bastion Host"]
        FILEGW["File Transfer / Patch Staging"]
        LOGGW["Log Forwarder / Syslog Relay"]
    end

    FWOT["Firewall OT<br/>deny-by-default"]

    subgraph Z3["Z3 - Servizi OT"]
        HIST["Historian locale"]
        BKP["Backup OT"]
        TIME["NTP / PTP / GPS Time Service"]
        IDS["IDS / NDR OT passivo"]
    end

    subgraph Z1["Z1 - Controllo locale"]
        SCADA["SCADA / HMI"]
        EMS["EMS"]
        BMS["BMS Supervisor"]
        ENG["Engineering Workstation OT"]
    end

    subgraph Z2["Z2 - Dominio Terna"]
        RTU["RTU"]
        UPDM["UPDM"]
        RTR["Router compatibile<br/>con architettura Terna"]
    end

    subgraph Z0["Z0 - Campo"]
        PCS["PCS / Inverter"]
        IED["IED / Protezioni"]
        METER["Misure / Contatori"]
        IO["I/O / Sensori / Attuatori"]
    end

    VENDOR -->|"VPN + MFA temporanea"| FWEXT
    TELCO -->|"VPN + MFA temporanea"| FWEXT
    FWEXT --> VPNGW
    IAM -->|"autenticazione / MFA"| VPNGW

    VPNGW --> JH
    JH -->|"sessione controllata"| FWOT
    FWOT --> ENG
    FWOT --> SCADA
    FWOT --> EMS
    FWOT --> BMS

    FILEGW -->|"patch / file approvati"| FWOT
    FWOT --> FILEGW

    SCADA <--> IED
    EMS <--> PCS
    BMS <--> PCS
    SCADA <--> METER
    UPDM <--> IO

    RTU <--> SCADA
    RTU --> RTR
    UPDM --> RTR

    SCADA --> HIST
    EMS --> HIST
    BMS --> HIST

    TIME --> SCADA
    TIME --> EMS
    TIME --> BMS
    TIME --> RTU
    TIME --> UPDM

    SCADA --> LOGGW
    EMS --> LOGGW
    BMS --> LOGGW
    ENG --> LOGGW
    RTU --> LOGGW
    UPDM --> LOGGW
    RTR --> LOGGW
    FWOT --> LOGGW
    FWEXT --> LOGGW

    LOGGW -->|"log / eventi"| SIEM
    FILEGW -->|"evidenze / change / ticket"| ITSM
    BKP --> FILEGW

    CCTV -->|"log / eventi se necessari"| LOGGW
    BMSAUX -->|"log / eventi se necessari"| LOGGW
    WIFI -. "nessun accesso verso OT" .-> FWEXT

    IDS -. "TAP / SPAN passivo" .-> Z1
    IDS -. "TAP / SPAN passivo" .-> Z2

    SIEM -. "nessun accesso diretto agli asset OT" .-> LOGGW
Figure 2: Architettura minima a zone e conduits per un impianto connesso a Terna

Il diagramma non implica che ogni impianto debba avere tutti i server rappresentati. Indica però una separazione logica minima: campo, controllo locale, dominio Terna, servizi OT, OT DMZ, IT/SOC, servizi ausiliari e terze parti non devono coincidere nella stessa rete piatta.

La lettura più semplice è questa: il campo produce segnali e attua comandi; il controllo locale coordina l’impianto; il dominio Terna espone le funzioni richieste dal Gestore; la OT DMZ controlla l’accesso dall’esterno; i servizi OT supportano esercizio, tempo, backup e diagnostica; IT/SOC riceve log ed evidenze senza amministrare direttamente gli asset critici.

Accesso remoto e OT DMZ

La prima parte da isolare è il percorso degli accessi remoti. Vendor, O&M contractor, BoP, telco e manutentori non devono entrare direttamente nella rete OT. Devono terminare l’accesso nella OT DMZ, passare da autenticazione forte, essere autorizzati per una finestra temporale e raggiungere solo gli asset necessari tramite jump host.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%

flowchart TD

    subgraph EXT["Soggetti esterni"]
        VENDOR["BoP / O&M / Vendor"]
        TELCO["Telco / Manutentori"]
    end

    subgraph IT["IT / Identity"]
        IAM["Identity / MFA"]
    end

    FWEXT["Firewall esterno<br/>VPN policy"]

    subgraph DMZ["OT DMZ"]
        VPNGW["VPN Gateway"]
        JH["Jump Host / Bastion Host"]
    end

    FWOT["Firewall OT<br/>deny-by-default"]

    subgraph OT["Asset OT autorizzati"]
        ENG["Engineering Workstation OT"]
        SCADA["SCADA / HMI"]
        EMS["EMS"]
        BMS["BMS Supervisor"]
    end

    VENDOR -->|"VPN temporanea"| FWEXT
    TELCO -->|"VPN temporanea"| FWEXT
    IAM -->|"MFA / identità"| VPNGW
    FWEXT --> VPNGW
    VPNGW --> JH
    JH -->|"sessione controllata"| FWOT
    FWOT --> ENG
    FWOT --> SCADA
    FWOT --> EMS
    FWOT --> BMS
Figure 3: Accesso remoto controllato tramite OT DMZ e jump host

Il punto non è introdurre complessità inutile. Il punto è evitare il caso più pericoloso: una VPN del fornitore che entra direttamente nella LAN OT. Il jump host diventa il punto in cui il Titolare può applicare identità nominativa, MFA, autorizzazione temporanea, logging, eventuale registrazione della sessione e revoca dell’accesso. Senza DMZ e jump host, l’accesso remoto resta una porta laterale verso l’impianto.

Catena di controllo locale e dominio Terna

La seconda parte da isolare è il rapporto fra controllo locale e dominio Terna. SCADA, EMS, BMS, PCS/inverter, IED, misure e sensori governano il comportamento dell’impianto. RTU, UPDM e router compatibile con l’architettura Terna costituiscono invece il dominio attraverso cui l’impianto diventa osservabile, controllabile o integrabile rispetto ai sistemi Terna.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%

flowchart LR

    subgraph FIELD["Z0 - Campo"]
        PCS["PCS / Inverter"]
        IED["IED / Protezioni"]
        METER["Misure / Contatori"]
        IO["I/O / Sensori / Attuatori"]
    end

    subgraph CONTROL["Z1 - Controllo locale"]
        SCADA["SCADA / HMI"]
        EMS["EMS"]
        BMS["BMS Supervisor"]
    end

    subgraph TERNA["Z2 - Dominio Terna"]
        RTU["RTU"]
        UPDM["UPDM"]
        RTR["Router compatibile<br/>con architettura Terna"]
    end

    EMS <--> PCS
    BMS <--> PCS
    SCADA <--> IED
    SCADA <--> METER
    UPDM <--> IO

    RTU <--> SCADA
    RTU --> RTR
    UPDM --> RTR
Figure 4: Separazione fra controllo locale di impianto, campo e dominio Terna

Questo sottodiagramma chiarisce un punto essenziale: il dominio Terna non deve essere una normale VLAN della LAN OT. RTU, UPDM e router devono essere trattati come una zona dedicata, con flussi strettamente necessari, regole di accesso esplicite e responsabilità di manutenzione definite. La logica è la stessa delle zone/conduits: il controllo locale resta il dominio operativo dell’impianto; il dominio Terna è il punto governato di esposizione verso controllo, monitoraggio e difesa.

Log, monitoraggio e raccolta evidenze

La terza parte da isolare è la raccolta di log, eventi e dati di esercizio. In un impianto proporzionato non serve necessariamente un SOC locale. Serve però che firewall, jump host, SCADA, EMS, BMS, RTU, UPDM e router producano eventi e che questi eventi arrivino a un punto di raccolta, locale o centrale. Il SIEM o il SOC devono ricevere log ed evidenze, non amministrare direttamente gli asset OT critici.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%

flowchart LR

    subgraph OT["Sistemi OT e dominio Terna"]
        SCADA["SCADA / HMI"]
        EMS["EMS"]
        BMS["BMS Supervisor"]
        RTU["RTU"]
        UPDM["UPDM"]
        RTR["Router compatibile<br/>con architettura Terna"]
        FWOT["Firewall OT"]
    end

    subgraph SERVICES["Servizi OT / DMZ"]
        LOGGW["Log Forwarder<br/>Syslog Relay"]
        BKP["Backup OT"]
        IDS["IDS / NDR OT passivo"]
        FILEGW["File Transfer<br/>Patch Staging"]
    end

    subgraph IT["IT / SOC / Governance"]
        SIEM["SIEM / SOC"]
        ITSM["Ticketing / Asset Register"]
    end

    SCADA --> LOGGW
    EMS --> LOGGW
    BMS --> LOGGW
    RTU --> LOGGW
    UPDM --> LOGGW
    RTR --> LOGGW
    FWOT --> LOGGW

    LOGGW -->|"log / eventi"| SIEM
    FILEGW -->|"evidenze / change / ticket"| ITSM
    BKP --> FILEGW

    IDS -. "TAP / SPAN passivo" .-> OT
    SIEM -. "nessun accesso diretto agli asset OT" .-> LOGGW
Figure 5: Raccolta log, monitoraggio passivo ed evidenze verso SIEM/SOC

Il valore di questo schema è pratico. Se un accesso remoto fallisce, se una configurazione cambia, se un apparato Terna perde connettività, se un UPDM segnala un’anomalia, se un firewall blocca traffico inatteso o se un sistema OT genera eventi critici, il Titolare deve poterlo vedere e ricostruire. La raccolta log non serve solo alla cybersecurity: serve anche alla manutenzione, al collaudo, alla gestione dei guasti, all’audit e alla dimostrazione della conformità.

Servizi ausiliari non OT

La quarta parte da isolare è spesso quella più sottovalutata. Videosorveglianza, controllo accessi fisico, Wi-Fi, rete ospiti e building management possono sembrare sistemi marginali, ma diventano pericolosi se usati come scorciatoia verso la rete OT. Devono quindi essere separati e, al massimo, inviare log o eventi verso il punto di raccolta.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%

flowchart LR

    subgraph AUX["Z7 - Servizi ausiliari non OT"]
        CCTV["Videosorveglianza"]
        BMSAUX["BMS edificio<br/>controllo accessi"]
        WIFI["Wi-Fi / rete ospiti"]
    end

    FWEXT["Firewall esterno<br/>policy di separazione"]

    subgraph DMZ["OT DMZ"]
        LOGGW["Log Forwarder<br/>Syslog Relay"]
    end

    subgraph OT["Rete OT critica"]
        OTBOUND["Boundary OT"]
        SCADA["SCADA"]
        EMS["EMS"]
        UPDM["UPDM"]
        RTU["RTU"]
    end

    CCTV -->|"log / eventi se necessari"| LOGGW
    BMSAUX -->|"log / eventi se necessari"| LOGGW
    WIFI -. nessun accesso verso OT .-> FWEXT
    FWEXT -. accesso vietato .-> OTBOUND
Figure 6: Separazione dei servizi ausiliari non OT dalla rete OT

Questa separazione è importante perché molti incidenti non nascono dal sistema più critico, ma dal sistema meno presidiato. Una telecamera, una rete Wi-Fi o un sistema di controllo accessi fisico non devono mai diventare un percorso tecnico verso SCADA, EMS, RTU, UPDM o router Terna. La regola è semplice: i servizi ausiliari possono essere monitorati, ma non devono amministrare né raggiungere il dominio OT critico.

Nel complesso, i sottodiagrammi servono a leggere il diagramma generale per parti. La vista completa mostra l’architettura minima; i sottodiagrammi mostrano le quattro logiche da preservare in ogni progetto: accesso remoto controllato, separazione del dominio Terna, raccolta delle evidenze e isolamento dei servizi ausiliari.

Raccordo minimo con IEC 62443

L’obiettivo non è dichiarare una certificazione IEC 62443 se non esiste un progetto formale di certificazione. L’obiettivo è usare IEC 62443 come modello di ragionamento per rendere l’architettura difendibile, verificabile e proporzionata. La serie ISA/IEC 62443 definisce requisiti e processi per implementare e mantenere sistemi IACS cyber-secure, con un approccio che collega operations, IT, process safety e cybersecurity.30

Principio IEC 62443 Traduzione pratica nell’impianto
Zone e conduits Separare campo, controllo locale, dominio Terna, servizi OT, OT DMZ, IT/SOC, terze parti e servizi ausiliari; documentare i conduits e i flussi ammessi.
Security level target basato sul rischio Non dichiarare genericamente IEC 62443 compliant; definire quali zone richiedono controlli più forti e quali controlli sono proporzionati alla taglia e criticità dell’impianto.
Least privilege e controllo accessi Account nominativi, MFA per accesso remoto, RBAC dove disponibile, accessi temporanei, niente account condivisi permanenti.
Restricted data flow Firewall e ACL tra zone, deny-by-default, matrice dei flussi, nessun accesso diretto IT/vendor verso asset OT critici.
System integrity Hardening, rimozione credenziali default, firmware e patch gestiti, antivirus/EDR conservativo su sistemi compatibili, controllo dei file introdotti in OT.
Timely response to events Log centralizzati, allarmi da firewall, jump host, server OT, RTU/UPDM ove esportabili, escalation e incident response.
Resource availability Backup configurazioni e sistemi, test di restore, ridondanze dove richieste, monitoraggio collegamenti, attenzione a non introdurre IPS o blocchi inline che riducano la disponibilità.

Il riferimento a IEC 62443 deve quindi produrre documenti e configurazioni, non slogan. Se il BoP consegna solo una dichiarazione generica di conformità IEC 62443 ma non consegna zone, conduits, matrice flussi, asset inventory, gestione accessi, logging, backup, hardening e procedure di change, la conformità non è utilizzabile dal Titolare.

Firewall, IDS/IPS e SIEM: cosa serve davvero

Il controllo minimo non richiede strumenti eccessivi, ma richiede che gli strumenti siano collocati correttamente.

Componente Dove collocarlo Configurazione proporzionata
Firewall IT/OT Tra Z4 OT DMZ e Z5 IT. Regole deny-by-default, log attivi, accessi IT verso OT vietati salvo casi documentati.
Firewall OT interno Tra Z4 OT DMZ e Z1/Z3; eventualmente tra Z1 e Z2 se non già coperto da apparati dedicati. Poche regole, molto chiare, approvate dal Titolare. Meglio una rulebase corta e verificabile che una complessa e non governata.
Firewall o ACL per dominio Terna A protezione dei flussi verso RTU/UPDM/router, nel rispetto dei requisiti Terna. Whitelisting stretto di IP, porte e protocolli. Nessun traffico Internet, nessun accesso amministrativo non previsto.
IDS/NDR OT passivo Su TAP/SPAN nei punti tra Z1, Z2 e Z3, non inline sui comandi critici. Rilevazione passiva di anomalie, asset discovery, protocolli OT. Evitare IPS inline dove può introdurre rischio operativo.
SIEM Preferibilmente SIEM/SOC già esistente del Titolare o servizio MSSP. Raccolta minima di log da firewall, router, jump host, sistemi Windows/Linux OT, UPDM/RTU ove esportabile, antivirus/EDR, backup.
EDR/antimalware Server Windows/Linux OT, engineering workstation, jump host. Profilo conservativo testato; evitare aggiornamenti o blocchi automatici non validati su sistemi critici.
Backup OT Z3, con copia offline/immutabile dove possibile. Backup configurazioni, immagini server, export configurazioni firewall/router, configurazioni EMS/BMS/SCADA/UPDM/RTU. Test di restore periodico.

La scelta più importante è non mettere controlli attivi o invasivi sulla catena di comando critica senza validazione. In OT il controllo deve rispettare disponibilità, determinismo e safety. Per questo, in impianti di costo limitato, è spesso più ragionevole usare IDS passivo, firewall ben configurati, log centralizzati e procedure robuste, piuttosto che IPS inline complessi, microsegmentazione estrema o piattaforme SOC sovradimensionate.

Requisiti minimi per il BoP

Il BoP non deve limitarsi a consegnare apparati funzionanti. Deve consegnare un’architettura verificabile. Nel contratto o nella specifica tecnica vanno richiesti almeno questi deliverable.

Deliverable Contenuto minimo
Network Architecture Diagram Zone, conduits, VLAN, firewall, router Terna, RTU, UPDM, SCADA, EMS, BMS, PCS, accessi remoti, OT DMZ, servizi ausiliari.
Matrice dei flussi Sorgente, destinazione, protocollo, porta, direzione, motivazione funzionale, owner, regola firewall, modalità di monitoraggio.
Piano IP e VLAN Separazione tra campo, controllo, Terna, servizi OT, DMZ, videosorveglianza, IT ausiliario e accessi terze parti.
Firewall Rulebase Regole nominate, motivate, senza any-any, con logging per i flussi critici e processo di change.
Asset Inventory OT Marca, modello, firmware, indirizzo IP, MAC address ove rilevante, funzione, zona, owner, criticità, supporto vendor.
Remote Access Procedure VPN, MFA, jump host, approvazione temporanea, account nominativi, logging, revoca accessi.
Hardening Baseline Disabilitazione servizi non necessari, credenziali default rimosse, utenti nominativi, password policy, porte fisiche/logiche protette.
Logging Plan Quali log vengono raccolti, dove vanno, retention, owner del monitoraggio, soglie di allarme.
Backup & Restore Plan Oggetti salvati, frequenza, posizione, protezione, test di restore, responsabilità.
Patch & Vulnerability Procedure Finestra di manutenzione, valutazione rischio, test prima del deploy, rollback.
Incident Response Procedure Contatti H24, escalation, tempi, eventi da notificare, isolamento controllato, ripristino.
Supplier Access Register Elenco fornitori autorizzati, motivazione dell’accesso, periodo di validità, sistemi raggiungibili, referente del Titolare.
As-built finale Disegni e configurazioni aggiornate dopo commissioning, non solo documenti di progetto.

Se il BoP non è in grado di produrre questi elementi, il problema non è solo documentale. Significa che il Titolare non ha controllo reale sulla catena che Terna sta iniziando a considerare critica.

Evidenze minime da pretendere in consegna

La conformità non è solo una configurazione corretta; è una configurazione corretta dimostrabile. Per questo, alla consegna dell’impianto il Titolare dovrebbe pretendere un pacchetto minimo di evidenze, non solo manuali generici o schemi preliminari.

Evidenza Perché serve
As-built di rete Dimostra zone, conduits, VLAN, firewall, router, RTU, UPDM, SCADA, EMS/BMS/PCS e accessi remoti effettivi.
Matrice dei flussi Permette di verificare che ogni comunicazione sia necessaria, autorizzata e controllata.
Export configurazioni Consente ripristino e confronto nel tempo di firewall, router, switch, RTU, UPDM e sistemi OT.
Asset inventory OT Permette gestione vulnerabilità, patching, supporto vendor e audit.
Lista firmware e setting Collega prove, tarature e comportamento dell’impianto alla configurazione reale.
Procedure accesso remoto Dimostra che fornitori e manutentori non hanno canali permanenti non governati.
Logging plan Chiarisce quali eventi sono raccolti, dove sono conservati e chi li monitora.
Backup & restore evidence Dimostra che configurazioni e sistemi possono essere recuperati.
Rapporti di prova e collaudo Rende verificabile il comportamento elettrico, OT e Terna-oriented dell’impianto.
Supplier access register Collega ogni fornitore autorizzato a sistemi, motivazione, periodo e referente del Titolare.

Ruolo minimo del Titolare

Il Titolare non deve necessariamente diventare un system integrator OT, ma deve diventare owner della postura di sicurezza dell’impianto. Questo ruolo non può essere lasciato interamente al BoP, perché il BoP consegna l’impianto, mentre il Titolare lo esercisce, risponde verso Terna, gestisce fornitori, approva accessi, conserva evidenze e prende decisioni di rischio.

Ambito Responsabilità del Titolare
Architettura Approvare il modello a zone/conduits e impedire reti piatte o accessi diretti non governati.
Fornitori Imporre requisiti cyber minimi a BoP, O&M, telco, vendor EMS/BMS/PCS, manutentori.
Accessi Autorizzare accessi remoti temporanei e nominativi; vietare account condivisi e VPN permanenti non controllate.
Evidenze Conservare asset inventory, matrice flussi, rulebase, log, report backup, report patch, test e as-built.
Incidenti Stabilire chi chiama chi, entro quando, con quali informazioni, e come si isola un problema senza compromettere la safety.
Change management Ogni modifica a firewall, router, RTU, UPDM, EMS/BMS/PCS, accessi remoti o collegamenti deve essere approvata e tracciata.
Audit Verificare periodicamente che l’impianto reale corrisponda alla documentazione.

Il Titolare deve quindi nominare almeno un responsabile interno o esterno per la governance IT/OT dell’impianto. Non serve una struttura grande, ma serve un owner chiaro.

Implementazione proporzionata per impianti a costi contenuti

Per contenere i costi, la soluzione deve privilegiare semplicità, riuso controllato e centralizzazione dove possibile.

Area Soluzione proporzionata
Segmentazione VLAN e firewall tra OT, Terna, DMZ, IT ausiliario, videosorveglianza e accessi remoti.
Firewall Uno o due firewall industriali/NGFW dimensionati correttamente, non una catena complessa di apparati.
IDS OT Un sensore passivo su TAP/SPAN nei punti critici, oppure servizio gestito se il Titolare ha più impianti.
SIEM Riutilizzare SIEM/SOC corporate o MSSP; per piccoli impianti, syslog collector locale + forwarding degli eventi essenziali.
Accesso remoto VPN centralizzata, MFA, jump host in DMZ, account nominativi, apertura temporanea.
Backup Backup configurazioni e server OT, con copia offline o immutabile e test periodico di restore.
Patching Processo trimestrale/semestrale basato su rischio, non aggiornamento automatico indiscriminato.
Asset inventory Registro semplice ma mantenuto: anche un CMDB leggero è meglio di file sparsi del BoP.
Procedure Poche procedure chiare: accesso remoto, change, backup/restore, incidenti, patch, gestione fornitori.

Gli eccessi da evitare sono altrettanto importanti:

  • non installare IPS inline su flussi di comando critici senza analisi e test;
  • non costruire un SOC locale dedicato per un singolo piccolo impianto se esiste un SOC centrale o un servizio gestito;
  • non moltiplicare firewall e VLAN senza una matrice dei flussi mantenibile;
  • non lasciare tool di vendor con VPN permanenti e account condivisi;
  • non introdurre sistemi di patching automatico su componenti OT senza validazione;
  • non usare la videosorveglianza, il Wi-Fi, il building management o l’IT ausiliario come scorciatoie verso la LAN OT;
  • non accettare documentazione di principio senza configurazioni as-built.

Errori tipici da evitare

Gli errori più frequenti non derivano dall’assenza di tecnologia, ma dall’assenza di governo architetturale. In impianti di taglia contenuta il rischio principale non è progettare una cybersecurity troppo semplice, ma progettare una cybersecurity implicita, non documentata e lasciata alle scelte locali del BoP o dei singoli vendor.

Errore Perché è critico
Rete OT piatta Permette propagazione laterale fra SCADA, EMS/BMS/PCS, accessi remoti, servizi ausiliari e dominio Terna.
VPN vendor permanente Trasforma la manutenzione remota in una porta sempre aperta verso l’impianto.
Account condivisi Impediscono attribuzione delle attività, revoca selettiva degli accessi e ricostruzione degli eventi.
UPDM trattata come apparato isolato Impedisce di verificare correttamente catena di comando, misure, tempi, log e manutenzione.
Router Terna inserito in una LAN OT generica Confonde il boundary Terna con la rete locale d’impianto e indebolisce la segregazione.
Assenza di matrice dei flussi Rende impossibile capire quali comunicazioni siano necessarie, autorizzate e monitorate.
Patching automatico non validato Può compromettere disponibilità, determinismo e compatibilità dei sistemi OT.
Assenza di backup delle configurazioni Trasforma un guasto o una modifica errata in un problema di ricostruzione manuale.
Documentazione preliminare mai aggiornata Produce una distanza pericolosa fra progetto, as-built e impianto realmente esercito.
Fornitori non vincolati contrattualmente sul cyber Rende non esigibili logging, accessi nominativi, gestione vulnerabilità, supporto e tempi di risposta.
Videosorveglianza, Wi-Fi o servizi ausiliari collegati alla rete OT Introduce scorciatoie tecniche verso sistemi critici attraverso domini meno controllati.
SIEM o IDS installati senza processo di gestione eventi Produce allarmi non presidiati e quindi una falsa percezione di controllo.

La regola pratica è semplice: se una configurazione non è documentata, se un accesso non è nominativo, se un flusso non è motivato, se una modifica non è tracciata e se un backup non è testato, allora il controllo dell’impianto è più dichiarato che reale.

Piano pratico in cinque fasi

Per un impianto nuovo, il Titolare dovrebbe imporre cinque fasi al BoP:

  • Fase 1 - Design review prima del procurement. Prima dell’acquisto degli apparati principali, il BoP deve presentare architettura a zone/conduits, matrice flussi, lista apparati, requisiti router/RTU/UPDM, schema accessi remoti, schema logging e schema backup. Questa fase evita di scoprire troppo tardi che un apparato non supporta logging, autenticazione, segregazione, protocolli richiesti o requisiti Terna.

  • Fase 2 - Configurazione controllata. Firewall, router, VLAN, account, jump host, EMS/BMS/SCADA, RTU e UPDM devono essere configurati secondo baseline approvate. Ogni regola deve avere una motivazione funzionale. Gli account default devono essere rimossi o disabilitati.

  • Fase 3 - FAT/SAT cyber-funzionale. Il test non deve limitarsi a verificare che l’impianto produca, accumuli o comunichi. Deve verificare anche segmentazione, flussi, accesso remoto, logging, backup, restore, allarmi, failover dei collegamenti e rispetto delle interfacce Terna.

  • Fase 4 - Handover operativo. Alla consegna, il Titolare deve ricevere as-built, configurazioni esportate, credenziali in modalità sicura, inventario, matrice flussi, procedure, contatti H24, lista fornitori autorizzati e piano di manutenzione.

  • Fase 5 - Esercizio e verifica periodica. Ogni sei o dodici mesi, in base alla criticità, il Titolare deve verificare che asset inventory, firewall rulebase, accessi remoti, backup, patch, log e contratti O&M siano ancora coerenti. La sicurezza decade non perché il progetto iniziale fosse sbagliato, ma perché l’impianto cambia senza governance.

Criterio finale di accettazione

Un impianto può essere considerato ragionevolmente allineato al nuovo trend Terna se il Titolare è in grado di rispondere, con evidenze e non con dichiarazioni, alle seguenti domande.

Domanda Evidenza attesa
Quali sono le zone OT, Terna, DMZ, IT, terze parti e servizi ausiliari? Diagramma di rete a zone/conduits e piano VLAN/IP.
Quali flussi sono ammessi tra le zone, e perché? Matrice dei flussi e firewall rulebase.
Chi può accedere da remoto, come, quando e con quale tracciamento? Procedura accessi remoti, registro fornitori, log VPN/jump host.
Dove sono raccolti i log dei sistemi critici? Logging plan, configurazione syslog/SIEM, retention definita.
Chi vede gli allarmi cyber e operativi? Modello di monitoraggio, escalation e contatti H24.
Come vengono salvate e ripristinate configurazioni e sistemi? Backup & restore plan e report di test restore.
Chi approva modifiche a firewall, router, RTU, UPDM, EMS/BMS/PCS? Procedura di change management e registro modifiche.
Quali fornitori hanno accesso e con quali obblighi? Supplier access register e clausole contrattuali minime.
Cosa succede se un apparato OT o una linea Terna ha un guasto? Procedura di incident/fault response, escalation e ruoli.
Quale documentazione dimostra che l’impianto reale corrisponde all’as-built? As-built finale, export configurazioni, evidenze di collaudo e inventario aggiornato.

Se queste risposte non esistono, il problema non è la mancanza di un prodotto cyber. Il problema è l’assenza di governo architetturale. Gli aggiornamenti Terna rendono sempre meno sostenibile questa assenza.

See also longforms

See also posts

Back to top

Footnotes

  1. Terna, Avviso aggiornamento Codice di Rete del 14/05/2026, URL↩︎

  2. NIS - Network Information Security - Agenzia per la Cybersicurezza Nazionale↩︎

  3. NIS2 Directive: securing network and information systems↩︎

  4. Regulation - 2022/2554 - EN - DORA - EUR-Lex↩︎

  5. Regulation - 2024/2847 - EN - Cyber Resilience Act - EUR-Lex↩︎

  6. D.L. 21 settembre 2019, n. 105 - Disposizioni urgenti in materia di Perimetro di Sicurezza Nazionale Cibernetica - Normattiva e D.P.C.M. 14 aprile 2021, n. 81 - Regolamento in materia di notifiche degli incidenti e misure di sicurezza per il Perimetro di Sicurezza Nazionale Cibernetica - Normattiva↩︎

  7. ENISA Threat Landscape 2025 - European Union↩︎

  8. See: Europol. (2026). The evolving threat landscape: How encryption, proxies and AI are expanding cybercrime – Internet Organised Crime Threat Assessment (IOCTA) 2026. Publications Office of the European Union. Website↩︎

  9. Foresight | ENISA - European Union↩︎

  10. Allegato A.17, Rev. 04 del 14/05/2026, “Centrali eoliche — Condizioni generali di connessione alle reti AAT e AT. Sistemi di protezione regolazione e controllo”, storia delle revisioni: “Aggiornamento dei requisiti tecnici connessi al monitoraggio dei servizi e alla modulazione/distacco della generazione e revisione generale”.↩︎

  11. Allegato A.17, Rev. 04 del 14/05/2026, paragrafo 2, “Campo di applicazione”: distinzione fra connessioni di Tipo 1 e connessioni di Tipo 2, queste ultime riferite a sezioni 36 kV di stazioni elettriche del Gestore.↩︎

  12. Allegato A.17, Rev. 04 del 14/05/2026, paragrafo 2, “Campo di applicazione”: obblighi per impianti esistenti relativi a installazione dell’UPDM conforme all’Allegato A.52 e connessione al Sistema di Difesa secondo l’Allegato A.69; attivazione della funzionalità di limitazione tramite segnale UPDM ove tecnicamente consentito.↩︎

  13. Allegato A.17, Rev. 04 del 14/05/2026, sezione 9, “Priorità azioni di controllo e azioni di protezione”.↩︎

  14. Allegato A.17, Rev. 04 del 14/05/2026, sezione 10, “Monitoraggio e scambio dati con il sistema di controllo di Terna”.↩︎

  15. Allegato A.68, Rev. 05 del 14/05/2026, “Centrali fotovoltaiche — Condizioni generali di connessione alle reti AAT e AT. Sistemi di protezione regolazione e controllo”, storia delle revisioni: “Aggiornamento dei requisiti tecnici connessi al monitoraggio dei servizi e alla modulazione/distacco della generazione e revisione generale”.↩︎

  16. Allegato A.68, Rev. 05 del 14/05/2026, paragrafo 2, “Campo di applicazione”: distinzione fra connessioni di Tipo 1 e connessioni di Tipo 2, queste ultime riferite a sezioni 36 kV di stazioni elettriche del Gestore.↩︎

  17. Allegato A.68, Rev. 05 del 14/05/2026, paragrafo 2, “Campo di applicazione”: precisazione secondo cui, per impianti con Sistemi di Accumulo, l’allegato tratta i requisiti relativi alla centrale fotovoltaica, mentre per i Sistemi di Accumulo si rimanda all’Allegato A.79 del Codice di Rete.↩︎

  18. Allegato A.68, Rev. 05 del 14/05/2026, paragrafo 2, “Campo di applicazione”: obblighi per impianti esistenti relativi a installazione dell’UPDM conforme all’Allegato A.52 e connessione al Sistema di Difesa secondo l’Allegato A.69; attivazione della funzionalità di limitazione tramite segnale UPDM ove tecnicamente consentito.↩︎

  19. Allegato A.68, Rev. 05 del 14/05/2026, sezione 9, “Priorità azioni di controllo e azioni di protezione”.↩︎

  20. Allegato A.68, Rev. 05 del 14/05/2026, sezione 10 e Appendice C, relative a monitoraggio, scambio dati con il sistema di controllo di Terna e informazioni per telecontrollo in tempo reale.↩︎

  21. Allegato A.18, Rev. 03 del 14/05/2026, “Verifica della conformità degli impianti di produzione alle prescrizioni tecniche del Gestore”, storia delle revisioni: “Revisione campo di applicazione e precisazioni sulle modalità di gestione delle prove in autonomia”.↩︎

  22. Allegato A.18, Rev. 03 del 14/05/2026, sezione 6, “Classificazione e modalità di svolgimento delle verifiche”: verifiche con ispezioni strumentali, monitoraggio continuo strumentale, prove in autonomia e ispezioni visive/documentali.↩︎

  23. Allegato A.18, Rev. 03 del 14/05/2026, sezioni relative alle verifiche dei requisiti per la gestione del sistema elettrico dei PPM e alle prove su avviamento, presa di carico, controllo e parallelo.↩︎

  24. Allegato A.18, Rev. 03 del 14/05/2026, sezioni relative alle verifiche su apparati UPDM/UVRP, protezioni, tarature, rapporti di prova, controlli periodici, conformità metrologica e registrazioni oscilloperturbografiche.↩︎

  25. Allegato A.18, Rev. 03 del 14/05/2026, sezioni relative alle modalità di verifica per PPM e BESS, organismi certificatori, rapporti di prova, autocertificazioni e prove in autonomia.↩︎

  26. NIST SP 800-82 Rev. 3 - Guide to Operational Technology (OT) Security↩︎

  27. CISA - Cybersecurity Best Practices for Industrial Control Systems↩︎

  28. ENISA - Zoning and Conduits for Railways: Security Architecture↩︎

  29. CISA - Cross-Sector Cybersecurity Performance Goals↩︎

  30. ISA/IEC 62443 Series of Standards - International Society of Automation↩︎

Reuse

Citation

BibTeX citation:
@online{montano2026,
  author = {Montano, Antonio},
  title = {Controllo e {Monitoraggio} Della {Rete:} La {Nuova} {Postura}
    Di {Sicurezza} Degli {Impianti} {Connessi}},
  date = {2026-05-16},
  url = {https://antomon.github.io/longforms/controllo-monitoraggio-rete-nuova-postura-sicurezza-impianti-connessi/},
  langid = {en}
}
For attribution, please cite this work as:
Montano, Antonio. 2026. “Controllo e Monitoraggio Della Rete: La Nuova Postura Di Sicurezza Degli Impianti Connessi.” May 16. https://antomon.github.io/longforms/controllo-monitoraggio-rete-nuova-postura-sicurezza-impianti-connessi/.