L’adozione massiva di dispositivi IoT sta trasformando case, ospedali, fabbriche, pagamenti, logistica e servizi pubblici in ecosistemi iperconnessi.
Il problema non è solo la sicurezza informatica del dispositivo, ma la governance dei dati che esso raccoglie, inferisce, conserva e condivide.
La mancanza di uno standard universale di privacy per l’IoT espone utenti e organizzazioni a rischi sistemici: profilazione occulta, inferenze comportamentali, uso secondario dei dati, vendor lock-in informativo, difficoltà di esercizio dei diritti GDPR.
Per i CISO, il tema non può più restare confinato al perimetro legale: deve diventare un requisito architetturale, contrattuale e operativo.
La comodità come superficie di trattamento
La storia dell’Internet of Things è stata raccontata, per anni, come una storia di efficienza: sensori che misurano, attuatori che rispondono, algoritmi che ottimizzano, piattaforme cloud che aggregano.
Nella smart home, il termostato apprende le abitudini domestiche; la videocamera riconosce movimento e presenza; l’assistente vocale resta in ascolto del comando di attivazione.
Nell’Internet of Medical Things, wearable, pompe insuliniche, monitor cardiaci e piattaforme di telemedicina raccolgono dati fisiologici con frequenza e granularità impensabili per la medicina tradizionale.
È proprio qui che nasce il paradosso. La comodità richiede prossimità al corpo, all’ambiente e alla routine. Più il servizio è “smart”, più deve conoscere contesto, abitudini, preferenze, anomalie, tempi di vita.
Come osservano Rizvi, Demeri e Rizvi in “Convenience at a Cost: The Urgent Need for Data Privacy Standards”, – ripubblicato da IEEE sulla rivista “Computing Edge” di aprile – la convenienza offerta dall’IoT arriva spesso al prezzo della privacy, perché i dispositivi raccolgono dati medici, finanziari, biometrici, localizzativi e comportamentali senza che esista un modello universale di data privacy specificamente progettato per reti IoT [1].
La questione, quindi, non è se l’IoT raccolga dati. Sarebbe ingenuo: l’IoT esiste per misurare.
La questione è se le organizzazioni siano in grado di dimostrare, in modo tecnico e verificabile, quali dati vengono raccolti, per quale finalità, per quanto tempo, con quali inferenze, verso quali terze parti, con quali basi giuridiche, con quali meccanismi di revoca e con quali garanzie di cancellazione effettiva.
Security is not privacy
Nel linguaggio aziendale, “sicuro” viene spesso usato come sinonimo di “protetto”. Ma, nell’IoT, un dispositivo può essere cifrato, autenticato e aggiornabile e restare comunque intrusivo.
La sicurezza protegge il dato da accessi e modifiche non autorizzati; la privacy disciplina invece la raccolta, l’uso, la correlazione, la condivisione e la riconducibilità del dato a una persona o a un gruppo.
Il modello CIA – Confidentiality, Integrity, Availability – rimane un fondamento della sicurezza informativa. Ma non basta a governare l’IoT.
Non risponde, da solo, a domande essenziali: il dato era necessario? Era proporzionato? È stato usato per una finalità compatibile? È stato aggregato con altri flussi? Può rivelare routine, salute, presenza in casa, fragilità, preferenze, relazioni sociali? Può produrre inferenze anche senza contenere identificativi diretti?
Il caso delle videocamere domestiche
L’esempio più istruttivo riguarda le videocamere domestiche: anche osservando solo traffico cifrato, ricercatori hanno mostrato la possibilità di inferire stato operativo e routine quotidiane attorno alla videocamera [1].
Questo punto è decisivo per i CISO: la cifratura è necessaria, ma non è una strategia privacy completa. I metadati, i pattern temporali, la frequenza di comunicazione, le destinazioni cloud e la volumetria dei flussi possono diventare dati personali o quasi-personali quando consentono inferenze su comportamenti e presenza.
In altri termini: nell’IoT, il rischio privacy non nasce soltanto dal contenuto del pacchetto, ma anche dalla semantica del contesto.
Il vuoto degli standard universali
Esistono norme, linee guida e standard importanti. Il GDPR impone principi di liceità, trasparenza, minimizzazione, limitazione della conservazione, integrità, riservatezza e accountability; l’articolo 25 codifica la data protection by design e by default; l’articolo 32 richiede misure tecniche e organizzative adeguate al rischio [2].
Le linee guida EDPB sull’articolo 25 chiariscono che la protezione dei dati deve essere incorporata nella progettazione del trattamento, non aggiunta ex post [3].
Sul piano tecnico, ETSI EN 303 645 ha definito una baseline di sicurezza per il consumer IoT, includendo requisiti come assenza di password universali predefinite, gestione delle vulnerabilità, aggiornamenti software, protezione delle credenziali e sicurezza delle comunicazioni [4]. NISTIR 8259 e NIST SP 800-213 offrono riferimenti robusti per produttori e organizzazioni che devono definire requisiti cyber per dispositivi IoT [5][6].
ENISA ha affrontato la sicurezza IoT lungo la supply chain e il ciclo di vita del prodotto [7].
Il Cyber Resilience Act europeo spinge inoltre verso obblighi orizzontali di cyber security per prodotti con elementi digitali, imponendo sicurezza lungo progettazione, sviluppo, manutenzione e gestione delle vulnerabilità [8].
Nel settore clinico, IEEE/UL 2933-2024 introduce il paradigma TIPPSS: Trust, Identity, Privacy, Protection, Safety, Security [9].
Eppure manca ancora un punto di convergenza: uno standard universale, interoperabile e verificabile che traduca la privacy IoT in requisiti tecnici, schemi di attestazione, interfacce di consenso, metadati di trattamento e controlli auditabili lungo l’intero ecosistema dispositivo-app-cloud-terze parti.
Oggi il mercato è frammentato. Ogni produttore definisce il proprio modello di raccolta dati, la propria informativa, le proprie API, la propria logica di retention, i propri canali cloud, la propria granularità di consenso.
Per l’utente è quasi impossibile comparare. Inoltre, per il DPO è difficile ricostruire l’intera catena di trattamento. Per il CISO è complesso trasformare requisiti privacy in controlli tecnici misurabili. Invece, per il procurement è arduo distinguere un dispositivo realmente privacy-preserving da un prodotto soltanto “compliant by brochure”.
Il rischio IoMT: quando il dato è anche cura
L’Internet of Medical Things porta il problema a un livello superiore. Qui il dato non descrive soltanto un’abitudine: può descrivere patologie, terapie, disabilità, fragilità, aderenza farmacologica, parametri vitali.
In sanità, inoltre, la disponibilità del dato è parte della continuità clinica. Un breach o un’interruzione non colpisce solo la confidenzialità, ma può degradare la qualità della cura.
Gli incidenti richiamati dalla letteratura recente – dalla compromissione di portali paziente e servizi sanitari fino all’impatto operativo di attacchi ransomware su grandi operatori healthcare – mostrano che la protezione del dato clinico non può essere separata dalla resilienza del servizio [1].
Ma la risposta non può ridursi a un generico hardening tecnico. Occorre progettare architetture in cui sicurezza, privacy, safety e continuità siano co-ingegnerizzate.
In IoMT, un requisito privacy mal progettato può diventare anche un rischio clinico:
- una cancellazione non governata può compromettere tracciabilità terapeutica;
- una retention eccessiva può esporre dati sanitari senza necessità;
- un consenso non granulare può rendere opaco il riuso secondario dei dati;
- una piattaforma cloud non governata può trasformare il wearable in un terminale di sorveglianza sanitaria permanente.
Cosa deve cambiare: i 5 passaggi verso uno standard privacy IoT
Per le aziende, conformarsi al GDPR nell’IoT non significa solo aggiornare informative o nominare responsabili del trattamento.
Significa trasformare i principi privacy in requisiti di architettura.
Il primo passaggio è costruire un inventario vivo dei trattamenti IoT. Non basta censire il dispositivo come asset.
Occorre mappare sensori, dati grezzi, dati derivati, frequenza di raccolta, finalità, basi giuridiche, retention, destinazioni, subfornitori, API, log, modelli di inferenza, aggiornamenti firmware e canali di telemetria.
Il registro dei trattamenti deve dialogare con CMDB, asset inventory, vulnerability management, vendor management e data catalog.
Il secondo passaggio è introdurre DPIA e threat modeling privacy-oriented fin dalla fase di procurement e design.
Accanto a STRIDE o ad altri modelli di threat modeling cyber, servono metodi orientati alla privacy come LINDDUN, capaci di analizzare linkability, identifiability, non-repudiation indesiderata, detectability, information disclosure, unawareness e non-compliance.
In ambito IoT, la DPIA non deve essere un documento finale: deve diventare una gate review architetturale.
Il terzo passaggio è imporre minimizzazione tecnica. Dove possibile:
- il dato deve essere trattato on-device o at-edge;
- i flussi verso cloud devono essere ridotti a eventi, alert o feature aggregate;
- la raccolta continua deve essere sostituita da raccolta contestuale;
- la retention deve essere parametrica, limitata e cancellabile;
- i dati biometrici e sanitari devono essere protetti con segregazione logica, cifratura forte, gestione robusta delle chiavi e pseudonimizzazione reale, non cosmetica.
Il quarto passaggio riguarda il consenso. Nei dispositivi IoT, il consenso non può essere nascosto in una schermata mobile letta una sola volta. Deve diventare una funzione di sistema: granulare, revocabile, temporizzata, comprensibile, esportabile.
Un assistente domestico dovrebbe permettere di distinguere comandi vocali, registrazioni, trascrizioni, diagnostica, miglioramento del servizio, condivisione con terze parti e retention.
Un wearable sanitario dovrebbe separare dato clinico necessario, dato statistico, dato di ricerca e dato commerciale.
Il quinto passaggio è contrattuale. Ogni fornitore IoT deve essere valutato con una security & privacy schedule che includa data mapping, localizzazione, subprocessor flow-down, vulnerability disclosure, patching, logging, breach notification, audit rights, secure decommissioning, portabilità e cancellazione verificabile.
La clausola “il fornitore è GDPR compliant” non è più sufficiente: occorrono evidenze.
Architetture by design: il modello operativo per i CISO
Un’architettura IoT privacy-by-design dovrebbe fondarsi su alcuni controlli minimi.
Primo: identità forte del dispositivo. Ogni device deve avere identità univoca, credenziali non condivise, rotazione sicura, certificati o meccanismi equivalenti, onboarding governato e revoca in caso di dismissione o compromissione.
Secondo: segmentazione e controllo dei flussi. Le reti IoT non devono essere reti “piatte”. Servono VLAN dedicate, microsegmentazione, NAC, policy di egress allowlist, broker sicuri, separazione tra rete utente, rete dispositivi, rete amministrativa e rete clinica o industriale.
L’obiettivo non è solo ridurre la propagazione di un attacco, ma impedire correlazioni e trasferimenti non necessari.
Terzo: telemetria minimizzata. Il principio dovrebbe essere “collect less, infer less, retain less”. La telemetria necessaria per sicurezza e manutenzione deve essere separata dalla telemetria commerciale.
Le finalità devono essere leggibili anche da sistemi di controllo automatico, non solo da informative legali.
Quarto: lifecycle security. Secure boot, firmware firmato, SBOM, patch management, vulnerability disclosure, hardening, test di penetrazione, configurazioni sicure by default e fine vita dichiarata sono requisiti ormai imprescindibili.
Ma devono essere connessi alla privacy: un dispositivo non aggiornabile diventa anche un rischio data protection.
Quinto: privacy observability. Le organizzazioni dovrebbero monitorare non soltanto eventi di sicurezza, ma eventi di trattamento: nuovi endpoint cloud, variazioni nei flussi, dichiarate, retention non conforme, log non cancellati. Il SOC del futuro, in ambienti IoT maturi, dovrà dialogare con funzioni privacy e data governance.
Sesto: privacy manifest. Come oggi si parla di SBOM per il software, l’IoT ha bisogno di un “Data Protection Bill of Materials”: un manifesto machine-readable che descriva categorie di dati, finalità, basi giuridiche, retention, destinazioni, inferenze abilitate, modelli di consenso, cancellazione, portabilità e contatti del responsabile.
Senza una semantica standardizzata, la privacy resterà non confrontabile.
La supply chain come catena di inferenze
La privacy IoT non si esaurisce nel produttore del dispositivo. App mobile, SDK, cloud provider, analytics provider, manutentori, integratori, vendor di AI, piattaforme di notifica e marketplace creano una catena di trattamento spesso più ampia della catena tecnica visibile.
Per questo motivo, la gestione del rischio terze parti deve includere domande specifiche: quali dati lascia il dispositivo? Invece, quali dati restano localmente? Quali dati sono trasferiti nel cloud? Quali subfornitori ricevono telemetria? Gli SDK raccolgono identificativi pubblicitari o diagnostica? Le API consentono esportazione massiva? Esistono ambienti separati per sviluppo, test e produzione? I log contengono dati personali? Le cancellazioni utente propagano davvero a backup, cache, data lake e sistemi di analytics?
Un CISO deve portare queste domande nel procurement. Il DPO deve trasformarle in requisiti di liceità e accountability. Il Legal deve invece tradurle in clausole verificabili. L’IT deve implementarle in architettura. Il business deve accettare che non ogni dato utile è anche necessario.
Dal GDPR allo standard universale: una proposta pragmatica per la privacy IoT
Il GDPR fornisce i principi. Gli standard cyber forniscono molte baseline tecniche. Però, il mercato IoT richiede un livello intermedio: uno standard operativo universale che renda la privacy misurabile per device, piattaforma e servizio.
Un tale standard dovrebbe includere almeno i seguenti requisiti:
- diritto di accesso tecnico ai dati generati dal device;
- rettifica dove applicabile; cancellazione propagata; opt-out e opt-in granulari;
- minimizzazione dimostrabile;
- notifica di violazione entro tempi definiti;
- retention limitata e automatizzata;
- non discriminazione verso chi sceglie opzioni privacy più restrittive;
- privacy by default; trasparenza sulle inferenze.
Questi elementi sono già presenti, in forme diverse, nelle principali normative privacy e nelle proposte richiamate dalla letteratura [1][2].
Il salto necessario è portarli dal piano giuridico al piano ingegneristico.
Non basta affermare il diritto alla cancellazione: il dispositivo e la piattaforma devono avere procedure, API e log di prova della cancellazione. Neanche basta dichiarare minimizzazione: il firmware deve impedire raccolte eccedenti. Non basta neppure invocare trasparenza: l’utente e l’organizzazione devono poter vedere, esportare e verificare cosa viene trattato.
Il futuro sarà connesso, ma non deve essere predatorio
L’IoT non è un incidente di percorso della trasformazione digitale: è il suo tessuto connettivo.
Entrerà sempre più in case, ospedali, fabbriche, mezzi di trasporto, reti energetiche, città, dispositivi indossabili e sistemi di cura.
Fermarlo non è realistico. Governarlo è urgente.
La sfida non è scegliere tra innovazione e privacy. La vera innovazione, ormai, è quella che riduce il costo invisibile della comodità.
Le aziende che sapranno progettare dispositivi e reti IoT con privacy by design, sicurezza by default, standard aperti, controlli verificabili e accountability lungo la supply chain avranno unvantaggio competitivo: fiducia, resilienza, minor esposizione regolatoria e maggiore qualità del dato.
Per i CISO, il messaggio è netto: l’IoT non va trattato come una periferica, ma come un ecosistema di dati personali, inferenze e responsabilità.
La sicurezza senza privacy è incompleta; la privacy senza architettura è retorica.
Servono invece standard universali perché, in un mondo di oggetti connessi, la protezione dei dati non può dipendere dalla buona volontà del singolo produttore.
La comodità può restare. Ma il suo costo non deve più essere pagato con la vita privata degli utenti.
Fonti essenziali
[1] Syed Rizvi, Anthony Demeri, Mohammad R. Rizvi, “Convenience at a Cost: The Urgent Need for Data Privacy Standards”, Computer, vol. 58, no. 10, 2025, DOI 10.1109/MC.2025.3591041; ripubblicato in ComputingEdge, aprile 2026, pp. 44-49.
[2] Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, General Data Protection Regulation, 27 aprile 2016.
[3] European Data Protection Board, Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, versione 2.0.
[4] ETSI EN 303 645 V3.1.3, Cyber Security for Consumer Internet of Things: Baseline Requirements, settembre 2024.
[5] NISTIR 8259 Series, Foundational Cybersecurity Activities and IoT Device
Cybersecurity Capability Core Baseline.
[6] NIST SP 800-213, IoT Device Cybersecurity Guidance for the Federal Government, 2021.
[7] ENISA, Guidelines for Securing the Internet of Things: Secure Supply Chain for IoT, 2020.
[8] Regolamento (UE) 2024/2847, Cyber Resilience Act, 23 ottobre 2024.
[9] IEEE/UL 2933-2024, Standard for Clinical Internet of Things Data and Device Interoperability with TIPPSS — Trust, Identity, Privacy, Protection, Safety and Security.
[10] D. Buil-Gil et al., “The digital harms of smart home devices: A systematic literature review”, Computers in Human Behavior, vol. 145, 2023, DOI
10.1016/j.chb.2023.107770.
[11] J. Li, Z. Li, G. Tyson, G. Xie, “Characterising usage patterns and privacy risks of a home security camera service”, IEEE Transactions on Mobile Computing, vol. 21, no. 7, 2022, DOI 10.1109/TMC.2020.3039787.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Aldo Ceccarelli
Source link
