Zero trust security per IoT: rischi e best practice

Sensori industriali, telecamere, contatori intelligenti, apparati medicali e sistemi per la gestione degli edifici sono spesso progettati per lavorare per anni, con capacità di elaborazione limitate e procedure di aggiornamento poco trasparenti. Una combinazione che rende l’Internet of Things uno dei punti più difficili da governare per CIO e CISO. Il modello zero trust permette di ridurre l’esposizione, a condizione di adattarlo ai vincoli operativi dell’IoT e di non considerarlo un prodotto da installare.

In Italia sono attivi 175 milioni di oggetti connessi, circa tre per abitante. Il mercato IoT ha raggiunto nel 2025 un valore di 10,9 miliardi di euro, in crescita del 12% rispetto all’anno precedente. Il 71% delle grandi aziende manifatturiere e il 59% di quelle medie hanno già avviato almeno un progetto Industrial IoT. Utility, auto connesse, smart building e fabbriche concentrano una parte consistente degli investimenti, secondo l’Osservatorio Internet of Things del Politecnico di Milano.

La stessa espansione moltiplica gli oggetti da censire, configurare, aggiornare e sorvegliare. Ogni dispositivo introduce software, credenziali, protocolli e dipendenze da servizi esterni. Compromettere un sensore può alterare un dato, mentre prendere il controllo di un attuatore può incidere sulla produzione, sulla sicurezza di un impianto o sulla continuità di un servizio.

È su questa superficie frammentata che lo zero trust trova una delle applicazioni più concrete. La domanda da porre a ogni connessione cambia: invece di presumere affidabile un dispositivo perché si trova nella rete aziendale, occorre verificarne identità, stato e comportamento, concedendogli soltanto le comunicazioni necessarie alla funzione assegnata.

Le debolezze ricorrenti della sicurezza IoT

La prima difficoltà è la visibilità. Molte organizzazioni non dispongono di un inventario completo degli oggetti collegati alle reti aziendali. Alcuni dispositivi vengono installati dall’IT, altri dai team OT, dal facility management, dalle funzioni di business o da fornitori esterni. Possono rimanere operativi anche dopo la conclusione del progetto che ne aveva giustificato l’acquisto.

L’inventario tradizionale degli endpoint risulta spesso insufficiente. Una telecamera IP, un controllore industriale o un sensore ambientale potrebbero non supportare agent di sicurezza, sistemi EDR o protocolli standard per la gestione delle identità. La loro presenza emerge allora dall’osservazione passiva del traffico, dai dati degli switch e dei gateway o dalle scansioni, da eseguire con cautela nei sistemi industriali sensibili.

Si aggiunge il problema del ciclo di vita. Il firmware può contenere vulnerabilità note; gli aggiornamenti possono essere rari, manuali oppure subordinati alla disponibilità del produttore. Alcuni apparati restano in esercizio per dieci o vent’anni, ben oltre la vita commerciale del software incorporato. Sostituirli comporta costi, fermi e nuove certificazioni, soprattutto in fabbrica, nella sanità e nelle infrastrutture.

Credenziali predefinite o condivise, servizi di amministrazione esposti a Internet e configurazioni deboli offrono agli attaccanti ingressi relativamente economici. L’Agenzia per la cybersicurezza nazionale ha richiamato l’attenzione sui rischi legati ai dispositivi IoT e ai servizi di accesso remoto direttamente raggiungibili dalla rete pubblica. Nel 2025 ACN ha inoltre segnalato ShadowV2, una variante di Mirai progettata per compromettere apparati IoT e impiegarli in botnet.

Il rischio riguarda anche la supply chain. Hardware, firmware, librerie, piattaforme cloud, servizi di manutenzione possono dipendere da soggetti diversi. Una vulnerabilità in un componente condiviso si propaga su un numero elevato di prodotti, mentre una backdoor o una credenziale del fornitore può sopravvivere alle normali attività di configurazione.

Infine, molti dispositivi comunicano più del necessario. Un oggetto compromesso può effettuare scansioni, contattare destinazioni esterne o tentare di raggiungere server e altri apparati presenti nella stessa rete. Una segmentazione approssimativa trasforma così un incidente circoscritto in un possibile movimento laterale verso sistemi gestionali, dati aziendali o ambienti OT.

Secondo l’ENISA Threat Landscape 2025, i dispositivi e i servizi esposti a Internet, in particolare i sistemi OT, continuano a essere bersagli di valore. Lo sfruttamento delle vulnerabilità ha rappresentato il 21% dei vettori iniziali osservati dall’Agenzia europea; nel 68% di questi casi è stato seguito dall’installazione di malware.

Come lo zero trust riduce il rischio IoT

Il NIST definisce lo zero trust come un insieme di principi che sposta la difesa dai perimetri statici verso utenti, asset e risorse.

Applicato all’IoT, il modello poggia su quattro funzioni.

• La prima è attribuire un’identità al dispositivo. Quando l’hardware lo consente, questa può essere basata su certificati, chiavi conservate in componenti sicuri, autenticazione reciproca e attestazione dell’integrità. Dove tali meccanismi mancano, l’identità deve essere ricostruita combinando dati di rete, caratteristiche del dispositivo, posizione, protocollo e comportamento abituale. Un indirizzo MAC, facilmente falsificabile, non basta.
• La seconda consiste nel concedere il privilegio minimo. Un sensore di temperatura può inviare dati a un gateway determinato, usando un protocollo e una porta stabiliti; non dovrebbe comunicare con il gestionale, interrogare altri dispositivi o raggiungere destinazioni Internet non autorizzate. Le policy trasformano la funzione dell’oggetto in una lista molto limitata di flussi consentiti.
• La terza è la microsegmentazione. Separare gli apparati in zone coerenti per funzione, rischio e criticità contiene gli effetti di una compromissione. La segmentazione può operare attraverso VLAN, firewall interni, software-defined networking, gateway IoT o controlli applicati alle reti private 5G. Nei contesti OT va costruita tenendo conto dei processi fisici e delle dipendenze tra impianti, evitando regole che possano interrompere comunicazioni essenziali.
• La quarta funzione è la verifica continua. La decisione di accesso non termina al momento dell’onboarding. Un cambiamento del firmware, un’anomalia nei volumi di traffico, il contatto con una destinazione insolita o la comparsa di una vulnerabilità critica possono ridurre il livello di fiducia e attivare restrizioni, quarantena o verifiche aggiuntive.

L’approccio è particolarmente utile dove il controllo non può essere installato sull’endpoint: l’applicazione centralizzata delle policy a livello di rete consente di governare migliaia di dispositivi differenti, compensando almeno in parte i limiti di sistemi operativi e firmware.

La microsegmentazione, tuttavia, non rende impossibile in senso assoluto la propagazione di un attacco. Ne riduce drasticamente le strade disponibili se le regole sono corrette, aggiornate e applicate in tutti i punti di passaggio. Configurazioni troppo permissive, canali di manutenzione dimenticati e gateway considerati automaticamente affidabili possono aggirare il modello.

I limiti dello zero trust negli ambienti IoT

L’identità rappresenta l’ostacolo tecnico più evidente. Numerosi dispositivi legacy non supportano certificati, autenticazione reciproca o protocolli moderni. Altri dispongono di risorse insufficienti per sostenere cifratura e controlli frequenti senza incidere su autonomia, latenza e prestazioni.

In questi casi occorre spostare l’enforcement verso switch, access point, gateway o firewall. È una soluzione utile, sebbene meno solida dell’identità crittografica incorporata nel dispositivo: il sistema riconosce un profilo di rete, con un margine di errore maggiore.

Anche la granularità ha un costo. Migliaia di regole costruite dispositivo per dispositivo diventano difficili da mantenere. Conviene definire profili per classi omogenee (ad esempio telecamere, sensori, stampanti, controllori, dispositivi medicali) prevedendo eccezioni tracciate e con scadenza. L’automazione è necessaria, purché non generi policy opache che nessuno sappia più ricostruire.

Resta infine una questione organizzativa. IT, cybersecurity, OT, procurement e responsabili di produzione osservano lo stesso dispositivo da prospettive differenti. Se l’IT applica una regola senza conoscere il processo industriale può provocare un’interruzione; se l’OT conserva connessioni permissive per prudenza operativa, mantiene aperta la strada al movimento laterale. Servono responsabilità condivise, procedure di escalation e criteri concordati per isolare un apparato.

Le migliori pratiche per implementare lo zero trust nell’IoT

1. Partire da inventario e dipendenze

Il censimento deve associare a ogni oggetto proprietario, funzione, ubicazione, firmware, stato di supporto, protocolli, dati trattati, servizi contattati e criticità del processo. L’inventario va alimentato automaticamente attraverso discovery passiva e telemetria di rete, poi verificato dai responsabili operativi.

Il primo indicatore utile è quota di questi oggetti per cui esistono proprietario, funzione e profilo di comunicazione conosciuti.

2. Classificare per rischio e impatto

Una lampada connessa e un controllore di una linea produttiva richiedono trattamenti diversi. La classificazione deve considerare almeno l’esposizione a Internet, la possibilità di aggiornamento, i dati trattati, l’eventuale capacità di attuazione fisica, l’impatto di un fermo e le connessioni verso sistemi sensibili.

Questa analisi stabilisce le priorità: gli apparati connessi a Internet, privi di supporto o collegati a processi essenziali devono entrare per primi nel programma.

3. Disegnare i flussi consentiti

Per ciascuna classe di dispositivi bisogna documentare quali risorse può contattare, in quale direzione, con quali protocolli e in quali fasce temporali. La policy zero trust deriva da questa mappa.

Una fase iniziale di osservazione permette di costruire la baseline senza bloccare il traffico. Le regole possono essere introdotte prima in modalità di monitoraggio, poi rese vincolanti dopo avere verificato gli effetti sul processo.

4. Usare identità forti dove possibile

I requisiti di acquisto dovrebbero includere identità univoca, autenticazione reciproca, gestione sicura delle chiavi, aggiornamenti firmati, secure boot, logging, cancellazione protetta dei dati e dichiarazione della durata del supporto.

Il NIST IR 8259A propone una baseline di capacità per i dispositivi IoT che comprende identificazione, configurazione, protezione dei dati, controllo degli accessi alle interfacce, aggiornamento sicuro e consapevolezza dello stato di cybersecurity.

5. Segmentare per funzione, non soltanto per sede

Una VLAN generica denominata “IoT” concentra nello stesso dominio oggetti con rischi e comportamenti differenti. La segmentazione dovrebbe seguire funzione e criticità, separando, per esempio, videosorveglianza, building automation, logistica e produzione. I gateway devono consentire esclusivamente i flussi approvati verso applicazioni, cloud e servizi di manutenzione.

Per gli apparati che non possono essere aggiornati, la segmentazione diventa un controllo compensativo: accesso ridotto, monitoraggio più stretto e nessuna esposizione diretta a Internet.

6. Governare accessi remoti e fornitori

Le sessioni di manutenzione devono essere autorizzate per tempo limitato, associate a identità personali, protette da autenticazione forte e registrate. Account condivisi, VPN sempre aperte e porte pubbliche sui dispositivi contraddicono il principio zero trust.

I contratti dovrebbero precisare tempi di correzione delle vulnerabilità, durata degli aggiornamenti, gestione delle chiavi, disponibilità di una software bill of materials (SBOM), modalità di notifica degli incidenti e procedure di uscita dal servizio.

7. Integrare il comportamento nelle decisioni

Quando l’identità tecnica è debole, il comportamento offre un secondo livello di verifica. Un sensore che inizia a eseguire scansioni, una telecamera che invia grandi volumi di dati fuori orario o un gateway che contatta un nuovo dominio devono produrre un segnale valutabile dal SOC.

Le reazioni automatiche vanno calibrate sull’impatto. In ufficio può essere accettabile isolare immediatamente una telecamera; in fabbrica potrebbe essere più sicuro limitare soltanto alcune comunicazioni, avvisare l’operatore e trasferire il processo in una condizione controllata.

8. Misurare copertura ed efficacia

Tra i KPI più utili rientrano la percentuale di dispositivi censiti, quella coperta da policy esplicite, il numero di apparati con firmware fuori supporto, le connessioni non autorizzate bloccate, il tempo necessario per mettere in quarantena un oggetto e la quota di accessi dei fornitori protetta da autenticazione forte.

Va misurato anche l’effetto operativo: una policy molto restrittiva che viene sistematicamente disabilitata offre una protezione solo formale.

Dal rischio tecnico alla responsabilità di filiera

La regolazione europea sta trasferendo parte dell’onere verso chi progetta e commercializza i prodotti. Il Cyber Resilience Act impone requisiti di cybersecurity lungo il ciclo di vita dei prodotti con elementi digitali. Gli obblighi principali si applicheranno dall’11 dicembre 2027; dall’11 settembre 2026 scatteranno quelli relativi alla segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi. In Italia, il decreto legislativo 138/2024 ha recepito la direttiva NIS2, rafforzando gli obblighi di gestione del rischio anche lungo la catena di fornitura per i soggetti interessati.

Queste norme miglioreranno progressivamente le caratteristiche dei nuovi apparati, senza eliminare il parco installato e le sue eredità. Lo zero trust serve soprattutto a governare questa fase di sovrapposizione: dispositivi recenti dotati di identità e aggiornamenti sicuri convivranno ancora a lungo con macchine che possono essere protette soltanto dalla rete e dai processi circostanti.

Per CIO e CISO, la decisione più significativa si prende quindi prima dell’installazione. Ogni nuovo oggetto connesso dovrebbe entrare in azienda con un proprietario, una durata di supporto, un’identità verificabile e un insieme dichiarato di comunicazioni consentite. In assenza di queste condizioni, il debito di sicurezza nasce insieme al dispositivo e può restare acceso molto più a lungo del progetto che lo ha portato in rete.