RED Delegated Act ed EN 18031 per dispositivi radio connessi

Per molti prodotti wireless venduti nel mercato europeo, la cybersecurity è già un requisito collegato alla Radio Equipment Directive (Direttiva 2014/53/UE). Il Regolamento delegato (UE) 2022/30, noto come RED Delegated Act, ha attivato i requisiti essenziali di cybersecurity previsti dall’Articolo 3(3), lettere d, e e f della Direttiva RED, che riguardano protezione della rete, tutela dei dati personali e della privacy, e protezione dalle frodi. Il regolamento si applica dal 1° agosto 2025, come stabilito dal testo consolidato pubblicato su EUR-Lex.

Produttori, OEM, importatori, distributori e aziende che commercializzano dispositivi radio connessi devono quindi considerare la cybersecurity come parte del percorso tecnico verso la marcatura CE.

Gli standard armonizzati EN 18031-1:2024, EN 18031-2:2024 ed EN 18031-3:2024 sono stati pubblicati nella Gazzetta Ufficiale dell’Unione Europea tramite la Decisione di esecuzione (UE) 2025/138, con alcune restrizioni. La conformità a questi standard conferisce presunzione di conformità ai requisiti essenziali coperti dalla Direttiva RED a partire dalla pubblicazione dei riferimenti in Gazzetta.

La questione centrale è operativa: come si dimostra tecnicamente che un dispositivo radio è sicuro? ISGroup interviene su questa parte come partner tecnico per verificare, con security assessment, analisi firmware, reverse engineering, hardware e software testing, API security testing, mobile app testing e penetration test controllati, se il dispositivo e il suo ecosistema digitale resistono a scenari di attacco realistici.

Cos’è il RED Delegated Act

La Radio Equipment Directive 2014/53/UE stabilisce il quadro normativo per l’immissione sul mercato europeo delle apparecchiature radio. Il Regolamento delegato (UE) 2022/30 integra la Direttiva RED applicando i requisiti essenziali dell’Articolo 3(3), lettere d, e e f, a specifiche categorie di apparecchiature radio.

Articolo RED	Area	Significato pratico
Art. 3(3)(d)	Protezione della rete	Il dispositivo non deve danneggiare la rete, il suo funzionamento o abusare delle risorse di rete
Art. 3(3)(e)	Protezione dati e privacy	Il dispositivo deve includere salvaguardie per proteggere dati personali e privacy di utenti e abbonati
Art. 3(3)(f)	Protezione dalle frodi	Il dispositivo deve supportare funzioni che proteggano da frodi, dove applicabile

Il regolamento nasce per alzare il livello di cybersecurity di dispositivi sempre più diffusi: prodotti IoT, wearable, smart device, gateway wireless, apparati connessi a Internet, dispositivi che trattano dati personali e prodotti che permettono trasferimenti di denaro, valore monetario o valuta virtuale.

Ambito di applicazione: quali dispositivi rientrano

Il perimetro del RED Delegated Act è più ampio di quanto molti produttori immaginino. Il requisito dell’Articolo 3(3)(d) si applica a qualsiasi apparecchiatura radio che possa comunicare su Internet, direttamente o tramite un altro apparato: il testo consolidato del Regolamento delegato (UE) 2022/30 parla esplicitamente di internet-connected radio equipment anche quando la comunicazione avviene tramite un dispositivo intermedio.

Il requisito dell’Articolo 3(3)(e) si applica, se il dispositivo tratta dati personali, traffico o localizzazione, a dispositivi radio connessi a Internet, dispositivi per childcare, giocattoli radio e dispositivi indossabili. Il requisito dell’Articolo 3(3)(f) riguarda invece le apparecchiature radio connesse a Internet che consentono al titolare o all’utente di trasferire denaro, valore monetario o valuta virtuale.

Categoria	Esempi
Dispositivi Wi-Fi	Smart device, router embedded, controller wireless, smart appliance
Dispositivi Bluetooth	Wearable, sensori, accessori con app mobile, apparati medicali consumer o industriali quando non esclusi
Gateway LTE/5G	Router industriali, edge gateway, apparati per telemetria
LoRaWAN / LPWAN	Sensori industriali, smart metering, dispositivi per smart city
Wearable	Smartwatch, tracker, dispositivi indossabili con dati personali
Childcare radio equipment	Baby monitor e dispositivi simili
Toys radio equipment	Giocattoli con funzionalità radio e trattamento dati
Dispositivi con pagamenti	Terminali, wallet, apparati che gestiscono valore monetario o virtuale
Gateway IoT industriali	Bridge tra macchina, rete OT, cloud e piattaforma di monitoraggio
Smart building / smart city	Sensori, attuatori, sistemi connessi e radio equipment distribuito

Il perimetro non riguarda solo il consumer IoT. Un gateway industriale LTE, un dispositivo Bluetooth in ambito B2B, un sensore wireless per smart grid, un apparato LoRaWAN per utility o un router per manutenzione remota possono rientrare nell’ambito se soddisfano le condizioni previste.

EN 18031-1, EN 18031-2, EN 18031-3: cosa coprono

La Decisione di esecuzione (UE) 2025/138 ha pubblicato i riferimenti agli standard armonizzati della serie EN 18031:2024, collegati ai requisiti cyber della Direttiva RED. La Decisione specifica anche restrizioni rilevanti: le sezioni “rationale” e “guidance” degli standard non conferiscono presunzione di conformità, e per le clausole relative alle password lo standard non conferisce presunzione di conformità se l’utente può non impostare e usare alcuna password.

Standard	Ambito	Requisito RED supportato
EN 18031-1:2024	Requisiti di sicurezza comuni per radio equipment connesso a Internet	Art. 3(3)(d): protezione della rete
EN 18031-2:2024	Requisiti di sicurezza comuni per radio equipment che tratta dati: connesso a Internet, childcare, toys, wearable	Art. 3(3)(e): dati personali e privacy
EN 18031-3:2024	Requisiti di sicurezza comuni per radio equipment connesso a Internet che tratta denaro virtuale o valore monetario	Art. 3(3)(f): protezione dalle frodi

Questo è un dettaglio operativo rilevante: non basta dichiarare di aver applicato EN 18031. Occorre verificare che i requisiti siano stati applicati correttamente e che le restrizioni siano comprese e gestite.

Presunzione di conformità e sicurezza reale: tre errori da evitare

La conformità a uno standard armonizzato pubblicato in Gazzetta Ufficiale può conferire presunzione di conformità ai requisiti essenziali coperti, ma solo entro il perimetro e le condizioni previste. La Decisione (UE) 2025/138 pubblica gli standard EN 18031 con restrizioni specifiche, il che rende necessaria attenzione su tre punti.

Confondere standard e certificazione. EN 18031 è uno standard tecnico. La sua applicazione può supportare la presunzione di conformità, ma non equivale automaticamente a una certificazione cyber del prodotto.

Affidarsi solo alla documentazione. Il technical file deve essere supportato da evidenze. Se il dispositivo presenta vulnerabilità reali su firmware, API, meccanismo di aggiornamento o interfacce radio, la documentazione da sola non è sufficiente.

Testare solo il dispositivo fisico. Molti prodotti radio sono ecosistemi distribuiti: hardware, firmware, app mobile, cloud, API, account utente, dashboard, server di aggiornamento e canali di comunicazione. Il rischio può risiedere fuori dal modulo radio.

Cosa va verificato in pratica

Un dispositivo radio connesso è una superficie d’attacco distribuita. Un assessment tecnico dovrebbe considerare hardware, firmware, bootloader, sistema di aggiornamento, interfacce di debug, comunicazioni radio, app mobile, backend cloud, API, account e ruoli, cifratura, gestione password, storage locale, log, gestione dati personali, meccanismi anti-frode dove presenti, configurazione di default, servizi esposti e supply chain software.

Firmware e meccanismo di aggiornamento

Il firmware è spesso il punto più critico. Le verifiche devono coprire credenziali hardcoded, servizi nascosti, librerie vulnerabili, configurazioni insicure, aggiornamenti non firmati, possibilità di rollback, pacchetti firmware alterabili, interfacce di debug attive, segreti salvati in chiaro e assenza di protezioni di integrità. Alcuni di questi problemi non si risolvono con una patch: se il design dell’aggiornamento è debole o manca una catena di trust robusta, può essere necessario un intervento architetturale.

Password, autenticazione e accesso

Le restrizioni pubblicate con la Decisione (UE) 2025/138 mostrano quanto il tema password sia sensibile: gli standard EN 18031 non conferiscono presunzione di conformità in determinate condizioni se l’utente è lasciato nella possibilità di non impostare e usare alcuna password. Le verifiche devono includere password di default, obbligo di cambio password, complessità minima, credenziali condivise, assenza di autenticazione, session management, protezione da brute force, recovery password, autenticazione API, accesso amministrativo e account tecnici o di manutenzione.

Protezione dati e privacy

Per dispositivi che trattano dati personali, traffico o localizzazione, le verifiche riguardano dati salvati localmente, dati trasmessi al backend, cifratura in transito e a riposo, esposizione tramite API, log contenenti informazioni sensibili, pairing Bluetooth, token e chiavi, autorizzazioni dell’app mobile e accesso non autorizzato a dati di altri utenti.

Protezione della rete

Un dispositivo radio connesso non deve danneggiare la rete né abusare delle sue risorse. Le verifiche devono coprire comportamento anomalo in rete, servizi esposti, configurazioni di rete, gestione degli errori, resilienza a input malformati, comunicazioni non necessarie, porte e protocolli attivi, possibilità di usare il dispositivo come pivot e interazioni con gateway o rete aziendale.

Protezione dalle frodi

Per dispositivi che processano denaro, valore monetario o valuta virtuale, le verifiche devono includere integrità delle transazioni, protezione delle credenziali, manipolazione del valore, replay, autorizzazione delle operazioni, validazione lato server, tampering di app o firmware, abuso di token, audit trail e aggiornamenti sicuri. La Decisione (UE) 2025/138 segnala limitazioni specifiche per EN 18031-3 in relazione ad alcuni criteri di assessment per gli aggiornamenti sicuri e la protezione degli asset finanziari.

Mappa delle verifiche per standard

Standard	Area	Verifiche tecniche consigliate
EN 18031-1	Dispositivi radio connessi a Internet	Analisi superficie d’attacco, test sicurezza di rete, analisi firmware, hardening, test meccanismo di aggiornamento
EN 18031-2	Dispositivi che trattano dati personali, childcare, toys, wearable	Test esposizione dati e privacy, test app mobile, API security, controllo accessi, analisi storage
EN 18031-3	Dispositivi che processano denaro o valore virtuale	Test sicurezza transazioni, analisi anti-frode, test autorizzazione, test tampering, analisi aggiornamenti sicuri
Tutti	Password e autenticazione	Policy password, credenziali di default, protezione brute force, session management, recupero account
Tutti	Firmware	Analisi firmware, reverse engineering, segreti hardcoded, interfacce debug, firma aggiornamenti
Tutti	Ecosistema digitale	Backend, API, app mobile, cloud, provisioning, logging, gestione vulnerabilità

Perché un modulo radio già certificato può non bastare

Molti produttori utilizzano moduli radio già testati o certificati a livello radio ed elettrico. Il requisito cyber riguarda però il prodotto finale e il suo comportamento nel contesto d’uso. Un modulo può essere corretto, ma il prodotto può risultare vulnerabile per ragioni indipendenti: firmware custom debole, password di default, pairing non sicuro, API non protette, backend vulnerabile, aggiornamenti non firmati, app mobile esposta, storage locale non cifrato, configurazioni errate, accesso remoto non tracciato o interfacce di debug lasciate attive.

La sicurezza del componente non dimostra automaticamente la sicurezza dell’intero prodotto. Per questo è necessaria una verifica end-to-end che copra dispositivo, firmware, software, cloud, app, API, dati e flussi.

Problemi che non si risolvono con un aggiornamento firmware

Pensare che ogni vulnerabilità possa essere corretta con un aggiornamento firmware è una semplificazione rischiosa. Alcuni problemi richiedono interventi architetturali o hardware: assenza di secure boot, meccanismo di aggiornamento non progettato per verificare firme robuste, storage hardware non protetto, interfacce di debug fisicamente accessibili, chip o architetture senza supporto adeguato a protezioni crittografiche, boot chain non verificabile, impossibilità di revoca delle chiavi, design radio o pairing insicuro, limiti hardware su memoria, CPU o entropia, assenza di partizionamento sicuro.

Se queste lacune emergono tardi nel ciclo di sviluppo, l’impatto può essere significativo: redesign, revisione della distinta base, ritardi di produzione, nuova validazione e aggiornamento della documentazione tecnica. Per questo il security assessment dovrebbe essere avviato il prima possibile.

Il legame tra RED, CRA e IEC 62443

Il RED Delegated Act si inserisce in un quadro normativo più ampio. Per un dispositivo radio connesso, possono entrare in gioco più livelli di requisiti tecnici e regolatori.

Livello	Riferimento	Focus
Dispositivo radio	RED Delegated Act / EN 18031	Requisiti cyber per radio equipment in scope
Prodotto digitale	Cyber Resilience Act	Cybersecurity by design e gestione vulnerabilità dei prodotti con elementi digitali
Ambiente industriale	IEC 62443	Controlli tecnici per componenti e sistemi IACS
Macchina connessa	Regolamento Macchine 2023/1230	Sicurezza macchina, software, dati, accessi e modifiche digitali
Organizzazione	NIS2	Gestione del rischio cyber e supply chain

Per un gateway industriale wireless, ad esempio, le domande rilevanti sono: il prodotto è connesso a Internet? Tratta dati personali, traffico o localizzazione? Abilita trasferimenti di valore? È un prodotto con elementi digitali? Viene usato in ambiente OT? Collega macchine, cloud e rete industriale? Introduce accessi remoti? Contiene firmware aggiornabile? Ha API o app mobile? La risposta a queste domande determina quali verifiche tecniche sono necessarie e quali framework normativi si applicano.

Caso applicativo: gateway LTE per manutenzione remota industriale

Un OEM installa un gateway LTE su macchine industriali per abilitare teleassistenza, diagnostica e aggiornamenti. Il dispositivo include connettività LTE, VPN verso il fornitore, firmware aggiornabile, interfaccia web locale, dashboard cloud, API di telemetria, account tecnico e accesso alla rete OT della macchina.

Dal punto di vista RED, il prodotto è radio equipment connesso a Internet e rientra nei requisiti dell’Articolo 3(3)(d) secondo il testo consolidato del Regolamento delegato (UE) 2022/30. Se tratta dati personali, traffico o localizzazione, può essere rilevante anche l’Articolo 3(3)(e).

Le verifiche tecniche dovrebbero includere: esposizione dei servizi del gateway, robustezza della VPN, gestione delle credenziali, hardening dell’interfaccia web, API security, analisi firmware, test del meccanismo di aggiornamento sicuro, logging degli accessi, segmentazione verso la rete OT, possibilità di pivot verso PLC/HMI e protezione dei dati trasmessi al cloud. Il risultato dell’assessment non è una certificazione RED, ma una base tecnica solida: evidenze, vulnerabilità, piano di remediation e re-test.

Checklist di autovalutazione per RED/EN 18031

1. Il dispositivo comunica su Internet direttamente o tramite gateway?
2. Tratta dati personali, traffico, localizzazione o dati utente?
3. È un wearable, un dispositivo per bambini, un giocattolo radio o un apparato con app mobile?
4. Permette trasferimenti di denaro, valore monetario o valuta virtuale?
5. Ha credenziali di default o account tecnici?
6. L’utente può usare il dispositivo senza impostare alcuna password?
7. Il firmware è aggiornabile in modo sicuro?
8. Gli aggiornamenti sono firmati e verificati?
9. Sono presenti interfacce di debug o porte fisiche accessibili?
10. Le API sono protette da autenticazione e autorizzazione corrette?
11. I dati sensibili sono cifrati in transito e a riposo?
12. L’app mobile espone token, segreti o dati sensibili?
13. Il backend cloud è stato sottoposto a test di sicurezza?
14. Il dispositivo può essere usato come ponte verso una rete interna o OT?
15. Esiste un report tecnico con evidenze, remediation e re-test?

Se diverse risposte sono negative o incerte, il problema non è solo normativo: è tecnico e richiede un assessment prima della commercializzazione o del percorso di conformità.

Come interviene ISGroup sui dispositivi radio e wireless

ISGroup esegue assessment tecnici su dispositivi connessi, wireless, embedded e Industrial IoT con un approccio offensivo controllato. Le attività possono includere IoT Security Assessment, hardware security testing, analisi firmware, reverse engineering, software security testing, API security testing, mobile app security testing, backend security assessment, protocol security testing, analisi della superficie d’attacco radio e wireless, vulnerability assessment, penetration test controllato, analisi del meccanismo di aggiornamento sicuro, revisione credenziali e segreti, piano di remediation e re-test post-correzione.

L’obiettivo è verificare se il dispositivo e il suo ecosistema digitale possono essere compromessi prima che il problema emerga in produzione, in audit, in laboratorio di prova o sul mercato.

Output dell’assessment

Documento	Utilità
Executive summary	Sintesi per management, product owner e qualità
Report tecnico	Evidenze tecniche, vulnerabilità, impatti e riproducibilità controllata
Mappa della superficie d’attacco	Firmware, hardware, API, app mobile, cloud, radio, servizi esposti
Risultati firmware	Credenziali, librerie, servizi, aggiornamenti, debug, hardening
Risultati API e backend	Autenticazione, autorizzazione, esposizione dati, logiche applicative
Risultati app mobile	Storage locale, token, comunicazioni, reverse engineering app
Risultati hardware	Interfacce debug, storage fisico, protezioni hardware
Piano di remediation	Priorità e interventi tecnici
Report di re-test	Evidenza della correzione
Evidenze per technical file	Materiale tecnico integrabile nei percorsi di conformità, audit o qualifica

Perimetro del servizio

ISGroup esegue verifica tecnica di dispositivi radio, IoT e Industrial IoT, test di firmware, hardware, software, API, app e backend, identificazione di vulnerabilità sfruttabili, reverse engineering controllato, security auditing, report tecnico ed executive, piano di remediation e re-test, e produce evidenze tecniche integrabili in percorsi RED, EN 18031, CRA o audit interni. ISGroup non rilascia marcatura CE, non sostituisce organismi notificati, non certifica EN 18031, non fornisce pareri legali e non garantisce rischio zero.

Domande frequenti su RED Delegated Act ed EN 18031

• Cos’è il RED Delegated Act e da quando si applica?
• È il Regolamento delegato (UE) 2022/30, che integra la Direttiva RED 2014/53/UE applicando i requisiti essenziali di cybersecurity dell’Articolo 3(3), lettere d, e e f, a specifiche categorie di apparecchiature radio. Si applica dal 1° agosto 2025.
• Quali dispositivi rientrano nei requisiti cyber RED?
• Rientrano, tra gli altri, dispositivi radio connessi a Internet direttamente o tramite altro apparato, dispositivi che trattano dati personali, traffico o localizzazione, childcare radio equipment, toys radio equipment, wearable e dispositivi connessi che permettono trasferimenti di denaro, valore monetario o valuta virtuale, come stabilito dal testo consolidato del Regolamento delegato (UE) 2022/30.
• Cosa coprono EN 18031-1, EN 18031-2 ed EN 18031-3?
• Sono standard armonizzati pubblicati nella Gazzetta Ufficiale UE con la Decisione di esecuzione (UE) 2025/138: EN 18031-1 per dispositivi radio connessi a Internet, EN 18031-2 per dispositivi che processano dati personali, childcare, toys e wearable, EN 18031-3 per dispositivi connessi che processano denaro o valore virtuale.
• La conformità a EN 18031 garantisce automaticamente la sicurezza del prodotto?
• No. La conformità a uno standard armonizzato può conferire presunzione di conformità ai requisiti coperti, ma la Decisione (UE) 2025/138 pubblica gli standard EN 18031 con restrizioni. La sicurezza reale del prodotto va dimostrata con evidenze tecniche, non solo con documentazione.
• Un modulo radio già certificato è sufficiente per la conformità RED?
• Non necessariamente. La sicurezza del modulo non dimostra automaticamente la sicurezza del prodotto finale: firmware, API, backend, app mobile, aggiornamenti e configurazioni devono essere valutati separatamente.
• Quando conviene avviare un assessment tecnico?
• Prima possibile: durante lo sviluppo, in fase pre-release, prima della compilazione del technical file, prima della commercializzazione, dopo modifiche a firmware o software, dopo remediation o prima di sottoporre il prodotto a test formali.

Approfondimenti utili

• Testare firmware e meccanismi di aggiornamento
• Inquadrare i dispositivi radio nel Cyber Resilience Act
• Controlli tecnici per ambienti industriali con IEC 62443
• Roadmap verso le scadenze del Cyber Resilience Act