EN 303 645

EN 303 645 — Norma di cibersicurezza per i dispositivi IoT di consumo

La ETSI EN 303 645 (titolo completo: Cyber Security for Consumer Internet of Things: Baseline Requirements) è la norma di base europea — e ormai di riferimento globale — per la cibersicurezza dei dispositivi IoT di consumo. Sviluppata da ETSI (European Telecommunications Standards Institute) e pubblicata per la prima volta nel giugno 2020, definisce 13 gruppi di disposizioni di sicurezza e una serie di disposizioni di protezione dei dati (nove nella versione attuale) che stabiliscono il livello minimo di cibersicurezza che ogni dispositivo di consumo connesso a Internet dovrebbe possedere.

La EN 303 645 è una norma di base volontaria: non è richiamata nell’Atto delegato RED né nel CRA, ma è richiamata nella normativa del Regno Unito sulla sicurezza dei prodotti ed è servita da base per gli schemi nazionali di etichettatura della cibersicurezza a Singapore e in Germania, nonché in Finlandia fino a quando, nel 2024, è cessato il rilascio di nuove etichette.

Fatti chiave

Le 13 disposizioni di sicurezza

La EN 303 645 raggruppa le proprie disposizioni di sicurezza in 13 clausole (5.1–5.13). Ogni singola disposizione è obbligatoria (SHALL) oppure è una raccomandazione (SHOULD); le clausole 5.7, 5.9, 5.10 e 5.12 contengono soltanto raccomandazioni. Una raccomandazione non applicata deve essere giustificata per iscritto (disposizione 5.0-1):

Disposizione 1: Nessuna password predefinita universale

La disposizione di maggiore impatto. Ogni dispositivo IoT deve, in alternativa:

• Essere fornito senza password predefinita, con l’obbligo per l’utente di impostarne una durante la configurazione, oppure
• Avere una password unica per dispositivo generata in modo da renderla imprevedibile

Le credenziali predefinite condivise (ad es. admin/admin, root/1234) identiche su tutte le unità di un modello sono vietate. Questa singola disposizione elimina il vettore di attacco IoT più comune dell’ultimo decennio — il credential stuffing contro le password predefinite.

Implicazione hardware: le password uniche per dispositivo devono essere memorizzate in modo sicuro in memoria non volatile e devono sopravvivere ai ripristini di fabbrica (oppure essere rigenerate dopo il ripristino). Ciò richiede un processo di provisioning in fase di produzione.

Disposizione 2: Implementare una politica di divulgazione delle vulnerabilità

I fabbricanti devono pubblicare una politica di divulgazione delle vulnerabilità (VDP) chiara e accessibile che:

• Fornisca informazioni di contatto per i ricercatori di sicurezza
• Indichi le tempistiche per la conferma iniziale di ricezione di una segnalazione
• Indichi le tempistiche degli aggiornamenti sullo stato fino alla risoluzione del problema

Si tratta di un requisito organizzativo — non hardware. Intervenire tempestivamente sulle segnalazioni e monitorare in modo continuo le vulnerabilità sono raccomandazioni.

Disposizione 3: Mantenere il software aggiornato

I dispositivi devono disporre di un meccanismo di aggiornamento sicuro, salvo che un vincolo di risorse del caso d’uso lo impedisca, e:

• I processi di aggiornamento devono essere semplici per l’utente (non richiedere conoscenze specialistiche)
• Gli aggiornamenti distribuiti tramite rete devono essere verificati quanto ad autenticità e integrità
• Gli aggiornamenti devono essere tempestivi — le vulnerabilità critiche devono essere affrontate prontamente
• Il fabbricante deve pubblicare il periodo di supporto definito
• Notificare all’utente che è necessario un aggiornamento di sicurezza è una raccomandazione

Implicazione hardware: la norma non impone la distribuzione OTA né la protezione contro il rollback; menziona una politica anti-rollback basata sul controllo della versione solo a titolo di esempio. La protezione contro il rollback resta comunque una buona pratica. Se l’MCU non può implementare l’anti-rollback (ad es. tramite contatori monotoni in memoria sicura), gli attacchi di downgrade del firmware diventano fattibili.

Disposizione 4: Memorizzare in modo sicuro i parametri di sicurezza sensibili

Credenziali, chiavi crittografiche e altri parametri sensibili devono essere memorizzati con una protezione adeguata. Le credenziali codificate fisse nel firmware sono vietate.

Implicazione hardware: i parametri sensibili dovrebbero essere memorizzati in uno spazio di archiviazione protetto a livello hardware (Secure Element, memoria protetta da TrustZone, aree bloccate tramite eFuse). L’archiviazione solo software in flash standard è insufficiente per i casi d’uso ad alta garanzia.

Disposizione 5: Comunicare in modo sicuro

Il dispositivo deve utilizzare crittografia conforme alle migliori pratiche per comunicare in modo sicuro; la norma deliberatamente non nomina protocolli né versioni. Inoltre:

• Segreti protetti — i parametri di sicurezza critici inviati tramite interfacce accessibili da remoto devono essere protetti in termini di riservatezza
• Configurazione autenticata — le modifiche di configurazione rilevanti per la sicurezza effettuate tramite rete devono richiedere l’autenticazione
• Raccomandato — autenticazione prima di qualsiasi accesso di rete alle funzioni del dispositivo

La norma in sé non fissa alcuna versione di TLS: i protocolli deprecati (SSLv3, TLS 1.0, WEP, WPA) non rientrano nelle migliori pratiche, e TLS 1.2 o successivo (preferibilmente TLS 1.3) è la lettura abituale per le comunicazioni Internet — un’interpretazione, non il testo della norma.

Disposizione 6: Ridurre al minimo le superfici di attacco esposte

Il dispositivo dovrebbe esporre solo ciò che è necessario alla funzionalità prevista:

• Le interfacce di rete e le interfacce logiche accessibili dalla rete non utilizzate devono essere disabilitate
• Le interfacce di debug (JTAG, SWD, UART) devono essere disabilitate o protette mediante autenticazione o controllo degli accessi
• Abilitare solo i servizi software necessari ed eseguire il software con il privilegio minimo sono raccomandazioni

Implicazione hardware: le interfacce di debug fisiche (JTAG, SWD) dovrebbero essere bloccate tramite protezione con fusibili OTP o disabilitate in modo permanente nei dispositivi di produzione. Lasciare JTAG abilitato sulle unità di produzione è un riscontro comune negli audit di sicurezza.

Disposizione 7: Garantire l’integrità del software

Il dispositivo dovrebbe verificare il proprio software e reagire alle modifiche non autorizzate — le disposizioni di questo gruppo sono raccomandazioni (SHOULD), non requisiti obbligatori:

• Secure boot — il dispositivo dovrebbe verificare il proprio software mediante meccanismi di secure boot
• Convalida dell’aggiornamento — coperta dalla disposizione 3 (obbligatoria per gli aggiornamenti distribuiti tramite rete)
• Se viene rilevata una modifica non autorizzata del software, il dispositivo dovrebbe avvisare l’utente o l’amministratore

Implicazione hardware: la norma indica una hardware root of trust come uno dei modi per supportare il secure boot; non la impone. Una catena Secure Boot completa dalla boot ROM fino al firmware applicativo, ancorata all’hardware (chiave radice in fusibili OTP), è l’implementazione robusta — i controlli di integrità solo software possono essere aggirati.

Disposizione 8: Garantire la sicurezza dei dati personali

Questo gruppo riguarda i dati personali in transito e i sensori del dispositivo:

• I dati personali sensibili inviati ai servizi associati devono essere protetti in termini di riservatezza con crittografia conforme alle migliori pratiche (raccomandato per gli altri dati personali)
• Tutte le capacità di rilevamento esterne (ad es. sensori ottici o acustici) devono essere documentate in modo chiaro per l’utente

Il consenso e la trasparenza sono trattati dalle disposizioni separate sulla protezione dei dati (clausola 6); la cancellazione dei dati dell’utente dalla disposizione 11.

Disposizione 9: Rendere i sistemi resilienti alle interruzioni

I dispositivi dovrebbero rimanere operativi e funzionanti a livello locale in caso di perdita dell’accesso alla rete e dovrebbero:

• Riprendere correttamente il funzionamento quando l’alimentazione viene ripristinata dopo un’interruzione
• Riconnettersi alle reti in modo ordinato

Disposizione 10: Esaminare i dati di telemetria del sistema

Se dai dispositivi vengono raccolti dati di telemetria, questi dovrebbero essere esaminati per individuare anomalie di sicurezza. Si tratta di una raccomandazione (SHOULD), non di un requisito (SHALL).

Disposizione 11: Facilitare la cancellazione dei dati personali da parte degli utenti

I dispositivi devono offrire agli utenti un modo semplice per cancellare dal dispositivo i propri dati utente (obbligatorio). La cancellazione dei dati personali dai servizi associati, istruzioni chiare e la conferma dell’avvenuta cancellazione sono raccomandazioni.

Disposizione 12: Facilitare l’installazione e la manutenzione

I processi di configurazione e manutenzione non dovrebbero richiedere all’utente conoscenze specialistiche di sicurezza. La sicurezza dovrebbe essere garantita “per impostazione predefinita”, senza richiedere configurazioni da parte dell’utente per essere attiva.

Disposizione 13: Convalidare i dati di input

I dispositivi devono convalidare i dati immessi tramite le interfacce utente e tramite le interfacce di rete, comprese le API, per prevenire manipolazioni e malfunzionamenti quali gli attacchi di injection (obbligatorio).

EN 303 645 ed EN 18031: relazione e differenze

Una comune fonte di confusione è la relazione tra la EN 303 645 e la più recente serie EN 18031:

Guida pratica: per le apparecchiature radio che rientrano nell’ambito di applicazione dell’Atto delegato RED, la EN 18031 è la serie di norme armonizzate citata nella Gazzetta ufficiale; la sua applicazione è volontaria e la presunzione di conformità è soggetta alle restrizioni pubblicate. La EN 303 645 non conferisce alcuna presunzione di conformità ai sensi della RED, ma rimane utile come base, per la conformità al mercato del Regno Unito e per gli schemi di etichettatura costruiti su di essa.

EN 303 645 e schemi nazionali/internazionali

La EN 303 645 è stata utilizzata come base tecnica per diversi schemi nazionali per l’IoT di consumo:

Un prodotto che raggiunge la conformità alla EN 303 645 dispone di una solida base per i requisiti di cibersicurezza di molteplici mercati nazionali — rendendola una base di riferimento globale de facto.

Prove di conformità: ETSI TS 103 701

La ETSI TS 103 701 è la specifica di prova complementare alla EN 303 645. Essa fornisce:

• Casi di prova specifici per ciascuna disposizione
• Metodi di prova definiti (black-box, white-box, revisione documentale)
• Criteri di superamento/fallimento per ciascun requisito

I laboratori di prova accreditati utilizzano la TS 103 701 per produrre rapporti di prova strutturati che fungono da evidenza nella documentazione tecnica per la conformità regolamentare.

Riepilogo delle implicazioni hardware

Dalla nostra esperienza

Eseguendo gap analysis EN 303 645 su prodotti IoT di consumo, questi sono i pattern che riscontriamo con maggiore costanza:

La disposizione 1 fallisce in circa il 60% delle prime valutazioni. Pur essendo il requisito EN 303 645 più pubblicizzato, le credenziali predefinite condivise rimangono la non conformità più comune che riscontriamo. La credenziale spesso non è admin/admin — i fabbricanti ne sono consapevoli — ma piuttosto un valore predefinito derivato dal modello del dispositivo (ad es. le ultime 4 cifre di un indirizzo MAC) algoritmicamente prevedibile. La ETSI TS 103 701 verifica esplicitamente le credenziali per dispositivo prevedibili, non solo quelle universali. La soluzione richiede sia una modifica del provisioning a livello hardware (credenziale unica generata e iniettata in produzione tramite un HSM) sia una modifica del processo produttivo. Raccomandiamo di trattare questo aspetto come un’attività di ingegneria di produzione, non come un’attività firmware.

Scoperta del JTAG nella disposizione 6: il riscontro più comune negli audit di sicurezza. In oltre l’80% delle valutazioni di sicurezza hardware in cui riceviamo unità di produzione (non campioni di ingegneria), l’accesso di debug JTAG o SWD rimane attivo. I fabbricanti tipicamente collaudano con campioni di ingegneria — in cui JTAG è intenzionalmente abilitato — e la build firmware di produzione non include la bruciatura dei fusibili OTP come fase finale di produzione. Il risultato è un dispositivo di produzione in cui qualsiasi malintenzionato dotato di una sonda di debug da 30 £ può eseguire il dump dell’intera flash, estrarre le credenziali, aggirare il secure boot e installare firmware arbitrario. Implementiamo una fase di verifica obbligatoria con JTAG bloccato nelle attrezzature di collaudo di produzione: qualsiasi unità che risponda a un tentativo di connessione JTAG dopo la fase di programmazione di produzione viene scartata.

Anti-rollback nella disposizione 3: spesso dichiarato, raramente implementato correttamente. Molti fabbricanti affermano che il loro sistema di aggiornamento OTA impedisce il downgrade del firmware. In pratica, riscontriamo che ciò è implementato come un controllo di versione software nel firmware applicativo — banalmente aggirabile da qualsiasi malintenzionato che abbia già compromesso il dispositivo. La EN 303 645 non richiede di per sé l’anti-rollback — menziona una politica di controllo della versione solo a titolo di esempio — ma a nostro avviso un anti-rollback robusto necessita di un contatore hardware monotono in una regione di memoria resistente alle manomissioni che non possa essere decrementato. Sui dispositivi privi di Secure Element o di un SoC con TrustZone, ciò è architetturalmente impossibile da implementare correttamente in puro software. La scelta di un chipset che supporti l’anti-rollback a livello hardware deve essere una decisione di progettazione del primo giorno.

Connessioni backend legacy TLS 1.0/1.1 nella disposizione 5. Un prodotto può supportare TLS 1.3 sul dispositivo — e dare comunque luogo a un riscontro relativo alla disposizione 5 se accetta un downgrade a TLS 1.0 o 1.1 perché il backend cloud a cui si connette offre ancora tali versioni per i client legacy. La EN 303 645 in sé non definisce prove; la complementare ETSI TS 103 701 verifica la crittografia effettivamente utilizzata dal dispositivo rispetto a quanto dichiarato dal fabbricante. Riscontriamo ciò più frequentemente nei prodotti che si connettono a backend aziendali esistenti non aggiornati quando il firmware del dispositivo è passato a TLS 1.2+. La soluzione consiste nel cessare di offrire le versioni deprecate sul backend e nel far sì che il dispositivo le rifiuti — e il lato backend è spesso al di fuori del controllo diretto del fabbricante hardware se si utilizza una piattaforma cloud condivisa.

Termini correlati

• EN 18031 — La serie di norme armonizzate citata per l’Atto delegato RED; un lavoro distinto del CEN-CENELEC, non una nuova edizione della EN 303 645.
• Atto delegato RED — Lo strumento giuridico che ha reso applicabili, dal 1° agosto 2025, i requisiti di cibersicurezza dell’articolo 3(3)(d), (e) e (f) della RED a determinate categorie di apparecchiature radio; non impone alcuna norma specifica.
• CRA — Cyber Resilience Act dell’UE; non richiama la EN 303 645 — le sue norme armonizzate sono in corso di elaborazione separatamente da parte di CEN, CENELEC ed ETSI.
• Secure Boot — Raccomandato dalla disposizione 7 (uno SHOULD, non un requisito obbligatorio).
• OTA Update — La disposizione 3 richiede un meccanismo di aggiornamento sicuro e la verifica degli aggiornamenti distribuiti tramite rete; l’anti-rollback compare solo a titolo di esempio.
• Hardware Root of Trust — Sottende le disposizioni 4 e 7.

Fonti ufficiali

• ETSI EN 303 645 V3.1.3 — download gratuito (etsi.org)
• ETSI TS 103 701 V2.1.1 — Specifica di valutazione della conformità per la EN 303 645 (download gratuito)
• Atto delegato RED UE 2022/30 — EUR-Lex
• ETSI releases world-leading Consumer IoT Security standard — comunicato stampa ETSI (giugno 2020)

La conformità alla EN 303 645 è sempre più un’aspettativa di base per i prodotti hardware connessi che entrano nei mercati dell’UE, del Regno Unito e globali. Inovasense esegue una gap analysis rispetto a tutte le 13 disposizioni della EN 303 645 — mappando le capacità hardware esistenti rispetto a ciascun requisito SHALL, individuando le modifiche hardware o di processo produttivo necessarie (provisioning, blocco delle porte di debug, archiviazione sicura) e producendo documentazione pronta per la prova da sottoporre a un laboratorio accreditato. Consulta la nostra competenza nella sicurezza embedded e i nostri servizi di conformità UE.