Il 27 luglio 2026 la Commissione europea ha approvato le Linee Guida sull’applicazione del Regolamento (UE) 2024/2847, noto come Cyber Resilience Act (“CRA” o il “Regolamento”). Si tratta del primo quadro orizzontale dell’Unione europea in materia di requisiti di cybersicurezza per i prodotti con elementi digitali, siano essi hardware, software o combinazioni dei due. Le Linee Guida non hanno natura vincolante, ma offrono indicazioni operative su diversi aspetti che, nella pratica, possono incidere in modo significativo sulle modalità con cui le imprese dovranno impostare la propria conformità. I chiarimenti riguardano, tra l’altro, la delimitazione dell’ambito di applicazione del CRA, il trattamento del software libero e open source, la determinazione del periodo di supporto, la valutazione dei rischi e la gestione delle vulnerabilità. La pubblicazione assume inoltre particolare rilievo perché, dall’11 settembre 2026, trovano applicazione gli obblighi di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi che incidono sulla sicurezza dei prodotti. Per le imprese, quindi, il punto è soprattutto capire come tradurre queste regole in processi concreti: quali prodotti rientrano nel perimetro, chi assume le diverse responsabilità, quali informazioni devono essere raccolte e quali procedure devono essere già operative per poter intervenire tempestivamente in caso di vulnerabilità o incidente. Ambito di applicazione: quali prodotti rientrano nel CRA Il CRA si applica ai prodotti con elementi digitali, hardware o software, immessi sul mercato dell’UE la cui destinazione d’uso o utilizzo ragionevolmente prevedibile includa una connessione dati[1], diretta o indiretta, a un dispositivo o a una rete. Il perimetro è quindi potenzialmente molto ampio e può comprendere, ad esempio, software autonomi, app e programmi informatici, dispositivi IoT, laptop e tablet, circuiti integrati e schede madri, oltre a prodotti composti da hardware e software commercializzati separatamente ma destinati a funzionare insieme. Con riferimento al software, le Linee Guida distinguono in modo particolare tra il software che costituisce un prodotto immesso sul mercato e i servizi forniti esclusivamente da remoto. Rientra nel CRA il software che viene scaricato, installato o comunque messo a disposizione dell’utente per essere eseguito sul suo sistema informatico. È il caso, ad esempio, di un’estensione del browser o di un’app sviluppata mediante tecnologie web ma destinata all’esecuzione locale. Non è invece sufficiente che l’utente possa accedere a una funzionalità software tramite una connessione internet: quando il software viene eseguito esclusivamente da remoto, il solo accesso a tale funzionalità non determina, di per sé, la qualificazione come prodotto con elementi digitali. La distinzione è particolarmente importante per i modelli basati su cloud e SaaS. Una web app accessibile attraverso un browser può, in linea generale, rimanere fuori dal perimetro del CRA quando costituisce un servizio erogato da remoto; al contrario, il sito o il servizio può rientrare nel Regolamento quando assume i caratteri di un trattamento remoto dei dati che integra il prodotto. Anche per questo motivo, la qualificazione non può essere effettuata sulla base della sola etichetta commerciale utilizzata per descrivere il servizio, ma richiede un esame concreto delle modalità tecniche con cui il software viene fornito e utilizzato. Per l’hardware, invece, il canale di distribuzione è irrilevante. Quando il software è necessario per il funzionamento, la configurazione, il controllo o l’utilizzo dell’hardware secondo la sua destinazione d’uso, i diversi elementi possono essere considerati come un unico prodotto con elementi digitali. È il caso, ad esempio, di una stampante di rete accompagnata dai relativi driver o di un dispositivo wearable utilizzabile attraverso la relativa companion app. Software libero e open source Uno dei chiarimenti più rilevanti riguarda il rapporto tra CRA e software libero e open source (FOSS, free and open-source software). Ai fini del Regolamento, un software può essere qualificato come FOSS quando è distribuito con una licenza libera o open source che ne consente l’accesso, l’utilizzo, la modifica e la redistribuzione e quando il relativo codice sorgente è pubblicamente disponibile. La questione della responsabilità, tuttavia, non dipende dalla sola possibilità tecnica di modificare il codice, ma dal ruolo effettivamente svolto nell’organizzazione e nella gestione del progetto. In questo contesto, le Linee Guida attribuiscono rilievo alla figura dei c.d. maintainer, vale a dire i soggetti che esercitano il controllo principale sullo sviluppo, sul rilascio delle versioni e sulle decisioni relative alla distribuzione e alla governance del progetto. Il semplice contributo allo sviluppo del codice non è invece, di per sé, sufficiente a far sorgere una responsabilità ai sensi del CRA[2]. Un altro aspetto importante riguarda la natura commerciale del software. Il fatto che un progetto sia disponibile gratuitamente non è sufficiente, da solo, a escludere l’applicazione del CRA. La valutazione deve tenere conto delle modalità con cui il software viene effettivamente fornito e monetizzato. Può assumere rilievo, per esempio, il pagamento richiesto per il software o per i file binari compilati, il fatto che il prodotto costituisca uno strumento per monetizzare altri beni o servizi, oppure che l’accesso a determinate versioni, aggiornamenti o funzionalità essenziali sia subordinato a un corrispettivo. Anche il trattamento di dati personali può rilevare quando non sia necessario per esigenze di sicurezza, compatibilità o interoperabilità. Al contrario, la semplice offerta di servizi professionali a pagamento non rende automaticamente commerciale il software. Un progetto può infatti rimanere al di fuori della nozione di immissione sul mercato quando il software è liberamente disponibile e i servizi di consulenza, formazione, installazione o assistenza vengono acquistati separatamente e facoltativamente. Anche una donazione volontaria, quando non condiziona l’accesso al software o alle sue funzionalità, non determina necessariamente la natura commerciale del progetto. Allo stesso modo, il fatto che lo sviluppo sia finanziato da un’impresa, da un ente pubblico o da uno sponsor non è, di per sé, decisivo: ciò che rileva è il modo in cui il software viene successivamente messo a disposizione sul mercato. Il CRA prevede inoltre una disciplina specifica per gli open-source software steward, cioè le persone giuridiche, diverse dai fabbricanti, che forniscono in modo sistematico e continuativo un supporto allo sviluppo di FOSS destinato ad attività commerciali e ne sostengono la sostenibilità nel tempo. Si tratta di un regime specifico, pensato per tenere conto del particolare ruolo svolto da questi soggetti nell’ecosistema open source. Tra gli obblighi previsti rientrano, in particolare, l’adozione di una politica di cybersicurezza, la cooperazione con le autorità di vigilanza e, nei casi previsti dal Regolamento, la segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi che incidano sulla sicurezza dei prodotti Le Linee Guida aiutano a distinguere l’incidenza di tali obblighi in funzione del tipo di supporto fornito. Un’attività esclusivamente non tecnica, come quella relativa al branding, alla governance, all’organizzazione di eventi o alla raccolta di donazioni, non comporta automaticamente gli stessi obblighi di uno steward che mette a disposizione infrastrutture tecniche oppure contribuisce direttamente allo sviluppo del software e alla gestione delle relative correzioni di sicurezza. Valutazione di conformità e valutazione dei rischi cyber Il CRA distingue tra prodotti con elementi digitali “ordinari”, prodotti “importanti” (di classe I e II) e prodotti “critici”. Questa classificazione è rilevante soprattutto perché incide sulla procedura con cui il fabbricante deve dimostrare la conformità del prodotto prima della sua immissione sul mercato. Per individuare la categoria di appartenenza non è sufficiente guardare alla descrizione commerciale del prodotto. Occorre considerare la funzionalità principale, individuata sulla base delle caratteristiche tecniche e dell’utilizzo previsto. Le funzioni meramente accessorie non determinano, da sole, la classificazione. Un prodotto sarà quindi “importante” o “critico” quando la sua funzionalità principale rientra in una delle categorie previste dagli Allegati III e IV del CRA. La classificazione produce effetti diretti anche sulle modalità con cui il fabbricante è tenuto a comprovare la conformità del prodotto ai requisiti essenziali dell’Allegato I[3]. Accanto alla classificazione esiste un secondo elemento, strettamente collegato, che le Linee Guida considerano centrale: la valutazione dei rischi cyber (art. 13, par. 2, del CRA). La valutazione del rischio non costituisce, infatti, dovrebbe orientare l’intero percorso di conformità. Dall’analisi dei rischi dipendono la scelta delle misure di sicurezza, l’individuazione dei requisiti essenziali applicabili e, in una certa misura, anche la determinazione del periodo di supporto. In concreto, il fabbricante deve considerare il modo in cui il prodotto è progettato e destinato a essere utilizzato, gli usi ragionevolmente prevedibili, gli utenti e gli ambienti di impiego, le minacce rilevanti, il possibile impatto di un incidente, le interfacce esposte, le componenti hardware e software, le dipendenze da soggetti o servizi esterni, i servizi remoti e i rischi connessi alla catena di fornitura, tenendo conto anche delle misure tecniche e organizzative già adottate. La valutazione deve inoltre essere aggiornata durante il periodo di supporto, in modo da riflettere l’evoluzione dei rischi. Un elemento particolarmente significativo delle Linee Guida è che, quando i rischi individuati non possono essere adeguatamente gestiti con l’architettura esistente, la risposta non può limitarsi alla predisposizione di documentazione o di misure organizzative. Può rendersi necessario intervenire sul progetto del prodotto, sulla sua architettura o sulle sue funzionalità, fino a rivederne, nei casi più rilevanti, lo stesso scopo previsto. Le esigenze commerciali o di costo non sono, di per sé, sufficienti a giustificare il mantenimento di un rischio incompatibile con i requisiti essenziali del CRA. La valutazione del rischio deve inoltre essere accompagnata da un’adeguata due diligence sulle componenti integrate. Il fabbricante è chiamato a prestare attenzione, sia al momento della selezione sia nel corso del ciclo di vita del prodotto, all’affidabilità dei componenti hardware e software di terze parti, delle soluzioni di elaborazione dati a distanza e dei servizi remoti dai quali il prodotto dipende. La valutazione cambia, tuttavia, quando si considerano infrastrutture esterne che non siano state progettate dal fabbricante e che non supportino direttamente una funzione del prodotto, come una rete pubblica o un sistema di back-end di un terzo estraneo alla sua architettura. Tali elementi restano esterni al prodotto, ma non possono essere ignorati: il fabbricante deve comunque tenerne conto nella valutazione complessiva dei rischi e adottare, ove necessario, misure di mitigazione attraverso la progettazione del prodotto e le informazioni o istruzioni fornite agli utenti. Periodo di supporto e gestione delle vulnerabilità Le Linee Guida intervengono in modo significativo anche sul periodo di supporto (art. 13, par. 8, del CRA). I cinque anni previsti dal Regolamento devono essere letti come una soglia minima e non come un periodo automaticamente applicabile a tutti i prodotti. La durata del supporto deve essere coerente con il periodo durante il quale ci si può ragionevolmente attendere che il prodotto venga utilizzato, tenendo conto della sua natura e delle aspettative degli utenti. La conseguenza pratica è importante: un prodotto destinato a rimanere in uso per un periodo significativamente più lungo di cinque anni potrà richiedere un supporto più esteso. La determinazione della durata del supporto dovrebbe quindi essere collegata alla vita utile attesa del prodotto e non essere trattata come una scelta meramente standardizzata. Per i soli software, il CRA (art 13, par. 10) introduce una specifica forma di flessibilità: il fabbricante può concentrare la correzione delle vulnerabilità sull’ultima versione immessa sul mercato, purché l’utente possa effettuare gratuitamente l’aggiornamento. Le Linee Guida precisano che l’assenza di “costi aggiuntivi” non esclude le normali attività operative necessarie per installare l’aggiornamento. Non sono normalmente considerati costi aggiuntivi, ad esempio, le ordinarie attività di test, configurazione o aggiornamento delle dipendenze software. Diverso è il caso in cui l’aggiornamento richieda l’acquisto obbligatorio di nuovo hardware, la sostituzione dell’infrastruttura o una modifica sostanziale dell’ambiente operativo. Resta in ogni caso fermo che la limitazione del supporto all’ultima versione non esonera il fabbricante dagli altri obblighi di gestione delle vulnerabilità (Parte II dell’Allegato I) e di segnalazione degli incidenti (art. 14). Obblighi di segnalazione: il termine decorre dalla consapevolezza Il CRA impone al fabbricante di notificare simultaneamente ad ENISA e al CSIRT di riferimento le vulnerabilità contenute nel prodotto che risultano attivamente sfruttate e gli incidenti gravi aventi impatto sulla sicurezza del prodotto. Le Linee Guida chiariscono un aspetto particolarmente importante per l’organizzazione interna delle imprese: il termine per la segnalazione inizia a decorrere dal momento in cui il fabbricante acquisisce una sufficiente consapevolezza dell’evento. Tale consapevolezza si determina quando, sulla base di una prima valutazione, il fabbricante raggiunge un ragionevole grado di certezza circa il fatto che una vulnerabilità sia attivamente sfruttata o che si sia verificato un incidente grave. Da quel momento, il sistema interno deve essere in grado di attivare tempestivamente il flusso di segnalazione. In particolare, il CRA prevede un primo early warning entro 24 ore, seguito dalla notifica principale entro 72 ore. Per una vulnerabilità attivamente sfruttata, la relazione finale deve essere trasmessa non oltre 14 giorni dalla disponibilità di una misura correttiva o di mitigazione; per un incidente grave, la relazione finale deve essere presentata entro un mese dalla notifica delle 72 ore. La Commissione chiarisce inoltre che l’obbligo può riguardare anche vulnerabilità presenti in componenti di terze parti, quando tali vulnerabilità risultino effettivamente sfruttabili nel prodotto del fabbricante. Non è invece prevista una segnalazione retroattiva per vulnerabilità che fossero già note al fabbricante come attivamente sfruttate prima dell’11 settembre 2026. Anche la comunicazione agli utenti deve essere gestita con attenzione. L’informazione dovrebbe essere adeguata al rischio e alle caratteristiche del prodotto e, nei contesti più sensibili, la divulgazione di dettagli tecnici eccessivamente specifici potrebbe aumentare il rischio di ulteriori attacchi. La gestione della comunicazione deve quindi trovare un equilibrio tra l’esigenza di informare tempestivamente gli utenti interessati e quella di non amplificare il rischio per la sicurezza del prodotto. Le principali scadenze Il calendario di applicazione del CRA si sviluppa su più date. La prima è l’11 settembre 2026, quando diventano applicabili gli obblighi di segnalazione previsti dall’articolo 14. La disciplina generale del CRA troverà invece piena applicazione dall’11 dicembre 2027. I certificati UE di esame del tipo e le relative decisioni di approvazione rilasciati nel quadro della precedente normativa di armonizzazione e relativi ai requisiti di cybersicurezza restano validi, salvo diversa previsione, fino all’11 giugno 2028, purché non scadano prima[4] Per i prodotti progettati prima della data di applicazione del CRA ma immessi sul mercato successivamente, il fabbricante non è tenuto a una integrale riprogettazione, ma deve svolgere la valutazione dei rischi di cybersicurezza e dimostrare, sulla base di essa, che il prodotto incorpora misure di sicurezza adeguate ai rischi individuati. Restano, secondo i casi, gli ulteriori adempimenti previsti dal CRA, tra cui la valutazione della conformità, la documentazione tecnica, la dichiarazione UE di conformità, la marcatura CE, i processi di gestione delle vulnerabilità, l’aggiornamento della valutazione del rischio e le informazioni e istruzioni destinate agli utenti. Conclusioni Le Linee Guida offrono un quadro interpretativo del CRA più concreto su numerosi aspetti che, per le imprese, saranno decisivi nella fase di attuazione. In particolare, in vista delle prossime scadenze, le imprese dovrebbero partire da una ricognizione dei propri prodotti e delle relative componenti, verificando anzitutto quali rientrino nel perimetro del CRA e quale sia la loro corretta classificazione. Su questa base sarà possibile collegare la valutazione del rischio alla funzionalità principale del prodotto e definire il percorso di conformità applicabile. Un secondo passaggio riguarda la costruzione (laddove non sia stato già implementato) di un processo strutturato di gestione delle vulnerabilità. È necessario che le responsabilità siano chiaramente individuate, che esistano canali interni per raccogliere le segnalazioni e che l’organizzazione sia in grado di far decorrere correttamente i termini di 24 e 72 ore, nonché quelli previsti per le relazioni finali. La questione non riguarda soltanto il team cybersecurity: in molti casi coinvolgerà anche le funzioni legale, compliance, prodotto, qualità e comunicazione. Particolare attenzione dovrà essere dedicata anche alle dipendenze esterne, ai componenti open source e ai servizi cloud o SaaS, verificando non soltanto che tali componenti siano affidabili, ma anche che i rapporti con i relativi fornitori consentano all’impresa di ottenere tempestivamente le informazioni necessarie per gestire vulnerabilità e incidenti. Infine, sarà utile verificare il coordinamento tra il CRA e gli altri quadri normativi europei che possono incidere sulle medesime organizzazioni, tra cui la NIS2, il GDPR, l’AI Act e, per i soggetti interessati, il DORA. L’obiettivo dovrebbe essere quello di evitare la creazione di processi paralleli e costruire invece un sistema coerente di gestione del rischio cyber, capace di coprire gli obblighi che derivano dalle diverse discipline. [1] Le Linee Guida chiariscono che per “connessione dati” deve intendersi uno scambio di informazioni codificate in forma digitale: la mera presenza di componenti elettroniche o di segnali elettrici che si limitano ad attivare o alimentare una funzione, senza veicolare informazioni digitalmente codificate, non è di per sé sufficiente a determinare l’applicazione del CRA. [2] I “maintainer” sono coloro (persone fisiche o giuridiche) che pubblicano il software libero e open source ed esercitano il controllo principale sul suo sviluppo, sul rilascio delle versioni e sulle decisioni relative alla distribuzione e alla governance. I “contributor”, invece, sono coloro che contribuiscono allo sviluppo di tale software open source, senza tuttavia esercitare il controllo sul rilascio delle versioni, sulle roadmap o sulle decisioni di governance. [3] Per la generalità dei prodotti – quelli che non ricadono nelle categorie degli Allegati III e IV – è ammesso il ricorso al modulo A di controllo interno, con autovalutazione del fabbricante. Per i prodotti importanti di classe I la medesima modalità di autovalutazione è consentita soltanto ove il fabbricante applichi integralmente le norme armonizzate, le specifiche comuni o i sistemi europei di certificazione della cibersicurezza pertinenti, coprendo così tutti i rischi associati alla funzionalità principale del prodotto; in caso contrario, il fabbricante deve necessariamente rivolgersi a un organismo notificato. Per i prodotti importanti di classe II e per i prodotti critici la valutazione da parte di terzi indipendenti è invece sempre obbligatoria; per i critici, in particolare, il fabbricante è chiamato a conseguire un certificato di cibersicurezza europeo di livello “sostanziale” o superiore ai sensi del Regolamento (UE) 2019/881. Un regime di favore è infine previsto per i software liberi e open source qualificati come importanti, che restano soggetti al solo regime ordinario di autovalutazione. [4] I certificati UE di esame del tipo e le relative decisioni di approvazione cui si riferisce l’articolo 69 del CRA restano validi fino all’11 giugno 2028, salvo scadenza anteriore o diversa previsione della normativa di armonizzazione applicabile.
