Ambito di applicazione, scadenze e requisiti del Regolamento (UE) 2024/2847
La cybersecurity dei prodotti digitali sta entrando in una nuova fase.
Con il Regolamento (UE) 2024/2847, meglio conosciuto come Cyber Resilience Act – CRA, l’Unione europea introduce un insieme armonizzato di requisiti di cibersicurezza applicabili ai prodotti con elementi digitali immessi sul mercato europeo.
Il cambiamento è significativo soprattutto per chi sviluppa e commercializza software o hardware. La sicurezza informatica diventa infatti un requisito da considerare lungo l’intero ciclo di vita del prodotto: dalla progettazione allo sviluppo, dalla distribuzione alla manutenzione, fino alla gestione delle vulnerabilità emerse dopo la commercializzazione.
Il CRA è entrato in vigore il 10 dicembre 2024, ma il legislatore europeo ha previsto un’applicazione progressiva degli obblighi. Alcune disposizioni sono già applicabili nel 2026, mentre il quadro entrerà pienamente a regime dall’11 dicembre 2027.
A quali prodotti si applica il Cyber Resilience Act
Il punto di partenza è il concetto di “prodotto con elementi digitali”.
Il Regolamento comprende i prodotti software o hardware e le relative soluzioni di elaborazione dati da remoto quando il loro utilizzo previsto o ragionevolmente prevedibile comporta una connessione logica o fisica, diretta o indiretta, a un dispositivo o a una rete.
Il perimetro è quindi molto ampio.
Possono rientrare, ad esempio, applicazioni software, sistemi operativi, dispositivi connessi, componenti hardware e software, strumenti di cybersecurity, dispositivi IoT e numerose soluzioni digitali commercializzate autonomamente.
Anche alcune funzionalità erogate da remoto possono rientrare nel perimetro quando sono progettate sotto la responsabilità del fabbricante e risultano necessarie affinché il prodotto svolga una delle proprie funzioni. È il caso, ad esempio, di un’applicazione che per funzionare necessita di un’API o di un database remoto sviluppato dal medesimo produttore. Un generico servizio cloud indipendente dal prodotto, invece, non rientra automaticamente nel CRA.
Questo aspetto è particolarmente importante per le software house: anche una soluzione installata presso il cliente può rientrare nel CRA se costituisce un prodotto software immesso sul mercato e presenta le caratteristiche previste dal Regolamento.
Chi sono i soggetti obbligati
Il CRA attribuisce responsabilità differenti ai diversi operatori economici della catena.
Il ruolo centrale è quello del fabbricante, definito come il soggetto che sviluppa o fabbrica un prodotto con elementi digitali, oppure lo fa progettare o sviluppare, e lo commercializza con il proprio nome o marchio. La definizione comprende anche prodotti messi a disposizione gratuitamente quando l’attività presenta comunque natura commerciale.
Accanto al fabbricante il Regolamento disciplina anche:
- rappresentanti autorizzati;
- importatori;
- distributori;
- altri operatori che intervengono nella messa a disposizione del prodotto sul mercato.
Importatori e distributori devono, tra le altre cose, verificare che siano stati rispettati gli obblighi applicabili al prodotto e che siano presenti la documentazione, la marcatura e le dichiarazioni richieste.
La responsabilità principale sulla sicurezza del prodotto rimane comunque fortemente concentrata sul fabbricante.
Open source: non tutto il software libero rientra automaticamente nel CRA
Il Regolamento dedica particolare attenzione al software libero e open source.
Il semplice sviluppo o contributo a un progetto open source svolto al di fuori di un’attività commerciale non determina automaticamente l’applicazione degli obblighi previsti per i fabbricanti.
Il CRA considera rilevante soprattutto il software open source messo a disposizione sul mercato nell’ambito di un’attività commerciale. Per gli open-source software steward, ossia soggetti che sostengono in modo continuativo determinati progetti open source destinati ad attività commerciali, è invece previsto un regime specifico e alleggerito, che comprende anche obblighi relativi alla gestione delle vulnerabilità.
È quindi fondamentale valutare concretamente il modello di distribuzione e commercializzazione del software.
Alcune esclusioni specifiche
Il CRA nasce come disciplina orizzontale, ma non sostituisce i regolamenti settoriali che già prevedono requisiti specifici di cybersecurity.
Sono quindi previste alcune esclusioni, tra cui determinati prodotti disciplinati dalla normativa europea sui dispositivi medici e diagnostici in vitro, alcuni prodotti automobilistici, prodotti aeronautici certificati e apparecchiature marittime soggette a discipline specifiche.
Per questo motivo la prima attività di adeguamento dovrebbe sempre essere una valutazione dell’applicabilità prodotto per prodotto, evitando di dedurre l’assoggettamento al CRA esclusivamente dal fatto che l’azienda operi nel settore software.
Prodotti standard, importanti e critici
Un altro elemento centrale è la classificazione del prodotto.
La maggior parte dei prodotti con elementi digitali rientra nella categoria ordinaria, spesso definita nella pratica come categoria “standard”.
Il CRA individua poi prodotti importanti, suddivisi nelle classi I e II, e prodotti critici.
La distinzione tiene conto soprattutto della funzione svolta dal prodotto e del potenziale impatto che una compromissione potrebbe avere sulla cybersecurity di altri prodotti, sistemi, reti o servizi.
Tra i criteri considerati rientrano, ad esempio, la presenza di funzioni essenziali per autenticazione, controllo degli accessi, rilevazione delle intrusioni, protezione degli endpoint, sicurezza delle reti, gestione delle configurazioni e altre funzioni particolarmente rilevanti per la cybersecurity.
La classificazione è importante perché incide anche sulle modalità attraverso cui deve essere dimostrata la conformità.
Per molti prodotti sarà possibile utilizzare procedure basate sul controllo interno. Per categorie maggiormente critiche possono invece essere necessarie procedure di valutazione della conformità più rigorose e, in determinati casi, il coinvolgimento di un organismo notificato.
La cybersecurity entra nel ciclo di vita del prodotto
Uno degli elementi più importanti del CRA è il passaggio da una sicurezza prevalentemente reattiva a una sicurezza integrata nel ciclo di sviluppo.
L’articolo 13 richiede al fabbricante di effettuare una valutazione dei rischi di cibersicurezza del prodotto e di utilizzarne i risultati durante le fasi di pianificazione, progettazione, sviluppo, produzione, consegna e manutenzione.
La valutazione deve essere documentata e aggiornata quando necessario.
L’Allegato I traduce questo principio in requisiti concreti.
I prodotti devono essere progettati, sviluppati e prodotti in modo da garantire un livello di cybersecurity adeguato ai rischi e, dove applicabile, devono essere immessi sul mercato senza vulnerabilità sfruttabili note, adottare configurazioni sicure per impostazione predefinita e proteggere adeguatamente disponibilità, autenticità, integrità e riservatezza dei dati e delle funzioni.
La logica di secure-by-design e secure-by-default diventa quindi parte strutturale della compliance di prodotto.
Gestione delle vulnerabilità e supporto nel tempo
Il CRA prosegue anche dopo la vendita del prodotto.
Il fabbricante deve predisporre processi per identificare, documentare, analizzare e correggere le vulnerabilità.
Assume quindi rilievo la capacità di mantenere un inventario delle componenti del prodotto, gestire patch e aggiornamenti di sicurezza, raccogliere le segnalazioni relative alle vulnerabilità e comunicare agli utenti le misure necessarie.
Il Regolamento richiede inoltre la definizione di un periodo di supporto, durante il quale il fabbricante deve garantire l’efficace gestione delle vulnerabilità. In via generale tale periodo non dovrebbe essere inferiore a cinque anni, salvo che la vita attesa del prodotto sia più breve; per prodotti destinati a essere utilizzati più a lungo il supporto deve essere coerente con la durata prevista.
Questo elemento incide direttamente anche sulle strategie di manutenzione e sul ciclo di vita commerciale dei prodotti software.
Le prime scadenze sono già molto vicine
Il calendario applicativo del CRA è progressivo.
Le principali date da ricordare sono:
- 11 giugno 2026 – sono entrate in applicazione le disposizioni relative alla notifica degli organismi di valutazione della conformità.
- 11 settembre 2026 – diventano applicabili gli obblighi dell’articolo 14 relativi alla segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi che impattano sulla sicurezza dei prodotti.
- 11 dicembre 2027 – entrano in piena applicazione gli obblighi principali del Cyber Resilience Act.
Il 2026 rappresenta quindi già un anno operativo per il CRA.
Vulnerabilità e incidenti: le nuove tempistiche di notifica
Dal 11 settembre 2026 assume particolare importanza l’articolo 14.
In caso di vulnerabilità attivamente sfruttata di cui il fabbricante venga a conoscenza, il CRA prevede un primo preallarme entro 24 ore e una notifica più completa entro 72 ore. La relazione finale relativa alla vulnerabilità deve essere presentata, salvo che le informazioni siano già state fornite, entro 14 giorni dalla disponibilità della misura correttiva o di mitigazione.
Per gli incidenti gravi che impattano sulla sicurezza del prodotto sono analogamente previsti un preallarme entro 24 ore, una successiva notifica entro 72 ore e una relazione finale entro un mese.
Le segnalazioni vengono indirizzate attraverso la piattaforma unica prevista dal Regolamento, gestita da ENISA.
La gestione delle vulnerabilità assume quindi anche una dimensione organizzativa: servono ruoli, responsabilità, escalation e procedure in grado di rispettare tempi molto brevi.
CRA e NIS2: due prospettive sulla stessa cybersecurity
Il CRA si inserisce in un ecosistema normativo europeo già articolato.
Il collegamento più evidente è quello con la Direttiva NIS2.
La NIS2 guarda principalmente alla sicurezza delle organizzazioni e dei loro sistemi informativi e di rete. Il CRA concentra invece l’attenzione sulla sicurezza dei prodotti con elementi digitali messi sul mercato.
Un produttore software può quindi trovarsi contemporaneamente a dover governare la cybersecurity della propria organizzazione secondo NIS2 e quella dei propri prodotti secondo CRA.
Esistono però numerosi elementi comuni: risk management, gestione delle vulnerabilità, incident response, sicurezza della supply chain, continuità, controllo degli accessi e monitoraggio.
Lo stesso legislatore europeo evidenzia che il CRA contribuisce anche al rispetto degli obblighi di sicurezza della supply chain previsti da NIS2 e DORA per le organizzazioni che utilizzano prodotti digitali.
CRA e AI Act: quando un prodotto digitale contiene intelligenza artificiale
Il collegamento con l’AI Act è ancora più diretto.
L’articolo 12 del CRA disciplina espressamente, infatti, i prodotti con elementi digitali che costituiscono anche sistemi AI ad alto rischio.
Quando vengono soddisfatti i requisiti essenziali di cybersecurity previsti dal CRA e le relative condizioni, tali prodotti possono essere considerati conformi anche ai requisiti di cybersecurity dell’articolo 15 dell’AI Act.
Un singolo prodotto può quindi trovarsi contemporaneamente nel perimetro di più regolamenti europei.
È uno degli esempi più evidenti dell’evoluzione verso una governance multi-framework.
CRA e ISO/IEC 27001: molte logiche sono già familiari
Anche la ISO/IEC 27001 offre numerosi elementi utili a chi deve prepararsi al CRA.
Risk assessment, asset management, gestione delle vulnerabilità, supplier security, incident management, controllo degli accessi e miglioramento continuo rappresentano concetti già consolidati nei sistemi di gestione per la sicurezza delle informazioni.
La certificazione ISO 27001, tuttavia, non equivale automaticamente alla conformità al CRA.
Il Regolamento prevede che la presunzione di conformità derivi dalle norme armonizzate o dagli altri strumenti espressamente riconosciuti nell’ambito del CRA per i requisiti da esse coperti. La Commissione sta lavorando proprio allo sviluppo del relativo quadro di standardizzazione.
Per un’organizzazione già certificata ISO 27001 esiste comunque una base metodologica importante da valorizzare e riutilizzare.
Dal prodotto alla governance
Il Cyber Resilience Act porta quindi la cybersecurity all’interno della governance del prodotto.
Per prepararsi al 2027 occorre partire molto prima.
Le organizzazioni dovrebbero censire i prodotti commercializzati, valutarne l’applicabilità, determinarne la classificazione, documentare il rischio di cybersecurity, verificare i processi di secure development, organizzare la vulnerability management, definire il support period e raccogliere le evidenze necessarie alla futura valutazione di conformità.
La compliance al CRA coinvolgerà quindi contemporaneamente sviluppo software, IT, cybersecurity, compliance, qualità, procurement e management.
La vera sfida sarà riuscire a mantenere tutte queste informazioni collegate e aggiornate durante l’intero ciclo di vita del prodotto.
👉 Nel prossimo approfondimento vedremo come le funzionalità già disponibili in C*RA possano supportare una parte importante di questo percorso e come stiamo sviluppando un modulo specificamente dedicato al Cyber Resilience Act.
Partecipa al nostro prossimo webinar dedicato al CRA – https://meet.zoho.eu/nmgu-ilm-ygm