Il CRA in un'ora: cosa cambia per chi costruisce prodotti connessi
29 luglio 2026·7 min di lettura·Alberto Scarpa
La maggior parte dei produttori sa che il CRA esiste. Molto meno chiaro è cosa chieda davvero, e come tradurne i requisiti in decisioni concrete di sviluppo. È la distanza tra “abbiamo letto che c’è un regolamento nuovo” e “sappiamo quali decisioni di prodotto prendere entro dicembre 2027”, ed è la distanza che costa.
Il Cyber Resilience Act (Regolamento UE 2024/2847, in vigore dal 10 dicembre 2024) è una legge di sicurezza del prodotto. Non descrive buone pratiche: impone requisiti che devono essere veri di ogni prodotto con elementi digitali venduto sul mercato europeo. Chi non li soddisfa non marca CE. Chi non marca CE non vende. In un’ora di lettura si capisce l’essenziale, e questo articolo è quell’ora. I riferimenti tra parentesi rimandano al testo ufficiale; dove scrivo un’interpretazione mia, lo segnalo.
Cosa rientra: “prodotto con elementi digitali”
Il perimetro del CRA è ampio in modo scomodo. Un prodotto con elementi digitali (PDE) è, nella definizione del regolamento, “qualsiasi prodotto software o hardware e le relative soluzioni di elaborazione dati da remoto” (art. 3, punto 1). Non serve che sia “smart” nel senso commerciale del termine.
In concreto: se il tuo prodotto ha un microcontrollore, un firmware, una porta di comunicazione o un componente che dialoga con qualcos’altro, con ogni probabilità è dentro. La centralina di una macchina agricola, il gateway di un impianto, il sensore che manda dati su un bus: tutti PDE.
Il confine, sul piano tecnico, si gioca sul tipo di connessione. Il regolamento distingue connessione logica, fisica e indiretta (art. 3, punti 8, 9 e 10), e considera parte del prodotto anche l’elaborazione dati da remoto sviluppata dal fabbricante, quando la sua assenza impedirebbe al prodotto di svolgere una funzione (art. 3, punto 2): il back-end cloud rientra. Gli orientamenti della Commissione (documento C(2026) 5252, non vincolanti, adottati ai sensi dell’art. 26) precisano che un segnale il quale si limita ad alimentare o attivare una funzione, senza trasportare dati digitali codificati, resta fuori.
Nota operativa (mia lettura, non testo di legge). Sul confine “trasporta dati oppure solo alimenta e attiva” si decide se un’intera linea di prodotto rientra o no. È la prima analisi che farei, prima di ogni altra: cambia tutto il resto.
I tre obblighi che prima non esistevano
Chi conosce IEC 62443 o i framework NIST riconosce buona parte dei requisiti del CRA, raccolti nell’Allegato I: sicurezza del prodotto (parte I) e gestione delle vulnerabilità (parte II). Ma tre obblighi non avevano un equivalente cogente prima del CRA. Sono questi che cambiano il modo di lavorare.
Il primo è il periodo di assistenza. Il fabbricante deve garantire la gestione delle vulnerabilità e gli aggiornamenti di sicurezza per un periodo che riflette la durata d’uso attesa del prodotto, e comunque per almeno cinque anni (art. 13, par. 8). Gli aggiornamenti già rilasciati devono restare disponibili per almeno dieci anni, o per il resto del periodo di assistenza se più lungo (art. 13, par. 9). IEC 62443 non prescrive alcuna durata; il CRA sì. Significa progettare da subito il meccanismo con cui distribuirai firmware firmato a un device che magari vendi una volta sola.
Il secondo è la segnalazione. Una vulnerabilità attivamente sfruttata va notificata al CSIRT coordinatore e a ENISA con un preallarme entro 24 ore dalla scoperta (art. 14, par. 2, lett. a), una notifica entro 72 ore (lett. b) e una relazione finale entro 14 giorni dalla messa a disposizione della correzione (lett. c), tramite la piattaforma unica di segnalazione (art. 16). Se il tuo processo di gestione delle vulnerabilità oggi misura i tempi in settimane, il CRA lo misura in ore. Le scadenze esatte, e cosa serve avere pronto per ciascuna, le ho messe in fila in Le scadenze del CRA.
Il terzo è la distinta base del software (SBOM, Software Bill of Materials): nella definizione del regolamento, “un registro formale contenente i dettagli e le relazioni della catena di approvvigionamento dei componenti” software del prodotto (art. 3, punto 39). Non è una best practice interna: è un requisito di gestione delle vulnerabilità (Allegato I, parte II, punto 1), che chiede di includere almeno le dipendenze di primo livello. È la distinta base del software. Se sai esattamente quali librerie hai integrato e in quale versione, gestisci una vulnerabilità critica in un giorno. Se non lo sai, ogni segnalazione diventa un’emergenza.
La conformità non è un documento a fine progetto
Qui sta il vero cambio di impostazione, e vale la pena dirlo senza giri: sotto il CRA la conformità non è qualcosa che sistemi prima della marcatura CE. Il regolamento chiede una valutazione dei rischi di cibersicurezza documentata e aggiornata per tutto il periodo di assistenza (art. 13, par. 2 e 3) e una gestione delle vulnerabilità che continua dopo il lancio (Allegato I, parte II). Il fabbricante deve dimostrare non solo che il prodotto era sicuro il giorno della vendita, ma che resta gestito per tutto il periodo dichiarato. Dimostrare è la parola chiave: serve evidenza documentata e aggiornata (art. 13, par. 3), quella che regge a un controllo di vigilanza del mercato, non una cartella messa insieme a posteriori.
In pratica: la sicurezza entra nelle decisioni di progetto (architettura, scelta dei componenti, meccanismo di aggiornamento), non nella documentazione di chiusura. Un sistema embedded pensato senza questo requisito ha due strade davanti: un retrofit costoso prima della scadenza, o un prodotto fuori mercato. Se parti da un sistema qualità certificato ISO 9001, una parte di questo impianto la puoi riusare, e una parte no: ne parlo in Hai già la ISO 9001?.
Un timore diffuso lo sciolgono gli orientamenti della Commissione (C(2026) 5252): un prodotto progettato prima del CRA può restare sul mercato dopo il 2027 sulla base di una valutazione del rischio attuale, senza obbligo di ricostruire documentazione storica di progetto che non esiste più. Il vincolo è sul futuro, non sul passato.
Chi decide se puoi autocertificarti
Non tutti i prodotti seguono lo stesso percorso. Il CRA distingue i PDE “default” (la maggioranza), i prodotti “importanti” elencati nell’Allegato III e divisi in classe I e II (art. 7), e i prodotti “critici” dell’Allegato IV (art. 8). La fascia decide la procedura di valutazione della conformità (art. 32).
In pratica: i prodotti default si autocertificano con il controllo interno (modulo A, Allegato VIII, parte I); i prodotti importanti e critici possono richiedere l’applicazione di norme armonizzate o l’intervento di un organismo notificato (art. 32, par. 2 e 3). Applicare una norma armonizzata dà presunzione di conformità (art. 27): è la scorciatoia legale che evita di dimostrare il requisito da zero.
Un punto che il regolamento mette nero su bianco, e che pesa in fase di progettazione: integrare in un prodotto un componente con funzionalità “importante” non rende, di per sé, l’intero prodotto soggetto alle procedure più severe (art. 7, par. 1). È la funzione principale del prodotto nel suo insieme a determinare il percorso. Un microcontrollore o un firewall dentro un device non lo rendono automaticamente “importante”.
Da dove si parte davvero
Il primo passo non è scegliere una norma. È guardare le proprie linee di prodotto e rispondere a tre domande: quali rientrano come PDE (art. 3, punto 1), in quale fascia cadono (art. 6, 7 e 8), e per ciascuna quanto dista il processo attuale dai requisiti dell’Allegato I. È un lavoro di mezza giornata per una linea, poco entusiasmante e decisivo, perché ogni stima di costo fatta prima di averlo fatto è un numero inventato.
La decisione non è se adeguarsi. È quando. E chi la paga di più è chi aspetta.
Riferimenti: Regolamento (UE) 2024/2847 (CRA), articoli 3, 6, 7, 8, 13, 14, 16, 27, 32 e Allegati I, III, IV, VIII; orientamenti della Commissione C(2026) 5252 (non vincolanti, art. 26). Le note segnalate come operative sono mie interpretazioni, non testo normativo.