Il Cyber Resilience Act (Reg. UE 2024/2847) impone obblighi diretti ai produttori di prodotti con elementi digitali, ma coinvolge indirettamente anche gli studi legali come acquirenti, integratori e consulenti dei propri clienti. Chi assiste aziende tech, software house o rivenditori deve già oggi mappare quali prodotti rientrano nel perimetro e quali adempimenti scattano entro settembre 2026. Le linee guida della Commissione UE pubblicate nel 2025 chiariscono ambito, esenzioni e soglie.
Punti chiave
- Punto 1 — Il Reg. UE 2024/2847 si applica a prodotti con elementi digitali immessi sul mercato UE dopo l’11 dicembre 2027.
- Punto 2 — I fornitori di software open source senza scopo commerciale sono esclusi, ma le eccezioni vanno verificate caso per caso.
- Punto 3 — Le modifiche sostanziali al prodotto riavviano il ciclo di conformità e la valutazione del rischio va aggiornata.
Gli studi legali che assistono clienti nel settore tech, manifatturiero connesso o distribuzione software devono oggi rispondere a una domanda concreta: i prodotti del cliente rientrano nel perimetro del Cyber Resilience Act? La risposta sbagliata espone il cliente a sanzioni fino al 2,5% del fatturato mondiale annuo o 15 milioni di euro, la cifra più alta tra le due. Non è più un tema da rimandare al reparto IT.
La Commissione europea ha pubblicato linee guida operative sul Cyber Resilience Act (Reg. UE 2024/2847) che chiariscono ambito applicativo, trattamento dell’open source, soluzioni cloud, modifiche sostanziali e obblighi di segnalazione delle vulnerabilità. Il regolamento è già in vigore; le prime scadenze operative scattano nel settembre 2026.
Il contesto normativo
Il Reg. UE 2024/2847, pubblicato in Gazzetta Ufficiale UE il 20 novembre 2024 ed entrato in vigore il 10 dicembre 2024, disciplina i requisiti di cybersicurezza per i prodotti con elementi digitali (PED) immessi sul mercato dell’Unione. L’art. 3 del regolamento definisce il perimetro: rientrano tutti i prodotti software e hardware connessi direttamente o indirettamente a una rete, con esclusioni tassative per dispositivi medicali (già coperti dal Reg. UE 2017/745), aeronautica e difesa. L’art. 13 fissa gli obblighi del fabbricante — valutazione del rischio, documentazione tecnica, dichiarazione di conformità — mentre l’art. 14 disciplina la segnalazione obbligatoria delle vulnerabilità attivamente sfruttate all’ENISA entro 24 ore dalla scoperta. Il coordinamento con il d.lgs. 138/2024 (recepimento NIS2) è diretto: le entità essenziali e importanti già soggette a NIS2 troveranno sovrapposizioni negli obblighi di incident reporting.
Cosa cambia per lo studio
- Due diligence sui fornitori software del cliente. Se assisti un’azienda che acquista o integra prodotti digitali di terzi, devi verificare che il fornitore abbia rilasciato la dichiarazione di conformità UE prevista dall’art. 13, par. 12. Contratti di fornitura privi di questa clausola espongono il cliente a responsabilità solidale in caso di audit.
- Gestione delle modifiche sostanziali. Le linee guida chiariscono che una modifica sostanziale — aggiornamento che altera le funzionalità di sicurezza o introduce nuovi vettori di rischio — riavvia l’intero ciclo di valutazione della conformità. Nei contratti di sviluppo software, inserisci clausole che obblighino il fornitore a notificare ogni modifica rilevante e a documentarla.
- Software open source e responsabilità. Il regolamento esclude i maintainer open source che operano senza scopo commerciale, ma l’esenzione non si applica se il software è distribuito nell’ambito di un’attività commerciale. Nelle consulenze a startup che rilasciano codice open source, verifica sempre il modello di business prima di dichiarare l’esenzione.
- Periodi di supporto contrattuali. L’art. 13 impone che il produttore garantisca aggiornamenti di sicurezza per un periodo commisurato alla vita attesa del prodotto, con un minimo di 5 anni. Nei contratti di licenza software, controlla che questa garanzia sia esplicitata: la sua assenza può configurare inadempimento contrattuale ai sensi dell’art. 1453 c.c.
- Obblighi di segnalazione rapida. Le vulnerabilità attivamente sfruttate vanno segnalate all’ENISA entro 24 ore. Assisti il cliente a costruire una procedura interna documentata: in caso di contenzioso, la traccia dimostra la diligenza richiesta e può escludere la responsabilità ex art. 2050 c.c. per attività pericolosa.
Attenzione a
Confondere l’ambito CRA con NIS2. NIS2 (d.lgs. 138/2024) riguarda le organizzazioni che gestiscono infrastrutture; il CRA riguarda i prodotti con elementi digitali. Un’azienda può essere soggetta a entrambi i regimi — e spesso lo è — ma gli obblighi non si sovrappongono perfettamente. Applicare solo la checklist NIS2 pensando di coprire anche il CRA è un errore che genera lacune di conformità difficili da giustificare in sede ispettiva.
Sottovalutare le soluzioni di elaborazione remota. Le linee guida della Commissione confermano che il software erogato come servizio cloud (SaaS) può rientrare nel perimetro se l’elaborazione remota è necessaria al funzionamento del prodotto. Non basta qualificare il prodotto come «servizio» per uscire dall’ambito: la valutazione va condotta sulla funzione tecnica, non sull’etichetta commerciale.
Domande frequenti
Il software SaaS rientra nel Cyber Resilience Act?
Dipende dalla funzione tecnica, non dall’etichetta commerciale. Le linee guida della Commissione UE chiariscono che se l’elaborazione remota è necessaria al funzionamento del prodotto, il SaaS rientra nel perimetro del Reg. UE 2024/2847. Qualificare il prodotto come “servizio” non è sufficiente per escluderlo: occorre analizzare l’architettura tecnica caso per caso prima di esprimere un parere definitivo al cliente.
Quando scattano le prime scadenze operative del Cyber Resilience Act?
Il Reg. UE 2024/2847 è in vigore dal 10 dicembre 2024. Gli obblighi di segnalazione delle vulnerabilità all’ENISA diventano applicabili a settembre 2026, mentre la piena applicabilità del regolamento — inclusa la conformità dei prodotti — scatta l’11 dicembre 2027. Le aziende che immettono oggi prodotti sul mercato devono però avviare subito la valutazione del rischio per rispettare i tempi tecnici di adeguamento.
Il software open source è escluso dal Cyber Resilience Act?
Solo in parte. Il Reg. UE 2024/2847 esclude i maintainer open source che operano senza scopo commerciale. Se però il software open source viene distribuito nell’ambito di un’attività commerciale — anche indirettamente, ad esempio come componente di un prodotto commerciale — l’esenzione non si applica. Per i clienti startup o ISV che rilasciano codice open source, verifica sempre il modello di business prima di confermare l’esclusione dal perimetro.
Fonte di riferimento: AgendaDigitale