Il Cyber Resilience Act entra in una nuova fase della sua applicazione. Dall’11 settembre 2026 diventano infatti applicabili gli obblighi di segnalazione previsti dall’articolo 14 del Regolamento (UE) 2024/2847 per le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza dei prodotti con elementi digitali.
La scadenza precede di oltre un anno la piena applicazione dei principali obblighi del Cyber Resilience Act, prevista per l’11 dicembre 2027, e rende particolarmente attuali le linee guida pubblicate dalla Commissione europea il 27 luglio 2026.
Il documento, identificato come C(2026) 5252 final, fornisce chiarimenti interpretativi e numerosi esempi sull’applicazione pratica del Regolamento, con particolare attenzione alle esigenze delle microimprese e delle PMI. Le linee guida non hanno carattere vincolante: la stessa Commissione precisa che l’interpretazione autoritativa del Regolamento spetta alla Corte di giustizia dell’Unione europea.
La Commissione ha predisposto il documento ai sensi dell’articolo 26 del CRA, dopo il confronto con l’Expert Group on Cybersecurity of products with digital elements e una consultazione pubblica svolta tra marzo e aprile 2026. La pagina ufficiale della Commissione evidenzia che le linee guida comprendono 67 esempi pratici, use case, flowchart e rappresentazioni grafiche.
Gli obblighi di reporting applicabili dall’11 settembre
Uno degli aspetti oggi più rilevanti riguarda il reporting delle vulnerabilità e degli incidenti.
L’articolo 14 del CRA impone al produttore di notificare al CSIRT designato come coordinatore e a ENISA:
- le vulnerabilità contenute nel prodotto che risultano attivamente sfruttate;
- gli incidenti gravi che incidono sulla sicurezza del prodotto con elementi digitali.
Le linee guida chiariscono espressamente che tali obblighi si applicano dall’11 settembre 2026 a tutti i prodotti con elementi digitali rientranti nel perimetro del CRA, compresi, in determinate condizioni, quelli immessi sul mercato prima dell’11 dicembre 2027.
Un elemento particolarmente rilevante riguarda il momento a partire dal quale decorrono i termini.
Secondo la Commissione, il produttore può essere considerato a conoscenza dell’evento quando, a seguito di una prima valutazione, dispone di un ragionevole grado di certezza che una vulnerabilità contenuta nel proprio prodotto sia attivamente sfruttata oppure che si sia verificato un incidente grave che abbia compromesso la sicurezza del prodotto.
Questo significa che anche i processi interni di escalation, analisi e classificazione degli eventi cyber assumono un’importanza decisiva ai fini della compliance.
24 ore, 72 ore e report conclusivo
Il sistema delineato dal CRA prevede una comunicazione progressiva delle informazioni.
Il produttore deve effettuare un early warning senza indebito ritardo e comunque entro 24 ore dal momento in cui viene a conoscenza dell’evento.
Segue una seconda notifica, da effettuare entro 72 ore, contenente ulteriori informazioni disponibili sulla vulnerabilità o sull’incidente.
Per le vulnerabilità attivamente sfruttate, il report finale deve essere trasmesso entro 14 giorni dalla disponibilità di una misura correttiva o di mitigazione. Per gli incidenti gravi, il rapporto finale deve invece essere trasmesso entro un mese dalla notifica delle 72 ore.
Il modello conferma quindi l’esigenza di collegare strettamente incident response, vulnerability management, responsabilità interne e flussi di comunicazione verso le autorità.
Nessun obbligo retroattivo generalizzato
La Commissione affronta anche una questione particolarmente delicata.
Le vulnerabilità per le quali il produttore fosse già a conoscenza di uno sfruttamento attivo prima dell’11 settembre 2026 non devono essere segnalate retroattivamente in base al nuovo obbligo.
La situazione cambia, invece, quando il produttore conosceva già l’esistenza della vulnerabilità ma viene a conoscenza del suo sfruttamento attivo soltanto dopo l’11 settembre: in questo caso entra in gioco l’obbligo di reporting previsto dal CRA.
Quali prodotti rientrano nel Cyber Resilience Act
Le linee guida dedicano ampio spazio al perimetro di applicazione del CRA.
Il Regolamento riguarda i prodotti con elementi digitali messi a disposizione sul mercato dell’Unione il cui uso previsto o ragionevolmente prevedibile comporta una connessione dati, diretta o indiretta, logica o fisica, a un dispositivo o a una rete.
Il concetto comprende una gamma molto ampia di prodotti: software standalone, applicazioni installate localmente, dispositivi IoT, computer, tablet, componenti hardware e combinazioni di hardware e software.
Particolarmente significativa è la distinzione formulata dalla Commissione tra software fornito all’utente ed eseguito sul suo sistema e software eseguito esclusivamente da remoto.
Una normale web application utilizzata esclusivamente attraverso il browser, ad esempio, non costituisce automaticamente un prodotto con elementi digitali ai fini del CRA. La valutazione cambia quando il trattamento remoto è necessario per permettere a un prodotto con elementi digitali di svolgere una propria funzione.
Remote Data Processing Solutions: quando il cloud diventa parte del prodotto
Uno dei chiarimenti più interessanti riguarda le Remote Data Processing Solutions – RDPS.
Perché un’elaborazione remota rientri nella nozione prevista dal CRA devono ricorrere due condizioni centrali:
l’assenza dell’elaborazione remota deve impedire al prodotto di svolgere almeno una delle sue funzioni e il relativo software deve essere progettato e sviluppato dal produttore o sotto la sua responsabilità.
La Commissione distingue quindi tra differenti modelli di utilizzo dei servizi cloud.
In presenza di IaaS o PaaS, il software sviluppato dal produttore e utilizzato sull’infrastruttura del provider può costituire RDPS. Un servizio SaaS standard di terzi, invece, normalmente non è stato progettato o sviluppato sotto la responsabilità del produttore e viene quindi trattato diversamente.
Ciò non significa che il relativo rischio possa essere ignorato: la dipendenza dal provider deve comunque entrare nella cybersecurity risk assessment e può rendere necessarie attività di due diligence sul fornitore.
Software open source: la commercializzazione diventa decisiva
Un’altra parte particolarmente articolata delle linee guida riguarda il free and open-source software – FOSS.
La Commissione chiarisce che la mera pubblicazione di software open source non determina automaticamente l’applicazione degli obblighi previsti per i produttori.
Occorre verificare, tra l’altro, se il software venga fornito nell’ambito di un’attività commerciale.
Il documento analizza numerose ipotesi: vendita del software, monetizzazione di altri servizi, utilizzo dei dati personali, servizi di assistenza, donazioni, finanziamento dello sviluppo e integrazione del software all’interno di prodotti commerciali.
Viene inoltre approfondita la nuova figura dell’open-source software steward, prevista dal CRA per determinati soggetti giuridici che forniscono in modo sistematico e continuativo supporto allo sviluppo di software open source destinato ad attività commerciali.
Quando un aggiornamento diventa una “modifica sostanziale”
Un altro nodo operativo riguarda la substantial modification.
Non ogni aggiornamento software determina una nuova applicazione degli obblighi di conformità.
Occorre valutare se la modifica incida sulla conformità ai requisiti essenziali di cybersecurity oppure modifichi la destinazione d’uso rispetto a quella considerata originariamente.
La Commissione invita in particolare a valutare se l’aggiornamento:
introduca nuovi vettori di minaccia, renda possibili nuovi scenari di attacco oppure modifichi in modo significativo la probabilità o l’impatto degli scenari precedentemente individuati.
Un normale security update diretto esclusivamente a ridurre un rischio cyber, senza modificare la destinazione del prodotto o introdurre nuovi rischi, generalmente non costituisce una modifica sostanziale. Al contrario, anche un aggiornamento apparentemente limitato può esserlo quando genera nuove esposizioni non considerate nella precedente valutazione del rischio.
Il support period non è automaticamente di cinque anni
Le linee guida forniscono inoltre un chiarimento significativo sul periodo di supporto.
L’articolo 13, paragrafo 8, stabilisce che il periodo durante il quale le vulnerabilità devono essere gestite efficacemente sia normalmente almeno pari a cinque anni, salvo che il prodotto abbia una vita utile prevista inferiore.
La Commissione precisa però che cinque anni non costituiscono una durata standard valida per tutti i prodotti.
Se il prodotto è ragionevolmente destinato a essere utilizzato per un periodo superiore, anche il support period dovrà essere determinato tenendo conto della sua effettiva durata prevista, della natura del prodotto e delle ragionevoli aspettative degli utenti.
La valutazione del rischio non può dipendere soltanto dalla risk appetite aziendale
Particolarmente importante per la governance aziendale è anche l’interpretazione della cybersecurity risk assessment.
La Commissione chiarisce che la tolleranza interna al rischio dell’impresa, le strategie commerciali o le mere considerazioni economiche non sono sufficienti a stabilire se un rischio cyber possa essere considerato adeguatamente trattato.
Il produttore deve invece valutare se il prodotto garantisca un livello di cybersecurity appropriato rispetto ai rischi, tenuto conto della destinazione d’uso e degli utilizzi ragionevolmente prevedibili.
Non è quindi possibile trasferire semplicemente all’utilizzatore o a un soggetto terzo la responsabilità derivante da carenze nella progettazione del prodotto.
Dal prodotto all’organizzazione: cosa cambia per le imprese
Le indicazioni della Commissione confermano che il Cyber Resilience Act non può essere affrontato esclusivamente come un tema tecnico.
La compliance richiede un collegamento tra progettazione e sviluppo dei prodotti, risk assessment, gestione delle vulnerabilità, procedure di incident response, rapporti con fornitori e componentisti, documentazione tecnica, processi di aggiornamento e responsabilità organizzative.
L’imminente applicazione degli obblighi di reporting dall’11 settembre 2026 rappresenta quindi un primo passaggio concreto.
Le organizzazioni interessate dovrebbero verificare non soltanto la propria capacità tecnica di individuare vulnerabilità e incidenti, ma anche chi deve valutarli, attraverso quali procedure devono essere escalati e come garantire il rispetto delle tempistiche previste dal Regolamento.
La piena applicazione del CRA arriverà l’11 dicembre 2027, ma una parte significativa del percorso di adeguamento deve necessariamente essere costruita prima. La stessa Commissione presenta le linee guida del 27 luglio come uno strumento per consentire alle imprese di prepararsi in anticipo e in maniera proporzionata.
