La frase «Data Act, 12 settembre 2026, segnalazione degli incidenti entro 24 ore» sovrappone due norme. Il Data Act si applica in generale dal 12 settembre 2025; inoltre, il suo articolo 50 stabilisce che l’obbligo dell’articolo 3(1) — progettare prodotti connessi e servizi correlati affinché determinati dati siano accessibili all’utente secondo le condizioni previste — riguarda quelli immessi sul mercato dopo il 12 settembre 2026. Ma la segnalazione cyber entro 24 ore non viene dal Data Act.
L’early warning entro 24 ore per vulnerabilità attivamente sfruttate e incidenti gravi dei prodotti con elementi digitali è previsto dal Cyber Resilience Act (CRA), articolo 14, applicabile dall’11 settembre 2026. Due date consecutive, due obblighi diversi.
Tre regole diverse sullo stesso oggetto connesso
Un macchinario connesso può essere, nello stesso momento, un bene industriale, un generatore di dati e un prodotto che incorpora hardware e software esposti a rischi cyber. È proprio questo il motivo per cui, nel 2026, parlare genericamente di “normativa IoT” è diventato fuorviante: le regole europee si sovrappongono, ma non fanno la stessa cosa.
Domanda chiave: chi può accedere e usare i dati generati dall’uso del prodotto connesso?
Applicabile dal 12 settembre 2025; art. 3(1) per prodotti/servizi immessi sul mercato dopo il 12 settembre 2026.
Domanda chiave: il prodotto digitale è gestito in modo sicuro e, se emerge un evento grave, il fabbricante lo segnala nei tempi previsti?
Reporting dal 11 settembre 2026; applicazione generale dal 11 dicembre 2027.
Domanda chiave: l’organizzazione soggetta alla direttiva gestisce il rischio cyber e notifica gli incidenti significativi che impattano i suoi servizi?
In Italia recepita con D.Lgs. 138/2024.
Il punto più importante è quindi separare sicurezza del prodotto, sicurezza dell’organizzazione e governance dei dati. Un singolo incidente può toccare due o tutti e tre questi livelli, ma le condizioni di notifica, i destinatari e le informazioni richieste non sono automaticamente coincidenti.
CRA: le 24 ore sono l’inizio, non la fine
Dal 11 settembre 2026 il CRA obbliga i fabbricanti di prodotti con elementi digitali a notificare due categorie di eventi: una vulnerabilità attivamente sfruttata di cui vengano a conoscenza e un incidente grave che incida sulla sicurezza del prodotto. Il regolamento non impone, quindi, di notificare entro 24 ore ogni anomalia, ogni CVE o ogni malfunzionamento: la classificazione dell’evento resta decisiva.
Per gli incidenti, la soglia di “gravità” è legata alla capacità del prodotto di proteggere disponibilità, autenticità, integrità o riservatezza di dati o funzioni, oppure alla possibile introduzione o esecuzione di codice malevolo nel prodotto o nei sistemi dell’utilizzatore. Questo rende il triage tecnico-giuridico molto più importante di quanto suggerisca la semplice formula “24 ore”.
La notifica CRA passa attraverso la Single Reporting Platform (SRP) di ENISA. La Commissione indica che la piattaforma sarà operativa entro l’11 settembre 2026; al 27 agosto 2026 ENISA sta pubblicando istruzioni operative per gli Assigned Representatives, con guida aggiornata anche il 14 agosto 2026 per le funzioni dell’interfaccia. L’accesso degli AR usa EU Login.
La notifica è instradata al CSIRT designato come coordinatore in base allo stabilimento principale del fabbricante nell’Unione ed è resa accessibile a ENISA, salvo circostanze eccezionali previste dalla disciplina. C’è poi un obbligo spesso trascurato nelle sintesi: dopo aver appreso di una vulnerabilità attivamente sfruttata o di un incidente grave, il fabbricante deve informare gli utenti impattati e, quando appropriato, tutti gli utenti, indicando le misure di mitigazione o correzione che possono adottare.
Le disposizioni transitorie del CRA precisano che l’articolo 14 si applica anche ai prodotti con elementi digitali rientranti nel regolamento che sono stati immessi sul mercato prima dell’11 dicembre 2027. In pratica, la procedura di incident reporting non può essere progettata pensando soltanto ai nuovi prodotti che usciranno dopo la piena applicazione del CRA: occorre conoscere anche l’installato già distribuito.
Chi deve notificare, e quando un macchinario è davvero nel perimetro
La formula “chi mette sul mercato un prodotto con componenti digitali” è utile per introdurre il tema, ma giuridicamente è troppo larga. L’articolo 14 pone il reporting in capo al fabbricante. Importatori e distributori hanno obblighi propri; tuttavia possono essere considerati fabbricanti, e quindi ricadere anche negli articoli 13 e 14, quando immettono il prodotto sul mercato con il proprio nome o marchio oppure effettuano una modifica sostanziale.
Quanto al prodotto, il CRA copre i prodotti con elementi digitali messi a disposizione sul mercato quando la loro destinazione d’uso o un uso ragionevolmente prevedibile comprende una connessione logica o fisica, diretta o indiretta, a un dispositivo o a una rete. Un macchinario industriale con PLC, firmware, gateway, interfaccia Ethernet, Wi-Fi, modem cellulare o componente software connesso è quindi molto spesso un candidato naturale al perimetro CRA. Ma “connesso” non significa automaticamente “sempre incluso”: il regolamento contiene esclusioni e coordinamenti settoriali, per esempio per alcuni dispositivi medici, veicoli soggetti a specifica omologazione e prodotti aeronautici certificati in altri quadri normativi.
| Evento | CRA Art. 14 | NIS2 / D.Lgs. 138 | Nota operativa |
|---|---|---|---|
| Vulnerabilità nota nel firmware, ma nessuna evidenza affidabile di sfruttamento | Non è, per questo solo fatto, una “vulnerabilità attivamente sfruttata” da notificare obbligatoriamente | Dipende dall’impatto sui servizi dell’entità soggetta | Avviare vulnerability handling; valutare disclosure volontaria e rischio reale |
| Exploit confermato contro una versione di prodotto già installata | Potenzialmente sì | Possibile, se l’evento produce un incidente significativo sull’entità | Far partire il clock di consapevolezza e preservare evidenze |
| Ransomware sull’ERP del fabbricante, senza impatto sulla sicurezza del prodotto | Non automaticamente | Possibile se rientra nelle soglie NIS2 | Non confondere incidente IT aziendale e incidente di sicurezza del prodotto |
| Compromissione del servizio cloud necessario a una funzione del dispositivo, con impatto su integrità o disponibilità | Da valutare con attenzione | Possibile obbligo parallelo | Mappare prodotto, servizio remoto, utenti e Stati interessati |
La tabella è una guida di classificazione, non una determinazione legale del singolo caso: la qualificazione dipende dai fatti, dal ruolo dell’impresa e dalle soglie applicabili.
Data Act: il cambio di paradigma è sui dati dell’IoT
Il Data Act non introduce il reporting cyber delle 24 ore. Il suo effetto sull’IoT è diverso: rafforza i diritti dell’utente sui dati generati dall’uso del prodotto connesso e impone di ripensare come quei dati vengono resi accessibili. Ed è qui che il 12 settembre 2026 torna davvero in gioco.
Il regolamento è applicabile dal 12 settembre 2025, ma contiene una transizione specifica: l’obbligo dell’articolo 3(1) si applica ai prodotti connessi e ai servizi correlati immessi sul mercato dopo il 12 settembre 2026. Per questi prodotti, i dati del prodotto e del servizio correlato devono essere, per impostazione predefinita, accessibili all’utente in modo facile, sicuro, gratuito, strutturato e leggibile da macchina; quando pertinente e tecnicamente possibile, l’accesso deve poter essere diretto. Se non lo è, il data holder deve rendere disponibili i dati prontamente disponibili e i metadati secondo le condizioni dell’articolo 4.
La Commissione chiarisce che il capitolo IoT riguarda in linea generale i dati grezzi e pretrattati generati dall’uso del prodotto o del servizio correlato e prontamente disponibili al data holder, insieme ai metadati necessari a interpretarli. I dati inferiti o derivati ad alto valore aggiunto non entrano automaticamente nello stesso perimetro.
L’accesso ai dati deve essere progettato in modo sicuro. Il Data Act consente inoltre, in condizioni specifiche, di limitare o vietare accesso, uso o ulteriore condivisione quando ciò potrebbe compromettere requisiti di sicurezza del prodotto previsti dal diritto UE o nazionale e provocare un grave effetto negativo su salute, safety o security delle persone. La governance dei dati IoT, quindi, non può essere separata dalla threat model del prodotto.
Per la gestione quotidiana questo significa rivedere API, portali clienti, meccanismi di esportazione, gestione delle identità, autorizzazioni, log di accesso e contratti. “Rendere il dato disponibile” non equivale a “aprire indiscriminatamente il dispositivo”: l’architettura deve consentire portabilità e uso legittimo senza trasformare l’interfaccia dati in un nuovo canale d’attacco.
NIS2: quando l’incidente riguarda anche l’organizzazione
NIS2 lavora su un livello diverso dal CRA: non guarda in primo luogo al prodotto venduto, ma alla sicurezza delle reti e dei sistemi dell’entità e alla continuità dei servizi rientranti nel suo perimetro. La direttiva include, tra gli altri, settori manifatturieri quali dispositivi medici, computer ed elettronica, macchinari e apparecchiature, veicoli e altri mezzi di trasporto, secondo le condizioni dimensionali e di classificazione previste.
In Italia la direttiva è stata recepita con il decreto legislativo 4 settembre 2024, n. 138, entrato in vigore il 16 ottobre 2024. Per gli incidenti significativi l’articolo 25 prevede una pre-notifica entro 24 ore dalla conoscenza, una notifica entro 72 ore e una relazione finale entro un mese, con ulteriori aggiornamenti nei casi previsti. È una scansione temporale simile a quella del CRA, ma non va confusa con essa: cambiano il presupposto, il soggetto obbligato, la nozione di incidente e il canale nazionale.
Il 26 maggio 2026 il NIS Cooperation Group ha adottato modelli comuni per l’incident reporting NIS2; la Commissione ha indicato come passo successivo un atto di esecuzione per renderli obbligatori. Parallelamente il Digital Omnibus propone un futuro single-entry point europeo per più obblighi di notifica cyber. Al 27 agosto 2026, però, va trattato come percorso di semplificazione in evoluzione, non come motivo per presumere che una notifica CRA assolva automaticamente gli obblighi NIS2, GDPR o settoriali.
Cosa cambia davvero nella gestione dell’IoT
Il vero salto organizzativo non è “imparare a compilare un modulo entro 24 ore”. È costruire una gestione dell’IoT capace di stabilire che cosa è successo, quale prodotto è coinvolto, chi ne è giuridicamente responsabile, quali utenti sono esposti e quali obblighi partono in parallelo. Senza queste informazioni, il cronometro delle 24 ore diventa un problema operativo prima ancora che normativo.
La prima urgenza: sapere che cosa è installato
Per un costruttore di macchine la gestione del parco installato diventa un asset di compliance. Seriali, configurazioni, versioni firmware, componenti, Paesi in cui il prodotto è disponibile e contatti dei clienti non servono solo al service: diventano dati essenziali per capire la diffusione di una vulnerabilità e per avvisare gli utenti in modo mirato.
La seconda: stabilire quando parte il cronometro
Il CRA fa decorrere i termini dalla conoscenza dell’evento da parte del fabbricante. Questo rende pericolosi i flussi informali: una segnalazione inviata a un commerciale, un ticket chiuso male, un alert del SOC non classificato o una mail di un ricercatore possono creare ambiguità sul momento in cui l’organizzazione ha acquisito consapevolezza. Serve un canale di intake unico, con timestamp, ownership e criteri di escalation.
La terza: prepararsi alla SRP senza creare una burocrazia parallela
ENISA prevede Assigned Representatives primari e secondari e autenticazione mediante EU Login. La sua guida di agosto 2026 segnala che la validazione dell’associazione tra rappresentante e fabbricante avviene in parallelo al reporting e non impedisce di trasmettere una notifica. ENISA suggerisce inoltre di non creare preventivamente associazioni non necessarie solo per “prenotarsi” sulla piattaforma: è invece sensato predisporre EU Login, deleghe interne, nominativi primario/backup e un esercizio di simulazione.
La quarta: non aspettare il 2027 per costruire la disciplina tecnica
Molti requisiti di secure-by-design, vulnerability handling, documentazione e supporto del CRA diventeranno pienamente applicabili nel dicembre 2027. Ma un’organizzazione che oggi non sa correlare un exploit a versioni, componenti e utenti avrà difficoltà a rispettare già il reporting del settembre 2026. Per l’IoT industriale, riferimenti come IEC 62443 per il lifecycle di sicurezza dei prodotti IACS e le metodologie OWASP dedicate all’IoT possono essere usati come supporto tecnico e di testing: non sostituiscono la legge, ma aiutano a trasformare l’obbligo giuridico in processi verificabili.
Timeline essenziale 2025–2027
AGO
25
SET
25
SET
26
SET
26
GEN
27
DIC
27
Per le imprese che producono o gestiscono macchinari connessi, questo è probabilmente il cambiamento più concreto. Il “dispositivo IoT” non può più essere amministrato come un oggetto isolato: è un nodo di una catena che comprende componenti software, servizi remoti, dati generati dall’uso, identità degli utenti, canali di aggiornamento, fornitori e obblighi di notifica. La compliance efficace nasce dalla capacità di tenere insieme questi pezzi, non dalla moltiplicazione dei moduli.
In sintesi
La formula da ricordare è questa. 12 settembre 2025: il Data Act diventa applicabile in generale. 11 settembre 2026: il CRA articolo 14 attiva l’early warning entro 24 ore, seguito dalla notifica a 72 ore e dal rapporto finale. Dopo il 12 settembre 2026: l’obbligo Data Act dell’articolo 3(1) si applica ai nuovi prodotti connessi e servizi correlati immessi sul mercato. NIS2 resta il livello organizzativo e di servizio, con un proprio regime di incident reporting.
Per un costruttore di macchine connesse, la priorità del 2026 non è soltanto adeguare il prodotto futuro: è mettere ordine nel presente — inventario del parco installato, ownership delle vulnerabilità, procedure di triage, evidenze, responsabilità di notifica, comunicazione agli utenti e mappatura degli obblighi paralleli. È qui che il diritto europeo sull’IoT smette di essere un tema “normativo” e diventa architettura operativa.
Fonti e riferimenti verificabili
Le fonti normative e istituzionali sono state privilegiate rispetto a riassunti e post secondari. Le fonti tecniche non normative sono utilizzate solo come supporto metodologico. Date e stato delle pagine sono quelli rilevati o dichiarati dalle fonti alla verifica del 27 agosto 2026.
| Fonte | Data / aggiornamento | Uso nell’articolo | URL |
|---|---|---|---|
| Norma UE Regolamento (UE) 2024/2847 — Cyber Resilience Act, EUR-Lex | GUUE 20 novembre 2024; versione vigente consultata 27 agosto 2026 | Art. 2 (campo di applicazione), art. 14 (reporting), art. 21, art. 64, art. 69 e 71 | eur-lex.europa.eu/eli/reg/2024/2847/oj/ita |
| Commissione UE Cyber Resilience Act — Reporting obligations | Ultimo aggiornamento: 31 luglio 2026 | 11 settembre 2026, 24h/72h/finale, SRP | digital-strategy.ec.europa.eu/it/policies/cra-reporting |
| Commissione UE Guidance C(2026) 5252 sull’applicazione del CRA | Pubblicazione e ultimo aggiornamento: 27 luglio 2026 | Chiarimenti pratici su perimetro, modifiche, support period, reporting e risk assessment | digital-strategy.ec.europa.eu/…/cra-implementation |
| ENISA Single Reporting Platform (SRP) e FAQ | FAQ aggiornate 3 agosto 2026; guida interfaccia AR aggiornata 14 agosto 2026 | Ruoli, EU Login, workflow, AR primario/backup, SRP | enisa.europa.eu/topics/product-security/single-reporting-platform-srp |
| Norma UE Regolamento (UE) 2023/2854 — Data Act, EUR-Lex | GUUE 22 dicembre 2023; applicabile dal 12 settembre 2025 | Art. 3 e 4: accesso ai dati; art. 50: applicazione generale dal 12/09/2025 e transizione dell’art. 3(1) per prodotti/servizi immessi sul mercato dopo il 12/09/2026 | eur-lex.europa.eu/eli/reg/2023/2854 |
| Commissione UE Data Act — pagina di attuazione | Ultimo aggiornamento: 2 luglio 2026 | Ambito IoT, macchinari industriali, diritti di accesso | digital-strategy.ec.europa.eu/it/policies/data-act |
| Commissione UE Data Act FAQ v1.4 | Versione 1.4: 22 gennaio 2026; pagina aggiornata 3 marzo 2026 | Chiarimenti interpretativi sul Data Act | digital-strategy.ec.europa.eu/…/data-act-faq |
| Italia · fonte primaria D.Lgs. 4 settembre 2024, n. 138 — recepimento NIS2 | GU n. 230 del 1 ottobre 2024; entrata in vigore 16 ottobre 2024 | Art. 25: pre-notifica 24h, notifica 72h, relazione finale | gazzettaufficiale.it/eli/id/2024/10/01/24G00155/SG |
| Commissione UE NIS2 Cooperation Group — modelli comuni di incident reporting | 26 maggio 2026 | Stato della semplificazione NIS2 nel 2026 | digital-strategy.ec.europa.eu/…/nis2-common-templates |
| Norma UE Regolamento (UE) 2023/1230 — Macchine | Testo consolidato consultato 27 agosto 2026; applicazione generale 20 gennaio 2027 | Timeline regolatoria per i macchinari | eur-lex.europa.eu/eli/reg/2023/1230/it |
| Norma UE Regolamento delegato (UE) 2026/339 | 2026 | Coordinamento tra requisiti cybersecurity RED e piena applicazione CRA | eur-lex.europa.eu/eli/reg_del/2026/339/oj/ita |
| Tecnica · nonprofit OWASP IoT Security Verification Standard | Versione 1.0, ottobre 2025 | Riferimento tecnico per requisiti e verifica dell’ecosistema IoT; non è fonte normativa | owasp.org/IoT-Security-Verification-Standard-ISVS/ |
| Standard tecnico IEC 62443-4-1 / ISA-IEC 62443 | IEC 62443-4-1:2018; serie in evoluzione, riferimenti verificati 27 agosto 2026 | Secure product development lifecycle per IACS; testo completo dello standard può essere a pagamento | webstore.iec.ch/en/publication/33615 |
Per date, scadenze e obblighi sono state utilizzate prioritariamente fonti originarie: EUR-Lex, Commissione europea, ENISA, Gazzetta Ufficiale italiana. Le fonti tecniche OWASP/IEC sono citate come supporto operativo e non come fonte del contenuto normativo. Non sono state utilizzate come prova primaria cifre o affermazioni rinvenute soltanto in blog, post o riassunti di terzi.