L’11 settembre 2026 scatteranno i primi obblighi del Regolamento (UE) 2024/2847, il Cyber Resilience Act o CRA: i produttori dovranno segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi che interessano i loro prodotti. La maggior parte delle altre disposizioni diventerà applicabile dall’11 dicembre 2027.
La sicurezza di hardware e software diventa così una condizione per vendere prodotti digitali nell’Unione europea. Il CRA impone di affrontare la cybersicurezza dalla progettazione alla fine del periodo di supporto, con requisiti per la gestione delle vulnerabilità, gli aggiornamenti e le informazioni fornite agli utenti.
Per chi acquista o utilizza questi prodotti, il cambiamento si traduce in configurazioni iniziali più sicure, maggiore trasparenza sulla durata del supporto e indicazioni tempestive quando una vulnerabilità o un incidente richiedono un intervento.
Il regolamento è entrato in vigore il 10 dicembre 2024, lasciando alle imprese un periodo di transizione per adeguare prodotti, processi e documentazione.
Che cos’è il Cyber Resilience Act e quali prodotti riguarda
Il CRA è il primo regolamento europeo orizzontale sui requisiti di cybersicurezza dei prodotti con elementi digitali. Si applica all’hardware e al software messi a disposizione sul mercato dell’Unione quando il loro impiego previsto, o ragionevolmente prevedibile, comporta una connessione logica o fisica, diretta o indiretta, con un dispositivo o una rete.
Il perimetro comprende, fra gli altri:
- smartphone, router, telecamere IP, dispositivi per la smart home, giocattoli connessi e wearable;
- apparati di rete, gateway, sensori, sistemi di controllo e dispositivi industriali connessi;
- applicazioni desktop e mobili, videogiochi e programmi destinati agli utenti finali;
- sistemi operativi, middleware, runtime, strumenti di amministrazione e software di sicurezza;
- software enterprise installato presso il cliente o distribuito come appliance virtuale;
- firmware e software embedded che controllano dispositivi, macchinari e apparati;
- librerie e componenti hardware o software commercializzati separatamente;
- soluzioni di elaborazione remota senza le quali il prodotto non potrebbe svolgere una delle proprie funzioni.
Il CRA interessa quindi una parte molto ampia dell’hardware e del software distribuito nell’UE. Per un’applicazione contano l’immissione sul mercato e il ruolo dell’operatore economico, non il fatto che sia venduta con licenza perpetua, in abbonamento, insieme a un dispositivo o gratuitamente nell’ambito di un’attività commerciale.
Chi distribuisce un’applicazione con il proprio nome è considerato produttore anche quando ne affida lo sviluppo a terzi. Il software realizzato e utilizzato soltanto all’interno di un’organizzazione, senza essere messo a disposizione sul mercato, rimane invece fuori dalla disciplina di conformità del prodotto. Il software personalizzato fornito a un cliente può rientrarvi: la natura su misura della soluzione non elimina i requisiti applicabili.
Il software libero e open source sviluppato o fornito fuori da un’attività commerciale segue un regime specifico; quando un’impresa lo commercializza o lo integra in un proprio prodotto, gli obblighi del CRA restano invece a carico del produttore. Eclipse Foundation e OWASP hanno avviato una collaborazione per preparare l’ecosistema open source ai nuovi obblighi europei.
La distinzione per SaaS e servizi cloud
I servizi SaaS, PaaS e IaaS autonomi non rientrano nel CRA per il solo fatto di essere accessibili attraverso una rete. Per i fornitori che soddisfano i requisiti dimensionali e settoriali previsti, la principale disciplina europea di riferimento è la direttiva NIS2.
Una funzione cloud entra invece nel perimetro del CRA quando è sviluppata dal produttore, o sotto la sua responsabilità, ed è indispensabile a una funzione del prodotto. È il caso, per esempio, del servizio remoto necessario per controllare un dispositivo connesso. La stessa offerta può quindi comprendere un’applicazione installabile soggetta al CRA, una piattaforma cloud autonoma disciplinata dalla NIS2 e una funzione remota valutata insieme al prodotto.
Le categorie disciplinate da norme settoriali
Il regolamento esclude alcune categorie già disciplinate da norme europee settoriali, fra cui dispositivi medici e diagnostici in vitro, determinati veicoli, prodotti certificati secondo le regole dell’aviazione civile e apparecchiature marittime. Disposizioni specifiche riguardano inoltre i prodotti destinati alla sicurezza nazionale o alla difesa.
Che cosa cambia per chi acquista e utilizza hardware e software
Il CRA è pensato per proteggere chi acquista o utilizza prodotti digitali: privati, aziende e pubbliche amministrazioni. Non attribuisce nuovi obblighi diretti all’utente ordinario, che dovrà comunque applicare gli aggiornamenti, proteggere le credenziali e seguire le istruzioni di sicurezza. Sposta però una parte maggiore della responsabilità verso chi progetta e vende il prodotto.
Prodotti più sicuri fin dal primo utilizzo
Router, telecamere, dispositivi domestici, applicazioni e altri prodotti digitali dovranno offrire una protezione adeguata fin dalla configurazione iniziale. Per chi li utilizza significa una minore esposizione a password universali, servizi superflui e accessi non protetti, oltre alla possibilità di ricevere automaticamente gli aggiornamenti di sicurezza mantenendo il controllo sulla loro installazione. Queste misure non eliminano le vulnerabilità, ma riducono la dipendenza dalla capacità del singolo acquirente di configurare correttamente il prodotto.
Durata del supporto dichiarata prima dell’acquisto
Il produttore dovrà indicare il mese e l’anno in cui termina il periodo di supporto. La durata degli aggiornamenti diventa così un elemento confrontabile prima dell’acquisto, accanto al prezzo e alle funzioni.
La trasparenza è rilevante anche per aziende e pubbliche amministrazioni. Sapere fino a quando un prodotto riceverà correzioni permette di pianificare aggiornamenti e sostituzioni, valutare il costo totale di possesso e inserire nei contratti tempi di risposta e procedure per la gestione di vulnerabilità e incidenti.
Il beneficio è particolarmente evidente per apparati destinati a restare operativi per anni, come gateway, sensori, sistemi di controllo, telecamere, componenti embedded, workstation e dispositivi di rete. Negli ambienti OT rimangono necessari test interni e finestre di manutenzione, perché una patch immediata può interferire con la continuità operativa. Il produttore deve però rendere disponibile la correzione e comunicare il rischio.
Per le organizzazioni soggette a NIS2 o DORA, il CRA offre una base più uniforme per valutare la sicurezza dei prodotti acquistati e la capacità del fornitore di mantenerli. Non sostituisce gli obblighi propri dell’acquirente, né rende superflua la valutazione dei prodotti destinati agli impieghi più critici.
Informazioni su vulnerabilità e incidenti
Quando viene a conoscenza di una vulnerabilità attivamente sfruttata o di un incidente grave, il produttore deve informare gli utenti interessati e, quando opportuno, tutti gli utenti del prodotto. La comunicazione deve indicare le misure correttive o di mitigazione disponibili, come l’installazione di una patch, la disattivazione temporanea di una funzione o una modifica della configurazione.
La notifica alle autorità non sostituisce quindi le indicazioni necessarie a chi usa il prodotto. Utenti, ricercatori e organizzazioni potranno inoltre inviare notifiche volontarie di vulnerabilità, minacce, incidenti e quasi incidenti attraverso la piattaforma europea prevista dal regolamento.
Marcatura CE e limiti della protezione
La marcatura CE indicherà che il produttore ha dichiarato la conformità al CRA seguendo la procedura applicabile. Le autorità di vigilanza potranno chiedere correzioni, limitare la commercializzazione e, nei casi più gravi, ordinare il ritiro o il richiamo del prodotto.
La marcatura non costituisce però un punteggio di sicurezza e non certifica l’assenza assoluta di vulnerabilità. Per gli acquisti ad alto rischio, aziende e amministrazioni dovranno continuare a valutare architettura, affidabilità del fornitore, certificazioni e requisiti specifici del proprio settore.
Chi si limita ad acquistare e usare un prodotto rimane un utilizzatore. Un’azienda che lo commercializza con il proprio marchio o lo modifica in modo sostanziale può invece assumere il ruolo e gli obblighi del produttore.
Gli obblighi per produttori, importatori e distributori
Il CRA distribuisce le responsabilità lungo la catena commerciale, assegnando il carico principale al produttore: il soggetto che sviluppa o fa sviluppare un prodotto e lo commercializza con il proprio nome o marchio. L’esternalizzazione dello sviluppo, l’acquisto del firmware da un fornitore o l’impiego di componenti di terzi non trasferiscono questa responsabilità.
Prima di immettere il prodotto sul mercato, il produttore deve effettuare una valutazione dei rischi di cybersicurezza e utilizzarne i risultati durante progettazione, sviluppo e realizzazione. La valutazione accompagna la documentazione tecnica e deve essere aggiornata durante il periodo di supporto.
Gli obblighi valgono anche per le aziende stabilite fuori dall’Unione che vendono nel mercato europeo. L’importatore deve verificare che il produttore abbia completato la valutazione di conformità, predisposto la documentazione richiesta e adottato procedure per la gestione delle vulnerabilità. Il distributore controlla gli elementi visibili della conformità, comprese marcatura CE, informazioni sugli operatori economici e durata del supporto. Se rileva una non conformità, non può rendere disponibile il prodotto finché il problema non viene corretto.
Un importatore o distributore che vende il prodotto con il proprio nome o introduce una modifica sostanziale può assumere le responsabilità del produttore.
Secure by design e secure by default
Il CRA trasforma secure by design e secure by default da buone pratiche in requisiti legali. I due principi intervengono in momenti diversi: il primo riguarda il modo in cui il prodotto viene concepito e costruito; il secondo la configurazione con cui viene consegnato e può essere usato fin dalla prima accensione.
Secure by design significa integrare la sicurezza nell’architettura e nel processo di sviluppo, partendo dalla valutazione dei rischi. Il prodotto deve ridurre la superficie di attacco, separare le funzioni quando necessario, applicare il principio del minimo privilegio e proteggere riservatezza, integrità e disponibilità di dati e servizi. Autenticazione, controllo degli accessi, cifratura, registrazione degli eventi e capacità di contenere un incidente devono essere proporzionati al rischio. Il produttore deve inoltre evitare di immettere sul mercato prodotti con vulnerabilità note sfruttabili.
Secure by default significa che il livello di protezione iniziale non deve dipendere da una configurazione esperta dell’utente. Il prodotto deve attivare soltanto le funzioni necessarie, evitare password universali o facilmente prevedibili, limitare accessi e privilegi e non lasciare esposti servizi superflui. Quando appropriato, gli aggiornamenti automatici di sicurezza devono essere abilitati; l’utente deve poterli rinviare o disattivare in modo chiaro. Devono essere previste anche modalità per ripristinare uno stato sicuro e cancellare dati e impostazioni senza lasciarne copie accessibili.
In sintesi, secure by design riduce i rischi incorporandone la gestione nel prodotto; secure by default evita che una configurazione iniziale debole annulli le protezioni progettate.
Il produttore deve anche pubblicare una policy di coordinated vulnerability disclosure, predisporre canali per le segnalazioni, analizzare i problemi ricevuti e correggere le vulnerabilità senza ritardi ingiustificati.
Aggiornamenti e periodo di supporto
Il periodo di supporto deve riflettere il tempo durante il quale il prodotto dovrebbe ragionevolmente essere utilizzato, tenendo conto di natura, finalità, aspettative degli utenti, disponibilità dell’ambiente operativo e durata del supporto dei componenti essenziali forniti da terzi.
La durata minima è di cinque anni. Se la vita utile prevista del prodotto è più breve, il supporto può corrispondere a quel periodo. L’indicazione deve essere comunicata chiaramente al momento dell’acquisto e inclusa nella documentazione.
Gli aggiornamenti di sicurezza pubblicati durante il supporto devono rimanere disponibili per almeno dieci anni dalla loro emissione oppure per il tempo restante del supporto, scegliendo il periodo più lungo. Manutenzione, distribuzione delle patch e risposta alle vulnerabilità diventano così costi da prevedere nel ciclo di vita commerciale del prodotto.
SBOM e dipendenze di terze parti
Quasi ogni prodotto digitale incorpora librerie, firmware, runtime e altri componenti sviluppati da terzi. Le vulnerabilità di queste dipendenze rientrano nella gestione del rischio del prodotto finale.
La documentazione deve includere una Software Bill of Materials (SBOM) in un formato comunemente usato e leggibile da una macchina, con almeno le dipendenze di primo livello. La distinta permette di collegare una vulnerabilità alle versioni e ai prodotti interessati, ma non costituisce di per sé una certificazione di sicurezza.
La SBOM deve essere mantenuta aggiornata e collegata al processo di sviluppo e al monitoraggio delle vulnerabilità. Il produttore deve inoltre proteggere le pipeline di sviluppo e conservare le informazioni necessarie a ricostruire ciò che è stato distribuito.
Il CRA non impone di pubblicare integralmente la SBOM. Il documento fa parte della documentazione tecnica e deve essere messo a disposizione delle autorità quando richiesto; il produttore può condividerlo con clienti e partner in base alle proprie esigenze e agli altri obblighi applicabili.
Il reporting obbligatorio dall’11 settembre 2026
La prima scadenza operativa riguarda le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza del prodotto. Dall’11 settembre 2026 il produttore dovrà trasmettere una prima segnalazione entro 24 ore da quando ne viene a conoscenza e una notifica più completa entro 72 ore.
Per una vulnerabilità attivamente sfruttata, il rapporto finale dovrà essere inviato entro 14 giorni dalla disponibilità di una misura correttiva o di mitigazione. Per un incidente grave, il termine sarà di un mese dalla notifica delle 72 ore.
Le comunicazioni passeranno attraverso la Single Reporting Platform gestita da ENISA. Il produttore effettuerà un solo invio, indirizzato al CSIRT designato come coordinatore e, salvo circostanze eccezionali, reso disponibile simultaneamente a ENISA.
Il reporting si applicherà anche ai prodotti messi a disposizione sul mercato prima dell’11 dicembre 2027. Le aziende devono quindi conoscere le versioni ancora in uso, identificare rapidamente quelle coinvolte, coordinare la correzione e raccogliere le informazioni richieste entro termini molto brevi.
Valutazione di conformità e prodotti già sul mercato
Prima dell’immissione sul mercato, il produttore deve dimostrare che il prodotto soddisfa i requisiti essenziali del CRA, predisporre la documentazione tecnica e la dichiarazione UE di conformità e apporre la marcatura CE.
Per la maggior parte dei prodotti, fra cui applicazioni mobili, videogiochi, smart speaker e molti elettrodomestici, è ammessa l’autovalutazione. Procedure più rigorose riguardano i prodotti considerati importanti o critici per la cybersicurezza.
Fra i prodotti importanti figurano, a seconda della categoria e della funzione principale, sistemi operativi, antivirus, router, gestori di rete e firewall. Per categorie critiche come secure element, smart card e gateway per contatori intelligenti, la valutazione da parte di un organismo notificato è obbligatoria. Gli standard armonizzati pubblicati nella Gazzetta ufficiale dell’Unione potranno attribuire una presunzione di conformità per i requisiti coperti.
I prodotti immessi sul mercato prima dell’11 dicembre 2027 saranno soggetti alla maggior parte delle nuove regole soltanto se, dopo quella data, subiranno una modifica sostanziale che incide sulla conformità o ne cambia la finalità prevista. Un aggiornamento correttivo ordinario non avvia automaticamente un nuovo iter; una modifica delle funzioni, dell’architettura o del profilo di rischio può invece richiedere una nuova valutazione. La guida pubblicata dalla Commissione europea nel luglio 2026 fornisce chiarimenti anche su questo punto.
Costi di adeguamento e vantaggi per le aziende
Per i produttori, l’adeguamento richiede investimenti in competenze, strumenti, documentazione e assistenza. Il costo iniziale può essere significativo quando prodotti e dipendenze non sono censiti, il processo di sviluppo non integra controlli di sicurezza o il supporto termina senza una politica definita.
Il CRA offre però una base normativa unica per il mercato europeo, evitando che lo stesso prodotto debba essere adattato a 27 discipline nazionali. Standard armonizzati e procedure comuni possono rendere più prevedibili progettazione, documentazione e accesso al mercato.
I requisiti minimi intervengono anche sulla concorrenza. Chi investe in test, aggiornamenti e gestione delle vulnerabilità non dovrà più competere alle stesse condizioni con chi riduce il prezzo rinunciando al supporto. Durata della manutenzione, trasparenza e qualità della protezione possono diventare elementi di differenziazione commerciale.
Inventari, SBOM e tracciabilità delle versioni producono inoltre un vantaggio operativo: permettono di individuare più rapidamente i prodotti esposti, assegnare priorità alle correzioni e rispondere con maggiore precisione a clienti e autorità. Per un produttore globale, adottare i requisiti europei come base di progettazione può anche evitare di mantenere una versione meno sicura per gli altri mercati, pur senza sostituire gli adempimenti locali.
Unione europea, Stati Uniti e Cina: tre approcci diversi
Il Cyber Resilience Act non ha un equivalente diretto negli Stati Uniti o in Cina. I due Paesi sono i principali poli mondiali dello sviluppo software e della produzione hardware, e una parte rilevante dei prodotti acquistati nell’Unione europea nasce da aziende o filiere radicate nei loro mercati. Confrontarne le regole permette di valutare le tutele offerte a chi acquista e utilizza le stesse tecnologie: nell’UE il CRA introduce requisiti comuni per l’intero ciclo di vita, mentre Stati Uniti e Cina si affidano a norme settoriali, programmi volontari, certificazioni e restrizioni mirate.
| Unione europea | Stati Uniti | Cina | |
|---|---|---|---|
| Impostazione | Regolamento orizzontale sui prodotti con elementi digitali | Norme settoriali, programmi volontari, appalti pubblici e restrizioni di sicurezza nazionale | Leggi su reti, dati, infrastrutture critiche e sicurezza nazionale |
| Centro della disciplina | Sicurezza del prodotto lungo il ciclo di vita | Rischio associato a settori, fornitori e categorie di dispositivi | Sicurezza delle reti e dei dati, controllo delle infrastrutture e affidabilità delle forniture |
| Secure by design | Requisito legale del prodotto | Principio promosso soprattutto attraverso linee guida e iniziative volontarie | Obblighi distribuiti fra leggi, standard, certificazioni e regole settoriali |
| Accesso al mercato | Conformità e marcatura CE, indipendentemente dal Paese di origine | Autorizzazioni e divieti mirati per determinate categorie o provenienze | Certificazioni, test e revisioni di sicurezza negli ambiti sensibili |
| Per chi acquista e utilizza | Requisiti comuni su configurazione, supporto, aggiornamenti e informazioni di sicurezza | Tutele variabili secondo settore e prodotto, con etichette volontarie e restrizioni mirate | Protezione affidata a controlli su reti, dati, certificazioni e sicurezza nazionale |
Stati Uniti: regole settoriali e sicurezza della supply chain
Gli Stati Uniti non dispongono di una legge federale unica che imponga alla generalità dei prodotti digitali requisiti di sicurezza dalla progettazione alla fine del supporto. Per chi acquista, ciò significa che garanzie, aggiornamenti e informazioni disponibili dipendono maggiormente dalla categoria del prodotto, dalle norme settoriali e dalle scelte del produttore.
La CISA promuove secure by design e secure by default, ma il suo Secure by Design Pledge per i produttori di software enterprise è volontario. Anche l’U.S. Cyber Trust Mark, creato dalla FCC per i dispositivi IoT consumer wireless, è un programma volontario di etichettatura basato su requisiti minimi di cybersicurezza.
Accanto a questi strumenti opera la FCC Covered List, che identifica apparecchiature e servizi considerati un rischio inaccettabile per la sicurezza degli Stati Uniti o dei suoi cittadini. I prodotti inclusi non possono ottenere una nuova autorizzazione FCC, necessaria per importare, promuovere o vendere negli Stati Uniti gran parte dei dispositivi elettronici.
Il 28 luglio 2026 la FCC ha aggiunto alla lista i dispositivi robotici avanzati prodotti all’estero e gli inverter connessi prodotti in Paesi stranieri. La prima categoria comprende i robot mobili: umanoidi e quadrupedi sono esempi, non un elenco esaustivo. Può quindi includere anche un robot domestico connesso per la pulizia, se il modello rientra nella definizione e richiede l’autorizzazione FCC. La decisione è seguita alla valutazione di un organismo interagenzia convocato dalla Casa Bianca, che ha individuato rischi per la supply chain, accessi remoti, raccolta ed esfiltrazione di dati e sicurezza delle infrastrutture critiche.
Il provvedimento riguarda i nuovi modelli che richiedono l’autorizzazione FCC. Non impedisce di continuare a usare dispositivi già acquistati né di vendere modelli autorizzati in precedenza. Sono possibili approvazioni condizionate da parte delle autorità competenti. La Covered List della FCC era già stata estesa a router consumer prodotti all’estero, sistemi aeromobili senza equipaggio e componenti critici.
La differenza rispetto all’Europa è netta anche per gli acquirenti. Il CRA stabilisce una soglia comune di sicurezza per i prodotti compresi nel proprio perimetro, indipendentemente dal luogo di produzione. La FCC può invece impedire l’ingresso di nuovi modelli ritenuti rischiosi per provenienza e catena di fornitura, ma non impone a tutti i prodotti autorizzati gli stessi obblighi europei su configurazione, aggiornamenti e durata del supporto.
Cina: reti, dati e infrastrutture strategiche
La Cina non ha adottato un regolamento sovrapponibile al CRA. La disciplina deriva da un insieme di leggi e misure che comprende Cybersecurity Law, Data Security Law, Personal Information Protection Law, regole per la protezione delle infrastrutture informative critiche, revisioni di sicurezza e standard nazionali.
La Cybersecurity Law cinese, modificata nel 2025, si applica alla costruzione, al funzionamento, alla manutenzione e all’uso delle reti nel Paese. Dal 1° gennaio 2026 la versione aggiornata rafforza le sanzioni e la responsabilità per la vendita o fornitura di apparecchiature di rete critiche e prodotti specializzati per la cybersicurezza privi delle certificazioni o dei test richiesti.
Le regole cinesi sulla gestione delle vulnerabilità dei prodotti di rete coprono hardware e software. Impongono ai fornitori di correggere le vulnerabilità, comunicarle alle autorità entro i termini previsti e rispettare vincoli sulla raccolta e pubblicazione dei dettagli tecnici. Gli operatori di infrastrutture informative critiche devono inoltre sottoporre a revisione gli acquisti di prodotti e servizi di rete che possono incidere sulla sicurezza nazionale.
L’approccio cinese attribuisce quindi maggiore peso al controllo delle reti, dei dati e delle infrastrutture strategiche. Questi strumenti possono impedire la vendita di prodotti privi delle certificazioni richieste e imporre la correzione delle vulnerabilità, ma non riuniscono in un’unica disciplina orizzontale le garanzie introdotte dal CRA su configurazione iniziale, durata del supporto, aggiornamenti e informazioni agli utenti.
Per chi acquista lo stesso tipo di hardware o software nei tre mercati, la protezione può quindi essere molto diversa. Nell’UE il riferimento è un insieme uniforme di requisiti lungo il ciclo di vita; negli Stati Uniti prevalgono interventi settoriali o mirati a specifiche provenienze; in Cina pesano soprattutto certificazioni, controllo delle reti e sicurezza nazionale.
Vigilanza e sanzioni
L’applicazione del CRA sarà affidata alle autorità nazionali di vigilanza del mercato, coordinate a livello europeo. Potranno imporre la correzione delle non conformità, limitare o vietare la commercializzazione del prodotto e disporne il ritiro o il richiamo.
Per la violazione dei requisiti essenziali di cybersicurezza e dei principali obblighi dei produttori, il regolamento prevede sanzioni amministrative fino a 15 milioni di euro o, per un’impresa, fino al 2,5% del fatturato mondiale annuo dell’esercizio precedente, scegliendo l’importo più elevato.
La valutazione terrà conto di natura, gravità e durata della violazione, dimensioni dell’operatore, grado di cooperazione e precedenti. Le microimprese e le piccole imprese non possono essere sanzionate per il solo mancato rispetto del termine di 24 ore previsto per la prima segnalazione; gli open source software steward non sono soggetti alle sanzioni amministrative del regolamento.
La sicurezza del prodotto continua dopo la vendita
Il cambiamento centrale introdotto dal CRA è la continuità della responsabilità. La sicurezza non si esaurisce quando hardware o software arrivano sul mercato: il produttore deve mantenerli, correggerli e informare gli utenti per il periodo dichiarato. Per chi acquista, questo non elimina ogni rischio, ma introduce una base comune di protezione, rende confrontabile la durata del supporto e offre strumenti più chiari per ottenere correzioni o l’intervento delle autorità.
