Dal 27 settembre 2026 trova applicazione il D.Lgs. 20 febbraio 2026, n. 30, e con esso la disciplina del software compie un altro passo avanti.
Fino a oggi le regole sul software hanno parlato soprattutto a chi lo progetta e lo immette sul mercato: requisiti essenziali, valutazione della conformità, marcatura CE. Così il Regolamento (UE) 2017/745 (MDR) per il software dispositivo medico, il Regolamento (UE) 2024/1689 (AI Act) per i sistemi di intelligenza artificiale, il Regolamento (UE) 2024/2847 (Cyber Resilience Act, di seguito CRA) per i prodotti con elementi digitali.
Indice degli argomenti
D.Lgs. 30/2026 e aggiornamenti software: dalla produzione alla commercializzazione
Il D.Lgs. 30/2026, che recepisce la Direttiva (UE) 2024/825 e modifica il Codice del consumo, sposta il fuoco sulla commercializzazione. Chi vende al consumatore beni con elementi digitali, contenuti digitali o servizi digitali deve indicare, prima della conclusione del contratto, per quanto tempo il produttore o il fornitore garantisce gli aggiornamenti software. E diventano pratiche ingannevoli in ogni caso alcune condotte legate proprio agli aggiornamenti.
Il filo che tiene insieme le due prospettive è il ciclo di vita del prodotto.
Il software non si esaurisce con la consegna: vive, si aggiorna, si espone a vulnerabilità e prima o poi esce dall’assistenza. Le regole di produzione ne governano l’inizio; quelle di commercializzazione devono ora dirne la durata.
Il decreto, però, chiede di informare. Non obbliga nessuno a decidere.
A decidere obbligherà il CRA, dall’11 dicembre 2027, quando ogni fabbricante di prodotti con elementi digitali dovrà stabilire un periodo di assistenza e dichiararne la data finale al momento dell’acquisto.
Vediamo allora cosa dice oggi il D.Lgs. 30/2026, perché il suo obbligo rischia di restare sulla carta, e come il CRA è destinato a riempirlo di contenuto.
Il D.Lgs. 30/2026: cosa cambia dal 27 settembre
Il D.Lgs. 20 febbraio 2026, n. 30 (pubblicato in Gazzetta Ufficiale n. 56 del 9 marzo 2026 ed entrato in vigore il 24 marzo 2026) si applica, per espressa previsione dell’art. 2, «a decorrere dal 27 settembre 2026».
Il decreto è noto soprattutto per il capitolo greenwashing (asserzioni ambientali generiche, etichette di sostenibilità, compensazione delle emissioni). Qui interessa invece l’altra metà del provvedimento, quella che riguarda la durabilità e il software.
Il decreto lavora su due piani distinti, che è bene tenere separati perché hanno destinatari diversi.
L’informazione precontrattuale
Il primo piano è quello dell’informazione precontrattuale.
Il nuovo art. 48, comma 1, lett. e-quinquies), Cod. cons. (per i contratti diversi da quelli a distanza o negoziati fuori dei locali commerciali) e il nuovo art. 49, comma 1, lett. n-quater), Cod. cons. (per i contratti a distanza e negoziati fuori dei locali commerciali) impongono di indicare (nella formulazione dell’art. 48) «per i beni comprendenti elementi digitali, per i contenuti digitali e per i servizi digitali, se il produttore o il fornitore mette a disposizione dell’operatore economico le informazioni, il periodo minimo, sia esso espresso mediante un termine o con riferimento a una data, per il quale il produttore o il fornitore fornisce aggiornamenti del software».
Le pratiche commerciali
Il secondo piano è quello delle pratiche commerciali.
L’art. 23, comma 1, Cod. cons. (le pratiche considerate in ogni caso ingannevoli) si arricchisce di due ipotesi specifiche: la lett. bb-quinquies) vieta di «non informare il consumatore del fatto che un dato aggiornamento del software inciderà negativamente sul funzionamento di beni che comprendono elementi digitali o sull’uso del contenuto digitale o dei servizi digitali»; la lett. bb-sexies) vieta di «presentare come necessario un aggiornamento del software che si limita a migliorare alcune caratteristiche di funzionalità». Accanto a queste, la lett. bb-septies) colpisce la comunicazione commerciale relativa a un bene che contiene una caratteristica introdotta per limitarne la durabilità: la cosiddetta obsolescenza programmata, che nel mondo connesso passa quasi sempre dal software.
Completa il quadro la nuova definizione di «aggiornamento del software» (art. 18, comma 1, lett. n-decies), e art. 45, comma 1, lett. p-quinquies), Cod. cons.), che comprende sia l’aggiornamento necessario a mantenere la conformità del bene, del contenuto o del servizio digitale – «compreso un aggiornamento di sicurezza» – sia l’aggiornamento delle funzionalità.
Chi è tutelato: consumatori e (solo in parte) microimprese
Qui serve una precisazione, perché i due piani appena descritti non hanno lo stesso ambito soggettivo.
Gli obblighi di informazione precontrattuale degli artt. 48 e 49 si applicano ai soli contratti tra professionista e consumatore (art. 46, comma 1, Cod. cons.). Le microimprese restano fuori.
I divieti dell’art. 23 si collocano invece nel titolo sulle pratiche commerciali scorrette, che per l’art. 19, comma 1, Cod. cons. si applica anche «alle pratiche commerciali scorrette tra professionisti e microimprese».
In sostanza: la software house che vende un gestionale a uno studio professionale con tre dipendenti non deve indicargli il periodo minimo di aggiornamenti; ma se gli presenta come «necessario» un aggiornamento che è solo migliorativo, commette una pratica ingannevole.
Due precisazioni ulteriori sull’ambito oggettivo.
In primo luogo, il perimetro non è il «software venduto» in senso stretto: la norma si riferisce più in generale a beni con elementi digitali, contenuti digitali e servizi digitali, e dunque copre anche l’app scaricata e il servizio in abbonamento.
In secondo luogo, per effetto dell’art. 46, comma 1-bis, Cod. cons., gli obblighi informativi si applicano anche quando il consumatore non paga un prezzo ma fornisce dati personali, salvo che questi siano trattati esclusivamente per fornire il servizio o per adempiere obblighi di legge. L’app «gratuita» che monetizza i dati non è quindi esente.
Quanto alla vigilanza, la competenza è dell’Autorità Garante della Concorrenza e del Mercato, sia per le pratiche commerciali (art. 27 Cod. cons.) sia per gli obblighi informativi (art. 66, comma 2, Cod. cons.), con sanzioni fino a 10 milioni di euro (art. 27, comma 9) e, nei casi di infrazioni diffuse ai sensi del Regolamento (UE) 2017/2394, fino al 4% del fatturato annuo realizzato in Italia o negli Stati membri interessati dalla violazione (art. 27, comma 9-bis).
Aggiornamenti software: un obbligo informativo condizionato
Veniamo al punto che appare più critico.
L’obbligo di indicare il periodo minimo di aggiornamenti è condizionato: scatta solo «se il produttore o il fornitore mette a disposizione dell’operatore economico» l’informazione.
Il D.Lgs. 30/2026 non obbliga dunque il produttore a garantire aggiornamenti per un determinato periodo, né a dichiararne la durata. Obbliga il venditore a riferire il dato, se lo ha.
Il produttore che non comunica nulla lascia il distributore senza nulla da riferire.
La scelta è coerente con l’impianto della Direttiva (UE) 2024/825, che lavora sulla trasparenza e non impone requisiti di prodotto. Ma ha una conseguenza pratica evidente: finché nessuna norma di prodotto obbliga il fabbricante a stabilire e dichiarare un periodo di aggiornamento, l’informazione al consumatore dipende dalla sua scelta volontaria.
Ciò non toglie che un obbligo di aggiornamento esista già, e da tempo.
Dal 1° gennaio 2022, per effetto dei D.Lgs. 4 novembre 2021, n. 170 e n. 173, l’art. 130, comma 2, Cod. cons. (per i beni con elementi digitali) e l’art. 135-undecies, comma 1, Cod. cons. (per contenuti e servizi digitali) obbligano il venditore o il professionista a tenere informato il consumatore sugli aggiornamenti disponibili, «anche di sicurezza», necessari a mantenere la conformità, ed altresì a fornirglieli. Per le forniture una tantum, il periodo di riferimento è quello che il consumatore «può ragionevolmente aspettarsi», formula elastica, che finora ha lasciato ampio margine di incertezza.
Il quadro nazionale, quindi, oggi è questo: l’obbligo di aggiornamento c’è, ma ha una durata indeterminata; l’obbligo di informare sulla durata c’è, ma dipende dal fatto che il produttore la comunichi al distributore.
Manca il tassello che obblighi qualcuno a fissare quella durata. È il tassello che fornirà il CRA.
Il CRA dall’11 dicembre 2027: il periodo di assistenza diventa un obbligo di prodotto
L’art. 71, par. 2, CRA fissa l’applicazione generale del regolamento all’11 dicembre 2027 (con l’anticipo per l’art. 14 efficace dall’11 settembre 2026 sulle notifiche degli incidenti e per il capo IV sulla notifica degli organismi di valutazione della conformità all’11 giugno 2026). Da quella data diventano operativi gli obblighi dei fabbricanti dell’art. 13, e tra questi quello che qui interessa.
L’art. 13, par. 8, CRA obbliga infatti il fabbricante a garantire che, all’atto dell’immissione sul mercato e per la durata del periodo di assistenza, le vulnerabilità del prodotto siano gestite in conformità dei requisiti dell’Allegato I, parte II. E, soprattutto, gli impone di determinare quel periodo.
Il criterio è fissato dalla norma: il periodo di assistenza deve riflettere «la durata di utilizzo prevista del prodotto, tenendo conto, in particolare, delle ragionevoli aspettative degli utilizzatori, della natura del prodotto, compresa la sua finalità prevista, nonché del pertinente diritto dell’Unione che determina la durata di vita dei prodotti con elementi digitali». Il fabbricante può considerare anche i periodi di assistenza di prodotti analoghi di altri fabbricanti, la disponibilità dell’ambiente operativo e i periodi di assistenza dei componenti di terzi che forniscono funzioni essenziali.
Il periodo di assistenza deve essere poi «di almeno cinque anni», salvo che il prodotto sia destinato a essere utilizzato per meno di cinque anni, nel qual caso corrisponde alla durata di utilizzo prevista. La Commissione può inoltre, con atti delegati, specificare periodi minimi per determinate categorie di prodotti, se i dati di vigilanza del mercato ne mostrano l’inadeguatezza. Le informazioni considerate per determinare il periodo entrano nella documentazione tecnica (Allegato VII).
La data finale del periodo di assistenza
Il periodo, però, non resta un dato interno.
L’art. 13, par. 19, CRA impone al fabbricante di garantire che la data finale del periodo di assistenza, «comprendente almeno il mese e l’anno», sia «specificata in modo chiaro e comprensibile al momento dell’acquisto in modo facilmente accessibile e, se del caso, sul prodotto con elementi digitali, sul suo imballaggio o con mezzi digitali». Il secondo comma aggiunge che, ove tecnicamente fattibile, il fabbricante notifica agli utilizzatori il raggiungimento della fine del periodo di assistenza.
Completa il quadro l’art. 13, par. 9, CRA: ogni aggiornamento di sicurezza messo a disposizione durante il periodo di assistenza deve restare disponibile per almeno dieci anni dal rilascio, o per il restante periodo di assistenza se superiore.
In sostanza, dal dicembre 2027 il fabbricante non potrà più scegliere se avere un periodo di aggiornamento di sicurezza: dovrà stabilirlo, motivarlo, documentarlo e dichiararlo.
Dove D.Lgs. 30/2026 e CRA si incontrano: il periodo di assistenza
Torniamo alla condizione dell’art. 48, lett. e-quinquies), e dell’art. 49, lett. n-quater), Cod. cons.: il periodo minimo di aggiornamenti va comunicato al consumatore «se» il produttore lo mette a disposizione.
Il CRA è la norma di prodotto che, dall’11 dicembre 2027, rende quel dato obbligatorio.
A parere di chi scrive, da quel momento la condizione posta dal Codice del consumo sarà di fatto sempre soddisfatta per i prodotti soggetti al CRA: il dato esisterà necessariamente, sarà dichiarato al momento dell’acquisto, e il distributore che vende al consumatore non potrà sostenere di non averlo ricevuto. Quello che oggi è un obbligo informativo eventuale diventerà, per questi prodotti, un obbligo sistematico.
C’è di più. Le due discipline parlano, quasi con le stesse parole, di aspettative.
L’art. 13, par. 8, CRA chiede di determinare il periodo di assistenza tenendo conto delle «ragionevoli aspettative degli utilizzatori»; gli artt. 130, comma 2, e 135-undecies, comma 1, Cod. cons. misurano l’obbligo di aggiornamento sul periodo che il consumatore «può ragionevolmente aspettarsi». A parere di chi scrive, la data di fine assistenza dichiarata ai sensi del CRA è destinata a diventare il parametro di riferimento anche per il Codice del consumo: è difficile immaginare che un giudice o l’AGCM considerino ragionevole un’aspettativa di aggiornamento inferiore alla durata che lo stesso fabbricante ha dichiarato.
Aggiornamenti di sicurezza e aggiornamenti funzionali
Le due nozioni, però, non coincidono.
Il periodo di assistenza del CRA riguarda la gestione delle vulnerabilità (Allegato I, parte II): è un periodo di sicurezza. L’«aggiornamento del software» del Codice del consumo comprende anche gli aggiornamenti funzionali e quelli necessari alla conformità contrattuale. Un prodotto può quindi ricevere patch di sicurezza per cinque anni e nessuna nuova funzionalità dopo il secondo. Chi redige l’informativa precontrattuale dovrà evitare di presentare il periodo di assistenza CRA come periodo di aggiornamento in generale, per non scivolare proprio in una delle pratiche ingannevoli che il D.Lgs. 30/2026 ha appena introdotto.
Un’ultima notazione sulla filiera.
I tre obblighi gravano su soggetti diversi: il periodo di assistenza sul fabbricante (CRA), l’informazione precontrattuale sul professionista che conclude il contratto con il consumatore (artt. 48 e 49 Cod. cons.), l’obbligo di fornire gli aggiornamenti sul venditore (art. 130 Cod. cons.). Soggetti che possono ovviamente coincidere, ma non necessariamente. Le informazioni devono quindi scorrere lungo la catena distributiva, e questo è un tema contrattuale ancor prima che regolatorio.
Sanità digitale: dispositivi medici fuori dal CRA, wearable e app dentro entrambe le discipline
Per chi opera in sanità digitale il quadro si complica, e merita quindi una lettura dedicata.
L’art. 2, par. 2, lett. a) e b), CRA esclude dal proprio ambito i prodotti con elementi digitali cui si applicano il Regolamento (UE) 2017/745 (MDR) e il Regolamento (UE) 2017/746 (IVDR). Il software dispositivo medico e i dispositivi medici connessi restano quindi soggetti ai requisiti di cibersicurezza dell’MDR e dell’IVDR, e non conosceranno il periodo di assistenza dell’art. 13, par. 8, CRA.
Diverso il caso dei prodotti che si collocano sul confine: wearable per il benessere, app di fitness o di monitoraggio degli stili di vita, dispositivi connessi per la casa che non hanno destinazione d’uso medica. Questi prodotti non sono dispositivi medici, ricadono nel CRA e, se venduti al consumatore, nelle nuove regole del Codice del consumo: dal 2027 avranno un periodo di assistenza obbligatorio e dichiarato, destinato a confluire nell’informativa precontrattuale.
La qualificazione del prodotto, che nel mondo della sanità digitale è già decisiva per l’MDR, diventa così determinante anche per stabilire se il fabbricante sarà obbligato a fissare e dichiarare un periodo di assistenza.
Quanto al Codice del consumo, va ricordato che l’art. 47, comma 1, lett. b), esclude dalle sezioni da I a IV (e quindi anche dagli artt. 48 e 49) i contratti di assistenza sanitaria per i servizi prestati da professionisti sanitari a pazienti, «ivi compresa la prescrizione, la somministrazione e la fornitura di medicinali e dispositivi medici». La terapia digitale prescritta e fornita nell’ambito del rapporto di cura resta quindi fuori dagli obblighi informativi. A parere di chi scrive, non vale lo stesso per il software dispositivo medico acquistato direttamente dal consumatore, al di fuori di qualunque rapporto con un professionista sanitario: qui l’esclusione non sembra operare, e l’informazione sul periodo minimo di aggiornamenti torna dovuta (se il fabbricante l’ha resa disponibile). Si tratta di un punto su cui manca, allo stato, qualunque indicazione applicativa. E, per il software dispositivo medico, il CRA non interverrà a rendere quel dato obbligatorio.
I divieti di pratiche ingannevoli dell’art. 23 non conoscono invece questa esclusione.
Il ciclo di vita del software, dalla produzione alla vendita
Il messaggio di questo settembre è chiaro: il legislatore europeo ha smesso di considerare il software come un bene che si esaurisce con la consegna.
Lo guarda come un prodotto che vive, si aggiorna, si espone a vulnerabilità e prima o poi esce dall’assistenza. Oggi, con il D.Lgs. 30/2026, pretende che la durata di quella vita sia comunicata al consumatore, quando è nota. Dal dicembre 2027, con il CRA, pretenderà che sia decisa, documentata e dichiarata.
Il diritto dei consumatori e il diritto della sicurezza dei prodotti, fino a ieri paralleli, convergono così sullo stesso dato: per quanto tempo quel software sarà mantenuto. Chi lo governa in modo unitario (una sola politica di aggiornamento, un solo dato dichiarato, coerente in tutti i documenti) si protegge su entrambi i fronti. Chi lo gestisce a compartimenti stagni, tra ufficio legale, marketing e sviluppo, rischia di dichiarare al consumatore una cosa e all’autorità di vigilanza un’altra.
Per chi produce e distribuisce software la conseguenza pratica è una sola: il periodo di aggiornamento va trattato fin da ora come una decisione aziendale, da prendere una volta, motivare e far scorrere lungo tutta la filiera, dal contratto di fornitura alla scheda prodotto.
Partecipa alla community