Immagine di jcomp su Magnific
I produttori di “soluzioni con elementi digitali” (questa la corretta espressione nei regolamenti), che rientrano nell’ambito di applicazione del Cyber Resilience Act, sono tenuti a segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi che ne compromettono la sicurezza. L’obbligo scatta l’11 settembre e la scadenza rientra nel percorso di piena applicazione del Regolamento (UE) 2024/2847, entrato in vigore il 10 dicembre 2024 con l’obiettivo di introdurre requisiti orizzontali di cybersecurity per l’intero ciclo di vita dei prodotti digitali. Per accompagnare i destinatari della norma, nel cuore dell’estate la Commissione Europea ha proposto un documento con le linee guida non vincolanti pensate per assistere operatori economici, autorità di sorveglianza del mercato e organismi notificati. Prima di entrare nei dettagli è importante collegarle a tre date chiave:
- 11 dicembre 2024 segna l’entrata in vigore del Regolamento;
- Dall’11 settembre 2026 si applicano gli obblighi di segnalazione dell’articolo 14;
- L’11 dicembre 2027 segna la data di piena applicazione del Cra, cioè quando scatteranno tutti gli altri obblighi sostanziali (requisiti essenziali, valutazione di conformità, marcatura, gestione delle vulnerabilità).
Il documento chiarisce quindi la ratio di alcune disposizioni chiave e il modo in cui possono essere attuate nella pratica. Non vincola gli operatori – l’interpretazione autentica del testo spetta soltanto alla Corte di giustizia dell’Unione Europea – ma esplicita la lettura della Commissione, corredandola di esempi e casi d’uso.
Il testo si articola in nove sezioni: dopo l’introduzione, si considera in successione l’ambito di applicazione, le specificità per il software libero e open source, quali sono considerabili le modifiche sostanziali, il periodo di supporto, i prodotti importanti e critici, la valutazione del rischio, il remote data processing e, infine, gli elementi aggiuntivi che comprendono gli oneri di segnalazione.
Ambiti di applicazione
La sezione che segue quella introduttiva delimita il perimetro del Regolamento e chiarisce il concetto di immissione sul mercato, già consolidato per i prodotti “tradizionali” dalla Blue Guide sull’attuazione delle norme UE.
La Commissione qualifica anche il software standalone, di natura intangibile: un programma si considera immesso sul mercato quando, terminata la fase di produzione, viene offerto per la prima volta alla distribuzione o all’uso nell’ambito di un’attività commerciale, e tutte le copie identiche si considerano immesse nello stesso istante della prima offerta. Le iterazioni successive costituiscono una nuova immissione soltanto quando configurano una “modifica sostanziale”, mentre le varianti che differiscono per componenti o funzionalità abilitate, come le build per sistemi operativi diversi, vanno trattate come prodotti distinti.
Software libero e open source
La terza sezione, fra le più corpose, affronta il tema del software libero e open source (Foss, Free and Open Source Software), definito come software il cui codice sorgente è apertamente condiviso e disponibile con una licenza che ne garantisce accessibilità, uso, modifica e ridistribuzione.
La guida chiarisce che il Foss è sotto la responsabilità di chi lo pubblica e ne governa sviluppo, rilasci e distribuzione (i maintainer), mentre chi si limita a contribuire con codice resta un contributor non soggetto al Regolamento. Un secondo blocco stabilisce quando un Foss si considera immesso sul mercato, passando in rassegna ipotesi che vanno dalla richiesta di un prezzo alla monetizzazione di servizi collegati, fino alle donazioni e alle entità senza scopo di lucro. Su questo sfondo il documento introduce la figura dell’open-source software steward: una persona giuridica, diversa dal produttore, che sostiene in modo sistematico e continuativo lo sviluppo di un Foss destinato ad attività commerciali senza però immetterlo sul mercato, come nel caso di chi distribuisce una versione “community” gratuita accanto a una versione monetizzata dello stesso software.
Modifiche sostanziali e parti di ricambio
La quarta sezione definisce il concetto di modifica sostanziale, come la variazione che, dopo l’immissione sul mercato, incide sulla conformità del prodotto ai requisiti essenziali oppure ne cambia la destinazione d’uso. È un concetto centrale, perché chi la effettua e rende disponibile il prodotto ne diventa il nuovo produttore. La guida distingue le riparazioni fisiche – rigenerazione, manutenzione e riparazione non comportano automaticamente una modifica sostanziale se non alterano destinazione d’uso, funzionalità e livello di rischio – dal trattamento delle parti di ricambio, per cui un componente identico all’originale non fa scattare nuovi obblighi. Un passaggio specifico riguarda gli aggiornamenti software come possibili modifiche sostanziali e le conseguenze che ne derivano, a seconda che l’intervento sia compiuto dal produttore originario o da un altro soggetto.
Periodo di supporto
La quinta sezione tratta il periodo di supporto, di norma pari ad almeno cinque anni salvo che la vita utile attesa del prodotto sia dimostrabilmente inferiore. Una modifica sostanziale non lo azzera né lo prolunga automaticamente: occorre verificare se incide sui fattori che ne avevano determinato la vita utile attesa. Se l’intervento riguarda il solo software, mentre la durata dipende dalla robustezza dell’hardware, il supporto resta allineato a quello originario; se invece la modifica estende la vita operativa del prodotto, va ricalcolato. La sezione illustra anche il concetto di “flessibilità” per i prodotti software, che consente a determinate condizioni di rimediare alle vulnerabilità solo sull’ultima versione immessa sul mercato, purché gli utenti possano aggiornarsi gratuitamente e senza costi aggiuntivi.
Prodotti importanti e critici con elementi digitali
La sesta sezione affronta la classificazione dei prodotti importanti – suddivisi in classe I e classe II ed elencati nell’Allegato III – e di quelli critici, contenuti nell’Allegato IV. Dalla classificazione dipende la procedura di valutazione della conformità: i prodotti della categoria “default” possono ricorrere all’autovalutazione, mentre le classi superiori richiedono procedure più stringenti, spesso con il coinvolgimento di un organismo terzo. Il criterio dirimente è la funzionalità di base, ossia le caratteristiche principali senza le quali il prodotto non assolverebbe la propria destinazione d’uso: un concetto non definito nel Regolamento che la guida precisa con numerosi esempi. La Commissione chiarisce che la semplice integrazione di un prodotto importante o critico in un altro non ne modifica la classificazione, e che il produttore non può rappresentarne in modo distorto la funzionalità di base per sottrarsi al regime più severo.
Valutazione del rischio e integrazione di più prodotti
La settima sezione riguarda la valutazione del rischio prevista dall’articolo 13(2) e l’integrazione di prodotti e componenti. Il documento fissa un principio netto: la tolleranza interna al rischio, la strategia commerciale o le sole considerazioni di costo non sono elementi rilevanti per stabilire se i rischi siano stati affrontati. Il rischio residuo è fisiologico, ma il prodotto può essere immesso sul mercato solo se, adottate le misure appropriate, quel rischio risulta sufficientemente trattato; il Regolamento non ammette il trasferimento della responsabilità agli utenti per compensare carenze di progettazione. Quando integra componenti di terzi, il produttore deve esercitare la due diligence e verificarne l’idoneità; per famiglie di prodotti che condividono architettura, progettazione security-relevant e destinazione d’uso sono ammessi una sola valutazione, un unico fascicolo tecnico e un’unica dichiarazione di conformità, purché le differenze rilevanti sul piano della sicurezza siano riflesse nella documentazione.
Remote data processing
L’ottava sezione è dedicata alle soluzioni di remote data processing (Rdps), incluse nel perimetro del prodotto. La guida offre un percorso per stabilire se un prodotto le comprenda, poggiato su tre elementi cumulativi: che il trattamento avvenga “a distanza”; che la sua assenza impedisca al prodotto di svolgere una delle proprie funzioni; e che il software sia progettato e sviluppato dal produttore o sotto la sua responsabilità. Un Rdps non deve necessariamente girare su cloud di terzi: anche una soluzione ospitata su server locali o su cloud privato nella sede del produttore può rientrare nella definizione. Tra le funzioni la cui assenza pregiudicherebbe il prodotto figurano l’invio di comandi a un dispositivo, la sincronizzazione dei file, la configurazione e la distribuzione automatizzata degli aggiornamenti, mentre resta fuori l’analisi remota di dati di telemetria a soli fini statistici. La sezione chiude con casi d’uso: dal mobile banking al termostato smart, dal robot industriale alla rete cellulare, che mostrano come applicare i criteri.
Oneri di segnalazione, gestione delle vulnerabilità e interplay
La nona sezione raccoglie gli elementi aggiuntivi e contiene il cuore delle disposizioni per la scadenza dell’11 settembre. In base all’articolo 14, il produttore deve notificare contemporaneamente al Csirt designato come coordinatore e all’Enisa sia le vulnerabilità attivamente sfruttate sia gli incidenti gravi che compromettono la sicurezza del prodotto. La notifica segue tempi progressivi: un preallarme entro 24 ore dal momento in cui il produttore ne diventa consapevole, una notifica più dettagliata entro 72 ore e un rapporto completo entro 14 giorni dalla disponibilità di una misura correttiva per le vulnerabilità, o entro un mese dalla notifica delle 72 ore per gli incidenti gravi.
Sul fronte della gestione delle vulnerabilità, si impone di segnalare a monte quelle presenti nei componenti integrati e di condividere con chi li mantiene le eventuali correzioni. L’ultima parte tratta l’interplay con le altre normative: sono esclusi dal Regolamento i prodotti soggetti alle norme sull’omologazione dei veicoli, mentre i certificati di esame UE del tipo relativi ad altre legislazioni armonizzate restano validi fino all’11 giugno 2028.
Gli orientamenti interpretativi trasversali
Al di là della struttura per sezioni, alcuni orientamenti attraversano l’intero documento. Il primo è la centralità dell’immissione sul mercato come momento in cui scattano gli obblighi, estesa anche al software intangibile. Il secondo è la nozione di “consapevolezza”, che fissa il momento da cui decorrono i termini di notifica: il produttore è tenuto ad attivarsi dopo una valutazione iniziale che gli offra un ragionevole grado di certezza sullo sfruttamento della vulnerabilità o sul verificarsi dell’incidente, senza obbligo di segnalazione retroattiva per gli sfruttamenti già noti prima dell’11 settembre 2026. Un terzo distingue il perimetro degli oneri di notifica da quello degli obblighi di gestione delle vulnerabilità: questi ultimi durano solo per il periodo di supporto e non si applicano ai prodotti immessi prima dell’11 dicembre 2027 o con supporto terminato, mentre la segnalazione continua a valere anche dopo la fine del supporto. Restano infine aperti, per possibili linee guida future, i rapporti con l’AI Act e con il regolamento Dora per il settore finanziario.
© RIPRODUZIONE RISERVATA
