Cyber Resilience Act: cosa cambia per firmware e IoT

L’11 settembre 2026 non entrerà ancora in piena applicazione il Cyber Resilience Act. Inizierà però la sua prima fase operativa: i produttori dovranno segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi che compromettono la sicurezza dei prodotti con elementi digitali.

Per un’azienda che produce dispositivi embedded, gateway Linux, apparecchiature IoT o macchine connesse, il problema non consiste semplicemente nel compilare una segnalazione. Prima di poter comunicare un evento entro le scadenze previste, l’azienda deve sapere quali prodotti sono coinvolti, quali versioni firmware utilizzano, quali componenti software contengono, dove sono installati e attraverso quale procedura possano essere corretti.

Se queste informazioni sono disperse tra repository non aggiornati, vecchi computer di sviluppo, file Excel e conoscenze personali dei tecnici, rispettare una scadenza di poche ore diventa estremamente difficile. Il Cyber Resilience Act rende quindi evidente un principio che nel settore embedded è stato spesso sottovalutato: la sicurezza non termina con la consegna del prodotto, ma deve essere gestita per tutto il suo ciclo di vita.

Il Regolamento (UE) 2024/2847, conosciuto come Cyber Resilience Act o CRA, non impone una singola architettura tecnica valida per qualsiasi dispositivo. Richiede però che hardware e software immessi sul mercato europeo siano progettati, sviluppati, documentati, aggiornati e mantenuti tenendo conto dei rischi di cybersecurity.

Per una panoramica più specifica su secure boot, aggiornamenti e sistemi Linux è disponibile anche il nostro approfondimento su Linux embedded sicuro, Cyber Resilience Act, secure boot e OTA. In questo articolo analizziamo invece cosa cambia concretamente dal settembre 2026, come prepararsi alla piena applicazione del 2027 e perché il CRA rappresenta soprattutto un problema di ingegneria del prodotto.

Questo articolo ha finalità informative e tecniche. La qualificazione giuridica di uno specifico prodotto, la scelta della procedura di valutazione della conformità e l’interpretazione del Regolamento devono essere confermate con professionisti legali o specialisti della conformità competenti.

Il CRA porta la cybersecurity dentro il prodotto

Per molti anni la cybersecurity di un dispositivo embedded è stata trattata come una caratteristica aggiuntiva. Il prodotto veniva progettato per svolgere una funzione e, in un secondo momento, si valutava se aggiungere la cifratura delle comunicazioni, una password, un bootloader aggiornabile o qualche controllo sugli accessi.

Questo approccio può funzionare quando la sicurezza viene considerata esclusivamente un vantaggio commerciale. Diventa molto più fragile quando il produttore deve dimostrare che i rischi sono stati valutati, che le scelte tecniche sono coerenti con tali rischi e che esiste un processo per gestire le vulnerabilità dopo la vendita.

Il CRA sposta quindi la domanda progettuale.

Non è più sufficiente chiedersi:

“Il dispositivo comunica e svolge correttamente la propria funzione?”

Diventa necessario chiedersi:

“Come reagirà il dispositivo se una credenziale viene compromessa, una libreria presenta una vulnerabilità, un aggiornamento viene interrotto o un’interfaccia di manutenzione viene utilizzata da una persona non autorizzata?”

Questa trasformazione riguarda direttamente firmware, bootloader, sistemi operativi, servizi cloud collegati, strumenti di produzione, procedure di assistenza e documentazione tecnica.

La conformità non può essere costruita alla fine del progetto aggiungendo una dichiarazione al manuale. Deve derivare da una catena coerente:

analisi del rischio → requisiti di sicurezza → architettura → implementazione → verifica → rilascio → monitoraggio → aggiornamento → supporto

Le date del Cyber Resilience Act da non confondere

Una delle principali fonti di confusione è la presenza di scadenze differenti. Dire genericamente che “il CRA entra in vigore nel 2026” oppure che “tutto sarà obbligatorio nel 2027” non descrive correttamente il percorso applicativo.

Il Regolamento è già entrato in vigore il 10 dicembre 2024. Alcune disposizioni hanno iniziato ad applicarsi prima della piena operatività, mentre gli obblighi principali diventeranno applicabili l’11 dicembre 2027.

La distinzione è importante perché l’11 settembre 2026 non rappresenta la data entro la quale ogni dispositivo dovrà già completare l’intero percorso di valutazione della conformità CRA.

Da quella data, però, il produttore dovrà essere in grado di gestire e notificare determinati eventi di sicurezza. Questo significa che una parte dell’organizzazione e dell’architettura tecnica deve essere preparata prima del 2027.

La Commissione europea mantiene una pagina dedicata allo stato di implementazione del Cyber Resilience Act, utile per seguire l’avanzamento di linee guida, atti applicativi, standard e infrastrutture di reporting.

Cosa deve essere segnalato dall’11 settembre 2026

Il CRA richiede ai fabbricanti di notificare due categorie principali di eventi: le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza del prodotto.

Questo non significa che qualsiasi bug, anomalia o vulnerabilità pubblicata debba essere automaticamente segnalata.

Una vulnerabilità attivamente sfruttata è una vulnerabilità per la quale esistono elementi affidabili che indicano un utilizzo malevolo effettivo e non autorizzato. La semplice presenza di un identificativo CVE o la pubblicazione di una vulnerabilità in una libreria utilizzata dal prodotto non dimostrano, da sole, che quella vulnerabilità sia stata attivamente sfruttata nel contesto previsto dal Regolamento.

Il produttore deve comunque valutare il problema, determinarne l’impatto e correggerlo quando necessario. L’obbligo di reporting dell’articolo 14 scatta però in presenza delle condizioni previste dal CRA, non per ogni aggiornamento di sicurezza disponibile sul mercato.

Lo stesso principio vale per gli incidenti. Un riavvio, un errore di comunicazione o una perdita temporanea del collegamento non diventano automaticamente incidenti gravi di cybersecurity. Devono essere valutati natura, impatto sulla sicurezza, diffusione e conseguenze sul prodotto e sui suoi utilizzatori.

Le tempistiche previste sono particolarmente strette.

L’allerta iniziale non presuppone necessariamente che l’intera indagine sia già conclusa. Serve a comunicare rapidamente l’esistenza del problema. Le informazioni possono essere completate durante le fasi successive.

Le notifiche saranno effettuate attraverso la Single Reporting Platform di ENISA. La piattaforma inoltrerà le informazioni al CSIRT competente e, secondo le modalità previste dal Regolamento, agli altri organismi interessati.

La Commissione europea ha pubblicato una pagina dedicata agli obblighi di reporting del Cyber Resilience Act, mentre ENISA ha già messo a disposizione indicazioni per la registrazione degli incaricati e l’invio delle notifiche.

Il reporting riguarda anche prodotti già sul mercato

Uno dei punti più rilevanti per il settore industriale è che gli obblighi di reporting non riguardano soltanto i nuovi prodotti progettati in vista del 2027.

La sintesi ufficiale della Commissione chiarisce che il reporting si applica ai prodotti con elementi digitali messi a disposizione sul mercato europeo, compresi quelli immessi prima dell’11 dicembre 2027.

Consideriamo un gateway industriale commercializzato nel 2022 e ancora utilizzato presso centinaia di clienti. Se nel 2026 il produttore viene a conoscenza di una vulnerabilità attivamente sfruttata che incide sulla sicurezza di quel gateway, la data originaria di progettazione non elimina automaticamente l’obbligo di reporting.

Questo crea una differenza importante tra due piani.

Per i prodotti immessi sul mercato prima dell’11 dicembre 2027, la piena applicazione delle disposizioni CRA è collegata anche alla presenza di una modifica sostanziale successiva. Il reporting, invece, segue la propria disciplina transitoria e interessa anche prodotti già distribuiti.

Un’azienda non dovrebbe quindi interpretare il 2027 come un motivo per rimandare qualsiasi attività. Prima ancora della conformità dei nuovi prodotti, deve capire quali famiglie esistenti siano ancora supportate, quali versioni siano in campo e chi sia responsabile di gestire un eventuale incidente.

Quali prodotti embedded e IoT possono rientrare nel CRA

Il Cyber Resilience Act utilizza la definizione di prodotto con elementi digitali. La definizione comprende prodotti software o hardware e le relative soluzioni di trattamento remoto dei dati, oltre a componenti software o hardware commercializzati separatamente.

Un prodotto entra potenzialmente nel campo di applicazione quando viene messo a disposizione sul mercato nell’ambito di un’attività commerciale e il suo uso previsto, o ragionevolmente prevedibile, comprende una connessione logica o fisica, diretta o indiretta, con un dispositivo o una rete.

La connessione non deve quindi coincidere necessariamente con un collegamento diretto a Internet.

Un controller può comunicare con una macchina attraverso CAN, Ethernet industriale o una seriale. Una scheda può essere collegata a un gateway. Un’applicazione può dipendere da un servizio remoto. Un firmware può essere commercializzato come componente da integrare in un prodotto più ampio.

Questa tabella non sostituisce un’analisi del prodotto. Alcuni settori e alcune categorie sono disciplinati da normative europee specifiche, mentre altri prodotti possono essere esclusi dal CRA o soggetti a regole coordinate con altri atti.

Il punto progettuale è che non basta verificare la presenza di una porta Wi-Fi. Devono essere considerati il modo in cui il prodotto viene commercializzato, le sue funzioni, la connessione prevista, le dipendenze remote e il soggetto che lo immette sul mercato.

Chi è il fabbricante quando il firmware viene sviluppato all’esterno

Nel settore embedded è normale che un’azienda affidi a un consulente o a un fornitore esterno lo sviluppo di firmware, Linux embedded, applicazioni, PCB o servizi cloud.

Il CRA considera fabbricante il soggetto che sviluppa o produce il prodotto, oppure lo fa sviluppare o produrre, e successivamente lo commercializza con il proprio nome o marchio.

Immaginiamo che un’azienda produca una macchina automatica e affidi a Silicon Logix lo sviluppo del firmware del controller. La macchina viene poi venduta con il marchio dell’azienda cliente.

In questo scenario, il committente rimane normalmente il fabbricante che immette il prodotto sul mercato con il proprio marchio. L’esternalizzazione dello sviluppo non trasferisce automaticamente al consulente tutti gli obblighi regolamentari del fabbricante.

Questo non significa però che il rapporto con lo sviluppatore esterno possa rimanere informale.

Per predisporre la documentazione tecnica, gestire le vulnerabilità e mantenere il prodotto, il fabbricante avrà bisogno di informazioni e attività provenienti dalla catena di fornitura: versioni dei componenti, dipendenze, procedure di compilazione, criteri di aggiornamento, documentazione delle interfacce, risultati dei test e disponibilità futura del supporto tecnico.

I contratti di sviluppo dovranno quindi definire con maggiore precisione proprietà e consegna dei materiali, gestione delle vulnerabilità, tempi di intervento, responsabilità sulla manutenzione, aggiornamenti, accessibilità dei sorgenti e conservazione dell’ambiente di build.

Se invece una società sviluppa una propria piattaforma software o un proprio dispositivo e lo vende con il proprio marchio, quella società può assumere direttamente il ruolo di fabbricante CRA.

La scadenza delle 24 ore richiede visibilità sul prodotto

Il vero problema del reporting non è la piattaforma utilizzata per inviare la segnalazione. Il problema è riuscire a produrre informazioni attendibili in un tempo molto breve.

Quando emerge una vulnerabilità in una libreria TLS, in un kernel Linux, in un bootloader o in uno stack di rete, il produttore deve poter collegare il componente alla propria gamma di prodotti.

La catena informativa dovrebbe essere simile a questa:

vulnerabilità → componente e versione → build firmware → variante hardware → prodotti interessati → dispositivi distribuiti → impatto → mitigazione → aggiornamento

Se l’azienda non sa quale versione della libreria sia stata inclusa in un determinato firmware, l’indagine inizia con una ricostruzione archeologica. Se il dispositivo non espone in modo affidabile la versione installata, diventa difficile capire quali unità siano interessate. Se non esiste un inventario dei prodotti ancora supportati, non è chiaro quali clienti debbano essere informati.

Il reporting rende quindi necessarie alcune capacità che spesso venivano considerate soltanto strumenti interni di sviluppo: identificazione univoca delle release, tracciabilità delle build, conservazione dei sorgenti, associazione tra firmware e hardware, gestione degli avvisi di sicurezza e definizione di un responsabile dell’incidente.

In molti prodotti sarà utile anche una diagnostica capace di distinguere un normale malfunzionamento da un comportamento potenzialmente anomalo. Il livello di telemetria deve comunque essere proporzionato al rischio, alla privacy e alle caratteristiche del sistema.

Un piccolo sensore a batteria non deve necessariamente produrre gli stessi log di un gateway Linux. Entrambi, però, dovrebbero offrire al fabbricante informazioni sufficienti a identificare versione, stato e condizioni rilevanti per la sicurezza.

La valutazione del rischio non è un documento generico

Il CRA richiede al fabbricante di effettuare una valutazione del rischio di cybersecurity e di utilizzarne i risultati durante pianificazione, progettazione, sviluppo, produzione, consegna e manutenzione.

Non si tratta di allegare alla documentazione una tabella generica con voci come “rischio hacker” o “perdita dati”.

Una valutazione utile deve partire dal prodotto concreto.

Un sensore industriale con collegamento LoRaWAN presenta una superficie di attacco diversa da un gateway Linux con accesso remoto. Un controller installato in un quadro elettrico presenta condizioni diverse da un dispositivo consumer raggiungibile da Internet. Un sistema che controlla un motore deve considerare conseguenze diverse rispetto a un semplice data logger.

L’analisi dovrebbe mettere in relazione almeno quattro elementi: le risorse da proteggere, le interfacce esposte, le minacce realistiche e le conseguenze di una compromissione.

La valutazione del rischio deve guidare le scelte tecniche. Non ogni prodotto avrà bisogno dello stesso secure element, dello stesso algoritmo crittografico o della stessa infrastruttura OTA.

Ciò che deve essere dimostrabile è la coerenza tra rischio, soluzione adottata e prove eseguite.

Secure by design non significa aggiungere TLS alla fine

Un prodotto può utilizzare TLS e rimanere comunque vulnerabile.

La comunicazione cifrata non risolve una password predefinita condivisa, un firmware non autenticato, una modalità di debug lasciata accessibile, una chiave identica su tutte le unità o un parser incapace di gestire correttamente dati non validi.

La cybersecurity di un prodotto embedded deriva dall’intera architettura.

Deve essere valutata la catena di avvio, la generazione e conservazione delle chiavi, l’identità del dispositivo, l’autenticazione degli utenti e dei servizi, la protezione delle interfacce di manutenzione, la configurazione iniziale, l’esposizione della rete, la gestione degli errori e la capacità di ripristino.

Anche la configurazione di fabbrica è importante. Un prodotto consegnato con servizi non necessari attivi, credenziali prevedibili o funzionalità diagnostiche liberamente accessibili trasferisce il rischio all’installatore e all’utilizzatore.

Il principio di sicurezza predefinita richiede invece che il prodotto venga consegnato in una configurazione ragionevolmente sicura, lasciando all’utente la possibilità di abilitare consapevolmente eventuali funzioni aggiuntive.

Nel caso di sistemi Linux embedded, la sicurezza coinvolge bootloader, kernel, device tree, filesystem, servizi di sistema, applicazioni, gestione dei privilegi e processo di aggiornamento. La semplice scelta di una distribuzione Linux non rende automaticamente sicuro il prodotto.

Secure boot e firma del firmware: strumenti, non slogan

Il CRA non impone che ogni dispositivo utilizzi la medesima implementazione di secure boot. In molti prodotti, tuttavia, la capacità di verificare autenticità e integrità del software prima della sua esecuzione rappresenta una misura tecnica coerente con il rischio.

Il secure boot permette al dispositivo di verificare che il codice da avviare provenga da una sorgente autorizzata e non sia stato alterato.

Il risultato dipende però da tutta la catena di fiducia.

Se la chiave privata utilizzata per firmare il firmware viene conservata senza adeguate protezioni, un attaccante potrebbe produrre immagini apparentemente valide. Se il bootloader può essere sostituito attraverso un’interfaccia non protetta, il controllo può essere aggirato. Se il dispositivo accetta versioni precedenti vulnerabili, un aggiornamento corretto può essere annullato attraverso un attacco di downgrade.

Un’architettura completa può quindi comprendere:

root of trust → bootloader verificato → firmware firmato → controllo versione → protezione delle chiavi → modalità di recovery

La soluzione effettiva dipende dal microcontrollore, dal SoC, dal volume di produzione, dalla criticità del prodotto e dal processo produttivo.

Per approfondire questo tema sono disponibili le pagine Silicon Logix dedicate a secure boot e sicurezza embedded e al confronto tra bootloader per MCU, Linux embedded e FPGA.

Gli aggiornamenti diventano parte dell’architettura

Gestire una vulnerabilità significa anche poter distribuire una correzione.

Per molti dispositivi connessi, un meccanismo di aggiornamento sicuro diventa quindi una componente fondamentale. Questo non significa che qualsiasi scheda debba necessariamente essere collegata a un servizio cloud o aggiornarsi automaticamente via Internet.

Un’apparecchiatura industriale isolata può utilizzare un aggiornamento locale firmato, eseguito da personale autorizzato. Un gateway distribuito in centinaia di sedi può invece richiedere un’infrastruttura remota. Un dispositivo consumer può avere esigenze ancora differenti.

La domanda corretta non è soltanto:

“Il firmware può essere aggiornato?”

Bisogna chiedersi:

“Il dispositivo può verificare l’autenticità dell’aggiornamento, recuperare da un’interruzione, impedire l’installazione di versioni non autorizzate e fornire una prova della versione effettivamente installata?”

Un sistema OTA professionale deve considerare firma, cifratura quando necessaria, compatibilità hardware, gestione della memoria, controllo dell’alimentazione, aggiornamenti progressivi, recovery e tracciabilità.

Anche il rollback deve essere progettato con attenzione. Tornare automaticamente alla versione precedente può ripristinare la funzionalità dopo un aggiornamento fallito, ma non dovrebbe consentire di reinstallare una release contenente una vulnerabilità nota.

Per questo rollback tecnico e protezione anti-downgrade devono essere coordinati.

Un approfondimento specifico è disponibile nell’articolo OTA firmware update sicuro: architettura, firma e rollback e nella pagina dedicata allo sviluppo di bootloader e aggiornamenti firmware.

La SBOM è la mappa del software realmente consegnato

Il Cyber Resilience Act introduce esplicitamente la Software Bill of Materials, normalmente indicata con la sigla SBOM.

La SBOM descrive i componenti software contenuti nel prodotto e deve essere predisposta in un formato comunemente utilizzato e leggibile automaticamente, coprendo almeno le dipendenze di livello superiore previste dal Regolamento.

Non dovrebbe essere interpretata come un foglio compilato una volta e conservato senza collegamenti con il processo di sviluppo.

Una SBOM efficace deve corrispondere a una release precisa.

Nel firmware di un microcontrollore possono essere presenti HAL del produttore, RTOS, stack TCP/IP, libreria TLS, filesystem, bootloader e componenti proprietari. In un sistema Linux embedded devono essere considerate anche le versioni dei pacchetti, il kernel, il bootloader, le applicazioni e le personalizzazioni della distribuzione.

La relazione utile è quindi:

prodotto → variante hardware → release firmware → build riproducibile → SBOM → vulnerabilità conosciute

Se una libreria viene aggiornata, la nuova build deve generare o aggiornare la propria distinta. Se esistono varianti hardware differenti, deve essere chiaro quale software sia compatibile con ciascuna variante.

Il Regolamento non richiede in via generale che ogni SBOM venga pubblicata liberamente online. La SBOM fa parte del processo di gestione delle vulnerabilità e della documentazione che deve essere disponibile secondo le condizioni previste dal CRA. Eventuali obblighi di pubblicazione possono dipendere dalla categoria del prodotto o da specifiche procedure applicabili.

Il vero valore della SBOM non è amministrativo. Quando viene pubblicata una vulnerabilità, consente al produttore di capire rapidamente se il componente interessato sia presente nei propri prodotti.

Senza questa correlazione, ogni vulnerabilità richiede di riaprire il progetto, ricostruire l’ambiente di compilazione e analizzare manualmente il codice.

Il periodo di supporto cambia il modello economico del prodotto

Il fabbricante deve stabilire un periodo di supporto durante il quale le vulnerabilità verranno gestite efficacemente. La data finale, comprensiva di mese e anno, deve essere comunicata in modo chiaro all’acquirente.

Il Regolamento prevede normalmente un periodo di almeno cinque anni. Quando il prodotto è destinato a essere utilizzato per meno di cinque anni, il supporto può corrispondere alla durata d’uso prevista.

I cinque anni non devono però essere letti automaticamente come durata massima.

Un gateway consumer e un controller installato su una macchina industriale possono avere aspettative di utilizzo molto differenti. Nella determinazione del periodo devono essere considerate natura del prodotto, durata ragionevolmente attesa, dipendenze e disponibilità degli aggiornamenti.

Per le apparecchiature industriali questo punto può avere un impatto rilevante. Molte macchine rimangono operative per dieci o quindici anni, mentre il firmware viene spesso considerato concluso pochi mesi dopo la consegna.

Mantenere un prodotto significa conservare sorgenti, documentazione, chiavi, ambiente di build, strumenti di programmazione e competenze sufficienti a produrre una nuova release.

Significa anche prevedere il costo del monitoraggio delle vulnerabilità, dei test, degli interventi e della distribuzione degli aggiornamenti.

Il periodo di supporto diventa quindi una caratteristica tecnica e commerciale del prodotto. Deve essere considerato nella definizione del prezzo, nei contratti di manutenzione, nella scelta dei componenti e nella pianificazione delle risorse.

Il firmware legacy è il problema più difficile

Le aziende che iniziano oggi un nuovo progetto possono integrare sicurezza, aggiornabilità e tracciabilità fin dalle prime fasi.

La situazione è più complessa quando il prodotto utilizza firmware sviluppato molti anni prima.

Un progetto legacy può dipendere da una versione non più supportata del compilatore, da librerie senza informazioni precise, da un microcontrollore prossimo alla fine del ciclo commerciale o da sorgenti che non producono più lo stesso binario.

In altri casi l’azienda possiede soltanto il file eseguibile utilizzato in produzione, mentre lo sviluppatore originario non è più disponibile.

Non sempre è necessario riscrivere immediatamente l’intero prodotto. La decisione deve derivare da una valutazione tecnica.

Un firmware stabile e ben documentato può essere messo sotto controllo introducendo versionamento, inventario dei componenti e un percorso di aggiornamento. Un progetto privo di sorgenti, con credenziali condivise e interfacce esposte può invece richiedere una revisione più profonda.

La domanda economica non è soltanto quanto costi modificare il firmware.

Bisogna confrontare il costo dell’intervento con il rischio di mantenere sul mercato un prodotto che non può essere analizzato, aggiornato o supportato in modo sostenibile.

Prodotti esistenti e modifica sostanziale

Per i prodotti immessi sul mercato prima dell’11 dicembre 2027, il Regolamento prevede una disciplina transitoria collegata alla modifica sostanziale.

Non ogni correzione o aggiornamento diventa automaticamente una modifica sostanziale.

La valutazione deve considerare se il cambiamento incida sulla conformità del prodotto ai requisiti essenziali o ne modifichi lo scopo previsto. L’aggiunta di una nuova interfaccia remota, un’importante trasformazione delle funzioni, la sostituzione dell’architettura di autenticazione o l’introduzione di un servizio cloud possono richiedere una valutazione più approfondita.

Anche il soggetto che modifica in modo sostanziale un prodotto e lo rende nuovamente disponibile può assumere obblighi assimilabili a quelli del fabbricante.

Per questo la gestione delle modifiche software deve diventare più strutturata.

Una release non dovrebbe essere descritta soltanto come “nuova versione”. Dovrebbe essere accompagnata da una valutazione del cambiamento, dall’aggiornamento della documentazione e dalla verifica dell’effetto sui requisiti di sicurezza e sulla procedura di conformità.

La Commissione europea ha dedicato una parte importante delle linee guida pubblicate il 27 luglio 2026 proprio al campo di applicazione, alle modifiche sostanziali, ai periodi di supporto, al reporting e alla valutazione del rischio.

Le linee guida sono uno strumento interpretativo importante, ma non sostituiscono il testo del Regolamento e non hanno carattere vincolante.

La valutazione di conformità non richiederà sempre un organismo esterno

Un altro equivoco frequente consiste nel pensare che qualsiasi dispositivo connesso debba essere certificato da un laboratorio terzo.

Il CRA distingue tra prodotti appartenenti alla categoria predefinita e prodotti importanti o critici, individuati in base alla loro funzione principale.

Per molti prodotti della categoria predefinita sarà possibile utilizzare una procedura di controllo interno, cioè un’autovalutazione del fabbricante accompagnata dalla documentazione e dalle prove necessarie.

La classificazione non deve essere dedotta dal valore economico del prodotto o dal fatto che sia utilizzato in una fabbrica. Dipende dalla funzione principale e dalle categorie definite negli allegati del CRA.

La Commissione ha ulteriormente precisato le descrizioni tecniche attraverso il Regolamento di esecuzione (UE) 2025/2392.

Una classificazione errata può portare a due risultati opposti: applicare una procedura eccessivamente onerosa a un prodotto comune oppure scoprire troppo tardi che il prodotto richiede una valutazione esterna.

Per questo l’inquadramento deve essere effettuato nelle fasi iniziali, mettendo in relazione analisi giuridica, descrizione commerciale e funzione tecnica del prodotto.

Gli standard armonizzati aiuteranno, ma aspettarli non è una strategia

Gli standard tecnici avranno un ruolo importante perché potranno trasformare i requisiti generali del CRA in specifiche applicabili e offrire una presunzione di conformità per i requisiti coperti.

La Commissione ha adottato la richiesta di standardizzazione M/606, che comprende 41 standard orizzontali e specifici per categoria di prodotto.

Gli standard orizzontali affronteranno temi comuni come gestione delle vulnerabilità, sviluppo sicuro e documentazione. Gli standard verticali saranno maggiormente orientati alle caratteristiche di specifiche famiglie di prodotti.

Al momento della redazione di questo articolo, nell’agosto 2026, il processo di standardizzazione è ancora in corso. Questo non significa che le aziende debbano sospendere i progetti fino alla pubblicazione di ogni documento.

Inventario dei prodotti, controllo delle versioni, valutazione del rischio, tracciabilità delle dipendenze, aggiornamenti firmati e gestione delle vulnerabilità richiedono tempo indipendentemente dallo standard finale.

Un’architettura fragile non diventa conforme automaticamente applicando una checklist pochi mesi prima della scadenza.

La pagina della Commissione dedicata alla standardizzazione per il Cyber Resilience Act permette di seguire l’evoluzione dei documenti e delle attività europee.

L’open source non trasferisce la responsabilità del prodotto

Linux, FreeRTOS, Zephyr, U-Boot, OpenSSL, Mbed TLS, lwIP e numerosi altri componenti open source sono utilizzati in prodotti commerciali.

Il CRA riconosce il valore dell’open source e prevede un trattamento specifico per il software libero non commercializzato e per gli open-source software steward.

Un singolo sviluppatore che contribuisce a un progetto open source non diventa automaticamente responsabile dei prodotti commerciali nei quali il codice viene integrato.

Quando però un fabbricante inserisce un componente open source nel proprio prodotto, rimane responsabile della valutazione dell’impatto di quel componente sulla sicurezza del prodotto finale.

Scrivere nella documentazione “la libreria è open source” non sostituisce la due diligence.

Il produttore deve sapere quale versione utilizza, come ricevere gli avvisi, quali configurazioni siano abilitate e come distribuire una correzione.

La dipendenza può inoltre essere indiretta. Un’applicazione potrebbe dipendere da un pacchetto che incorpora a sua volta altri componenti. Una distribuzione Linux può contenere centinaia di pacchetti, non tutti necessariamente utilizzati o esposti nello stesso modo.

Ridurre il numero di componenti non necessari diminuisce la superficie di attacco e rende più sostenibile la manutenzione.

La Commissione ha pubblicato una pagina specifica sull’applicazione del Cyber Resilience Act al software open source.

Un caso realistico: controller e gateway per una macchina industriale

Consideriamo una macchina industriale composta da un controller STM32, un pannello operatore e un gateway Linux collegato alla rete aziendale.

Il controller gestisce sensori e attuatori. Il gateway raccoglie i dati, espone un’interfaccia web e comunica attraverso MQTT con un servizio remoto di assistenza.

Il prodotto funziona correttamente e viene venduto da diversi anni. Il firmware del controller può essere aggiornato mediante una porta di servizio, mentre il gateway utilizza una distribuzione Linux personalizzata.

L’azienda scopre però che non esiste una correlazione completa tra numeri seriali, versione del gateway e versione del controller. Alcune macchine sono state aggiornate sul campo senza registrare l’intervento. La versione della libreria TLS dipende dall’immagine installata e il bootloader del microcontrollore non verifica la firma del firmware.

Finché non emerge un problema, questa situazione può apparire gestibile.

Supponiamo però che venga pubblicata e attivamente sfruttata una vulnerabilità relativa a una versione della libreria presente su alcuni gateway.

Il produttore dovrebbe stabilire rapidamente quali immagini contengano la libreria, quali macchine utilizzino tali immagini, se la configurazione sia vulnerabile e quale mitigazione possa essere applicata.

Se l’indagine richiede di contattare manualmente ogni installatore o di collegarsi singolarmente alle macchine, le scadenze del reporting diventano difficili da rispettare.

Un percorso tecnico più sostenibile potrebbe introdurre identificazione univoca delle release, SBOM associata alla build, inventario delle installazioni, aggiornamento firmato, diagnostica della versione e una procedura documentata per ricevere e valutare le segnalazioni.

La nuova catena diventerebbe:

codice sorgente → build controllata → SBOM → immagine firmata → installazione tracciata → monitoraggio → vulnerabilità → aggiornamento → verifica

Il valore di questa architettura non consiste soltanto nella conformità. L’azienda riduce anche i tempi di assistenza, comprende meglio il proprio parco installato e limita il rischio di interventi non riproducibili.

Un percorso realistico dall’agosto 2026 al dicembre 2027

Il CRA non può essere affrontato con un unico intervento eseguito pochi giorni prima della scadenza.

È più efficace suddividere il lavoro in fasi, distinguendo la preparazione immediata al reporting dalla conformità dei prodotti che verranno immessi sul mercato dopo la piena applicazione.

Questa è una possibile roadmap tecnica, non un insieme di scadenze normative intermedie.

L’ordine effettivo dipende dal numero di prodotti, dallo stato del firmware, dalla disponibilità dei sorgenti, dalla categoria CRA e dal ciclo commerciale dell’azienda.

Un produttore con un solo dispositivo recente può completare rapidamente l’analisi. Un’azienda con venti anni di varianti, sviluppatori differenti e prodotti ancora in assistenza deve iniziare da una mappatura più ampia.

Un assessment tecnico CRA non dovrebbe produrre soltanto una checklist

Una verifica preliminare utile non dovrebbe limitarsi a rispondere “presente” o “assente” a una serie di controlli.

Il primo risultato dovrebbe essere la comprensione del prodotto: funzioni, interfacce, varianti, software, componenti, processo di produzione e modalità di aggiornamento.

Da questa base è possibile costruire una valutazione tecnica dei rischi e identificare le lacune che hanno un impatto reale.

Un assessment può mettere in evidenza, ad esempio, che il prodotto dispone già di comunicazioni cifrate ma utilizza la stessa credenziale su tutte le unità. Oppure può rilevare che l’aggiornamento è firmato, ma non esiste una modalità di recovery in caso di interruzione.

Il risultato finale dovrebbe collegare ogni problema a una priorità e a un possibile intervento.

prodotto e versioni → superficie di attacco → dipendenze → gap tecnici → rischio → interventi → prove → documentazione

Per un dispositivo legacy, il primo obiettivo può essere rendere nuovamente riproducibile la build. Per un nuovo progetto, può essere definire fin dall’inizio secure boot, provisioning delle chiavi e aggiornamento.

L’assessment permette inoltre di distinguere gli interventi necessari da quelli che sarebbero tecnicamente interessanti ma non proporzionati al rischio.

Questo evita di trasformare il CRA in un progetto sovradimensionato e costoso.

Come Silicon Logix può supportare le aziende

Silicon Logix interviene nel punto in cui i requisiti del Cyber Resilience Act diventano problemi concreti di firmware, Linux embedded, bootloader, connettività e manutenzione del prodotto.

L’attività può iniziare con una valutazione tecnica dell’architettura esistente, verificando superfici esposte, processo di aggiornamento, dipendenze software, tracciabilità delle release, protezione delle chiavi e possibilità di identificare la versione installata.

Nel caso di firmware legacy, l’analisi può comprendere recupero e organizzazione dei sorgenti, ricostruzione dell’ambiente di build, identificazione delle librerie e definizione di un percorso realistico di manutenzione.

Per nuovi prodotti, Silicon Logix può supportare la progettazione di firmware embedded, bootloader, aggiornamenti firmati, diagnostica, gestione delle credenziali e meccanismi di recovery.

Nei sistemi più complessi può essere analizzata anche la piattaforma Linux embedded basata su Yocto o Buildroot, includendo pacchetti, servizi, configurazione, aggiornamenti e generazione delle informazioni necessarie alla SBOM.

L’obiettivo non è applicare indistintamente ogni tecnologia disponibile.

Il progetto deve individuare le misure proporzionate al prodotto e costruire evidenze tecniche riutilizzabili nella documentazione del fabbricante e nella successiva procedura di valutazione della conformità.

Silicon Logix non sostituisce il consulente legale, l’organismo notificato o il professionista responsabile della conformità regolamentare. Può però supportare l’azienda nella parte ingegneristica: analisi del firmware, definizione dell’architettura, implementazione degli interventi e preparazione delle informazioni tecniche necessarie.

Domande frequenti sul Cyber Resilience Act per firmware e IoT Il CRA si applica a qualsiasi dispositivo embedded?

No. Devono essere valutati commercializzazione, uso previsto, connessioni dirette o indirette, funzione del prodotto ed eventuali normative settoriali applicabili. Molti dispositivi connessi rientrano potenzialmente nel campo di applicazione, ma la presenza di un microcontrollore non è sufficiente per stabilirlo.

Dall’11 settembre 2026 tutti i prodotti dovranno già essere conformi?

No. Dall’11 settembre 2026 si applicano gli obblighi di reporting dell’articolo 14. Le principali disposizioni del Regolamento diventeranno applicabili dall’11 dicembre 2027.

Deve essere segnalata qualsiasi vulnerabilità presente nel firmware?

No. L’obbligo di reporting riguarda vulnerabilità attivamente sfruttate e incidenti gravi che incidono sulla sicurezza del prodotto. Le altre vulnerabilità devono comunque essere valutate e gestite durante il periodo di supporto.

Il reporting riguarda anche dispositivi venduti prima del 2027?

Sì. Le indicazioni ufficiali della Commissione chiariscono che gli obblighi di reporting interessano anche prodotti già messi a disposizione sul mercato europeo prima dell’11 dicembre 2027.

Il secure boot è sempre obbligatorio?

Il Regolamento definisce requisiti di sicurezza e obiettivi da raggiungere, non una singola architettura per ogni prodotto. Secure boot e firma del firmware possono essere misure appropriate quando è necessario proteggere autenticità e integrità del software eseguito.

Il CRA rende obbligatorio un aggiornamento OTA via cloud?

Non necessariamente. Il prodotto deve poter gestire efficacemente le vulnerabilità e gli aggiornamenti di sicurezza secondo le condizioni applicabili. La soluzione può essere remota, locale o basata su strumenti di assistenza, purché sia coerente con il rischio e con il ciclo di vita previsto.

La SBOM deve essere pubblicata sul sito del produttore?

Non in via generale. Deve essere predisposta e gestita secondo i requisiti del CRA e della documentazione applicabile. La pubblicazione può dipendere dalla categoria del prodotto o da specifiche condizioni, ma non rappresenta un obbligo universale per qualsiasi prodotto.

Utilizzare Linux o librerie open source esenta il produttore dalle responsabilità?

No. Il CRA tutela i normali contributori open source e distingue le attività non commerciali. Il fabbricante che integra componenti open source in un prodotto commerciale deve comunque valutarli, documentarli e gestirne le vulnerabilità.

Affidare il firmware a un consulente trasferisce gli obblighi CRA?

Normalmente no. Il soggetto che commercializza il prodotto con il proprio nome o marchio rimane generalmente il fabbricante. Le responsabilità tecniche e contrattuali del fornitore devono però essere definite con precisione.

Il periodo di supporto è sempre esattamente di cinque anni?

No. Il Regolamento stabilisce normalmente un periodo minimo di cinque anni, salvo prodotti la cui durata prevista sia inferiore. La determinazione deve considerare la natura e il tempo di utilizzo atteso del prodotto.

È sempre necessario un organismo notificato?

No. Molti prodotti della categoria predefinita potranno utilizzare il controllo interno del fabbricante. Per prodotti importanti e critici possono essere previste procedure differenti e, in determinati casi, una valutazione di terza parte.

Una microimpresa è completamente esentata dal CRA?

No. Il Regolamento prevede proporzionalità, strumenti di supporto e alcune disposizioni specifiche per micro e piccole imprese, ma non introduce un’esenzione generale dagli obblighi applicabili al prodotto.

Silicon Logix può rilasciare una certificazione CRA?

Silicon Logix può supportare la valutazione tecnica, la progettazione e l’adeguamento di firmware e architetture embedded. La procedura formale di conformità, l’eventuale intervento di un organismo notificato e l’interpretazione legale devono essere gestiti dai soggetti competenti.

Conclusione

Il Cyber Resilience Act non deve essere letto soltanto come un nuovo adempimento europeo.

Per il settore embedded introduce un cambiamento più profondo: il software diventa una parte del prodotto che deve essere conosciuta, mantenuta e supportata anche dopo la vendita.

Dal settembre 2026 il fabbricante deve poter reagire rapidamente quando viene a conoscenza di una vulnerabilità attivamente sfruttata o di un incidente grave. Dal dicembre 2027 dovrà inoltre dimostrare che i nuovi prodotti sono stati progettati, sviluppati e mantenuti secondo i requisiti applicabili.

Questo richiede molto più di una comunicazione cifrata.

Servono versioni identificabili, dipendenze conosciute, build controllate, aggiornamenti affidabili, responsabilità definite, diagnostica e un periodo di supporto sostenibile.

La domanda non è più soltanto:

“Il firmware funziona?”

La domanda diventa:

“Sappiamo cosa contiene, possiamo correggerlo, possiamo dimostrare come è stato sviluppato e saremo ancora in grado di supportarlo tra alcuni anni?”

Le aziende che inizieranno il percorso partendo dall’architettura potranno trasformare il CRA in un miglioramento concreto della qualità del prodotto.

Quelle che rimanderanno tutto alla documentazione finale rischieranno invece di scoprire che le informazioni necessarie non possono essere ricostruite senza modificare firmware, strumenti e processi.

Riferimenti ufficiali

1. Unione europea, Regolamento (UE) 2024/2847 – Cyber Resilience Act, testo ufficiale del Regolamento.
2. Commissione europea, Cyber Resilience Act, panoramica ufficiale, finalità e scadenze applicative.
3. Commissione europea, The Cyber Resilience Act – Summary of the legislative text, sintesi di campo di applicazione, obblighi, reporting e valutazione della conformità.
4. Commissione europea, Cyber Resilience Act – Reporting obligations, scadenze e funzionamento delle notifiche.
5. ENISA, CRA Single Reporting Platform, piattaforma e indicazioni operative per il reporting.
6. Commissione europea, Guidance on the application of the Cyber Resilience Act, linee guida pubblicate il 27 luglio 2026.
7. Commissione europea, Cyber Resilience Act – Conformity assessment, categorie di prodotto e procedure di valutazione.
8. Commissione europea, Cyber Resilience Act – Standardisation, standard armonizzati e richiesta M/606.
9. Commissione europea, Cyber Resilience Act – Open source, applicazione del CRA al software libero e agli open-source software steward.
10. Unione europea, Regolamento di esecuzione (UE) 2025/2392, descrizioni tecniche delle categorie di prodotti importanti e critici.
11. ENISA, SME Cyber Resilience Maturity Assessment Model, modello di valutazione della maturità dedicato a micro, piccole e medie imprese.