Per decenni, l’industria del software ha operato secondo una logica implicita molto permissiva: rilascia il prodotto velocemente, correggi bug e falle di sicurezza dopo tramite aggiornamenti. Un difetto nel codice poteva avere effetti gravi, come paralizzare ospedali o filiere logistiche,ma larga parte dei rischi ricadeva sugli utenti finali. Il Cyber Resilience Act (CRA) mette fine a questa logica.
Nel mondo dei prodotti fisici, invece, i produttori sono sottoposti a vincoli e responsabilità molto più stringenti. Ad esempio, Se un’azienda immette sul mercato un elettrodomestico con un difetto di fabbrica che rischia di causare un cortocircuito, il prodotto viene immediatamente ritirato e il produttore ne risponde legalmente. Finora, per i prodotti digitali, questo livello di responsabilità diretta non esisteva.
Con questa nuova normativa, l’Unione Europea ha deciso di equiparare il mondo digitale a quello fisico. Se vendi software nel mercato unico europeo, devi garantirne la sicurezza dalla fase di progettazione fino al termine del suo ciclo di vita.
Non si tratta di una semplice raccomandazione. La sicurezza informatica cessa di essere una caratteristica opzionale e diventa un requisito vincolante per l’accesso al mercato.
Prima di affrontare le complesse sfide tecniche legate all’adeguamento, devi rispondere a una domanda fondamentale: il tuo prodotto rientra in questa normativa?
Nelle prossime sezioni esploreremo esattamente chi è coinvolto, chi è escluso e come funzionano le classi di rischio. Ti guideremo attraverso i concetti chiave con l’esperienza di chi ha seguito l’evoluzione di questa legge fin dalle sue prime bozze, aiutandoti a trasformare un obbligo normativo in un reale vantaggio competitivo per la tua azienda.
Perché l’Europa ha deciso che il software non può più ignorare la sicurezza?
L’Europa ha introdotto il Cyber Resilience Act per rendere la sicurezza informatica un requisito legale obbligatorio per i prodotti digitali. L’obiettivo è proteggere il mercato dalle vulnerabilità sistemiche, superando la frammentazione normativa e trasferendo la responsabilità della sicurezza dai consumatori finali ai produttori di software.
Prima dell’approvazione di questa legge, mancavano requisiti minimi obbligatori. Ogni stato membro aveva linee guida diverse, creando un mosaico normativo che penalizzava le aziende virtuose e lasciava enormi falle nella protezione delle infrastrutture. L’onere della sicurezza ricadeva sulle spalle degli utenti, costretti a districarsi tra aggiornamenti costanti e configurazioni complesse.
La spinta decisiva per legiferare è arrivata dalla realtà dei fatti. Negli ultimi anni, abbiamo assistito a incidenti che hanno dimostrato come una singola falla possa mettere in ginocchio migliaia di organizzazioni simultaneamente. Questi eventi hanno reso evidente la necessità di comprendere i rischi e le vulnerabilità della software supply chain per evitare effetti a catena devastanti.
Tra i casi storici che hanno guidato il legislatore europeo troviamo:
L’attacco a SolarWinds, dove un codice malevolo inserito in un aggiornamento legittimo ha compromesso agenzie governative e aziende Fortune 500.
La vulnerabilità sistemica di Log4Shell, un difetto in una minuscola libreria di logging che ha esposto milioni di server a livello globale.
La compromissione di Codecov, che ha permesso agli attaccanti di esfiltrare credenziali direttamente dagli ambienti di CI/CD.
Questi incidenti hanno aperto gli occhi dei legislatori, mettendo in evidenza falle sistemiche in grado di innescare effetti a catena devastanti. Hanno dimostrato che il problema risiede nella base stessa dello sviluppo, colpendo la Supply Chain Security, ovvero letteralmente la sicurezza della catena di approvvigionamento del software.
Il CRA ribalta questa logica: si passa da un approccio reattivo, basato sul rilascio frenetico di patch dopo un attacco, a una sicurezza preventiva. La sicurezza deve essere integrata fin dalla fase di progettazione, adottando il principio della Security by Design, e le aziende dovranno adottare pratiche rigorose di software supply chain management.
Sarà necessario garantire che ogni componente di terze parti sia tracciato, verificato e mantenuto sicuro fin dal primo giorno di sviluppo. Ad esempio, l’uso di strumenti per generare e monitorare le distinte base del software (SBOM) diventerà uno standard operativo per una secure software supply chain. Non basta più reagire bene; la legge ora impone di progettare in modo sicuro.
Quali prodotti software rientrano nel perimetro del Cyber Resilience Act?
Il Cyber Resilience Act si applica a tutti i “prodotti con elementi digitali” immessi sul mercato europeo. La normativa coinvolge produttori, importatori e distributori di applicazioni, sistemi operativi, firmware e componenti software, stabilendo regole di sicurezza obbligatorie per chiunque sviluppi e commercializzi tecnologia nell’Unione Europea.
Per capire se la tua azienda è coinvolta, devi guardare alla definizione di prodotto digitale. Il concetto di “Prodotti con Elementi Digitali” è stato volutamente formulato in modo ampio per evitare scappatoie legali. In termini semplici, se il tuo prodotto contiene del codice e comunica con l’esterno, è quasi certamente soggetto alla normativa.
La legge non fa distinzione tra un’applicazione mobile scaricata da uno store, un software gestionale installato on-premise o il firmware che fa funzionare un router aziendale. Se il tuo codice elabora dati o si connette a una rete, è altamente probabile che rientri nel raggio d’azione del legislatore.
La normativa definisce con precisione chi deve assumersi l’onere della conformità:
I produttori di software commerciale, indipendentemente dalle dimensioni dell’azienda, che vendono licenze o distribuiscono app nel mercato UE.
I fornitori di componenti software, inclusi coloro che sviluppano SDK, librerie o moduli che verranno poi integrati nei prodotti di altre aziende.
Gli importatori e distributori che immettono sul mercato europeo tecnologie sviluppate al di fuori dei confini dell’Unione.
Un aspetto cruciale da comprendere è il legame con la secure software supply chain. Il perimetro della legge non si limita al codice scritto dai tuoi sviluppatori, ma include tutte le librerie open source e i componenti di terze parti integrati nel prodotto finale.
In altre parole, sei legalmente responsabile anche per le vulnerabilità presenti nei pacchetti esterni che hai deciso di includere. Per questo motivo, diventa vitale adottare i principi e le best practice per la sicurezza applicativa del software fin dalle primissime fasi di sviluppo.
Un altro nodo molto dibattuto riguarda le piattaforme SaaS (Software as a Service). Sebbene l’infrastruttura cloud in sé possa ricadere sotto altre direttive, il software fornito tramite modello SaaS è spesso considerato un prodotto con elementi digitali.
Se la tua azienda offre servizi cloud, è essenziale valutare tempestivamente la propria posizione e implementare strategie di software supply chain security conformi per evitare sanzioni.
Tuttavia, il legislatore ha previsto delle esclusioni specifiche per evitare sovrapposizioni normative:
Il software a uso interno, sviluppato su misura e utilizzato esclusivamente all’interno dell’azienda senza essere commercializzato.
I prodotti già coperti da normative settoriali altrettanto stringenti, come i dispositivi medici regolati dal Medical Devices Regulation o i sistemi software per l’automotive.
I progetti open source sviluppati e mantenuti al di fuori di qualsiasi logica commerciale, per tutelare la ricerca e la collaborazione libera.
L’obiettivo è creare una catena di fornitura sicura a livello continentale, colpendo i prodotti commerciali che pongono rischi reali agli utenti, senza soffocare l’innovazione interna o sovra-regolamentare settori già presidiati.
Come funzionano le classi di rischio del Cyber Resilience Act?
Il Cyber Resilience Act classifica i prodotti in tre livelli: la Classe Default per la maggior parte dei software, e due classi di “Prodotti Importanti” (Classe I e Classe II) per i sistemi critici. A ogni livello corrispondono requisiti di valutazione della conformità progressivamente più severi.
Per un Project Manager o un responsabile IT, capire in quale “cassetto” inserire il proprio progetto è il primo passo operativo.
L’Europa ha scelto un approccio proporzionale. Non ha senso imporre gli stessi controlli di sicurezza a un’app per la gestione delle note e a un firewall di livello enterprise. Per questo motivo, il legislatore ha strutturato un sistema a piramide che determina l’impegno richiesto alle aziende.
Per precisione tecnica, è utile notare che la Classe I e la Classe II compongono la categoria dei cosiddetti “Prodotti Importanti” (Allegato III del regolamento). Esiste poi una categoria ancora più ristretta di “Prodotti Critici” (Allegato IV) soggetta a regole specifiche. La tabella seguente riassume come sono suddivise le categorie di rischio principali.
| Classe | Categoria regolamento | Esempi | Valutazione richiesta |
|---|---|---|---|
| Classe Default | ~90% dei prodotti software standard sul mercato | App mobile comuni, software gestionali, videogiochi, smart TV, termostati IoT | Autovalutazione della conformità da parte del produttore |
| Classe I | Prodotti Importanti che gestiscono privilegi o dati sensibili (Allegato III) | Password manager, browser web, router, sistemi operativi generici, antivirus | Applicazione di standard armonizzati UE o valutazione di terze parti |
| Classe II | Prodotti Importanti ad alto rischio per l’infrastruttura digitale (Allegato III) | Container runtime, hypervisor, firewall industriali, smart meter | Audit obbligatorio condotto da enti certificatori indipendenti |
| Prodotti Critici | Sistemi critici per infrastrutture digitali strategiche (Allegato IV) | Sistemi per infrastrutture critiche nazionali | Requisiti specifici aggiuntivi |
L’impatto sulle moderne architetture IT della classificazione stabilita dal CRA è profondo. Tecnologie fondamentali per il paradigma Cloud Native, come i container runtime e gli hypervisor, sono state inserite esplicitamente nella Classe II. Questo significa che i motori che fanno girare i microservizi di mezza Europa dovranno superare gli esami più severi previsti dalla legge.
Se la tua azienda sviluppa o fornisce infrastrutture basate su Kubernetes o ambienti virtualizzati, il livello di attenzione deve essere massimo. Diventa fondamentale approfondire le sfide e le strategie di Cloud Native Security per capire come questi requisiti cambieranno il modo in cui orchestriamo e distribuiamo le applicazioni moderne. La sicurezza dell’infrastruttura di base non è più solo una best practice operativa, ma un obbligo di legge certificato.
Quali sono le scadenze e le date da segnare per il Cyber Resilience Act?
Il Cyber Resilience Act prevede un’applicazione graduale per permettere alle aziende di adeguarsi. Le date chiave sono l'11 giugno 2026 per l’operatività degli organismi di valutazione, l'11 settembre 2026 per l’obbligo di notifica delle vulnerabilità, e l'11 dicembre 2027 per la piena conformità dei prodotti.
Il regolamento è ormai in vigore, e le aziende devono iniziare a pianificare l’adeguamento al CRA. Il legislatore ha previsto un periodo di transizione a tappe per permettere al mercato di organizzarsi senza subire blocchi improvvisi.
Ecco le scadenze legali che ogni Project Manager e CTO deve conoscere:
11 giugno 2026: Diventano operative le disposizioni relative agli organismi di valutazione della conformità. Inizierà ufficialmente l’infrastruttura di certificazione per i prodotti di Classe I e II.
11 settembre 2026: Scatta l’obbligo di notifica. I produttori dovranno segnalare alle autorità competenti le vulnerabilità attivamente sfruttate e gli incidenti di sicurezza significativi entro limiti di tempo stringenti.
11 dicembre 2027: Entrano in vigore tutti i requisiti obbligatori per i nuovi prodotti. Da questa data, nessun software soggetto al regolamento potrà essere venduto nell’UE senza dimostrare la piena conformità al CRA.
Da proposta controversa a legge: cosa cambia per l’open source?
Il Cyber Resilience Act esclude esplicitamente dal perimetro normativo diretto il software open source sviluppato al di fuori di logiche commerciali. Questa è una tutela fondamentale per l’ecosistema che sta alla base delle tecnologie Cloud Native e protegge i contributor indipendenti dell’ecosistema open source.
Eppure questa esclusione non è scontata: è il risultato diretto di una forte mobilitazione della community, che ha ottenuto una revisione della proposta originale ed un testo finale molto più equilibrato.
Oggi, la legge fa una distinzione molto chiara e pragmatica. Se un programmatore sviluppa un software o una libreria nel tempo libero e la pubblica online come progetto open source senza fini di lucro, non è soggetto agli obblighi del CRA.
Tuttavia, se un’azienda prende quel progetto gratuito, lo integra nel proprio software proprietario e vende il prodotto finale, l’azienda si assume la totale responsabilità legale della sicurezza di quel componente.
Questo meccanismo sposta la responsabilità esattamente dove risiede il profitto. Le aziende che utilizzano componenti open source per costruire i propri servizi dovranno investire risorse per verificare il codice open source che scelgono di adottare. Un compromesso che tutela i creatori indipendenti obbligando le aziende a fare la loro parte.
SparkFabrik e il #FixTheCRA: quando la community si è fatta sentire
Il raggiungimento di questo equilibrio normativo non è avvenuto per caso. È il risultato di una forte mobilitazione globale in cui la community tecnologica ha fatto sentire la propria voce in modo coeso e strutturato.
Quando il regolamento era ancora in fase di bozza, il testo originale presentava un rischio enorme per l’innovazione. La formulazione iniziale non distingueva in modo chiaro tra il rilascio di codice open source da parte di volontari e l’immissione sul mercato di un prodotto commerciale.
Questo avrebbe reso i contributor upstream legalmente responsabili per le vulnerabilità dei loro progetti, anche quando questi venivano usati da multinazionali per generare profitti.
Comprendendo la gravità della situazione, SparkFabrik e molti altri attori del settore si sono uniti alla campagna #FixTheCRA promossa dalla Linux Foundation Europe. Il nostro obiettivo era chiaro: difendere la competitività europea e sovranità digitale dell’UE senza distruggere il modello collaborativo su cui si basa il software moderno.
Il nostro CTO, Paolo Mainardi, in qualità di Advisory Member della Linux Foundation Europe, ha partecipato attivamente a questo sforzo di advocacy. Abbiamo documentato e diffuso le preoccupazioni della community per l’open source, spiegando ai decisori politici che strangolare i manutentori indipendenti avrebbe reso l’Europa meno sicura, non il contrario.
Questo sforzo riflette il profondo impegno di SparkFabrik nei confronti dell’ecosistema open source, che consideriamo il vero motore dell’innovazione digitale.
La mobilitazione della community ha funzionato, portando a un testo finale molto più equilibrato e consapevole delle dinamiche di sviluppo reali. Anzi: oggi la posizione dell’Europa e delle PA verso l’open source software è sempre più favorevole, riconoscendone l’importanza per gli obiettivi di sovranità digitale.
Cosa significa il CRA per la tua azienda e quali sono i prossimi passi?
Per la tua azienda, il CRA significa dover mappare accuratamente tutto il software prodotto e utilizzato, valutare le classi di rischio e preparare una documentazione trasparente sulle dipendenze. Il primo passo è eseguire un assessment completo per identificare le vulnerabilità attuali.
Il messaggio centrale è inequivocabile: il CRA trasforma la sicurezza informatica da una caratteristica opzionale del prodotto a un requisito legale indispensabile per accedere al mercato europeo. Oggi non è più possibile pensare di rilasciare un software senza pensare anche alla sicurezza, già a partire dalla fase di progettazione.
Il primo passo è comprendere se il tuo prodotto rientra nella normativa e in quale livello di rischio si colloca. Questa mappatura iniziale è fondamentale per evitare di disperdere risorse o, al contrario, sottovalutare obblighi legali stringenti.
Il passo successivo è capire come affrontare l’adeguamento tecnico. Si tratta di un impatto profondo che richiede conoscenze specifiche, dalla gestione sicura delle dipendenze all’implementazione di controlli automatizzati nelle pipeline di rilascio.
Inoltre, non bisogna dimenticare che questa legge non opera in isolamento, fa parte di una strategia europea molto più ampia. L’Unione Europea sta costruendo uno scudo normativo integrato.
Mentre il CRA si concentra sulla sicurezza intrinseca dei prodotti, è fondamentale anche analizzare l’impatto di NIS2 e DORA sulla cybersecurity per comprendere come proteggere le infrastrutture critiche, tenendo sempre d’occhio l’AI Act per i sistemi ad alto rischio.
Per navigare questa complessità e la transizione verso la compliance senza rallentare il time-to-market, è opportuno valutare il supporto di un partner esperto come SparkFabrik, in grado di unire competenze normative e profonda padronanza delle architetture Cloud Native.
A garanzia della nostra competenza in questo ambito, SparkFabrik è in fase di certificazione ISO 27001, lo standard internazionale per la gestione della sicurezza delle informazioni. La sinergia con il CRA è diretta: il risk management e i controlli operativi della ISO 27001 facilitano i risk assessment e il secure lifecycle management obbligatori del CRA. Chi già implementa i processi ISO 27001, infatti, ha un vantaggio significativo per raggiungere la compliance.
Nonostante le sfide tecniche, il Cyber Resilience Act non deve essere vissuto solo come un onere burocratico. Questa transizione è un’opportunità straordinaria per eliminare il debito tecnico, migliorare la stabilità dei prodotti e conquistare la fiducia dei clienti enterprise, trasformando un obbligo di legge in un solido vantaggio competitivo.
Se la tua azienda sviluppa software commerciale o gestisce piattaforme complesse, non aspettare il 2027 per scoprire che la tua architettura non è conforme. Scopri come SparkFabrik può supportarti con il Cyber Resilience Act attraverso servizi di assessment, modernizzazione e implementazione di pipeline sicure by design.
