Cyber Resilience Act (CRA): cos'è e chi riguarda

Il Cyber Resilience Act è il regolamento (UE) 2024/2847: impone requisiti di cibersicurezza a chi immette sul mercato europeo prodotti con elementi digitali, cioè software e hardware che si connettono a un dispositivo o a una rete. Si applica in pieno dall'11 dicembre 2027, ma gli obblighi di segnalazione delle vulnerabilità sfruttate valgono già dall'11 settembre 2026.

Chi cerca informazioni su questo regolamento, di solito abbreviato in CRA, ha in testa una domanda sola: riguarda anche la mia azienda. Qui rispondiamo con i criteri del testo, articolo per articolo, e con il calendario reale, che non è una data unica e proprio per questo viene raccontato spesso in modo sbagliato.

Che cos'è il Cyber Resilience Act

Il titolo ufficiale dell'atto è lungo: regolamento (UE) 2024/2847 del Parlamento europeo e del Consiglio del 23 ottobre 2024 relativo a requisiti orizzontali di cibersicurezza per i prodotti con elementi digitali. È stato pubblicato nella Gazzetta ufficiale dell'Unione europea il 20 novembre 2024 ed è entrato in vigore il ventesimo giorno successivo, cioè il 10 dicembre 2024.

Essendo un regolamento e non una direttiva si applica direttamente in tutti gli Stati membri: non c'è un decreto italiano di recepimento da aspettare, come è stato invece per la NIS2 con il D.Lgs. 138/2024.

L'articolo 1 fissa quattro contenuti: norme per la messa a disposizione sul mercato dei prodotti con elementi digitali, requisiti essenziali di cibersicurezza per progettazione, sviluppo e produzione, requisiti per i processi di gestione delle vulnerabilità "durante il periodo in cui si prevede che i prodotti siano in uso", regole di vigilanza del mercato. In pratica il CRA porta sul terreno della cibersicurezza la logica della marcatura CE: un prodotto non conforme non si può mettere sul mercato europeo.

Riguarda anche la mia azienda? Quattro verifiche concrete

Il perimetro si stabilisce in quattro passaggi: i primi due dicono se sei dentro, gli altri due quanto ti costa esserci.

1. Il prodotto ha una connessione dati

L'articolo 2 definisce l'ambito: il regolamento si applica ai prodotti con elementi digitali messi a disposizione sul mercato "la cui finalità prevista o il cui utilizzo ragionevolmente prevedibile include una connessione dati logica o fisica diretta o indiretta a un dispositivo o a una rete". La definizione di prodotto con elementi digitali (articolo 3, punto 1) è ampia: qualsiasi prodotto software o hardware e le relative soluzioni di elaborazione dati da remoto, compresi i componenti immessi sul mercato separatamente.

Due dettagli che allargano il perimetro più di quanto si pensi. La connessione può essere indiretta, quindi un componente che dialoga solo con un altro apparato, che a sua volta va in rete, è dentro. E la definizione di fabbricante include la commercializzazione "a titolo oneroso, di monetizzazione o gratuito": rientra anche il software distribuito gratuitamente nel corso di un'attività commerciale.

2. Che ruolo hai nella catena

È il punto che il mid-market industriale italiano sottovaluta di più. Gli obblighi pesanti, articoli 13 e 14, stanno in capo al fabbricante, cioè a chi sviluppa o fa sviluppare il prodotto e lo commercializza con il proprio nome o marchio. Ma l'articolo 21 è netto:

• un importatore o distributore è ritenuto fabbricante, con gli stessi obblighi, quando immette sul mercato un prodotto con il proprio nome o marchio commerciale;
• lo stesso vale quando apporta una modifica sostanziale a un prodotto già sul mercato, cioè una modifica che incide sulla conformità ai requisiti essenziali o che cambia la finalità prevista per cui il prodotto era stato valutato;
• l'articolo 22 estende la regola a chiunque altro apporti una modifica sostanziale e metta il prodotto a disposizione sul mercato.

Tradotto: chi fa private label su hardware di terzi è fabbricante; chi integra un modulo software in una macchina e la vende con il proprio marchio è fabbricante; chi personalizza in modo significativo un prodotto altrui e lo rivende è fabbricante per la parte modificata, o per l'intero prodotto se la modifica incide sulla cibersicurezza complessiva. Che il codice l'abbia scritto qualcun altro non sposta la responsabilità.

3. Cosa resta fuori

Le esclusioni dell'articolo 2 sono precise, non generiche: dispositivi medici e diagnostici in vitro (regolamenti (UE) 2017/745 e 2017/746), veicoli a motore (regolamento (UE) 2019/2144), prodotti certificati per l'aviazione civile (regolamento (UE) 2018/1139), equipaggiamento marittimo (direttiva 2014/90/UE), pezzi di ricambio identici, prodotti per sicurezza nazionale, difesa o informazioni classificate.

Merita una riga a parte il software erogato come servizio. Il regolamento copre le soluzioni di elaborazione dati da remoto solo quando sono parte del prodotto, cioè quando la loro assenza impedirebbe al prodotto di svolgere una delle sue funzioni. Il considerando 12 lo chiarisce: i servizi cloud la cui progettazione e il cui sviluppo esulano dalla responsabilità del fabbricante di un prodotto non rientrano, e ai modelli SaaS, PaaS e IaaS si applica la direttiva (UE) 2022/2555, cioè la NIS2. Di regola, quindi, un gestionale venduto in abbonamento e usato dal browser resta fuori, mentre l'app che comanda un apparato e il servizio che la fa funzionare, sviluppati dal fabbricante di quell'apparato, rientrano: la verifica va fatta caso per caso sulla definizione di elaborazione dati da remoto.

4. Il prodotto è "importante" o "critico"

Se sei dentro, la categoria decide come si dimostra la conformità. L'Allegato III elenca i prodotti importanti in due classi, in base alla funzionalità principale. In classe I stanno, tra gli altri, sistemi di gestione dell'identità e degli accessi privilegiati, browser, gestori di password, antimalware, prodotti con funzione VPN, sistemi di gestione della rete, sistemi SIEM, sistemi operativi, router, modem e switch, prodotti per case intelligenti con funzionalità di sicurezza, giocattoli connessi con funzioni sociali o di geolocalizzazione. In classe II ce ne sono quattro: ipervisori e sistemi di runtime container, firewall e sistemi di rilevamento e prevenzione delle intrusioni, microprocessori e microcontrollori a prova di manomissione. L'Allegato IV elenca i prodotti critici: dispositivi hardware con cassette di sicurezza, gateway per contatori intelligenti, carte intelligenti ed elementi sicuri. Per capire dove ricade il proprio prodotto non basta il nome commerciale: la descrizione tecnica di tutte queste categorie sta nel regolamento di esecuzione (UE) 2025/2392 del 28 novembre 2025, pubblicato in Gazzetta ufficiale dell'Unione europea il 1 dicembre 2025.

La classificazione conta perché cambia la procedura di valutazione della conformità (articolo 32): per i prodotti che non sono importanti né critici basta il controllo interno; per la classe I resta possibile solo applicando norme armonizzate, specifiche comuni o un sistema europeo di certificazione, altrimenti serve un organismo notificato; per la classe II serve sempre l'esame UE del tipo, la garanzia della qualità totale o una certificazione europea. È la ragione per cui il capo IV sugli organismi notificati si applica prima del resto.

Il calendario: tre date, non una

Qui si concentrano gli errori che circolano. L'articolo 71 stabilisce tre momenti distinti.

1. 11 giugno 2026: si applica il capo IV, articoli da 35 a 51, cioè le regole su autorità di notifica e organismi notificati.
2. 11 settembre 2026: si applica l'articolo 14, gli obblighi di segnalazione dei fabbricanti. Questa data è già passata: l'obbligo è operativo.
3. 11 dicembre 2027: si applica tutto il resto, quindi requisiti essenziali, marcatura CE, dichiarazione di conformità UE, documentazione tecnica, valutazione della conformità.

C'è poi una disposizione transitoria che vale la pena leggere due volte. L'articolo 69 comma 2 dice che i prodotti immessi sul mercato prima dell'11 dicembre 2027 sono soggetti al regolamento solo se, da quella data, subiscono una modifica sostanziale. Ma il comma 3 introduce una deroga esplicita: gli obblighi dell'articolo 14 si applicano a tutti i prodotti nell'ambito di applicazione immessi sul mercato prima dell'11 dicembre 2027. In pratica il parco installato non è esente dalla segnalazione, anche se è esente dai requisiti di prodotto fino a una modifica sostanziale.

Cosa chiede, in concreto

Requisiti sul prodotto

L'Allegato I, parte I, elenca i requisiti essenziali, da applicare sulla base della valutazione dei rischi di cibersicurezza che l'articolo 13 impone di documentare. I più impegnativi da dimostrare: immissione sul mercato senza vulnerabilità sfruttabili note, configurazione sicura per impostazione predefinita, correzione delle vulnerabilità tramite aggiornamenti di sicurezza, controllo degli accessi con segnalazione di quelli non autorizzati, riservatezza e integrità dei dati, continuità delle funzioni essenziali anche dopo un incidente, superficie di attacco limitata, registrazione e monitoraggio delle attività interne rilevanti.

Gestione delle vulnerabilità e periodo di assistenza

L'Allegato I, parte II, riguarda i processi, e per molte aziende è la parte che manca davvero: una distinta base del software leggibile da un dispositivo automatico con almeno le dipendenze di primo livello, correzione tempestiva delle vulnerabilità con aggiornamenti separati da quelli funzionali, prove e riesami periodici della sicurezza del prodotto, divulgazione pubblica delle vulnerabilità risolte, una politica di divulgazione coordinata con un indirizzo di contatto dedicato, distribuzione degli aggiornamenti in modo sicuro, gratuito e tempestivo.

A questo si lega il periodo di assistenza dell'articolo 13 comma 8. Lo determina il fabbricante in base alla durata di utilizzo prevista del prodotto, ma il testo fissa un pavimento: almeno cinque anni, salvo che il prodotto sia destinato a essere usato per meno tempo. Ogni aggiornamento di sicurezza reso disponibile in quel periodo resta accessibile per almeno dieci anni dal rilascio, o per il resto del periodo di assistenza se più lungo (comma 9), e la data finale del periodo, con almeno mese e anno, va indicata in modo chiaro al momento dell'acquisto (comma 19).

Chi vende apparati con una vita utile di quindici anni si accorge subito che questa è la clausola con l'impatto economico maggiore: significa impegnare risorse di sviluppo su versioni che oggi si considerano chiuse. Le prove e i riesami periodici della parte II, poi, sono il tipo di lavoro che si organizza con un programma di vulnerability assessment ricorrente, non con un controllo una tantum prima del lancio.

Segnalazione: 24 ore, 72 ore, relazione finale

L'articolo 14, quello già applicabile, prevede due eventi da notificare simultaneamente al CSIRT designato come coordinatore e all'ENISA, attraverso la piattaforma unica di segnalazione istituita dall'articolo 16: le vulnerabilità attivamente sfruttate contenute nel prodotto e gli incidenti gravi che hanno un impatto sulla sicurezza del prodotto.

Una vulnerabilità è "attivamente sfruttata" quando esistono prove attendibili che un soggetto malintenzionato l'ha sfruttata in un sistema senza l'autorizzazione del proprietario. I tempi:

• preallarme entro 24 ore da quando il fabbricante ne è venuto a conoscenza;
• notifica entro 72 ore, con informazioni sul prodotto interessato, sulla natura dello sfruttamento e sulle misure correttive o di attenuazione;
• relazione finale entro 14 giorni dalla messa a disposizione di una misura correttiva o di attenuazione, nel caso della vulnerabilità, o entro un mese dalla notifica delle 72 ore, nel caso dell'incidente grave.

Il comma 8 aggiunge un obbligo verso il mercato: il fabbricante informa gli utilizzatori interessati della vulnerabilità o dell'incidente e delle misure che possono adottare; se non lo fa tempestivamente, può farlo il CSIRT. La sequenza ricorda quella della notifica degli incidenti NIS2, ma le due non si sostituiscono: là si notifica un incidente che colpisce i propri servizi come soggetto obbligato, qui una falla nel prodotto che si è messo sul mercato, verso tutti gli utilizzatori che lo hanno installato.

Le sanzioni

L'articolo 64 lascia agli Stati membri le norme sanzionatorie, ma fissa i massimali:

• fino a 15 milioni di euro o al 2,5% del fatturato mondiale totale annuo dell'esercizio precedente, se superiore, per la non conformità ai requisiti essenziali dell'Allegato I e agli obblighi degli articoli 13 e 14;
• fino a 10 milioni di euro o al 2% per gli obblighi di importatori e distributori, dichiarazione di conformità, marcatura CE, documentazione tecnica e valutazione della conformità;
• fino a 5 milioni di euro o all'1% per informazioni inesatte, incomplete o fuorvianti fornite a organismi notificati e autorità di vigilanza del mercato.

Il comma 10 prevede due esenzioni mirate, e conviene leggerne la portata esatta: in deroga ai paragrafi da 3 a 9, le sanzioni pecuniarie previste da quei paragrafi non si applicano ai fabbricanti che si qualificano come microimprese o piccole imprese per il mancato rispetto del termine di 24 ore, né alle violazioni dei gestori di software open source.

Cyber Resilience Act e NIS2: due perimetri che si incontrano

Sono due norme diverse e conviene tenerle separate in testa. La NIS2 guarda a chi eroga servizi in settori individuati e chiede misure di gestione del rischio sui propri sistemi; il Cyber Resilience Act guarda a cosa metti sul mercato. Un'azienda può essere fuori da una e dentro all'altra, o dentro a entrambe con due impianti di conformità distinti: per il perimetro NIS2 valgono i criteri di settore e dimensione spiegati in a chi si applica la NIS2.

Il punto di contatto è la catena di fornitura, ed è il motivo per cui questo regolamento arriva sulla scrivania di aziende che non lo stavano seguendo. I soggetti NIS2 devono presidiare il rischio dei propri fornitori, e l'articolo 5 del Cyber Resilience Act chiede agli Stati membri di far pesare nelle procedure di appalto la conformità ai requisiti essenziali, compresa la capacità del fabbricante di gestire le vulnerabilità. Nella pratica significa questionari, clausole contrattuali e richieste di evidenze che scendono lungo la filiera, la stessa dinamica già descritta per la NIS2 nel manifatturiero. Chi produce componenti per un cliente regolato si sentirà chiedere la documentazione prima di dicembre 2027, non a dicembre 2027.

Da dove partire adesso

Con l'articolo 14 già applicabile e l'applicazione generale a dicembre 2027, il lavoro utile nei prossimi mesi è ordinato. Cinque passi, in quest'ordine.

1. Inventario dei prodotti che immetti sul mercato europeo con il tuo marchio, software compreso, segnando se hanno una connessione dati diretta o indiretta.
2. Ruolo per ogni prodotto, alla luce degli articoli 21 e 22: fabbricante, importatore, distributore, oppure fabbricante di fatto perché rimarchi o modifichi.
3. Classificazione di quello che resta dentro, con gli Allegati III e IV e il regolamento di esecuzione (UE) 2025/2392: la classe decide se ti serve un organismo notificato.
4. Attivazione della parte già obbligatoria: chi monitora le vulnerabilità sui tuoi prodotti, chi decide se una è attivamente sfruttata, chi trasmette il preallarme entro 24 ore e con quali dati. È un processo con nomi e turni, non una procedura scritta e archiviata.
5. Cantiere sui processi dell'Allegato I parte II: distinta base del software, politica di divulgazione coordinata, cadenza delle prove di sicurezza, decisione sul periodo di assistenza e su come comunicarlo.

Gli ultimi due passi sono organizzativi prima che tecnologici, e sono quelli che un cliente ti chiederà per primo, molto prima che un'autorità di vigilanza del mercato bussi alla porta.

Se stai ricostruendo il perimetro dei tuoi prodotti e vuoi confrontarti su come impostare monitoraggio delle vulnerabilità e processo di segnalazione, scrivici: partiamo da cosa avete già in casa.

In sintesi: il Cyber Resilience Act è il regolamento (UE) 2024/2847 sui prodotti con elementi digitali, in vigore dal 10 dicembre 2024 e applicabile in pieno dall'11 dicembre 2027, con gli obblighi di segnalazione dell'articolo 14 già operativi dall'11 settembre 2026. Riguarda chi produce, ma anche chi rivende con il proprio marchio o modifica in modo sostanziale. Il lavoro vero non è il certificato: è sapere quali prodotti hai sul mercato, chi ne risponde e come gestisci le vulnerabilità per tutta la loro vita utile.