Il Cyber Resilience Act (CRA), Regolamento (UE) 2024/2847, introduce nell’Unione europea un quadro orizzontale di requisiti di cybersecurity per i prodotti con elementi digitali. A differenza di normative come la NIS2, che si concentra principalmente su determinate categorie di soggetti e servizi, il CRA guarda soprattutto al prodotto e alla sua sicurezza lungo il ciclo di vita.
Il regolamento è entrato in vigore il 10 dicembre 2024. La maggior parte degli obblighi si applicherà dall’11 dicembre 2027, ma alcune disposizioni sono già operative: in particolare, gli obblighi di reporting dell’art. 14 si applicano dall’11 settembre 2026. Strategia Digitale Europea+1
A chi si applica il CRA?
Il punto di partenza è il concetto di “prodotto con elementi digitali”. Si tratta, in sostanza, di un prodotto hardware o software e delle relative soluzioni di trattamento dati a distanza, compresi componenti hardware o software immessi sul mercato separatamente, quando la finalità prevista o l’uso ragionevolmente prevedibile comprende una connessione, diretta o indiretta, logica o fisica, a un dispositivo o a una rete.
Il perimetro è quindi molto ampio e può comprendere, tra gli altri, software, sistemi operativi, applicazioni, dispositivi IoT, router, switch, telecamere, sistemi embedded, componenti hardware e software e prodotti di cybersecurity.
Gli obblighi principali gravano sui seguenti soggetti.
Fabbricanti
È il soggetto centrale del CRA. È considerato fabbricante chi sviluppa o produce un prodotto, oppure ne commissiona lo sviluppo o la produzione, e lo commercializza con il proprio nome o marchio, anche se il prodotto è fornito gratuitamente. EUR-Lex
Il fabbricante deve assicurare che il prodotto sia progettato, sviluppato e prodotto nel rispetto dei requisiti essenziali di cybersecurity e deve effettuare una valutazione documentata dei rischi di cybersecurity.
Gli obblighi non si esauriscono al momento dell’immissione sul mercato: il CRA introduce infatti una vera e propria responsabilità di vulnerability handling durante il ciclo di vita del prodotto.
Importatori
L’importatore UE di un prodotto fabbricato da un soggetto extra-UE deve svolgere specifici controlli prima dell’immissione sul mercato, verificando, tra l’altro, la conformity assessment, la documentazione tecnica, la marcatura CE, la dichiarazione UE di conformità e le informazioni per l’utilizzatore.
Se viene a conoscenza di una vulnerabilità, deve informare senza indebito ritardo il fabbricante; in presenza di un rischio significativo di cybersecurity sono previsti ulteriori obblighi nei confronti delle autorità di vigilanza.
Distributori
Anche i distributori sono soggetti a obblighi di due diligence. Devono, tra l’altro, verificare la presenza della marcatura CE e alcuni elementi relativi agli obblighi del fabbricante e dell’importatore, nonché adottare misure correttive quando emergano problemi di conformità o rischi significativi.
Soggetti che modificano sostanzialmente un prodotto
Particolare attenzione deve essere prestata alle modifiche successive alla prima immissione sul mercato.
Un soggetto diverso dal fabbricante, importatore o distributore che effettua una modifica sostanziale e mette il prodotto a disposizione sul mercato può essere considerato fabbricante ai fini del CRA e assumere gli obblighi degli artt. 13 e 14 per la parte modificata o, in determinate circostanze, per l’intero prodotto.
Quali prodotti sono particolarmente interessati?
Il CRA si applica, in linea di principio, ai prodotti con elementi digitali che rientrano nel suo perimetro generale. Alcune categorie sono tuttavia considerate più rischiose e sono sottoposte a procedure di valutazione della conformità più rigorose.
Tra i prodotti importanti di Classe I rientrano, ad esempio, sistemi di gestione dell’identità e degli accessi privilegiati, password manager, software antimalware, VPN, sistemi di network management, SIEM, sistemi PKI, sistemi operativi, router, modem e switch, nonché alcuni prodotti smart home e wearable.
La Classe II comprende, tra gli altri, hypervisor e container runtime, firewall, sistemi di intrusion detection/prevention e alcuni microprocessori e microcontrollori tamper-resistant.
L’Allegato IV individua inoltre alcune categorie di prodotti critici, tra cui determinati hardware security devices, smart-meter gateways e smartcard/secure elements.
La classificazione è importante soprattutto perché determina la procedura di conformity assessment. Per i prodotti ordinari può essere sufficiente, in determinate condizioni, il controllo interno; per i prodotti importanti di Classe I e soprattutto di Classe II sono previste procedure più rigorose, con coinvolgimento di organismi terzi nei casi previsti dal regolamento.
I principali obblighi dei fabbricanti
Il CRA introduce un insieme di obblighi che interessano tanto la fase di progettazione quanto quella successiva all’immissione sul mercato.
Tra i principali:
- effettuare e documentare una cybersecurity risk assessment;
- progettare e sviluppare il prodotto secondo principi di sicurezza by design e by default;
- identificare e gestire le vulnerabilità;
- predisporre una policy di coordinated vulnerability disclosure;
- predisporre un punto di contatto per la segnalazione delle vulnerabilità;
- effettuare test e revisioni periodiche della sicurezza;
- predisporre meccanismi sicuri per la distribuzione degli aggiornamenti;
- fornire tempestivamente gli aggiornamenti di sicurezza;
- predisporre la documentazione tecnica;
- effettuare la procedura di valutazione della conformità applicabile;
- redigere la dichiarazione UE di conformità;
- apporre la marcatura CE quando richiesta;
- fornire agli utenti informazioni e istruzioni per l’uso sicuro del prodotto;
- comunicare chiaramente il periodo di assistenza del prodotto. Strategia Digitale Europea+1
Particolarmente significativo è il support period: il fabbricante deve garantire una gestione efficace delle vulnerabilità per il periodo in cui il prodotto è ragionevolmente atteso in uso. Il periodo deve essere, in linea generale, di almeno cinque anni; se il prodotto è ragionevolmente destinato a essere utilizzato per meno di cinque anni, il periodo può corrispondere alla durata prevista di utilizzo.
Gli aggiornamenti di sicurezza devono essere distribuiti senza ritardo e, salvo l’eccezione prevista per determinati prodotti su misura destinati a utenti professionali, gratuitamente.
Il CRA richiede inoltre che il fabbricante identifichi e documenti vulnerabilità e componenti, anche attraverso una software bill of materials (SBOM) in formato machine-readable, almeno per le dipendenze di primo livello.
Il nuovo obbligo di reporting: già operativo
L’aspetto più urgente, perché già applicabile, è l’art. 14.
Dal 11 settembre 2026, i fabbricanti devono notificare le:
- actively exploited vulnerabilities, ossia vulnerabilità contenute nel prodotto che risultano essere attivamente sfruttate;
- severe incidents, cioè incidenti gravi che incidono sulla sicurezza del prodotto.
La notifica deve essere effettuata attraverso la Single Reporting Platform (SRP) gestita da ENISA-.
I termini sono particolarmente stringenti:
- entro 24 ore dalla conoscenza: early warning;
- entro 72 ore: notifica completa;
- per una vulnerabilità attivamente sfruttata, entro 14 giorni dalla disponibilità della misura correttiva: relazione finale;
- per un incidente grave, entro un mese dalla notifica delle 72 ore: relazione finale.
Questo rende opportuno, già oggi, integrare il CRA nei processi di incident response e vulnerability management dell’azienda.
Per le microimprese e piccole imprese esiste una specifica deroga alle sanzioni amministrative per il mancato rispetto del termine di 24 ore previsto dall’art. 14, ma l’obbligo di reporting resta.
E il software open source?
Il CRA introduce una disciplina particolare per il free and open-source software.
Il software open source non commercializzato non è automaticamente equiparato a un prodotto commerciale. Tuttavia, il regolamento introduce la figura dell’open-source software steward: un soggetto giuridico che fornisce supporto sistematico e continuativo allo sviluppo di determinati prodotti open source destinati ad attività commerciali.
Gli steward sono soggetti a obblighi specifici, tra cui una cybersecurity policy e attività di vulnerability handling. Gli obblighi di reporting dell’art. 24(3) si applicheranno dall’11 dicembre 2027.
SaaS e cloud: attenzione alle semplificazioni
Non è corretto affermare che “tutto il software” o “tutto il cloud” rientri nel CRA.
Un SaaS puro, in linea generale, non è un prodotto con elementi digitali soggetto al CRA. Tuttavia, una soluzione di trattamento dati a distanza può rientrare nel regolamento quando il software è sviluppato dal fabbricante o sotto la sua responsabilità e la sua assenza impedirebbe al prodotto di svolgere una delle proprie funzioni.
Un esempio è una smart home device la cui funzionalità dipende da un servizio cloud sviluppato dal relativo fabbricante. Al contrario, i servizi cloud generici non necessari al funzionamento di un prodotto non ricadono, per questo solo fatto, nel CRA.
Le principali esclusioni
Il CRA non si applica, tra gli altri, a determinati prodotti già disciplinati da normative UE settoriali, tra cui dispositivi medici e dispositivi medico-diagnostici in vitro, determinati prodotti automotive e prodotti aeronautici certificati secondo il quadro normativo indicato dal regolamento.
Sono inoltre previste esclusioni per determinate apparecchiature marittime, pezzi di ricambio identici e prodotti sviluppati o modificati esclusivamente per finalità di sicurezza nazionale o difesa o per trattare informazioni classificate.
Le scadenze da ricordare
| Data | Cosa succede |
| 10 dicembre 2024 | Entrata in vigore del CRA |
| 11 giugno 2026 | Si applicano le disposizioni del Capo IV relative alla notifica degli organismi di valutazione della conformità |
| 11 settembre 2026 | Diventano applicabili gli obblighi di reporting dell’art. 14 |
| 11 dicembre 2027 | Piena applicazione della maggior parte del CRA |
| 11 dicembre 2027 | Si applicano anche gli obblighi di reporting specifici degli open-source software stewards |
Una regola transitoria merita particolare attenzione: i prodotti con elementi digitali immessi sul mercato prima dell’11 dicembre 2027 sono generalmente assoggettati ai requisiti del CRA solo se, a partire da tale data, sono oggetto di una modifica sostanziale. Gli obblighi dell’art. 14, invece, si applicano anche ai prodotti già messi a disposizione sul mercato prima dell’11 dicembre 2027.
Cosa dovrebbero fare oggi le imprese?
Per un’impresa che potrebbe rientrare nel CRA, il percorso di compliance dovrebbe partire almeno da questi passaggi:
- Mappare i prodotti hardware e software commercializzati nell’UE.
- Identificare il ruolo dell’impresa: fabbricante, importatore, distributore o altro soggetto.
- Verificare scope ed esclusioni.
- Classificare i prodotti come ordinari, importanti Classe I/II o critici.
- Effettuare una gap analysis rispetto all’Allegato I.
- Formalizzare vulnerability management e coordinated vulnerability disclosure.
- Definire il support period e la relativa comunicazione agli utenti.
- Verificare documentazione tecnica, conformity assessment, CE marking e dichiarazione UE di conformità.
- Integrare il CRA nei processi di incident response.
- Per i fabbricanti, predisporre immediatamente il processo di reporting tramite la Single Reporting Platform di ENISA.
- Rivedere i contratti con sviluppatori, fornitori e produttori di componenti.
- Coordinare gli obblighi CRA con quelli derivanti da GDPR, NIS2, DORA e altre normative settoriali applicabili.
CRA e GDPR: un’intersezione importante
Per i professionisti della data protection, il CRA presenta un punto di particolare interesse: molte delle attività richieste dal regolamento possono essere coordinate con processi già esistenti in materia di sicurezza dei dati personali.
Cybersecurity risk assessment, vulnerability management, incident response, gestione dei fornitori, security by design e gestione degli aggiornamenti possono infatti interagire con gli obblighi derivanti dal GDPR, pur rimanendo obblighi giuridicamente distinti.
Il CRA non è quindi una “nuova versione del GDPR cybersecurity”: è un regime autonomo di product cybersecurity, che si aggiunge agli altri framework applicabili all’impresa.
Per molte software house, produttori IoT, aziende che sviluppano sistemi embedded e imprese che importano prodotti tecnologici da Paesi extra-UE, il 2026 rappresenta quindi il momento opportuno per avviare lo screening e non il momento per attendere l’11 dicembre 2027.
