Il Cyber Resilience Act – regolamento (UE) 2024/2847 – era uno dei temi trasversali di Embedded World 2026, e da allora è diventato una delle domande che ci arrivano più spesso: “riguarda anche noi?”. La risposta, per la quasi totalità dei costruttori di macchine e dei produttori di apparecchi elettronici che vendono in Europa, è sì.
La data che conta è vicina: l'11 settembre 2026. Non è la piena applicazione del regolamento – quella arriva nel dicembre 2027 – ma è il momento in cui scatta il primo obbligo operativo e sanzionabile, quello di segnalazione delle vulnerabilità. Ed è un obbligo che non si soddisfa con un documento: richiede che il prodotto sia già stato progettato in un certo modo.
Dall'11 settembre 2026 ogni fabbricante deve saper rilevare, e notificare entro 24 ore, una vulnerabilità attivamente sfruttata nel proprio prodotto. Chi non ha secure boot, aggiornamento firmato e SBOM non ha gli strumenti per farlo – e li deve mettere nell'hardware, non nelle procedure.
Le scadenze del Cyber Resilience Act: cosa scatta e quando
Il regolamento è in vigore dal 10 dicembre 2024, ma si applica per gradi. Tenere a mente le tre date evita sia gli allarmismi sia le sorprese:
- 11 giugno 2026 – si applica il Capo IV: gli organismi di valutazione della conformità devono essere notificati dalle autorità nazionali per poter operare. È il presupposto perché esista una filiera di certificazione funzionante quando servirà.
- 11 settembre 2026 – si applica l'articolo 14: obbligo di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi. Vale per tutti i prodotti già sul mercato, non solo per quelli immessi dopo questa data.
- 11 dicembre 2027 – piena applicazione: requisiti essenziali di cybersicurezza (Allegato I), valutazione di conformità, marcatura CE estesa alla sicurezza informatica, documentazione tecnica.
L'errore più comune è leggere il 2027 e archiviare il tema. La segnalazione del 2026 è il primo obbligo con una sanzione dietro, e le sanzioni del CRA non sono simboliche: fino a 15 milioni di euro o il 2,5% del fatturato annuo mondiale per le violazioni dei requisiti essenziali e degli obblighi degli articoli 13 e 14.
Chi è il fabbricante ai sensi del CRA
È la domanda che, nella nostra esperienza, sposta di più il quadro. Ai sensi del regolamento, fabbricante è chi immette il prodotto sul mercato UE con il proprio nome o marchio. Non chi ha progettato la scheda, non chi ha scritto il firmware: chi ci mette la targhetta.
Le conseguenze pratiche sono tre. Un costruttore di macchine che acquista un modulo di comunicazione da un fornitore asiatico e lo integra nel proprio quadro risponde delle vulnerabilità di quel modulo. Un importatore che rimarchia un prodotto diventa a tutti gli effetti il fabbricante. E chi modifica in modo sostanziale un prodotto già immesso sul mercato – per esempio aggiungendo connettività a una macchina esistente – fa scattare di nuovo gli obblighi su di sé.
Da qui discende una regola di acquisto che vale la pena adottare subito, prima ancora che il regolamento sia pienamente applicabile: l'SBOM del fornitore e un impegno scritto sugli aggiornamenti di sicurezza vanno chiesti in sede di offerta. Un componente che non è patchabile non è un problema tecnico – è un rischio che si eredita insieme alla fornitura.
Segnalazione vulnerabilità: 24 ore, 72 ore, 14 giorni
L'articolo 14 impone al fabbricante di notificare, attraverso la piattaforma unica di comunicazione prevista dal CRA, al CSIRT dello Stato membro in cui ha lo stabilimento principale e contestualmente ad ENISA. Le finestre temporali sono queste:
Le 24 ore decorrono dal momento in cui il fabbricante viene a conoscenza della vulnerabilità sfruttata o dell'incidente grave. È il punto che rende l'obbligo tecnico e non burocratico: per rispettare una finestra di 24 ore serve un canale attraverso cui la notizia arriva, e serve la capacità di capire quali unità sul campo sono affette.
In concreto significa avere tre cose che si progettano, non si improvvisano: un punto di contatto pubblico per la segnalazione responsabile delle vulnerabilità (una pagina raggiungibile e un indirizzo che qualcuno legge davvero), un inventario delle versioni firmware installate sul campo, e la possibilità di distribuire una patch in tempi compatibili con la finestra di 14 giorni della relazione finale. Un parco macchine aggiornabile solo con un tecnico in loco e una chiavetta non regge questo calendario.
Il CRA si applica anche ai dispositivi non connessi a Internet
È il malinteso più diffuso, e quello che lascia scoperte le aziende più tradizionali. Il regolamento parla di “prodotti con elementi digitali” la cui destinazione d'uso, o l'uso ragionevolmente prevedibile, comporta una connessione dati logica o fisica diretta o indiretta a un dispositivo o a una rete.
Quel indiretta è la parola decisiva. Un nodo sensore su bus CAN che non ha né Ethernet né radio, e che dialoga solo con la centralina della macchina su cui è montato, rientra nel perimetro se quella centralina è a sua volta collegata a un gateway, a un PLC o a un sistema di telemetria. Ed è esattamente l'architettura della quasi totalità delle macchine industriali e delle macchine mobili prodotte oggi.
La conseguenza progettuale è che la sicurezza non può essere concentrata sul solo componente “connesso”. In una rete CAN ogni nodo è un potenziale punto di ingresso, e il bus – per come è nato – non offre autenticazione dei messaggi. Ragionare per perimetro, mettendo un firewall sul gateway e assumendo che il resto sia protetto, è la parte che il CRA obbliga a rivedere.
Cosa deve avere il firmware: secure boot, OTA firmato e SBOM
I requisiti essenziali dell'Allegato I diventano vincolanti nel dicembre 2027, ma un prodotto in sviluppo oggi arriverà sul mercato dopo quella data. Sono quindi decisioni da prendere adesso, nella fase in cui costano poco: aggiungere secure boot a un progetto già validato significa quasi sempre cambiare microcontrollore e rifare la campagna di test.
Secure boot e root of trust
Il dispositivo deve verificare crittograficamente il codice che esegue, a partire da una radice di fiducia immutabile. Sui progetti nuovi la scelta più lineare è una MCU con TrustZone e boot sicuro nativo – la famiglia STM32 Cortex-M33 (H5, U5, L5) integra secure boot, gestione delle chiavi e protezione del debug senza componenti esterni. Il costo differenziale rispetto a una MCU equivalente senza queste funzioni è oggi nell'ordine di pochi euro; il costo di aggiungerle dopo è un redesign.
Aggiornamento firmware firmato
L'aggiornamento OTA deve essere autenticato, integro e reversibile. In pratica: firma asimmetrica dell'immagine verificata dal bootloader, dual bank con rollback automatico se la nuova immagine non parte, e anti-downgrade per impedire il ritorno forzato a una versione vulnerabile. Su bus CAN questo si traduce in un bootloader che gestisce l'aggiornamento a nodo remoto senza smontare la macchina – una funzione che, prima del CRA, molti consideravano un lusso.
Software Bill of Materials
L'SBOM è l'elenco tracciabile di tutto ciò che gira nel prodotto, nei formati standard CycloneDX o SPDX: RTOS, stack di comunicazione, librerie crittografiche, HAL del produttore, e le rispettive versioni. Serve a rispondere in poche ore alla sola domanda che conta quando esce una CVE su una libreria diffusa: i nostri prodotti la usano, e quali. Senza SBOM quella risposta richiede giorni di archeologia sul codice, e la finestra è di 24 ore.
Periodo di supporto dichiarato
Il fabbricante deve stabilire e comunicare per quanto tempo fornirà aggiornamenti di sicurezza: il regolamento indica almeno cinque anni, salvo che la vita attesa del prodotto sia inferiore. Per l'industriale, dove una macchina resta in servizio dieci o quindici anni, questo si riflette a monte sulla scelta dei componenti: un microcontrollore a fine ciclo di vita o uno stack software non più mantenuto rendono impossibile onorare l'impegno.
Cosa fare entro settembre 2026: cinque passi concreti
- Censire il catalogo: elencare i prodotti a marchio proprio che hanno una connessione dati, anche indiretta. È la lista di ciò che ricade nel perimetro.
- Pubblicare un canale di segnalazione: una pagina di coordinated vulnerability disclosure con un indirizzo presidiato, e un file
security.txtsecondo la RFC 9116. È il passo che costa meno ed è anche il più visibile. - Ricostruire l'SBOM dei prodotti attivi: partendo da quelli con maggiore diffusione sul campo. Se il firmware è stato sviluppato all'esterno, richiederlo al fornitore.
- Definire la procedura di notifica: chi decide che una vulnerabilità è “attivamente sfruttata”, chi compila la segnalazione, entro quanto. Una procedura di tre righe che funziona vale più di un manuale.
- Mettere i requisiti nei progetti nuovi: secure boot, OTA firmato e generazione dell'SBOM entrano nelle specifiche insieme alle funzioni, non dopo la validazione.
L'approccio Nexilica alla conformità CRA
In Nexilica la conformità normativa non è una fase finale del progetto: entra nella consulenza tecnologica iniziale, insieme alla marcatura CE e all'analisi di fattibilità. Sul piano hardware significa selezionare il microcontrollore anche in base alle funzioni di sicurezza e al ciclo di vita dichiarato dal produttore, e curare la progettazione elettronica prevedendo l'accesso protetto al debug. Sul piano software significa costruire il firmware embedded con bootloader sicuro, catena di firma e generazione automatica dell'SBOM nella pipeline di build – dove non costa nulla, perché è il compilatore a fornire l'elenco delle dipendenze.
Vale anche per i dispositivi con intelligenza artificiale embedded, dove il modello stesso – non solo il firmware che lo esegue – deve essere aggiornabile in modo sicuro e tracciato nell'SBOM.
Il Cyber Resilience Act non chiede di reinventare il prodotto: chiede di poterlo aggiornare, sapere cosa contiene e accorgersi quando qualcosa va storto. Sono tre requisiti che si mettono nell'architettura all'inizio e costano poco, oppure si rincorrono dopo e costano un redesign. Se stai progettando un prodotto che arriverà sul mercato dopo il 2027, o se hai un parco installato da mettere in regola per settembre, contattaci: partiamo da un'analisi del perimetro e da cosa manca davvero.
