C’è un momento preciso in cui un impianto produttivo cessa di essere un ambiente fisicamente delimitato e diventa, di fatto, un operatore di telecomunicazioni. Accade quando l’azienda installa una rete 5G privata, un campus network autonomo, per connettere robot industriali, sistemi AGV (Automated Guided Vehicle), sensori IoT e stazioni operative. È un salto tecnologico che porta con sé una promessa concreta: latenza submillisecondo, banda garantita, isolamento logico dal 5G pubblico, controllo totale sullo spettro assegnato. Ma è anche un salto in un territorio di rischio che molte organizzazioni non hanno ancora imparato a cartografare con rigore.
La diffusione delle reti 5G private negli ambienti industriali è uno dei fenomeni più rilevanti del ciclo attuale di trasformazione digitale. Le stime di mercato variano significativamente a seconda del perimetro di analisi: tra i 5 e gli 11 miliardi di dollari nel 2025 secondo le principali società di ricerca, con proiezioni convergenti verso i 22-28 miliardi entro il 2029-2030 (Research and Markets, 2025; Grand View Research, 2025). Il dato che più impressiona, però, non è il valore di mercato: è il divario tra la velocità di adozione e la maturità dei modelli di sicurezza che accompagnano questa adozione.
La domanda che le imprese si pongono raramente con la giusta profondità non è “come connettere meglio i nostri asset”, ma “cosa cambia nella nostra superficie d’attacco quando introduciamo una rete 5G privata in un ambiente che ospita sistemi SCADA, PLC e HMI”. La risposta è scomoda: cambia tutto, e in una direzione che la maggior parte dei responsabili della sicurezza OT non ha ancora del tutto esplorato.
La convergenza IT/OT: un problema noto con una forma radicalmente nuova
Il tema della convergenza IT/OT non è nuovo. Da anni si discute dei rischi derivanti dalla connessione tra reti informatiche tradizionali e sistemi di controllo industriale; le vulnerabilità strutturali dei sistemi SCADA e ICS sono ben documentate, anche in questa sede.
Ma il 5G privato introduce una dimensione inedita: una rete di comunicazione mobile, con la propria architettura di core, i propri protocolli di segnalazione e la propria logica di gestione degli accessi, si inserisce fisicamente e logicamente all’interno dell’ambiente OT. Non si tratta più di un confine tra IT e OT mediato da un firewall perimetrale. Si tratta di una rete progettata per connettere tutto, che porta con sé gli stessi vettori di attacco propri delle infrastrutture di telecomunicazione.
Il rapporto PwC Global Digital Trust Insights 2026, condotto tra maggio e luglio 2025 su 3.887 executive in 72 paesi, fotografa con precisione questa criticità strutturale: il 41% delle organizzazioni intervistate identifica come principale ostacolo alla sicurezza OT/IIoT la mancanza di segmentazione di rete tra ambienti OT/IIoT e IT. Il 47% cita la carenza di competenze specialistiche OT, e il 39% denuncia assenza di governance e responsabilità chiare. Non sono problemi tecnici irrisolvibili: sono ritardi culturali e organizzativi nell’affrontare la convergenza con gli strumenti appropriati.
A dare la misura finanziaria del problema contribuisce il 2025 OT Security Financial Risk Report pubblicato da Dragos in collaborazione con il Cyber Risk Intelligence Center di Marsh McLennan (agosto 2025): in uno scenario estremo ma statisticamente plausibile (evento 1-su-250-anni), il rischio finanziario globale derivante da incidenti OT potrebbe raggiungere i 329,5 miliardi di dollari, con 172,4 miliardi attribuibili alla sola interruzione d’esercizio. Anche in anni ordinari, il rischio medio annuo stimato supera i 31 miliardi di dollari. Il dato più significativo del report, basato su un decennio di dati assicurativi e di breach, è che le perdite indirette, spesso escluse dai modelli tradizionali, rappresentano fino al 70% dell’impatto reale di un’intrusione OT.
Il 5G privato non risolve questa frammentazione: la amplifica. Introduce un layer supplementare, quello della rete mobile, che dialoga con entrambe le dimensioni, IT e OT, e che risponde a logiche di sicurezza proprie del mondo delle telecomunicazioni, non del mondo industriale. Il personale che gestisce i sistemi SCADA raramente ha familiarità con protocolli come GTP o NAS. I team di network security aziendale conoscono scarsamente le architetture del 5G core. Il risultato è uno spazio interstiziale dove nessuno guarda con sufficiente attenzione.
Robert M. Lee, CEO di Dragos, ha sintetizzato questa discrasia in modo diretto: “circa il 95% di tutti i budget destinati alla cybersecurity va al lato IT, non al lato OT. Eppure è sul lato OT che si genera tutta la capacità di fatturato, tutto l’impatto sulla sicurezza fisica e sulla sicurezza nazionale” (The Chemical Show, maggio 2025). Sono parole che descrivono con precisione l’asimmetria in cui si trovano le organizzazioni industriali che adottano il 5G privato: il nuovo vettore di attacco appartiene al dominio telco-IT, ma il danno si materializza nel dominio OT.
Specificità di sicurezza del 5G privato rispetto al 5G pubblico
Comprendere perché il 5G privato presenta sfide di sicurezza distinte rispetto alle reti pubbliche è essenziale per impostare correttamente la valutazione del rischio.
In una rete 5G pubblica, l’operatore assume la responsabilità primaria della sicurezza del core network: aggiornamenti software, gestione dell’autenticazione, integrità della segnalazione. L’impresa è sostanzialmente un utilizzatore finale, con visibilità limitata su ciò che accade al di là dell’interfaccia radio. In un campus network privato, questa responsabilità si sposta interamente sull’organizzazione che lo gestisce. Il 5G core, composto da funzioni virtualizzate come AMF (Access and Mobility Management Function), SMF (Session Management Function) e UPF (User Plane Function), è deployato in sede o in un cloud privato aziendale. La sua sicurezza dipende dalle competenze interne o da quelle di un system integrator terzo, spesso senza che i requisiti di sicurezza telco siano stati esplicitamente negoziati nel contratto.
Questa redistribuzione della responsabilità ha implicazioni dirette. La superficie d’attacco aumenta perché l’azienda gestisce ora componenti telco che in precedenza erano fuori dal proprio perimetro. Le architetture cloud-native delle funzioni 5G core introducono rischi legati a misconfigurazioni dei container, a vulnerabilità nelle interfacce Service-Based Interfaces (SBI) e a possibili movimenti laterali attraverso l’infrastruttura cloud condivisa. Il network slicing, presentato come la soluzione tecnologica per isolare logicamente i servizi, garantisce separazione a livello logico, ma non necessariamente a livello protocollare di basso livello, come si vedrà nel prossimo paragrafo.
Esistono poi vulnerabilità specifiche legate alle deployment Non-Standalone (NSA), le più diffuse negli ambienti industriali attualmente in fase di adozione. In queste architetture ibride, il core network LTE coesiste con la radio 5G, creando un paesaggio di sicurezza che eredita le debolezze di entrambe le generazioni e introduce complessità di correlazione degli indicatori di compromissione tra domini eterogenei. Come documenta ABI Research (settembre 2025), per le reti 5G Non-Standalone “il modello ibrido crea un panorama di sicurezza di complessità significativa, con la correlazione incrociata degli indicatori di minaccia come fattore critico per fronteggiare gli attacchi.”
Il problema GTP: un protocollo progettato senza avversari
Il GPRS Tunneling Protocol (GTP) è il protocollo che trasporta il traffico dati degli utenti nelle reti mobili, incapsulandolo in tunnel tra il nodo radio (gNB) e le funzioni di core. Nella variante GTP-U gestisce il piano utente; nella variante GTP-C gestisce i messaggi di controllo tra le funzioni di core nelle architetture NSA.
Il problema fondamentale di GTP è di natura storica: come molti protocolli di telecomunicazione, è stato progettato in un’epoca in cui le reti mobili erano ambienti fisicamente chiusi e l’autenticazione reciproca tra i nodi era considerata secondaria rispetto all’affidabilità della connessione. Il risultato è che GTP-C può essere abusato per manipolare i bearer path, i percorsi attraverso cui fluiscono i dati degli utenti, iniettando traffico non autorizzato nel piano utente (GTP-U) o causando interruzioni di sessione attraverso messaggi di controllo falsificati. Come documenta P1 Security nel febbraio 2026, “gli attaccanti che guadagnano accesso alla funzione di controllo possono creare messaggi che istanziano o modificano tunnel GTP, pur senza avere accesso diretto al protocollo GTP.”
Un attaccante che accede a un nodo interno alla rete 5G privata può usare messaggi GTP-C per terminare sessioni attive di dispositivi connessi, con effetti immediati sulle operazioni: un AGV che perde connettività nel mezzo di un ciclo produttivo, un sensore di sicurezza che smette di trasmettere, un sistema di monitoraggio remoto che diventa cieco. In contesti industriali dove il costo del downtime supera i 260.000 dollari per ora nei grandi stabilimenti manifatturieri e raggiunge i 2,3 milioni di dollari per ora nel comparto automotive (Siemens, True Cost of Downtime 2024), questi scenari non sono esercizi teorici.
La ricerca più recente ha chiarito un punto critico che riguarda anche il network slicing. Come analizzato in dettaglio su Cyber Defense Magazine (novembre 2025): “protocolli come GTP-U e PFCP (Packet Forwarding Control Protocol) operano a un livello inferiore rispetto alla separazione logica tra slice, all’interno dell’infrastruttura condivisa della User Plane Function (UPF). Un exploit su questi protocolli non rispetta i confini logici delle slice perché colpisce la risorsa fisica condivisa.” La promessa di isolamento offerta dal network slicing è, in assenza di controlli di sicurezza specifici aggiuntivi, una garanzia solo parziale.
Per le reti 5G Standalone (SA), l’architettura Service-Based ha sostituito GTP-C con interfacce HTTP/2 per la comunicazione tra le funzioni di core. Questo riduce alcune delle vulnerabilità di segnalazione ereditate da GTP-C, ma apre nuove superfici di attacco: le SBI sono esposte ad API fuzzing, a vulnerabilità di validazione degli input e a possibili escalation di privilegio attraverso la logica di orchestrazione condivisa. GTP-U rimane in uso anche nelle architetture SA per il piano dati.
Vulnerabilità NAS e il piano di segnalazione come vettore d’attacco
Il Non-Access Stratum (NAS) è il protocollo che gestisce la mobilità e la gestione della sessione tra il dispositivo (UE) e il core network, attraverso le funzioni AMF e SMF. È il livello dove avvengono autenticazione, cifratura e negoziazione degli algoritmi di sicurezza.
In architetture 5G NSA, i messaggi NAS vengono scambiati in chiaro durante la fase di attach iniziale, prima che la cifratura sia negoziata. Questa finestra espone informazioni sulla configurazione del dispositivo e sull’identità temporanea dell’utente (TMSI). Un attaccante può iniettare messaggi RRC falsificati a livello di base station per causare denial-of-service sul singolo terminale, sfruttando il fatto che il messaggio RRC Connection Request viene trasmesso in chiaro e contiene il TMSI dell’utente.
I cosiddetti downgrade attack, che forzano il dispositivo a retrocedere verso 4G o 3G perdendo le protezioni aggiuntive del 5G Standalone, rappresentano un rischio concreto nelle deployment industriali ibride. Quando la copertura 5G non è disponibile, il terminale effettua automaticamente il fallback verso la rete LTE, perdendo funzionalità di sicurezza come SUCI (Subscription Concealed Identifier) e l’autenticazione estesa. “Gli attaccanti possono sfruttare questa vulnerabilità attraverso downgrade attack che forzano o ingannano i dispositivi 5G a usare reti 4G, con conseguente perdita prevedibile di protezione” (TechTarget, 2025).
Nel contesto industriale, i dispositivi connessi alla rete 5G privata includono sensori, PLC con moduli cellulari, telecamere di supervisione e HMI mobili. Molti di questi dispositivi non sono soggetti allo stesso ciclo di aggiornamento del firmware riservato agli endpoint IT tradizionali, e i loro stack di comunicazione cellulare possono presentare vulnerabilità note non patchate. La superficie di attacco via NAS si estende quindi ben oltre la rete mobile in senso stretto: un dispositivo OT compromesso attraverso il vettore cellulare diventa un punto di accesso all’interno del segmento di controllo industriale.
Le analisi cross-protocollari di P1 Security (febbraio 2026) hanno evidenziato come gli attaccanti che guadagnano accesso alle funzioni AMF o SMF del core possano manipolare messaggi NAS per alterare la gestione della mobilità, triggerare drop di sessione, o ottenere informazioni sull’identità e la posizione dei dispositivi connessi. In ambienti dove la posizione di un AGV o di una macchina a controllo numerico è un dato operativo critico, la compromissione del piano di segnalazione ha implicazioni che vanno oltre la sicurezza informatica per toccare la safety fisica.
Il rischio di lateral movement verso sistemi SCADA
L’architettura di un campus network 5G privato crea, per sua natura, ponti tra domini che in precedenza erano separati. Il core 5G è tipicamente deployato su infrastruttura server in sede o cloud privato aziendale, che condivide risorse di rete con i sistemi IT aziendali. La UPF, la funzione che instrada il traffico degli utenti, è configurata per inviare i pacchetti verso le destinazioni appropriate, che possono includere sia server cloud sia sistemi OT locali.
Il rischio di lateral movement si concretizza quando un attaccante che ha compromesso un nodo della rete 5G, o un dispositivo connesso, riesce a raggiungere sistemi SCADA, DCS (Distributed Control System) o PLC che non erano direttamente esposti sulla rete IT. Il percorso tipico sfrutta la fiducia implicita che l’architettura ripone nel traffico proveniente dalla UPF: una volta dentro il tunnel GTP, il traffico è considerato legittimo dalla rete di destinazione, e la sua instradazione dipende dalla configurazione delle route. Se la segmentazione tra il segmento 5G e il segmento OT non è implementata con rigore (con firewall industriali, VLAN separate, deep packet inspection del traffico applicativo), il tunnel GTP diventa una via diretta verso i sistemi di controllo.
In questo scenario, i protocolli industriali legacy come Modbus, DNP3, IEC 104 e BACnet, che per definizione non includono autenticazione né cifratura, diventano il target terminale di un attacco che ha percorso un tragitto attraverso un vettore di telecomunicazione moderno. Un’azienda può aver investito considerevoli risorse nella sicurezza perimetrale della propria rete SCADA, ma aver lasciato aperto un accesso laterale attraverso l’infrastruttura 5G introdotta nell’impianto nell’ultimo anno.
La ricerca condotta nell’ambito del framework SWICS (Lenz et al., arXiv aprile 2026), il primo testbed virtuale per sistemi di controllo industriale che interconnette componenti ICS attraverso 5G in un ambiente di simulazione a eventi discreti, ha confermato che in condizioni di canale degradato o sotto attacco di jamming, i sistemi ICS connessi via 5G mostrano una suscettibilità agli attacchi significativamente superiore rispetto a quelli su rete cablata. In particolare, la variabilità del canale radio rende inaffidabile il rilevamento di anomalie basato su pattern di comunicazione: i modelli addestrati su dati 5G in condizioni ottimali falliscono nel rilevamento quando il canale si degrada, aprendo finestre di invisibilità che un attaccante può sfruttare deliberatamente tramite tecniche di jamming selettivo.
Quando un’infrastruttura cloud ospita il core 5G virtualizzato, si aggiunge un ulteriore vettore: le vulnerabilità dell’infrastruttura cloud stessa possono diventare punti di accesso per movimenti laterali che, attraverso la UPF, raggiungono la rete OT. Come evidenziato nel white paper di OneLayer dedicato alle reti cellulari private, “quando il core cellulare è eseguito nel cloud, qualsiasi vulnerabilità sfruttabile dell’infrastruttura cloud può esporre la rete ospitata a lateral movement.”
NIS2 e la governance delle reti 5G private industriali
In questo contesto di rischio emergente, il quadro normativo europeo e italiano offre strumenti di risposta, ma anche interrogativi aperti sulla loro applicazione concreta alle reti 5G private.
La Direttiva NIS2 (UE 2022/2555), recepita in Italia con il D.Lgs. 138/2024 entrato in vigore il 16 ottobre 2024, estende gli obblighi di sicurezza informatica a 18 settori critici, inclusi manifattura strategica, infrastrutture digitali, energia e trasporti.
L’Italia ha proceduto all’attuazione per fasi: dopo la registrazione obbligatoria dei soggetti NIS entro febbraio 2025 e la pubblicazione degli obblighi di base con la Determinazione ACN 164179/2025 (aprile 2025), il quadro operativo è stato consolidato a fine dicembre 2025 con due ulteriori determinazioni del Direttore Generale dell’ACN, la 379887/2025 (che disciplina il Portale NIS) e la 379907/2025 (che definisce le misure di sicurezza di base e gli incidenti significativi di base), applicabile dal 15 gennaio 2026. Come abbiamo analizzato in dettaglio sugli adempimenti NIS2, la mappa delle scadenze è ora precisa e non lascia spazio a rinvii.
Dal gennaio 2026 è pertanto operativo l’obbligo di notifica degli incidenti significativi allo CSIRT Italia, con pre-notifica entro 24 ore dalla rilevazione. Entro ottobre 2026, i soggetti NIS dovranno aver adottato le misure di sicurezza definite dalla Determinazione ACN 164179/2025: 37 misure per i soggetti importanti (87 requisiti complessivi) e 43 misure per i soggetti essenziali (116 requisiti). Entro aprile 2026, l’ACN dovrà adottare il modello di categorizzazione delle attività e dei servizi e gli obblighi a lungo termine, ulteriore evoluzione rispetto agli obblighi di base già operativi.
Calate in un contesto 5G privato, le prescrizioni NIS2 richiedono una traduzione tecnica non banale. La segmentazione di rete deve ora includere il piano di controllo 5G e il piano dati GTP-U, non solo le tradizionali VLAN IT/OT. La gestione delle vulnerabilità deve estendersi ai componenti software delle funzioni virtualizzate del core (AMF, SMF, UPF), ai firmware dei dispositivi UE industriali e alle dipendenze software della piattaforma cloud su cui il core può essere ospitato. Il monitoraggio continuo deve saper interpretare il traffico di segnalazione NAS e GTP, protocolli che i SIEM aziendali tradizionali non analizzano senza strumenti specializzati.
Sul versante della supply chain, la NIS2 impone mappatura e classificazione dei fornitori ICT rilevanti, con clausole contrattuali esplicite su gestione degli incidenti, obblighi di notifica e diritto di audit. Nel caso delle reti 5G private, questa catena include i vendor del core network (Ericsson, Nokia e altri), i fornitori di hardware radio (gNB), i system integrator che hanno realizzato la deployment e i fornitori cloud su cui è eventualmente ospitato il core virtualizzato. Ogni anello è potenzialmente un punto di ingresso.
Una questione normativa aperta riguarda la qualificazione della rete 5G privata industriale all’interno del perimetro NIS2 di un’organizzazione: la rete stessa è infrastruttura digitale soggetta agli obblighi, o è semplicemente un componente dell’infrastruttura produttiva? La risposta dipenderà dal settore di appartenenza dell’organizzazione e dalla classificazione come soggetto essenziale o importante, ma in ogni caso il rischio cyber derivante dalla rete 5G privata deve essere incluso nella valutazione del rischio complessiva che la NIS2 richiede.
Verso un modello di sicurezza integrato per il campus 5G
La soluzione non risiede in un singolo strumento tecnologico, ma in un cambio di prospettiva sull’architettura di rischio. Un campus network 5G industriale deve essere governato con un modello che integri tre livelli di competenza oggi troppo spesso separati: sicurezza delle telecomunicazioni (con conoscenza dei protocolli 5G), sicurezza IT (con capacità di network security, SIEM, identity management) e sicurezza OT (con comprensione dei sistemi industriali e delle loro specificità operative).
Il principio Zero Trust, applicato all’accesso dei dispositivi UE alla rete 5G privata, richiede che ogni dispositivo sia autenticato individualmente prima di ottenere accesso alle risorse OT, indipendentemente dalla posizione fisica nell’impianto. L’identità del SIM e del dispositivo deve essere verificata continuamente, non solo al momento dell’attach iniziale. L’uso di SUCI (Subscription Concealed Identifier) al posto del SUPI non cifrato riduce il rischio di tracking e intercettazione dell’identità durante la fase di attach.
La microsegmentazione del piano dati, implementata a livello di UPF tramite policy PFCP, consente di isolare il traffico tra gruppi di dispositivi anche all’interno dello stesso slice, limitando la propagazione di un eventuale lateral movement. Questa segmentazione deve essere progettata esplicitamente, non affidata alla configurazione di default del vendor.
Il monitoraggio del piano di segnalazione, attraverso strumenti capaci di analizzare messaggi NAS e GTP-C, è indispensabile per rilevare anomalie non visibili a un tradizionale IDS/IPS. La letteratura recente (MDPI Future Internet, ottobre 2025) indica come strategie raccomandate “cifratura avanzata, autenticazione a più fattori, sistemi di intrusion detection e audit di sicurezza periodici per mitigare rischi emergenti ed evolutivi.”
La gestione del rischio di downgrade, ovvero la ricaduta automatica su 4G o 3G in assenza di copertura 5G, deve essere valutata esplicitamente per ogni categoria di dispositivo. Per i dispositivi che accedono a sistemi OT critici, la policy preferibile può essere l’interdizione della connessione in assenza di 5G, piuttosto che la tolleranza di un fallback che degrada le protezioni di autenticazione.
Il rischio di jamming selettivo dell’interfaccia radio, documentato dal testbed SWICS (2026) come vettore per rendere inefficaci i sistemi di rilevamento anomalie, va infine incluso esplicitamente nei modelli di minaccia delle reti 5G private industriali, al pari degli attacchi protocollari sul core.
Conclusioni: la falsa sicurezza dell’isolamento privato
Il termine “privato” nel contesto delle reti 5G private porta con sé una connotazione di isolamento e controllo che rischia di diventare una trappola cognitiva. Una rete è privata nel senso che è dedicata a un singolo operatore, ma non è immune per natura dagli attacchi, né da quelli che provengono dall’esterno attraverso i dispositivi connessi, né da quelli interni che sfruttano le vulnerabilità protocollari del core.
Le industrie manifatturiere, energetiche e logistiche che stanno adottando campus network 5G si trovano a gestire una superficie d’attacco ibrida di tipo nuovo, dove la convergenza IT/OT si arricchisce di una terza dimensione, quella telco, per la quale non sempre esistono competenze interne, standard di riferimento condivisi o strumenti di difesa già consolidati. Il report PwC 2026 conferma che solo il 25% delle organizzazioni manifatturiere spende significativamente di più in misure di sicurezza proattive rispetto a quelle reattive: uno squilibrio che, nell’era dei campus network 5G, diventa ancora più pericoloso.
Ignorare questa specificità, o trattare il 5G privato come una semplice evoluzione del Wi-Fi industriale, è un errore che le organizzazioni critiche non possono permettersi. La NIS2, con gli obblighi ora operativi in Italia, offre una cornice normativa che spinge verso un approccio strutturato, ma la compliance non è sinonimo di sicurezza.
Il vero lavoro consiste nell’adattare il modello di gestione del rischio alla specificità tecnica di un’infrastruttura che parla simultaneamente i linguaggi del 3GPP, dell’IEC 62443 e dell’ISO/IEC 27001, e nel farlo prima che un attaccante trovi nel campus network il percorso verso il sistema SCADA che controlla la produzione.
https://www.ictsecuritymagazine.com/articoli/reti-5g-private/
