Cyber resilience act, tutto ciò che bisogna sapere per essere preparati

Il Cyber Resilience Act entra nella fase più importante.

Il 27 luglio 2026 la Commissione europea ha reso disponibile un ampio documento di orientamento sull’applicazione del Regolamento (UE) 2024/2847 (Il Cyber Resilience Act), con l’obiettivo di aiutare produttori, sviluppatori, importatori, distributori e imprese di ogni dimensione a comprendere concretamente come applicare i nuovi requisiti europei di cybersicurezza dei prodotti.

Le linee guida UE sul Cyber resilience act

Il documento affronta molte delle questioni che, dopo l’entrata in vigore del regolamento, avevano generato dubbi interpretativi: il perimetro dei prodotti interessati, il trattamento del software open source, le soluzioni di elaborazione remota, le modifiche sostanziali, i periodi di supporto, la gestione delle dipendenze, la valutazione del rischio e gli obblighi di segnalazione; quindi la Commissione ha costruito gli orientamenti attraverso il confronto con il gruppo di esperti sulla cybersicurezza dei prodotti con elementi digitali e mediante una consultazione pubblica svoltasi tra il 3 marzo e il 13 aprile 2026. Il risultato è un documento di oltre ottanta pagine, accompagnato da numerosi casi applicativi, nel quale sono presentati 67 esempi pratici.

È però opportuno evidenziare una precisazione formale: la comunicazione del 27 luglio approva il contenuto della bozza di linee guida, mentre l’adozione definitiva da parte della Commissione avverrà quando saranno disponibili tutte le versioni nelle lingue ufficiali dell’Unione; solo da quel momento il testo formalmente adottato troverà applicazione come orientamento della Commissione.

Le linee guida sul Cyber Resilience Act, anche dopo l’adozione, non avranno natura giuridicamente vincolante, considerando che l’interpretazione autoritativa del regolamento resta infatti di competenza della Corte di giustizia dell’Unione europea. Esse rappresentano, tuttavia, la posizione interpretativa della Commissione e costituiranno inevitabilmente un importante riferimento per produttori, organismi notificati, autorità di vigilanza e consulenti.

Le scadenze del Cyber Resilience Act: il primo appuntamento è già a settembre 2026

Il Cyber Resilience Act è entrato in vigore il 10 dicembre 2024, ma la sua applicazione avviene secondo un calendario progressive: Il Capitolo IV del regolamento, relativo agli organismi notificati e alla valutazione della conformità, si applica dall’11 giugno 2026; gli obblighi di segnalazione previsti dall’articolo 14 si applicheranno invece dall’11 settembre 2026 ed infine l’intero regolamento diventerà pienamente applicabile dall’11 dicembre 2027.

Questo significa che la prima vera scadenza operativa non è nel 2027, ma è ormai imminente. Le imprese che producono o commercializzano prodotti con elementi digitali devono essere in grado, già da settembre 2026, di individuare, valutare e segnalare vulnerabilità attivamente sfruttate e incidenti gravi; non è quindi sufficiente pianificare un generico progetto CRA da completare entro la fine del 2027 poichè una parte significativa del modello organizzativo deve essere già operativa.

Il CRA introduce una nuova idea di sicurezza del prodotto

Il principio alla base del regolamento è semplice: un prodotto digitale non può più essere considerato conforme, affidabile o di qualità se la cybersicurezza non viene gestita durante tutto il suo ciclo di vita; difatti il CRA si applica ai prodotti con elementi digitali messi a disposizione sul mercato dell’Unione europea quando il loro uso previsto, o ragionevolmente prevedibile, comporta una connessione logica o fisica, diretta o indiretta, a un dispositivo o a una rete.

Il perimetro può comprendere:

• software autonomi, applicazioni e programmi;
• dispositivi IoT;
• router, firewall e apparati di rete;
• laptop, tablet e dispositivi indossabili;
• componenti hardware come microcontrollori, circuiti integrati e schede madri;
• sistemi industriali e di automazione;
• combinazioni di hardware e software distribuiti anche attraverso canali differenti;
• soluzioni di elaborazione remota necessarie al funzionamento del prodotto.

La sicurezza non deve quindi essere considerata soltanto nella fase di progettazione o nel momento della vendita; il produttore deve gestire i rischi, le vulnerabilità e gli aggiornamenti durante il periodo di supporto dichiarato.

Quando un software viene “immesso sul mercato” per il Cyber Resilience Act

Uno dei chiarimenti più interessanti riguarda il momento nel quale un software autonomo viene considerato immesso sul mercato europeo. Se per un prodotto fisico è relativamente semplice identificare il momento della prima messa a disposizione, per il software, che può essere scaricato da un numero indefinito di utenti e aggiornato continuamente, il concetto è meno intuitivo. Secondo le linee guida, un software autonomo viene immesso sul mercato quando la sua fase di produzione è completata e quella versione viene offerta per la prima volta per la distribuzione o l’utilizzo nell’Unione europea nell’ambito di un’attività commerciale. Le copie della stessa versione vengono considerate immesse sul mercato nello stesso momento, anche se gli utenti le scaricano o acquistano in date differenti; comprendiamo quindi che la situazione cambia quando vengono distribuite varianti con componenti, configurazioni o funzionalità differenti. Una versione per Windows e una per Linux, oppure un’edizione base e una enterprise con funzionalità diverse, possono dover essere considerate prodotti distinti; e le successive versioni del software costituiscono una nuova immissione sul mercato soltanto quando introducono una modifica sostanziale. Gli aggiornamenti minori che non incidono sulla conformità non modificano invece la data originaria di immissione sul mercato.

Questa interpretazione rende indispensabile una gestione rigorosa delle versioni. Le imprese dovranno poter dimostrare:

• quando ogni versione è stata resa disponibile;
• quali modifiche sono state introdotte;
• se la modifica è stata valutata come sostanziale;
• quale valutazione del rischio supporta tale decisione;
• quale periodo di supporto si applica alla versione.

Linee guida sul Cyber Resilience Act: applicazioni installate, web application e siti web

La Commissione chiarisce anche il confine tra software come prodotto e software erogato esclusivamente come servizio remoto. Un’applicazione scaricata da un app store e installata su uno smartphone è normalmente un prodotto con elementi digitali e lo stesso vale per un’applicazione desktop, anche se sviluppata con tecnologie web, quando viene installata ed eseguita sul sistema dell’utente. Una web application utilizzata esclusivamente tramite browser, invece, non è automaticamente considerata un prodotto con elementi digitali ed anche un sito web puramente informativo rimane generalmente fuori dal perimetro. Una componente web o cloud può però rientrare nel CRA quando risulta necessaria per permettere a un prodotto con elementi digitali di svolgere una delle proprie funzioni. In questo caso può essere considerata una soluzione di trattamento remoto dei dati, o remote data processing solution. Comprendiamo quindi che la distinzione non dipende semplicemente dal fatto che esista un servizio cloud, ma dal ruolo che quel servizio svolge rispetto alle funzioni del prodotto.

Hardware e software possono costituire un unico prodotto

Un altro elemento rilevante riguarda i prodotti nei quali hardware e software vengono distribuiti separatamente. Il fatto che un’applicazione venga scaricata da un app store o che un driver venga recuperato dal sito del produttore non significa necessariamente che si tratti di un prodotto distinto. Se il software è necessario per installare, utilizzare, configurare, controllare o far funzionare l’hardware secondo il suo scopo previsto, hardware e software costituiscono nel loro insieme un unico prodotto con elementi digitali. Una stampante di rete e i relativi driver possono quindi essere considerati un solo prodotto. Lo stesso vale per uno smartwatch e l’applicazione necessaria a visualizzare i dati, configurare il dispositivo e utilizzare le sue funzionalità principali. Questa impostazione incide sulla valutazione del rischio, sulla documentazione tecnica e sulla gestione delle vulnerabilità: il produttore non può limitarsi a valutare separatamente il dispositivo fisico ignorando l’applicazione che ne consente l’utilizzo.

Non ogni segnale elettrico è una connessione dati

Le linee guida forniscono anche un chiarimento particolarmente tecnico sulla nozione di connessione dati. Il perimetro del CRA non è determinato dalla semplice presenza di componenti elettronici. È necessario che il prodotto sia in grado di trasmettere o ricevere informazioni digitalmente codificate. Un semplice segnale elettrico che accende o spegne una funzione non rappresenta necessariamente una connessione dati. Perché vi sia una connessione rilevante ai fini del CRA, gli stati binari devono essere intenzionalmente codificati come informazione e devono poter essere interpretati come dati dal destinatario. Il CRA riguarda quindi i prodotti che partecipano a una comunicazione digitale, non ogni apparecchiatura che utilizza elettricità o segnali elettronici.

Sistemi complessi e tecnologie legacy

I sistemi industriali, le infrastrutture complesse e i prodotti con cicli di progettazione molto lunghi rappresentano uno dei punti più delicati.

Un sistema può essere stato progettato prima dell’entrata in applicazione del CRA, può integrare componenti già esistenti o può dover comunicare con infrastrutture che utilizzano protocolli non più considerati allo stato dell’arte.

Le linee guida chiariscono che queste condizioni non escludono il sistema dal CRA. Devono però essere valutate secondo un approccio basato sul rischio.

Quando un requisito non può essere pienamente applicato senza compromettere la sicurezza funzionale, l’interoperabilità obbligatoria o il corretto funzionamento del prodotto, il produttore deve:

1. identificare e documentare il vincolo;
2. valutare il rischio derivante;
3. adottare misure alternative o compensative;
4. descrivere il rischio residuo nella documentazione tecnica;
5. fornire agli utenti indicazioni chiare sulle limitazioni;
6. rivalutare periodicamente il vincolo durante il periodo di supporto.

Un protocollo meno sicuro può, ad esempio, essere mantenuto quando è indispensabile per l’interoperabilità con sistemi esistenti. Se il prodotto può supportare sia il protocollo moderno sia quello legacy, il protocollo sicuro dovrebbe essere attivo per impostazione predefinita, mentre quello meno sicuro dovrebbe essere abilitato soltanto quando necessario ed è un approccio coerente con il principio di secure by default, senza ignorare i limiti reali degli ambienti industriali e operativi.

I prodotti progettati prima del CRA non devono essere necessariamente riprogettati

Le linee guida affrontano anche il caso di prodotti progettati prima dell’11 dicembre 2027 ma immessi sul mercato dopo tale data. Il CRA non impone automaticamente la completa riprogettazione del prodotto. Il produttore deve effettuare una valutazione del rischio aggiornata e dimostrare che le misure già presenti garantiscono un livello di cybersicurezza adeguato rispetto allo scopo previsto e all’uso ragionevolmente prevedibile: Se il prodotto incorpora già controlli efficaci, questi possono essere utilizzati come evidenza di conformità; non è necessario aggiungere nuove funzionalità di sicurezza quando la valutazione dimostra che i rischi rilevanti sono già adeguatamente trattati.

Rimangono però obbligatorie:

• la valutazione della conformità;
• la documentazione tecnica;
• la dichiarazione UE di conformità;
• la marcatura CE;
• i processi di gestione delle vulnerabilità;
• l’aggiornamento periodico della valutazione del rischio;
• le informazioni e le istruzioni da fornire agli utenti.

La Commissione chiarisce inoltre che non è necessariamente richiesto ricostruire retroattivamente tutta la documentazione storica di progettazione o tutti i test originari, quando ciò non contribuirebbe concretamente alla sicurezza del prodotto; il produttore dovrà però fornire evidenze attuali e verificabili della conformità.

Software libero e open source: non basta guardare la licenza

Una parte consistente delle linee guida è dedicata al free and open-source software, o FOSS.

Per essere considerato FOSS ai fini del CRA, il software deve soddisfare congiuntamente due condizioni:

• essere distribuito con una licenza libera e open source che consenta accesso, utilizzo, modifica e redistribuzione;
• avere il codice sorgente pubblicamente disponibile.

Un software distribuito con una licenza formalmente open source, ma il cui codice è accessibile soltanto a clienti paganti o a un gruppo ristretto, non soddisfa la definizione CRA.

Le linee guida distinguono inoltre tra maintainer e semplici contributori.

La responsabilità principale ricade su chi pubblica il software e controlla le decisioni relative allo sviluppo, alle versioni, alla distribuzione e alla governance del progetto. Chi invia una pull request o contribuisce con una porzione di codice, senza controllare le release o la roadmap, non diventa per questo soggetto responsabile ai sensi del CRA; anche il semplice accesso tecnico al repository o la possibilità di effettuare commit non sono sufficienti per attribuire la responsabilità.

Quando l’open source diventa attività commerciale

L’assenza di un prezzo non significa automaticamente che un software sia fuori dal mercato.

Un FOSS può essere considerato immesso sul mercato nell’ambito di un’attività commerciale quando:

• viene richiesto un prezzo per il software o per i binari compilati;
• consente di monetizzare altri prodotti o servizi;
• l’utilizzo è subordinato a trattamenti di dati personali non necessari per sicurezza, compatibilità o interoperabilità;
• l’accesso a versioni, aggiornamenti o funzionalità essenziali è collegato a un pagamento;
• una donazione costituisce di fatto il prezzo necessario per ottenere il prodotto.

Il semplice fatto di offrire servizi professionali a pagamento non rende però automaticamente commerciale il software.

Un progetto può rimanere fuori dal concetto di immissione sul mercato quando il software è liberamente scaricabile e i servizi di consulenza, formazione, installazione o assistenza vengono acquistati separatamente e in modo facoltativo; anche le donazioni volontarie, quando non condizionano l’accesso al software, agli aggiornamenti o alle funzionalità, non rappresentano normalmente un’attività commerciale. Il finanziamento dello sviluppo da parte di un’impresa, di un ente pubblico o di uno sponsor non determina di per sé la natura commerciale del progetto. Ciò che conta è il modo in cui il software viene successivamente fornito e monetizzato.

La nuova figura dell’open-source software steward

Il CRA introduce la figura dell’open-source software steward.

Si tratta di una persona giuridica, diversa dal produttore, che sostiene in modo sistematico e continuativo lo sviluppo di software libero destinato ad attività commerciali e ne assicura la sostenibilità.

Può trattarsi, ad esempio, di una fondazione o di un’organizzazione che:

• ospita e gestisce le piattaforme di collaborazione;
• governa il progetto;
• coordina gli sviluppatori;
• gestisce repository e infrastrutture;
• organizza le release;
• riceve e gestisce segnalazioni di vulnerabilità;
• contribuisce con risorse tecniche e ingegneristiche.

Gli obblighi concretamente applicabili dipendono dal tipo di supporto fornito.

Un’organizzazione che svolge soltanto attività amministrative o di governance non avrà necessariamente gli stessi obblighi di un soggetto che gestisce direttamente il codice, le infrastrutture di sviluppo e le patch di sicurezza.

La stessa persona giuridica può essere produttore per una versione commerciale e steward per una versione community dello stesso progetto.

Che cosa è una modifica sostanziale

La nozione di modifica sostanziale è fondamentale perché una versione sostanzialmente modificata, quando viene resa disponibile, viene trattata come un nuovo prodotto immesso sul mercato.

Non ogni aggiornamento è però sostanziale.

Una modifica tende a essere sostanziale quando:

• altera lo scopo previsto del prodotto;
• introduce funzionalità non considerate nella valutazione originaria;
• modifica significativamente il profilo di rischio;
• introduce nuove superfici di attacco;
• aggiunge interfacce raggiungibili dall’esterno;
• modifica materialmente i flussi di dati;
• introduce nuove dipendenze o servizi esterni;
• incide sulla conformità ai requisiti essenziali.

Un aggiornamento di sicurezza che corregge una vulnerabilità, rafforza configurazioni esistenti o applica misure già previste nella valutazione del rischio non è normalmente una modifica sostanziale. Rendere obbligatoria l’autenticazione multifattore già prevista, disabilitare porte inutilizzate, rafforzare le regole del firewall o sostituire un algoritmo crittografico obsoleto con uno più sicuro già supportato non dovrebbe, in linea generale, comportare una nuova immissione sul mercato. La conclusione cambia quando l’aggiornamento, pur motivato dalla sicurezza, trasforma l’architettura del prodotto. Un software progettato per cifrare localmente i file che, dopo un aggiornamento, trasferisce tutti i dati verso un servizio cloud del produttore cambia radicalmente scopo, flussi informativi e superficie di rischio. La modifica può quindi essere considerata sostanziale. Lo stesso può accadere quando un sistema crittografico interno viene sostituito con un servizio esterno di gestione delle chiavi non considerato nella valutazione iniziale. La decisione deve essere documentata. Non dovrebbe dipendere soltanto dalla numerazione commerciale della versione: un passaggio da 1.0 a 2.0 non è automaticamente sostanziale, mentre una modifica apparentemente minore potrebbe esserlo se incide profondamente sul rischio.

Riparazioni e componenti di ricambio

Le attività di manutenzione, riparazione e ricondizionamento non costituiscono normalmente modifiche sostanziali quando riportano il prodotto alle condizioni originariamente previste senza alterarne lo scopo o il profilo di rischio. Anche l’impiego di una parte di ricambio non determina automaticamente una nuova immissione sul mercato. La valutazione cambia quando il componente sostitutivo introduce capacità, connessioni, dipendenze o rischi significativamente differenti rispetto a quelli originariamente valutati. Per i sistemi complessi, questo chiarimento è particolarmente rilevante: non ogni sostituzione tecnologica determina l’obbligo di rivalutare completamente l’intero sistema, ma deve essere analizzato l’effetto concreto della modifica sulla cybersicurezza complessiva.

Il periodo di supporto: cinque anni non sono il valore predefinito

Il CRA stabilisce che il periodo di supporto debba essere normalmente di almeno cinque anni, salvo che il prodotto abbia una vita attesa inferiore. Questo non significa che tutti i prodotti possano essere supportati per soli cinque anni. Quando è ragionevole attendersi che il prodotto venga utilizzato più a lungo, il periodo di supporto dovrebbe essere proporzionalmente maggiore. Cinque anni rappresentano una soglia minima di garanzia, non un valore standard applicabile indiscriminatamente.

Il produttore deve considerare:

• la vita attesa del prodotto;
• la natura e lo scopo del prodotto;
• le ragionevoli aspettative degli utenti;
• l’ambiente operativo;
• i periodi di supporto di prodotti analoghi;
• la disponibilità dei sistemi operativi necessari;
• la durata del supporto dei componenti integrati;
• la rilevanza e la criticità delle funzioni svolte.

Al momento dell’acquisto deve essere indicata in modo chiaro e comprensibile la data di fine supporto, almeno specificando mese e anno. Quando tecnicamente possibile, l’utente deve inoltre ricevere una notifica alla scadenza del supporto.

Le versioni software e la gestione degli aggiornamenti

Ogni versione sostanzialmente modificata e immessa sul mercato deve avere un periodo di supporto conforme ai criteri del CRA.

Una modifica sostanziale non determina però automaticamente il riavvio del periodo di supporto. È necessario verificare se la modifica abbia cambiato i fattori che determinano la vita attesa del prodotto. Per il software, il produttore può in alcune circostanze concentrare la correzione delle vulnerabilità sull’ultima versione disponibile, purché gli utilizzatori delle versioni precedenti possano aggiornare gratuitamente e senza costi aggiuntivi rilevanti. Non sono necessariamente considerati costi aggiuntivi le normali attività operative di test o configurazione. Lo sarebbero invece, ad esempio, l’acquisto di nuovo hardware o una trasformazione fondamentale dell’infrastruttura dell’utente. Anche quando il produttore interrompe la correzione delle versioni precedenti, restano applicabili gli altri obblighi di gestione delle vulnerabilità, come la coordinated vulnerability disclosure e la condivisione delle informazioni di sicurezza.

Prodotti importanti e critici

Il CRA distingue tra prodotti appartenenti alla categoria ordinaria, prodotti importanti di classe I o II e prodotti critici.

La classificazione dipende dalla funzionalità principale del prodotto, non dalla semplice presenza di una funzione accessoria. La funzionalità principale è costituita dalle caratteristiche tecniche senza le quali il prodotto non potrebbe raggiungere il proprio scopo previsto. Per determinarla devono essere considerate anche la documentazione tecnica, le istruzioni, il materiale commerciale e le dichiarazioni del produttore. La classificazione incide soprattutto sulla procedura di valutazione della conformità. I prodotti della categoria ordinaria possono normalmente utilizzare il controllo interno basato sul modulo A, cioè una forma di autovalutazione del produttore. I prodotti importanti di classe I, quelli di classe II e i prodotti critici sono invece soggetti a procedure più rigorose, che possono richiedere l’intervento di organismi terzi. Per alcuni prodotti importanti distribuiti come software libero e open source, il regolamento consente tuttavia di applicare le procedure previste per la categoria ordinaria.

La valutazione del rischio è il cuore del CRA

La valutazione del rischio cyber non è un documento preparato una volta sola per accompagnare la marcatura CE. Deve guidare la progettazione, lo sviluppo, la produzione, la configurazione predefinita, la documentazione, la gestione delle vulnerabilità e le decisioni sul supporto.

Il produttore deve valutare il rischio considerando:

• scopo previsto;
• uso ragionevolmente prevedibile;
• utenti e ambienti di utilizzo;
• minacce applicabili;
• impatto potenziale;
• esposizione delle interfacce;
• componenti software e hardware;
• dipendenze esterne;
• servizi remoti;
• rischi della supply chain;
• misure tecniche e organizzative adottate.

La valutazione deve essere mantenuta aggiornata per tutto il periodo di supporto.

Quando emergono rischi che non possono essere adeguatamente gestiti con il progetto esistente, potrebbe essere necessario modificare la funzionalità, l’architettura o persino lo scopo previsto del prodotto. Le sole considerazioni economiche o commerciali non sono sufficienti per lasciare un rischio senza trattamento quando ciò impedirebbe il rispetto dei requisiti essenziali.

Dipendenze e componenti di terze parti

Il CRA prevede due obblighi distinti ma complementari.

• Il primo è la valutazione del rischio del prodotto nel suo complesso.
• Il secondo è la due diligence sui componenti integrati.

Il produttore deve quindi comprendere quali librerie, moduli, microcontrollori, sistemi operativi, servizi cloud e componenti open source siano integrati nel prodotto e quale impatto possano avere sulla sicurezza. Questo non significa che ogni fornitore debba garantire autonomamente la conformità del prodotto finale. È il produttore del prodotto con elementi digitali che deve valutare l’effetto della dipendenza sul proprio prodotto e adottare le misure necessarie.

Diventano quindi essenziali:

• inventario delle dipendenze;
• Software Bill of Materials;
• processi di selezione e valutazione dei fornitori;
• monitoraggio delle vulnerabilità;
• gestione delle versioni;
• clausole contrattuali di sicurezza;
• canali per la condivisione delle vulnerabilità;
• verifica della durata del supporto dei componenti.

Le valutazioni e le evidenze possono essere riutilizzate per famiglie di prodotti quando questi condividono architettura, componenti e profilo di rischio, purché l’impresa documenti adeguatamente le caratteristiche comuni e le differenze.

Quando un servizio cloud fa parte del prodotto

Una soluzione di elaborazione remota rientra nel prodotto quando sono soddisfatte due condizioni principali:

1. senza tale elaborazione il prodotto non potrebbe svolgere una delle sue funzioni;
2. il software remoto è progettato e sviluppato dal produttore o sotto la sua responsabilità.

Non è determinante chi gestisce fisicamente l’infrastruttura.

Un produttore può progettare un’applicazione e farla eseguire su un’infrastruttura cloud di terzi. Se il software è stato sviluppato dal produttore e risulta necessario al funzionamento del prodotto, può essere una remote data processing solution soggetta al CRA.

Nel caso di un servizio IaaS, il software installato e gestito dal produttore sull’infrastruttura cloud può rientrare nella soluzione remota. Nel caso di un PaaS, l’applicazione sviluppata dal produttore può ugualmente rientrare nel perimetro. Un’applicazione SaaS standard, interamente sviluppata dal fornitore cloud e semplicemente configurata dal produttore, generalmente non viene considerata progettata sotto la responsabilità di quest’ultimo. Può però costituire una dipendenza esterna che deve essere valutata secondo logiche analoghe a quelle applicabili ai componenti di terze parti. Un robot industriale che invia le immagini delle telecamere a un software cloud sviluppato dal produttore e riceve da questo le coordinate necessarie per prelevare i componenti rappresenta un esempio di soluzione remota inclusa nel prodotto. Una rete cellulare 5G utilizzata da uno smartphone per comunicare, invece, non è una soluzione di elaborazione remota del produttore. È un canale di comunicazione e non svolge direttamente una funzione di elaborazione necessaria al prodotto.

Gli obblighi di segnalazione dall’11 settembre 2026

Dall’11 settembre 2026 il produttore dovrà segnalare simultaneamente al CSIRT coordinatore competente e a ENISA:

• le vulnerabilità contenute nel prodotto che risultano attivamente sfruttate;
• gli incidenti gravi che compromettono la sicurezza del prodotto.

Gli obblighi si applicano a tutti i prodotti che rientrano nel CRA, compresi quelli immessi sul mercato prima dell’11 dicembre 2027.

Un elemento particolarmente significativo è che gli obblighi di segnalazione continuano anche dopo la fine del periodo di supporto. Terminato il supporto, possono cessare gli obblighi ordinari di gestione e correzione delle vulnerabilità, ma non l’obbligo di segnalare gli eventi previsti dall’articolo 14.

Quando inizia il conteggio delle 24 ore

I termini non iniziano necessariamente nel momento in cui compare il primo segnale tecnico.

Il produttore viene considerato consapevole dell’evento quando, dopo una prima e tempestiva valutazione, raggiunge un ragionevole grado di certezza che:

• una vulnerabilità del prodotto è attivamente sfruttata;
• oppure si è verificato un incidente grave che ha compromesso la sicurezza del prodotto.

La presenza di un evento sospetto, di una segnalazione di un ricercatore, di un articolo di stampa o di un’anomalia tecnica deve però attivare immediatamente l’analisi. La possibilità di svolgere una verifica preliminare non deve diventare un modo per ritardare artificiosamente il momento della conoscenza.

Una volta acquisita la ragionevole certezza, il produttore deve effettuare:

• una segnalazione iniziale entro 24 ore;
• una notifica più completa entro 72 ore;
• per una vulnerabilità attivamente sfruttata, una relazione finale entro quattordici giorni dalla disponibilità della misura correttiva o di mitigazione;
• per un incidente grave, una relazione finale entro un mese dalla notifica delle 72 ore.

La logica è progressiva: non si pretende che tutte le informazioni siano disponibili entro le prime 24 ore, ma si richiede che l’organizzazione comunichi tempestivamente ciò che sa e aggiorni la segnalazione durante l’indagine.

Nessuna segnalazione retroattiva, ma attenzione agli eventi successivi

Le linee guida chiariscono che non è richiesto segnalare retroattivamente una vulnerabilità quando il produttore era già a conoscenza del suo sfruttamento attivo prima dell’11 settembre 2026. La situazione è diversa quando il produttore conosceva la vulnerabilità, ma viene a conoscenza soltanto dopo tale data del fatto che essa è attivamente sfruttata.

In questo caso nasce l’obbligo di segnalazione.

La distinzione rende necessario conservare evidenze precise sul momento in cui l’organizzazione:

• ha ricevuto l’informazione;
• ha avviato l’analisi;
• ha verificato l’applicabilità al prodotto;
• ha acquisito un ragionevole grado di certezza;
• ha classificato l’evento;
• ha effettuato la segnalazione.

Vulnerabilità nei componenti di terze parti

Quando una vulnerabilità riguarda una libreria o un componente di terze parti, il produttore deve stabilire se essa sia effettivamente presente e sfruttabile nel proprio prodotto.

Se il codice vulnerabile non è raggiungibile o la vulnerabilità non è sfruttabile nella specifica implementazione, non si configura necessariamente una vulnerabilità attivamente sfruttata contenuta nel prodotto. Rimangono però gli obblighi di valutazione, gestione e comunicazione verso il produttore o il manutentore del componente. Il CRA introduce infatti un obbligo di reporting upstream: il produttore che individua una vulnerabilità in un componente integrato deve informare chi lo produce o lo mantiene, utilizzando preferibilmente i canali di coordinated vulnerability disclosure previsti. Non è necessario ripetere la segnalazione quando è possibile confermare che il manutentore è già consapevole della vulnerabilità.

Informazione agli utenti e divulgazione responsabile

Dopo aver individuato una vulnerabilità attivamente sfruttata o un incidente grave, il produttore deve informare gli utenti interessati e, quando appropriato, tutti gli utilizzatori.

L’informazione deve essere proporzionata al rischio.

Il CRA non impone di rendere immediatamente pubblici tutti i dettagli tecnici. Per prodotti utilizzati in infrastrutture critiche o ambienti sensibili, una diffusione indiscriminata potrebbe facilitare ulteriori attacchi. Il produttore può quindi limitare inizialmente le informazioni ai clienti coinvolti, fornendo le indicazioni necessarie per mitigare il rischio. Dopo la correzione, una comunicazione più ampia può diventare appropriata. Una volta disponibile l’aggiornamento di sicurezza, il produttore è tenuto a divulgare pubblicamente informazioni sulle vulnerabilità risolte, con modalità e tempistiche compatibili con il rischio residuo.

Vulnerabilità note e test regolari

Una vulnerabilità può essere considerata nota quando:

• è presente in banche dati pubblicamente accessibili;
• viene comunicata attraverso una coordinated disclosure;
• viene individuata tramite test interni;
• emerge da strumenti automatizzati o sistemi basati sull’intelligenza artificiale;
• viene riportata in modo credibile da fonti specialistiche o mezzi di informazione affidabili.

La semplice pubblicazione di una vulnerabilità non significa però che questa sia applicabile o sfruttabile nel prodotto. Il produttore deve verificare la versione interessata, la configurazione, la raggiungibilità del codice e le condizioni di utilizzo. Il CRA richiede inoltre test e revisioni efficaci e regolari durante il periodo di supporto. “Regolare” non significa ripetere meccanicamente la stessa campagna di test ogni sei o dodici mesi. L’impresa deve verificare periodicamente se nuove minacce, vulnerabilità, modifiche del prodotto o cambiamenti del contesto richiedano nuovi test o l’aggiornamento di quelli esistenti.

La frequenza e la profondità devono essere proporzionate al profilo di rischio del prodotto.

Cyber Resilience Act, cosa devono fare ora le aziende

Le linee guida consentono di trasformare il CRA in un piano di lavoro concreto.

La prima attività dovrebbe essere l’identificazione dei prodotti potenzialmente interessati. Non basta un inventario commerciale: servono versioni, varianti, componenti, applicazioni collegate, servizi remoti, dipendenze e date di immissione sul mercato.

Per ogni prodotto dovrebbe essere predisposta una scheda contenente almeno:

• scopo previsto;
• uso ragionevolmente prevedibile;
• classificazione CRA;
• ruolo dell’organizzazione;
• data di immissione sul mercato;
• versioni e varianti;
• componenti hardware e software;
• dipendenze open source;
• soluzioni di trattamento remoto;
• periodo di supporto;
• procedura di conformità;
• responsabile del prodotto;
• canale di segnalazione delle vulnerabilità.

La seconda attività è l’istituzione di una governance CRA trasversale, coinvolgendo sicurezza, sviluppo, ingegneria, qualità, compliance, legale, acquisti, supply chain, assistenza, comunicazione e direzione.

La terza è la formalizzazione di un processo di valutazione del rischio cyber del prodotto, integrato nel ciclo di sviluppo e mantenuto aggiornato.

La quarta è la creazione o il rafforzamento di un Product Security Incident Response Team, con responsabilità chiare per:

• ricezione delle segnalazioni;
• triage;
• analisi tecnica;
• verifica dello sfruttamento;
• classificazione dell’incidente;
• coordinamento con i fornitori;
• rilascio delle patch;
• comunicazione agli utenti;
• segnalazione alle autorità.

La quinta consiste nella preparazione di una procedura specifica per le notifiche CRA, con simulazioni delle scadenze di 24 e 72 ore.

Il vero rischio è trattare il CRA come un progetto documentale

Il CRA non richiede soltanto policy, moduli e dichiarazioni.

Richiede che l’impresa sappia:

• quali prodotti commercializza;
• quali componenti utilizza;
• quali rischi introduce;
• chi li mantiene;
• come vengono ricevute le vulnerabilità;
• chi decide il rilascio di una patch;
• per quanto tempo il prodotto sarà supportato;
• come vengono informati gli utenti;
• chi può autorizzare una segnalazione entro 24 ore.

Una documentazione formalmente perfetta non può sostituire processi tecnici e organizzativi non funzionanti. Al contrario, un processo di sviluppo sicuro, una buona gestione delle dipendenze, un inventario attendibile e un PSIRT collaudato costituiscono le basi dalle quali può essere prodotta una documentazione credibile.

Considerazioni finali sul Cra e obblighi

Con il documento del 27 luglio 2026, il Cyber Resilience Act passa definitivamente dalla teoria normativa alla fase operativa. Le linee guida chiariscono molti aspetti, ma confermano anche che la conformità non potrà essere raggiunta attraverso un unico adempimento. Il produttore dovrà governare la sicurezza durante l’intero ciclo di vita del prodotto, comprendendo software, hardware, servizi remoti, componenti esterni, vulnerabilità e aggiornamenti.

La scadenza più urgente è l’11 settembre 2026. Da quel giorno le imprese dovranno essere in grado di segnalare vulnerabilità attivamente sfruttate e incidenti gravi secondo tempistiche estremamente ristrette. Il 2027 resta la data della piena applicazione, ma non è la data nella quale iniziare. Le organizzazioni che agiranno ora potranno utilizzare il CRA per migliorare concretamente la qualità, la sicurezza e l’affidabilità dei propri prodotti. Quelle che attenderanno l’ultimo momento rischieranno invece di scoprire che una valutazione del rischio, un processo di vulnerability handling, una supply chain controllata e una capacità di risposta entro 24 ore non possono essere improvvisati.

Fonti

https://ec.europa.eu/newsroom/dae/redirection/document/131456