Il 27 luglio 2026 la Commissione europea ha approvato, con la Comunicazione C(2026) 5252 final, il testo definitivo delle linee guida sull’applicazione del Regolamento (UE) 2024/2847, il Cyber Resilience Act, di seguito CRA: oltre ottanta pagine e 67 esempi pratici, che chiudono il percorso avviato con la bozza pubblicata a marzo 2026 e sottoposta a consultazione pubblica dal 3 marzo al 13 aprile 2026.
L’orologio degli adempimenti CRA corre infatti veloce: il Capo IV, relativo alla notifica degli organismi di valutazione della conformità, si applica già dall’11 giugno 2026; gli obblighi di segnalazione dell’art. 14 scattano l’11 settembre 2026; l’applicazione integrale del regolamento arriverà l’11 dicembre 2027.
Chi produce software o prodotti connessi destinati al mercato europeo ha quindi davanti un documento che (seppur ovviamente non vincolante) costituirà il punto di riferimento delle autorità di vigilanza del mercato.
Senza pretese di esaustività, vediamo allora i punti principali delle Linee Guida.
Indice degli argomenti
Cyber Resilience Act: perimetro, software e prodotti legacy
Partiamo dalla norma. Il CRA si applica ai «prodotti con elementi digitali», che l’art. 3, punto 1, definisce come “il prodotto software o hardware e le sue soluzioni di trattamento remoto dei dati, inclusi i componenti software o hardware immessi sul mercato separatamente“.
Dentro questa definizione cade — ed è la vera portata innovativa del regolamento — anche il software venduto da solo: un gestionale, un’app, un sistema operativo sono «prodotti» ai fini del CRA esattamente come un dispositivo fisico connesso. Gli obblighi scattano con l’immissione sul mercato, cioè con la prima messa a disposizione del prodotto sul mercato dell’Unione nel corso di un’attività commerciale.
La sezione 2 dell’Allegato affronta proprio i temi dell’immissione sul mercato, del software come prodotto con elementi digitali, del codice sorgente e dei sistemi complessi.
Ma il passaggio di maggior peso operativo è quello dedicato ai prodotti progettati prima della data di applicazione del CRA (sezione 2.7).
La questione è infatti molto concreta: cosa accade alle unità di prodotto immesse sul mercato dopo l’11 dicembre 2027, ma fabbricate secondo un tipo o modello progettato e sviluppato prima?
La risposta della Commissione è rassicurante (e condivisibile, a parere di chi scrive): la conformità al CRA non richiede necessariamente la riprogettazione del prodotto. Il fabbricante deve però svolgere la valutazione dei rischi di cibersicurezza ai sensi dell’art. 13, par. 2, CRA e, se questa dimostra che il prodotto incorpora già misure di sicurezza adeguate ed efficaci rispetto ai rischi identificati, può fondare su tali misure la dimostrazione di conformità.
Se invece la valutazione fa emergere rischi non adeguatamente coperti, l’esonero non opera: il fabbricante dovrà colmare il divario e adottare le misure necessarie a soddisfare i requisiti essenziali prima di immettere le nuove unità sul mercato. In sostanza, ciò che la guidance esclude è la riprogettazione non necessaria: il CRA — precisa la Commissione — non impone di per sé di introdurre nuove funzionalità di sicurezza dove non servono a fronteggiare i rischi identificati.
Ciò però suggerisce di progettare, sin da ora, tenendo conto del CRA.
Open source nel Cyber Resilience Act: ruoli e attività commerciale
Circa il software open source, il CRA definisce software libero e open source (FOSS) il software il cui codice sorgente è condiviso apertamente e messo a disposizione con una licenza libera che ne consente accesso, uso, modifica e ridistribuzione (art. 3, punto 48).
Dato atto che il CRA si applica solo ai prodotti forniti nel corso di un’attività commerciale, il FOSS che non viene monetizzato resta fuori dal suo perimetro (considerando 18).
Per gli enti che, pur senza immettere il software sul mercato, ne sostengono sistematicamente e stabilmente lo sviluppo — si pensi alle fondazioni open source — il regolamento crea però la figura nuova dell’open-source software steward (art. 3, punto 14): la persona giuridica, diversa dal fabbricante, che ha lo scopo di fornire sostegno sistematico e continuativo allo sviluppo di FOSS destinato ad attività commerciali, assicurandone la vitalità.
Il sostegno rilevante può assumere forme diverse: ospitare e gestire piattaforme di collaborazione per lo sviluppo, ospitare il codice sorgente, governare o dirigere lo sviluppo del software.
Lo steward è poi assoggettato a un regime dedicato e molto alleggerito rispetto a quello del fabbricante (art. 24): niente requisiti essenziali né marcatura CE, ma obblighi mirati — tra cui dotarsi di una politica di cibersicurezza — e obblighi di segnalazione graduati in funzione del tipo di sostegno fornito (art. 24, par. 3).
Palese per tutti che il punto critico nella pratica è stabilire quando la fornitura di software open source resta tale e quando diventa «attività commerciale».
In questo senso la sezione 3 — che affronta questo tema — è forse quella più attesa dal settore.
Ruoli e commercializzazione del software open source
Sotto questo profilo si chiariscono tre elementi.
- Il primo riguarda i ruoli. Il FOSS è «sotto la responsabilità» di chi lo pubblica ed esercita il controllo primario su sviluppo, rilasci e decisioni di distribuzione (i maintainer). Chi si limita a contribuire con il codice — anche con accesso in scrittura al repository — è un contributor e non è soggetto al CRA: il mero contributo di codice sorgente, chiarisce la guidance, non fa scattare alcun obbligo.
- Il secondo chiarimento riguarda la commercializzazione, cioè il discrimine tra FOSS fuori e dentro il perimetro del regolamento. “La guidance passa in rassegna le ipotesi concrete: la vendita dei binari precompilati è immissione sul mercato; la monetizzazione di altri servizi attraverso il software (pubblicità, commissioni, abbonamenti) o la richiesta di trattamento di dati personali come condizione d’uso — per finalità diverse da sicurezza, compatibilità o interoperabilità — parimenti. I servizi professionali opzionali (consulenza, formazione, supporto all’installazione) invece no, purché l’accesso al software e alla sua manutenzione resti libero. Le donazioni non costituiscono di regola attività commerciale, nemmeno quando superano i costi: lo diventano solo quando sono, di fatto, il prezzo di accesso al software, alle sue funzionalità essenziali o agli aggiornamenti”.
- Interessante anche il chiarimento sul modello open-core: la versione a pagamento è immessa sul mercato e rende il fornitore fabbricante; la versione community gratuita no, ma se il fornitore è una persona giuridica sarà soggetto, per quella versione, agli obblighi (assai più leggeri) degli open-source software steward ex art. 24 CRA.
- Il terzo chiarimento riguarda proprio la figura dello steward — la vera novità sistematica del CRA in materia. La guidance precisa che lo stesso soggetto può essere steward per un progetto e fabbricante per un altro, e che la qualificazione va condotta progetto per progetto. Quanto agli obblighi di segnalazione, la loro estensione dipende dal tipo di sostegno: lo steward che offre solo supporto non tecnico (governance, branding, raccolta di donazioni) non è tenuto a notificare; chi fornisce l’infrastruttura informatica del progetto notifica gli incidenti gravi relativi a quell’infrastruttura; chi contribuisce anche risorse di ingegneria (sviluppatori, gestione dei rilasci, gestione delle patch) notifica anche le vulnerabilità attivamente sfruttate di cui venga a conoscenza.
Per le fondazioni che offrono piattaforme di collaborazione e supporto continuativo a progetti FOSS destinati ad attività commerciali, la qualifica di steward sarà la regola.
Aggiornamenti e modifiche sostanziali secondo il CRA
Veniamo ad un altro punto molto delicato: le modifiche sostanziali.
L’art. 3, punto 30, CRA definisce «modifica sostanziale» la modifica apportata al prodotto dopo la sua immissione sul mercato che incide sulla conformità ai requisiti essenziali o cambia la finalità prevista per la quale il prodotto è stato valutato.
La conseguenza è pesante: il prodotto sostanzialmente modificato e messo a disposizione sul mercato è trattato come un prodotto nuovo, con nuova immissione sul mercato e nuova valutazione della conformità; e se la modifica è compiuta da un terzo, sarà il terzo ad assumere la qualifica — e le responsabilità — di fabbricante (artt. 21 e 22 CRA). Per un’industria che vive di rilasci continui, capire quando un aggiornamento è «sostanziale» è dunque questione di sopravvivenza operativa. La sezione 4 dell’Allegato serve esattamente a questo.
Il criterio guida indicato dalla Commissione è netto: non contano la scala o la complessità tecnica della modifica, ma il suo impatto potenziale sul profilo di rischio di cibersicurezza.
Una funzionalità apparentemente minore (l’esempio della guidance: un persistent login che memorizza token di autenticazione in locale) può integrare una modifica sostanziale se introduce rischi non valutati; una riscrittura tecnica anche importante può non esserlo, se i rischi erano già coperti dalla valutazione originaria. La guidance offre quattro parametri di verifica: nuovi vettori di minaccia, nuovi scenari di attacco, variazione della probabilità e variazione dell’impatto degli scenari già identificati.
Patch di sicurezza e pezzi di ricambio
Per gli aggiornamenti di sicurezza la regola è quella da tutti attesa: le patch destinate esclusivamente a ridurre il rischio — che non modificano la finalità prevista e non introducono nuovi rischi — non sono modifiche sostanziali, anche quando tecnicamente rilevanti. Con un’eccezione da non sottovalutare: l’aggiornamento security-driven che altera materialmente confini, flussi di dati o dipendenze del prodotto (l’esempio è il passaggio da cifratura locale a un servizio di cifratura remoto) torna a essere modifica sostanziale.
Chiude il quadro la disciplina dei pezzi di ricambio: l’art. 2, par. 6, CRA esenta i ricambi identici fabbricati secondo le stesse specifiche dei componenti che sostituiscono.
La guidance precisa che l’identità va valutata sulle caratteristiche rilevanti per la cibersicurezza: quindi, a titolo di esempio, un chip sostitutivo con diversa implementazione crittografica o diverso meccanismo di secure boot non è identico, e diventa un prodotto con elementi digitali autonomamente soggetto al CRA.
L’esenzione vale solo quando la finalità di riparazione o manutenzione emerge dal contesto della fornitura — canali after-sales, identificazione del prodotto di destinazione — con evidenze da tenere a disposizione delle autorità di vigilanza.
Periodo di supporto nel CRA: cinque anni come soglia minima
L’art. 13, par. 8, CRA impone poi al fabbricante di determinare il periodo di supporto: in altre parole l’arco di tempo durante il quale le vulnerabilità del prodotto, componenti inclusi, devono essere gestite efficacemente secondo la Parte II dell’Allegato I (identificazione e correzione, divulgazione coordinata, test e riesami regolari).
Il periodo va determinato in base al tempo durante il quale il prodotto è destinato a essere utilizzato — contano le ragionevoli aspettative degli utenti, la natura e la finalità del prodotto — e deve comunque durare almeno cinque anni, salvo che l’uso atteso sia più breve. La data di fine supporto va indicata al momento dell’acquisto, almeno con mese e anno (art. 13, par. 19).
Su questo impianto la guidance smonta una semplificazione circolata a lungo: cinque anni non è il periodo di supporto standard. È un presidio minimo. Il periodo di supporto deve riflettere il tempo di utilizzo atteso del prodotto: se il prodotto è ragionevolmente destinato a essere usato più a lungo — e per molti prodotti, dall’industriale al consumer durevole, lo è — il periodo di supporto deve essere corrispondentemente più lungo. Sotto i cinque anni si può scendere solo quando il tempo di utilizzo atteso è dimostrabilmente inferiore.
Rilasci continui e durata del supporto
Per il software a rilascio continuo, la guidance valorizza la flessibilità dell’art. 13, par. 10: il fabbricante può limitare la correzione delle vulnerabilità all’ultima versione immessa sul mercato, a condizione che gli utenti delle versioni precedenti possano accedere all’ultima versione gratuitamente e senza costi aggiuntivi per adeguare l’ambiente hardware e software. Per quanto attiene ai «costi aggiuntivi» si precisa che non vi rientrano gli sforzi operativi ordinari (tempo del personale, test, aggiustamenti di configurazione); vi rientrano invece gli acquisti obbligati di nuovo hardware o i cambi infrastrutturali radicali.
Un punto rilevante è poi il rapporto tra modifica sostanziale e periodo di supporto.
Si è visto (sezione 3) che il prodotto sostanzialmente modificato è un prodotto «nuovo», nuovamente immesso sul mercato: verrebbe quindi da pensare che a ogni modifica sostanziale il periodo di supporto riparta da zero, con altri cinque anni (almeno) di gestione delle vulnerabilità. Non è così.
Il periodo di supporto dipende dal tempo di utilizzo atteso del prodotto: se la modifica non cambia i fattori che quel tempo lo avevano determinato, il periodo non si allunga.
L’esempio della guidance rende bene l’idea: un robot aspirapolvere ha un periodo di supporto tarato sulla durata fisica dell’hardware; se dopo qualche anno il fabbricante rilascia un aggiornamento software con nuove funzioni di navigazione — modifica sostanziale a tutti gli effetti — la durata attesa del prodotto resta quella dell’hardware, e il supporto copre solo il tempo di utilizzo residuo originario. Se invece la modifica estende la vita del prodotto (l’esempio è la sostituzione dell’intera piattaforma di calcolo di un controllore industriale con componenti di nuova generazione), allora il periodo di supporto va ricalcolato sul nuovo tempo di utilizzo atteso.
Prodotti importanti e critici: la classificazione nel CRA
I prodotti digitali soggetti al CRA sono poi suddivisi in classi di rischio del prodotto.
I prodotti digitali che non rientrano in alcuna categoria speciale e che la stessa Commissione chiama prodotti della categoria di default (default category) ricorrerono all’autovalutazione del fabbricante (controllo interno ex art. 32, par. 1); i prodotti qualificati invece come «importanti» (important products: quelli che rientrano nelle categorie dell’Allegato III, divise in classe I e classe II: es. password manager, firewall, sistemi operativi) ed i prodotti «critici» (critical products) dell’Allegato IV sono invece soggetti a procedure più stringenti, che possono richiedere il coinvolgimento di soggetti terzi (artt. 7, 8 e 32 CRA).
Classificare correttamente il proprio prodotto è quindi il primo passo di qualsiasi percorso di conformità: da lì dipendono tempi, costi e interlocutori.
Su questo la guidance introduce il criterio operativo della core functionality: un prodotto è «importante» (classe I o II) o «critico» solo se presenta la funzionalità essenziale di una delle categorie elencate negli Allegati III e IV del CRA, come tecnicamente descritte dal Regolamento di esecuzione (UE) 2025/2392. Il fatto che un prodotto svolga anche funzioni riconducibili a una categoria importante o critica, in via ancillare rispetto alla propria funzionalità essenziale, non ne determina la riclassificazione.
Resta ferma la valvola dell’art. 32, par. 5: i prodotti importanti qualificabili come FOSS possono seguire le procedure della categoria di default (l’autovalutazione), anche se di classe I o II.
Cloud e trattamento remoto dei dati nel Cyber Resilience Act
Come si è visto, il prodotto con elementi digitali comprende per definizione anche le sue soluzioni di trattamento remoto dei dati (remote data processing solutions, di seguito RDPS): il trattamento di dati a distanza il cui software è progettato e sviluppato dal fabbricante o sotto la sua responsabilità, e in assenza del quale il prodotto non potrebbe svolgere una delle sue funzioni (art. 3, punto 2, CRA).
La ratio è chiara (considerando 11): il prodotto deve essere sicuro nella sua interezza, a prescindere dal fatto che i dati siano trattati sul dispositivo dell’utente o sui server del fabbricante. In concreto: se l’app funziona solo perché dialoga con il back-end cloud del produttore, quel back-end fa parte del prodotto e deve rispettarne i requisiti di sicurezza.
La sezione 8 dell’Allegato porta ordine su questo che è uno dei perimetri più incerti del CRA.
I tre criteri per le soluzioni di trattamento remoto
I criteri sono tre e cumulativi:
- il trattamento deve avvenire «a distanza» rispetto all’ambiente dell’utente;
- la sua assenza deve impedire al prodotto di svolgere una delle sue funzioni (non solo la funzionalità essenziale: anche onboarding, sincronizzazione, distribuzione di aggiornamenti, gestione delle identità);
- il software deve essere progettato e sviluppato dal fabbricante o sotto la sua responsabilità, cioè costruito esclusivamente da o per conto del fabbricante su sue specifiche.
Ne discendono conseguenze pratiche rilevanti per le architetture cloud.
Il software che il fabbricante distribuisce su infrastruttura IaaS o PaaS di terzi resta tipicamente una RDPS, cioè una soluzione di trattamento remoto dei dati che fa parte del prodotto (il fabbricante la progetta e sviluppa, pur non controllando l’infrastruttura sottostante); la soluzione SaaS di terzi integrata nel prodotto, invece, non è una RDPS, perché non è sviluppata sotto la responsabilità del fabbricante.
Ma — e qui sta il punto che gli uffici legali devono presidiare — ciò non significa che il SaaS di terzi sia irrilevante: va trattato alla stregua di un componente di terze parti, con valutazione dei rischi dell’integrazione, misure di mitigazione a livello di prodotto e un dovere di diligenza analogo a quello dell’art. 13, par. 5, CRA, proporzionato al rischio.
Segnalazioni CRA dal settembre 2026: tempi e obblighi
Veniamo ora alla scadenza più vicina, partendo anche qui dalla norma.
L’art. 14 CRA impone ai fabbricanti di notificare due categorie di eventi: le vulnerabilità attivamente sfruttate contenute nei loro prodotti (cioè le falle che qualcuno sta effettivamente utilizzando per un attacco) e gli incidenti gravi che incidono sulla sicurezza dei prodotti stessi. La logica è quella dell’allerta precoce dell’ecosistema: le autorità devono sapere subito che un prodotto sul mercato è sotto attacco, per contenere la propagazione.
E attenzione: l’obbligo riguarda tutti i prodotti che rientrano nell’ambito di applicazione del CRA, compresi quelli immessi sul mercato prima dell’11 dicembre 2027 — dunque anche prodotti che non sono mai stati progettati secondo i requisiti del regolamento (art. 69, par. 3, CRA). Per questi ultimi non si applicano gli obblighi di gestione delle vulnerabilità della Parte II dell’Allegato I, ma la segnalazione ex art. 14 sì.
Tempi e decorrenza delle notifiche CRA
Dall’11 settembre 2026 la notifica va effettuata simultaneamente al CSIRT designato quale coordinatore e all’ENISA, secondo la scansione dell’art. 14 CRA: allerta precoce entro 24 ore, notifica entro 72 ore, relazione finale entro 14 giorni dalla disponibilità della misura correttiva per le vulnerabilità attivamente sfruttate, ovvero entro un mese dalla notifica delle 72 ore per gli incidenti gravi.
La guidance chiarisce tre punti che valgono da soli la lettura della sezione dedicata (sezione 9.1 dell’Allegato):
1) i termini decorrono dalla consapevolezza, intesa come il momento in cui il fabbricante, all’esito di una valutazione iniziale da condurre immediatamente, raggiunge un ragionevole grado di certezza sullo sfruttamento attivo della vulnerabilità o sull’incidente. La nozione è dichiaratamente allineata al Regolamento di esecuzione (UE) 2024/2690 (attuativo di NIS2) e alle Guidelines 9/2022 dell’EDPB sul data breach: un allineamento interpretativo tra framework che chi gestisce procedure di notifica multiple apprezzerà (giustamente, verrebbe da dire: era ora che qualcuno lo scrivesse).
2) l’obbligo si applica dall’11 settembre 2026, ma senza retroattività: se il fabbricante sapeva già prima dell’11 settembre 2026 che una vulnerabilità era attivamente sfruttata, quella vulnerabilità non va notificata. Diverso il caso in cui il fabbricante conoscesse la vulnerabilità, ma scopra solo dopo quella data che qualcuno la sta effettivamente utilizzando per un attacco: qui la notifica è dovuta, perché è dopo l’11 settembre 2026 che matura la consapevolezza dello sfruttamento attivo.
3) gli obblighi di segnalazione sopravvivono alla fine del periodo di supporto. La gestione delle vulnerabilità (Parte II dell’Allegato I) cessa con il supporto; la notifica ex art. 14 no. Il monitoraggio del portafoglio prodotti, anche a fine vita, dovrà quindi restare organizzato.
Merita un cenno anche l’obbligo di informare gli utenti ex art. 14, par. 8, che la guidance declina in chiave risk-based: informare gli utenti non significa divulgazione pubblica indiscriminata, e per i prodotti impiegati in ambienti sensibili o essenziali — la sanità è l’esempio che viene subito in mente a chi scrive — la limitazione della disclosure di dettaglio ai soli utenti interessati può essere la scelta corretta, fino alla remediation.
Cyber Resilience Act e governance del ciclo di vita del software
Il quadro che emerge dalle linee guida è chiaro: la Commissione ha scelto un’interpretazione pragmatica e proporzionata — niente riprogettazioni obbligate del legacy, patch di sicurezza libere da riassessment, open source protetto nei suoi contributori — ma in cambio pretende che il fabbricante governi davvero il proprio prodotto: valutazione dei rischi viva e aggiornata, censimento delle dipendenze, presidio del fine vita.
Il baricentro si sposta dall’adempimento documentale alla governance continuativa del ciclo di vita del software. È la stessa traiettoria di NIS2 e DORA: la sicurezza della supply chain digitale come tema strutturale, trasversale ai framework, destinato a entrare stabilmente nei contratti e nei modelli organizzativi.
Le priorità operative per i fabbricanti
Un mero elenco di profili su cui cominciare a ragionare:
– mappare il portafoglio prodotti rispetto al perimetro CRA, qualificando le eventuali RDPS secondo i tre criteri cumulativi e distinguendo le soluzioni di terzi da trattare come componenti;
– censire i componenti FOSS integrati e chiarire i ruoli nella filiera (fabbricante, steward, contributor), adeguando la due diligence ex art. 13, par. 5, CRA;
– cominciare a predisporre la procedura interna di segnalazione a CSIRT ed ENISA, con la definizione operativa del momento di «consapevolezza» e il raccordo con le procedure NIS2 e GDPR già esistenti;
– rivedere la politica di aggiornamento software alla luce dei criteri sulla modifica sostanziale, documentando nella valutazione dei rischi le evoluzioni funzionali già pianificate (che, se anticipate lì, non costituiranno modifica sostanziale);
– determinare e dichiarare i periodi di supporto sulla base del tempo di utilizzo atteso, senza appiattirsi sui cinque anni;
– aggiornare la contrattualistica con i fornitori cloud e software, allocando obblighi di sicurezza, flussi informativi sulle vulnerabilità e cooperazione nelle notifiche.
Buon lavoro e… buona estate!
Partecipa alla community