La Commissione Europea ha pubblicato la sua Guida ufficiale per l’applicazione del Cyber Resilience Act (CRA, Regolamento UE 2024/2847), prima normativa che, in seno al più ampio pacchetto normativo europeo sulla cybersecurity, si applica in maniera trasversale a tutti i prodotti con elementi digitali, software, hardware e applicazioni, definendo i requisiti di sicurezza cyber per questi prodotti. Entrato in vigore lo scorso 10 dicembre 2024, il Regolamento avrà piena applicazione a partire dall’11 dicembre 2027.
Il CRA si applica dunque a una vasta e variegata gamma di tecnologie che possiedano elementi digitali, quindi software, applicazioni, dispositivi connessi e sistemi IoT, dotati di una connessione dati diretta o indiretta a un dispositivo o a una rete. Diversi sono quindi gli obblighi che il CRA impone a carico dei produttori, spostando su di essi la responsabilità della sicurezza di quanto producono, includendo la valutazione dei rischi, l’elaborazione della documentazione tecnica, la dichiarazione di conformità e la marcatura CE, secondo un principio di security-by-design e security-by-default. In tal senso, il regolamento impone ai produttori di impegnarsi a integrare misure di sicurezza adeguate fin dalle fasi di progettazione, garantendo un livello adeguato di sicurezza informatica al momento di immissione del prodotto sul mercato.
Una delle principali novità del CRA è quindi l’estensione degli obblighi di sicurezza dei prodotti digitali oltre la loro prima immissione sul mercato, coprendo l’intero ciclo di vita. In particolare, ai produttori vengono richiesti tre ulteriori adempimenti: garantire una gestione continua delle vulnerabilità, assicurare il rilascio obbligatorio di aggiornamenti di sicurezza per tutta la durata del prodotto e notificare tempestivamente alle autorità competenti eventuali incidenti di sicurezza rilevanti.
Tra le novità contenute nel documento, la Guida procede quindi a chiarire innanzitutto cosa si debba intendere per ‘prodotti con elementi digitali’: questi sono app e programmi software standalone, hardware con software integrato (IoT), hardware standalone come circuiti integrati e schede madri e, infine, qualsiasi combinazione di hardware/software forniti separatamente ma progettati per operare insieme. Il criterio discriminante è la capacità del prodotto di scambiare ‘informazioni digitali’; il che comporta l’esistenza di una connessione dati, diretta o indiretta, logica o fisica, a un dispositivo o a una rete. Altresì, viene chiarito come per parlare di data connection, e quindi far scattare gli obblighi del CRA, occorre che i segnali generati dal prodotto siano codificati deliberatamente come informazione da una sorgente, e quindi decodificati come tale dalla destinazione, veicolando dunque l’informazione. Ad esempio, un termostato base, che trasmette un segnale elettrico per aprire o chiudere un circuito, non rientra nel perimetro della normativa. Vi rientra invece se lo stesso comunica con una app via wi-fi.
Altro concetto chiave su cui la Commissione offre delucidazioni è quello del momento della ‘immissione sul mercato’ del prodotto, in particolare per la fattispecie del software standalone. Per questa tipologia di software, non avendo supporto fisico, né stock, né logistica, ogni download genera di fatto una nuova copia identica del file originario. Il software standalone si considera quindi immesso sul mercato nel momento in cui il produttore lo rende disponibile per la prima volta, a fini di distribuzione o utilizzo nel mercato dell’Unione Europea, nell’ambito di un’attività commerciale. Per quanto invece concerne gli aggiornamenti successivi alla immissione sul mercato, se la nuova versione non costituisce una modifica sostanziale del software, la data di immissione sul mercato non cambia. Se la modifica invece è da considerarsi sostanziale, le iterazioni del software vengono considerate come un nuovo prodotto, implicando una nuova data di immissione e per il produttore un nuovo obbligo di valutazione della conformità.
Rilevante è quindi capire in cosa consista una modifica sostanziale per il software iterativo: si definisce come ‘sostanziale’ la modifica che incide sulla conformità del prodotto ai requisiti essenziali di cybersecurity, oppure che vada a modificare la finalità d’uso per cui il prodotto era stato valutato. La Guida aiuta in tal senso con alcuni criteri pratici, per cui una modifica è sostanziale quando:
- introduce nuovi vettori di minaccia (es. interfacce aggiuntive, canali di comunicazione, ambienti di esecuzione, dipendenze esterne attraverso cui le minacce potrebbero concretizzarsi);
- abilita nuovi scenari di attacco (es. nuove modalità in cui potrebbe verificarsi accesso non autorizzato, manipolazione, interferenza o uso improprio);
- aumenta la probabilità di scenari già identificati (es. abbassando le competenze richieste per sfruttarli, aumentando l’esposizione ad attori non fidati, indebolendo le salvaguardie esistenti);
- aumenta l’impatto potenziale degli scenari esistenti (ampliando i dati o le funzioni coinvolte, aggravando le conseguenze operative).
Al contrario, aggiornamenti di sicurezza che non vanno a introdurre nuove funzionalità né nuove finalità d’uso, non aggiungono nuovi rischi e non sarebbero da considerarsi come sostanziali.
Un capitolo a parte riguarda quindi il software libero e open source (FOSS, Free and Open Source Software): sebbene infatti il CRA si applichi a prodotti immessi sul mercato nel corso di un’attività commerciale, la monetizzazione legata a un software open source fa scattare l’attività commerciale, andando a far ricadere anche il FOSS nel perimetro del Regolamento. La monetizzazione può infatti assumere forme non subito evidenti: secondo la Guida, un FOSS si considera dunque ‘immesso sul mercato’ ad esempio se si addebita un prezzo per l’utilizzo di alcune sue funzionalità, se lo distribuisce tramite una piattaforma che monetizza altri prodotti o servizi, se condiziona l’accesso al software alla raccolta di dati personali per fini diversi dalla sicurezza, compatibilità o interoperabilità dello stesso, o ancora se offre accesso a versioni specifiche con benefici aggiuntivi su base remunerativa (es. assistenza tecnica o ottimizzazione delle prestazioni).
La Guida chiarisce infine che cinque anni è il periodo di supporto minimo durante il quale i produttori devono garantire una gestione efficace delle vulnerabilità del prodotto. Oltre questo periodo minimo di default, i produttori devono quindi determinare periodi di supporto più lunghi e appropriati in base a una serie di criteri, tra cui ovviamente la natura del prodotto e il periodo di vita atteso. Ancora, in tema di obbligo di segnalazione di eventuali incidenti, il CRA impone vengano notificati simultaneamente al CSIRT e all’ENISA le vulnerabilità sfruttate attivamente e gli incidenti gravi che impattano la sicurezza del prodotto. Serrate sono le tempistiche: early warning entro le 24 ore, notifica completa entro 72 ore, report finale entro 14 giorni (per le vulnerabilità sfruttate) o un mese (per incidenti gravi). La Commissione chiarisce quindi che a definire il termine di decorrenza dei tempi è la ‘consapevolezza’ acquisita dal produttore: allineandosi con quanto previsto per GDPR e NIS2, ciò comporta che la ricezione esterna di una segnalazione non fa scattare subito la decorrenza del termine. Serve prima un’analisi preliminare, necessaria a far sì che il produttore maturi consapevolezza e un ragionevole grado di certezza che sia stata sfruttata una determinata vulnerabilità del suo prodotto, o che un incidente grave ne abbia compromesso la sicurezza.
Sotto, infine, un utile confronto tra gli ambiti applicativi e le caratteristiche salienti di tre direttive europee sulla cybersecurity, che mostra come NIS2, CER (Critical Entities Resilience) e CRA siano fortemente complementari fra loro.
