La produzione di un dispositivo IoT viene tradizionalmente gestita come un progetto hardware: elettronica, involucro, alimentazione, compatibilità elettromagnetica, firmware, collaudo di produzione, documentazione e, infine, vendita.

Un prodotto connesso, però, non resta invariato dopo la consegna. Nuove vulnerabilità emergono nel codice proprietario, nelle librerie utilizzate, nel sistema operativo o nei componenti di comunicazione. Il panorama delle minacce può cambiare mentre il prodotto continua a funzionare per anni nello stesso sito.

Il Cyber Resilience Act (CRA) dell’Unione europea trasforma questo rischio legato al ciclo di vita in un obbligo del fabbricante.

A che punto siamo a settembre 2026?

Il CRA, ossia il regolamento (UE) 2024/2847, è entrato in vigore il 10 dicembre 2024.

I principali requisiti di prodotto si applicano dall’11 dicembre 2027. Gli obblighi di segnalazione, invece, sono già applicabili dall’11 settembre 2026. La preparazione, quindi, non è un progetto lontano che inizierà alla fine del 2027.

Il regolamento riguarda i prodotti hardware e software con elementi digitali; l’ambito di applicazione preciso, la categoria di prodotto e la procedura di valutazione della conformità devono essere determinati da ciascun fabbricante per il proprio prodotto.

Un gateway IoT industriale, un contatore in grado di comunicare in rete, un controllore intelligente o il relativo software rientrano con buona probabilità in una famiglia di prodotti che, a causa del CRA, va riesaminata in modo consapevole.

La security by design non è più uno slogan

Il regolamento impone requisiti di cybersicurezza obbligatori nelle fasi di progettazione, sviluppo, produzione e manutenzione. La sicurezza non può quindi essere «aggiunta» al prodotto finito con un test di penetrazione alla fine del progetto.

Già a livello di architettura occorre decidere, tra l’altro:

  • quali servizi sono accessibili per impostazione predefinita;
  • come avviene l’identificazione univoca del dispositivo;
  • se esistono credenziali di fabbrica, condivise o facilmente indovinabili;
  • come sono protetti i dati in transito e a riposo;
  • come si può limitare l’accesso;
  • come si possono registrare gli eventi di sicurezza;
  • che cosa succede in caso di input errati o manipolati;
  • come si può ripristinare uno stato sicuro.

Il principio della superficie di attacco minima significa che ciò che non è necessario al funzionamento del prodotto non deve essere disponibile per impostazione predefinita.

L’aggiornabilità è una funzione del prodotto

Non basta progettare un dispositivo connesso in modo che sembri sicuro il giorno della vendita. Deve anche poter essere aggiornato in modo sicuro.

A tal fine possono essere necessari:

  • firmware con firma digitale e verifica dell’integrità;
  • un canale di aggiornamento sicuro;
  • gestione delle versioni e della compatibilità;
  • ripristino dopo un aggiornamento non riuscito;
  • una gestione dei dispositivi su larga scala ma controllata;
  • registro degli aggiornamenti e stato dell’installazione;
  • una comunicazione chiara del periodo di assistenza.

L’aggiornamento OTA, di per sé, non garantisce la sicurezza. Senza verifica della firma, gestione delle autorizzazioni, rollback o prova dell’installazione, è il meccanismo di aggiornamento stesso a poter diventare una superficie di attacco.

Gestione delle vulnerabilità per l’intero periodo di assistenza

Uno dei cambiamenti fondamentali del CRA è che tratta la sicurezza del prodotto come un processo. Il fabbricante deve essere in grado di ricevere, valutare, correggere e comunicare le vulnerabilità.

Per questo serve anche un’organizzazione interna funzionante:

  • chi riceve le segnalazioni di sicurezza;
  • come si valutano la gravità e l’impatto;
  • quali versioni del prodotto sono interessate;
  • quale componente causa il problema;
  • come viene preparata e testata la correzione;
  • come arriva ai clienti;
  • come si documenta la chiusura.

Un indirizzo e-mail, da solo, non è un processo di gestione delle vulnerabilità.

Bisogna sapere che cosa c’è nel firmware

Il firmware e il software moderni raramente sono composti interamente da codice proprietario. Librerie open source, componenti del sistema operativo, stack di rete e SDK dei fornitori si sovrappongono l’uno all’altro.

Se uno di questi diventa vulnerabile, il fabbricante deve sapere quali prodotti e quali versioni sono interessati. Serve quindi un registro ordinato delle dipendenze e dei componenti. La distinta base del software (SBOM) può essere uno strumento importante in questo senso.

La SBOM, tuttavia, è solo un inventario. Acquista valore quando è collegata al controllo delle versioni, alle informazioni sulle vulnerabilità, al parco dispositivi interessato e al processo di aggiornamento.

L’obbligo di segnalazione richiede capacità di rilevamento

Dall’11 settembre 2026 i fabbricanti sono soggetti a obblighi di segnalazione per determinate vulnerabilità attivamente sfruttate e per gli incidenti di sicurezza gravi. Il fabbricante deve seguire la procedura dettagliata e le indicazioni aggiornate delle autorità in base al proprio ruolo e al proprio prodotto.

Dal punto di vista pratico, però, una cosa è certa: non si può segnalare entro i termini ciò che l’organizzazione non è in grado di rilevare, di gestire con un’escalation interna e di ricondurre alle versioni del prodotto.

I prerequisiti del processo di segnalazione sono pertanto:

  • un registro dei prodotti e delle versioni;
  • un referente per la sicurezza;
  • una classificazione degli incidenti;
  • regole decisionali e di approvazione;
  • la comunicazione con i clienti;
  • un registro degli eventi dimostrabile.

Dietro la marcatura CE ci saranno prove dello sviluppo

Secondo il CRA, la marcatura CE dei prodotti conformi indicherà anche la conformità ai requisiti di cybersicurezza. A seconda della classificazione del rischio del prodotto, può essere necessaria una diversa procedura di valutazione della conformità, per alcune categorie con il coinvolgimento di un organismo notificato (notified body).

Ciò richiede un processo di sviluppo documentato. Occorre conservare la valutazione dei rischi, le decisioni architetturali, i risultati dei test, le informazioni sui componenti, la gestione delle vulnerabilità e le prove di rilascio.

A posteriori è molto difficile ricostruire in modo credibile perché una decisione di sicurezza sia stata presa anni prima. La documentazione deve quindi crescere insieme allo sviluppo.

Che cosa significa per uno sviluppo di tipo OrigSmart?

Viste le competenze di OrigSmart in materia di hardware, gateway e piattaforma, la sicurezza non può fermarsi all’involucro del dispositivo. L’intero ciclo di vita del sistema va gestito nel suo insieme:

  • hardware e firmware su misura;
  • comunicazione di campo;
  • identità e configurazione dei dispositivi;
  • aggiornamento sicuro;
  • autorizzazioni lato piattaforma;
  • registro degli eventi e monitoraggio;
  • gestione degli incidenti e delle vulnerabilità;
  • processi operativi lato cliente.

Presidiare l’intera catena del valore è al tempo stesso una responsabilità e un vantaggio competitivo. Il fabbricante e integratore che collega hardware, software, esercizio e processi di sicurezza dimostrabili già in fase di progettazione del prodotto non si troverà a produrre in fretta documenti di conformità alla fine del 2027.

L’essenza del CRA non è affiancare più carte al dispositivo IoT, ma fare in modo che il prodotto digitale resti un rischio di cybersicurezza gestibile per tutto il suo ciclo di vita supportato.

Parliamo del vostro progetto

Fonti

Nota: il presente articolo costituisce un’informazione professionale di carattere generale e non una consulenza legale o in materia di conformità.