Che cos'è l'Atto delegato RED?
L'Atto delegato RED (Regolamento delegato (UE) 2022/30 della Commissione) attiva gli articoli 3.3(d), (e) e (f) della Direttiva sulle apparecchiature radio (2014/53/UE), rendendo obbligatorie la cibersicurezza, la privacy e la protezione contro le frodi per tutte le apparecchiature radio connesse a internet vendute nell'UE a partire dal 1° agosto 2025. La serie di norme armonizzate EN 18031-1/2/3 definisce i requisiti tecnici specifici. La mancata conformità comporta che i prodotti non possano legalmente recare la marcatura CE per le apparecchiature radio.
Il contesto normativo: cosa è cambiato
La Direttiva sulle apparecchiature radio (RED) contiene gli articoli 3.3(d), (e) e (f) dal 2014. Tali articoli definiscono i requisiti di protezione delle reti, dei dati personali e della prevenzione delle frodi. Per dieci anni sono stati facoltativi — i fabbricanti potevano invocarli, ma non erano obbligati a farlo.
L’Atto delegato RED (UE 2022/30) cambia questa situazione. Dal 1° agosto 2025 tali requisiti sono obbligatori per tutte le apparecchiature radio in grado di connettersi a internet — direttamente o tramite un gateway.
La data è già stata posticipata una volta: la scadenza originaria era agosto 2024, rinviata per dare il tempo di finalizzare e pubblicare la norma armonizzata EN 18031 (cosa avvenuta all’inizio del 2025). Non vi saranno ulteriori proroghe.
Rapporto con la marcatura CE: il quadro della marcatura CE include ora EN 18031 come norma armonizzata obbligatoria per le apparecchiature radio connesse a internet. Aggiornare la Dichiarazione di conformità senza le evidenze di prova EN 18031 darà luogo a una Documentazione tecnica incompleta.
Chi è interessato
Se il vostro prodotto dispone di una qualsiasi interfaccia wireless e può — direttamente o tramite un dispositivo connesso — raggiungere internet, rientra nell’ambito di applicazione:
| Tipo di dispositivo | Rientra nell’ambito? |
|---|---|
| Dispositivi con Wi-Fi (tutte le categorie) | ✅ Sì |
| Dispositivi Bluetooth che instradano i dati tramite uno smartphone o un hub | ✅ Sì |
| IoT cellulare (LTE-M, NB-IoT, Cat-1) | ✅ Sì |
| Sensori, gateway e hub per la casa intelligente | ✅ Sì |
| Wearable (smartwatch, fitness tracker, monitor della salute) | ✅ Sì |
| Baby monitor, telecamere per la sorveglianza dei bambini | ✅ Sì |
| Terminali di pagamento wireless | ✅ Sì (anche EN 18031-3) |
| Dispositivi Zigbee/Z-Wave connessi a un gateway internet | ✅ Sì |
| Dispositivo Bluetooth standalone senza percorso dati verso internet | Zona grigia — richiedere un parere legale |
Importante: l’ambito di applicazione è quello delle “apparecchiature radio connesse a internet” — non solo i prodotti di consumo. L’IoT industriale, gli accessori medicali connessi (non classificati ai sensi dell’MDR), i sensori per edifici intelligenti e i tracker per la logistica rientrano tutti nell’ambito di applicazione se dispongono di un’interfaccia wireless con un percorso dati verso internet.
Cosa richiede effettivamente EN 18031
La serie di norme armonizzate EN 18031 è composta da tre parti, ciascuna corrispondente a un articolo dell’Atto delegato:
EN 18031-1 — Protezione della rete (art. 3.3(d))
Il dispositivo non deve danneggiare la rete né utilizzare in modo improprio le risorse di rete. In termini hardware:
- Protezione della rete — il dispositivo non deve danneggiare attivamente la rete. I servizi non devono essere esposti per impostazione predefinita (nessun telnet aperto, nessun MQTT non protetto, nessuna porta di debug aperta). Per dimostrare la conformità è fortemente raccomandato implementare backoff esponenziale e rate limiting per la riconnessione.
- Integrità del software [SUM-2] — EN 18031-1 richiede che il dispositivo installi esclusivamente software la cui integrità e autenticità siano valide al momento dell’installazione. La norma è neutra dal punto di vista tecnologico: tra le implementazioni accettate rientrano le firme digitali verificate nel bootloader, la consegna esclusivamente tramite canale sicuro da una fonte autenticata, oppure il controllo degli accessi combinato con un hash. Il Secure Boot hardware (verifica a livello di silicio, residente in ROM) è l’implementazione più robusta ed è fortemente raccomandato per modelli di minaccia elevati o per dispositivi soggetti anche a EN 18031-3 (prevenzione delle frodi). Tuttavia non è esplicitamente imposto da EN 18031-1 — una verifica basata su software con documentazione approfondita nella Documentazione tecnica può soddisfare SUM-2.
Implicazione per la Documentazione tecnica: se implementate SUM-2 tramite firme digitali, la gestione della chiave di firma e la logica di verifica del bootloader devono essere documentate in modo approfondito. Catene di verifica deboli o non documentate sono la causa più frequente di esito negativo nella valutazione di SUM-2.
EN 18031-2 — Protezione della privacy (art. 3.3(e))
Il dispositivo deve proteggere i dati personali e la privacy dell’utente. Applicabile a tutti i dispositivi che trattano, memorizzano o trasmettono dati personali, di traffico o di localizzazione.
- Archiviazione hardware delle chiavi (o SSM equivalente) — EN 18031 è neutra dal punto di vista tecnologico: impone un Secure Storage Mechanism (SSM) per le chiavi crittografiche, non una implementazione specifica. Tra gli approcci accettati rientrano ARM TrustZone con un servizio di gestione delle chiavi, un Secure Element esterno (ad es. ATECC608B, STSAFE-A, SE050) oppure un MCU con archiviazione delle chiavi basata su OTP/eFuse. Le implementazioni SSM basate su software senza isolamento hardware sono possibili, ma richiedono un’ampia giustificazione nella Documentazione tecnica — la maggior parte dei laboratori di prova le esaminerà con attenzione.
- Nessuna password predefinita universale — i dispositivi non devono essere forniti con credenziali di fabbrica condivise. Ogni unità necessita di una password univoca, oppure il dispositivo deve imporre la modifica della password al primo utilizzo con provisioning applicato a livello hardware.
- Architettura di minimizzazione dei dati — il dispositivo non dovrebbe raccogliere o trasmettere dati oltre a quanto necessario. Si tratta principalmente di un requisito di progettazione software/firmware, ma le scelte hardware (ad es. l’inclusione di un microfono quando non necessario) sono rilevanti.
- Dispositivi per bambini in particolare — EN 18031-2 include requisiti specifici per i dispositivi destinati ai bambini: interfacce di controllo parentale, raccolta dati limitata e controllo degli accessi più rigoroso.
Implicazione hardware: un ESP32 che memorizza le credenziali Wi-Fi e le chiavi del dispositivo nella flash NVS (non cifrate, senza alcuna protezione a livello software) non soddisfa i requisiti SSM. Indipendentemente dal fatto che si utilizzi una protezione delle chiavi basata su hardware o su software, chiavi in chiaro accessibili dal contesto applicativo = non conforme.
EN 18031-3 — Prevenzione delle frodi (art. 3.3(f))
Si applica ai dispositivi che gestiscono transazioni finanziarie, valore monetario o valuta virtuale:
- Verifica del firmware ancorata all’hardware — per i dispositivi di pagamento, la catena di verifica del firmware deve essere ancorata all’hardware (Secure Boot). Una firma digitale da sola, senza un Hardware Root of Trust che ancori la verifica, è generalmente considerata insufficiente per questo modello di minaccia — l’intera catena di verifica viene compromessa se il verificatore stesso può essere sostituito.
- Interfacce di pagamento sicure — le interfacce che gestiscono le credenziali di pagamento devono essere isolate a livello hardware.
- Meccanismi di verifica delle transazioni — i dispositivi devono implementare misure di salvaguardia contro comandi di transazione riprodotti (replay) o iniettati.
Chi è interessato: terminali POS (point-of-sale) connessi, wearable e-wallet, accessori per pagamenti mobili, portafogli hardware per criptovalute, contatori intelligenti con funzionalità di prepagamento.
Decisioni hardware che non si possono correggere con una patch
Questa è la sezione che la maggior parte dei team trascura. Diversi requisiti di EN 18031 risalgono direttamente a decisioni di architettura a livello di silicio che non possono essere implementate retroattivamente via firmware:
| Requisito | Decisione hardware | MCU che lo supportano |
|---|---|---|
| Secure Boot hardware | Bootloader in ROM + archiviazione delle chiavi su eFuse/OTP | STM32U5, nRF5340, ESP32-S3, i.MX RT1170, STM32H5 |
| Isolamento hardware delle chiavi | TrustZone o Secure Element | ARM Cortex-M33+, ATECC608B, SE050, STSAFE-A |
| Protezione anti-rollback (buona pratica, non normativa — EN 18031-1 Clausola 6.3.3 Guidance) | Contatore monotonico hardware (OTP/eFuse) o contatore di versione sicuro | nRF9160, STM32H5, ESP32-S3, STM32WBA |
| Credenziali univoche per dispositivo | Infrastruttura di provisioning in produzione | Richiede la programmazione (burning) di eFuse o il provisioning del SE in produzione |
| TRNG per la generazione delle chiavi | Generatore di numeri casuali reali (true random) on-chip | La maggior parte degli MCU moderni — verificare nel datasheet |
Avviso sulle piattaforme di generazioni precedenti: STM32F4, STM32F7 e componenti Cortex-M4/M7 più datati senza TrustZone offrono un supporto limitato al Secure Boot. I progetti basati su questi chip possono richiedere una revisione della scheda per essere conformi — non un aggiornamento del firmware. Se state progettando su queste piattaforme, raccomandiamo una revisione dell’architettura prima di impegnarvi nella produzione.
La realtà dell’applicazione a livello nazionale
L’Atto delegato è normativa dell’UE, applicata a livello nazionale. L’applicazione non è uniforme tra gli Stati membri e il livello di attività di vigilanza del mercato varia:
🇮🇹 Italia — MIMIT (Ministero delle Imprese e del Made in Italy) Il MIMIT è l’autorità competente per la vigilanza del mercato delle apparecchiature radio in Italia. I controlli di conformità sono coordinati con l’Agenzia delle Dogane e dei Monopoli (ADM), che verifica la documentazione di conformità (marcatura CE, Dichiarazione di conformità) all’importazione e può trattenere le spedizioni non conformi. I prodotti immessi sul mercato italiano devono presumere di poter essere sottoposti a controllo.
🇩🇪 Germania — Bundesnetzagentur (BNetzA) La Germania ha storicamente una delle vigilanze del mercato dei prodotti più attive dell’UE. La BNetzA acquista e sottopone a prova i prodotti in modo indipendente, conduce campagne mirate e rimuove attivamente i prodotti non conformi. I prodotti venduti su Amazon.de e tramite i distributori tedeschi dovrebbero presumere di essere sottoposti a controllo.
🇫🇷 Francia — DGCCRF + Dogane (DGDDI) La DGCCRF (Direzione generale per la concorrenza, gli affari dei consumatori e la repressione delle frodi) si occupa della conformità dei prodotti. Le dogane francesi controllano attivamente le importazioni alla ricerca della documentazione di conformità e possono trattenere le spedizioni in attesa dell’esame della documentazione.
🇳🇱 Paesi Bassi — RDI (Agenzia per le radiocomunicazioni dei Paesi Bassi) L’RDI è un partecipante attivo alle campagne congiunte ADCO RED a livello UE. I Paesi Bassi sono un importante punto di ingresso per le merci destinate al mercato dell’UE — l’RDI ha leva ai punti di ispezione doganale.
🇸🇪 Svezia — PTS (Autorità per le poste e le telecomunicazioni) Nota per l’applicazione proattiva sui dispositivi IoT e di consumo connessi. Attiva nelle campagne di vigilanza paneuropee.
Conseguenza pratica: la non conformità rilevata da una qualsiasi autorità nazionale comporta il ritiro dal mercato e la notifica al sistema Safety Gate / RAPEX. Una volta che un prodotto è notificato, gli altri Stati membri vengono automaticamente allertati. Un esito di non conformità in Germania equivale di fatto a una non conformità a livello UE.
Il rapporto con il CRA
L’Atto delegato RED e il Cyber Resilience Act (CRA) (UE 2024/2847) si sovrappongono in termini di ambito di applicazione per l’hardware connesso:
| Aspetto | Atto delegato RED | CRA |
|---|---|---|
| Si applica da | 1° agosto 2025 | 11 dicembre 2027 |
| Ambito | Apparecchiature radio connesse a internet | Tutti i prodotti con elementi digitali |
| Norma | EN 18031-1/2/3 | EN 18031 + IEC 62443 + nuove norme CRA |
| SBOM richiesto | No | Sì |
| Segnalazione delle vulnerabilità | No | Sì (24 h all’ENISA da set. 2026) |
| Rapporto | Il CRA sostituirà i requisiti di cibersicurezza della RED | Più ampio; assorbe l’ambito dell’Atto delegato RED |
Implicazione pratica: la conformità a EN 18031 oggi vi fornisce le basi hardware di sicurezza per essere pronti al CRA nel 2027. Non copre l’SBOM, la gestione delle vulnerabilità o gli obblighi relativi al ciclo di vita — si tratta di aggiunte specifiche del CRA. Consultate la nostra checklist di conformità hardware al CRA per i requisiti CRA completi.
La checklist pre-agosto
Per qualsiasi prodotto radio connesso a internet attualmente sul mercato dell’UE o in fase di sviluppo attivo:
Ambito:
- Confermare che il prodotto disponga di un percorso dati verso internet (diretto o tramite gateway)
- Individuare quali parti di EN 18031 si applicano (18031-1 sempre; -2 se vi sono dati personali; -3 se vi sono pagamenti)
Hardware:
- Secure Boot: catena applicata a livello hardware confermata e implementata
- SSM per l’archiviazione delle chiavi: TrustZone + servizio per le chiavi, Secure Element, OTP/eFuse, oppure basato su software con giustificazione del rischio documentata nella Documentazione tecnica
- Anti-rollback: contatore monotonico hardware presente e integrato
- Password predefinita: univoca per dispositivo o modifica forzata al primo utilizzo confermata
- TRNG: generatore hardware di numeri casuali nel silicio o esterno
Documentazione:
- Documentazione tecnica aggiornata con le evidenze di prova EN 18031-x
- Dichiarazione di conformità aggiornata per fare riferimento agli articoli 3.3(d)(e)(f)
- Percorso di valutazione della conformità EN 18031 confermato — l’autodichiarazione (Modulo A) è ammessa per la maggior parte dei dispositivi; caratteristiche specifiche del prodotto (meccanismi di bypass della password, dispositivi per bambini, funzionalità di pagamento) possono attivare il requisito di un organismo notificato. Verificate rispetto alle clausole applicabili al vostro prodotto specifico.
Se oggi uno qualsiasi degli elementi hardware presenta una lacuna, dovete prendere una decisione di re-spin della scheda. I tempi di approvvigionamento della produzione e i tempi di nuova prova rendono agosto 2025 molto vicino.
Informazioni sull’autore
Vladimir Vician è il fondatore di Inovasense, un’azienda di ingegneria hardware embedded e della conformità con sede nell’UE. Con oltre 10 anni di esperienza nella progettazione di hardware embedded, collabora con i fabbricanti di hardware sulla conformità normativa completa dell’UE — dalla selezione del silicio e dalla preparazione della Documentazione tecnica fino alla marcatura CE e alla preparazione al CRA. È l’autore dello strumento MCU vs MPU Architecture Advisor utilizzato dai team hardware in tutta Europa.
Connettiti su LinkedIn · Inovasense Embedded Security & IoT
Fonti e riferimenti ufficiali
- Cyber Resilience Act — Regulation (EU) 2024/2847 — EUR-Lex (Gazzetta ufficiale dell'UE)
- RED Delegated Act — Regulation (EU) 2022/30 — EUR-Lex (Gazzetta ufficiale dell'UE)
- Radio Equipment Directive — 2014/53/EU — EUR-Lex (Gazzetta ufficiale dell'UE)
- Medical Device Regulation — Regulation (EU) 2017/745 — EUR-Lex (Gazzetta ufficiale dell'UE)