Cyber Resilience Act (UE) 2024/2847 — obblighi del fabbricante dall’11 settembre 2026

Per vent’anni la cybersicurezza dei prodotti è stata regolata nell’Unione a frammenti: in parte tramite la direttiva sulle apparecchiature radio, in parte tramite norme settoriali, in larga misura per nulla. Il regolamento (UE) 2024/2847 — il Cyber Resilience Act — chiude questa fase. Riguarda ogni prodotto con elementi digitali messo a disposizione sul mercato dell’Unione, dal router alla libreria software venduta come prodotto, e lo collega alla marcatura CE.

La scadenza più vicina non è lontana. L’11 settembre 2026 entrano in vigore gli obblighi di segnalazione: le vulnerabilità attivamente sfruttate e gli incidenti gravi vanno comunicati entro 24 ore. Vale anche per i prodotti già presenti sul mercato. L’applicazione piena arriva l’11 dicembre 2027. Per i fabbricanti questo non significa solo nuovo lavoro tecnico, ma anche un insieme di dati che deve raggiungere l’utente e restare vero per anni — lo stesso problema che il passaporto digitale di prodotto risolve in altri ambiti di conformità.

I punti chiave

Il regolamento (UE) 2024/2847 è entrato in vigore il 10 dicembre 2024. Si applica per fasi: le disposizioni sugli organismi notificati dall’11 giugno 2026, gli obblighi di segnalazione dall’11 settembre 2026, l’applicazione piena dall’11 dicembre 2027.
L’ambito è orizzontale: prodotti con elementi digitali, cioè hardware e software il cui utilizzo comporta una connessione dati diretta o indiretta a un dispositivo o a una rete. Sono esclusi i prodotti coperti da regimi propri: dispositivi medici, veicoli a motore, aviazione civile, equipaggiamento marittimo e il settore della difesa.
La maggior parte dei prodotti segue un’autovalutazione (modulo A). I prodotti importanti dell’allegato III classe I richiedono un organismo notificato se le norme armonizzate non sono state applicate integralmente; la classe II e i prodotti critici dell’allegato IV richiedono sempre organismo notificato o certificazione.
Il periodo di supporto è stabilito dal fabbricante, ma di regola non può essere inferiore a cinque anni, salvo che la vita utile prevista del prodotto sia più breve. La data di fine (mese e anno) va indicata al momento dell’acquisto.
L’SBOM — una distinta base del software leggibile da macchina che copra almeno le dipendenze di primo livello — è un requisito dell’allegato I. Va tenuta aggiornata e messa a disposizione delle autorità di vigilanza del mercato su richiesta.
Gli aggiornamenti di sicurezza sono gratuiti e, una volta rilasciati, devono restare disponibili per almeno dieci anni oppure fino alla fine del periodo di supporto, se più lungo.
La conformità è attestata da dichiarazione di conformità UE e marcatura CE, gli stessi strumenti del resto del diritto dei prodotti.
La soglia sanzionatoria più alta per la violazione dei requisiti essenziali e degli obblighi degli articoli 13 e 14 è di 15 milioni di euro o il 2,5 % del fatturato annuo mondiale, se superiore.
Il CRA non istituisce un passaporto digitale di prodotto. Crea però un insieme di informazioni legate al prodotto e alla versione che deve restare raggiungibile per anni, e questo è un problema di gestione dei dati.

Che cosa è davvero il Cyber Resilience Act

Il CRA è un atto orizzontale: non descrive un settore, ma una proprietà comune dei prodotti. Questa proprietà è la presenza di un elemento digitale e la capacità di scambiare dati. Strutturalmente appartiene alla famiglia del diritto dei prodotti nota dalla marcatura CE: requisiti essenziali in un allegato, valutazione della conformità, documentazione tecnica, dichiarazione e marchio.

La novità sta altrove. Il diritto dei prodotti valutava finora la merce al momento dell’immissione sul mercato; dopo, l’interesse del regolatore in pratica cessava. Il CRA non accetta questa premessa. L’obbligo di gestire le vulnerabilità, rilasciare aggiornamenti e segnalare incidenti si estende all’intero periodo di supporto dichiarato. Un prodotto conforme il giorno della vendita può non esserlo più due anni dopo, se il fabbricante smette di correggere le vulnerabilità note.

Va segnalato anche il riordino che il CRA introduce nel diritto vigente. Il regolamento delegato (UE) 2022/30, che dal 2025 attuava requisiti di cybersicurezza attraverso la direttiva sulle apparecchiature radio, è abrogato alla data di piena applicazione del CRA, l’11 dicembre 2027. I requisiti essenziali dell’allegato I coprono tutto ciò che coprivano le norme sulle apparecchiature radio, quindi il doppio regime scompare.

Che cosa è un «prodotto con elementi digitali»

La definizione è ampia, e lo è di proposito. Si tratta di un prodotto hardware o software il cui uso previsto o ragionevolmente prevedibile include una connessione dati diretta o indiretta a un dispositivo o a una rete. Comprende anche le soluzioni di elaborazione dati a distanza, quando sono necessarie al funzionamento del prodotto.

In pratica è più semplice indicare che cosa resta fuori dall’ambito, perché l’elenco delle esclusioni è chiuso e concreto:

Dispositivi medici e dispositivi medico-diagnostici in vitro — regolamenti (UE) 2017/745 e (UE) 2017/746.
Veicoli a motore — regolamento (UE) 2019/2144.
Aviazione civile — regolamento (UE) 2018/1139.
Equipaggiamento marittimo — direttiva 2014/90/UE.
Prodotti sviluppati esclusivamente per finalità di sicurezza nazionale o difesa e prodotti non forniti nell’ambito di un’attività commerciale.

Al di fuori di queste esclusioni l’ambito è molto ampio. Il software venduto come prodotto è coperto quanto un dispositivo. Il software libero e open source sviluppato senza finalità commerciali non lo è, ma l’articolo 24 crea una figura distinta e più leggera, quella dell’amministratore di software open source, per i soggetti che sostengono in modo stabile lo sviluppo di tale software destinato a usi commerciali.

Tre livelli di rischio e tre percorsi di valutazione

Il regolamento gradua il rigore in base all’impatto che una violazione della sicurezza potrebbe avere per ciascun prodotto.

Prodotti ordinari: la grande maggioranza del mercato. Il fabbricante esegue il controllo interno (modulo A) e redige da sé documentazione tecnica e dichiarazione. Non serve un organismo notificato.

Prodotti importanti, allegato III classe I: tra gli altri gestori di password, antivirus, sistemi di gestione delle identità e degli accessi privilegiati, VPN, sistemi operativi, router e switch, microprocessori con funzioni legate alla sicurezza, assistenti virtuali domestici, giocattoli connessi a internet e dispositivi indossabili. L’autovalutazione resta possibile, ma solo applicando integralmente norme armonizzate o specifiche comuni. In mancanza, interviene un organismo notificato.

Prodotti importanti, allegato III classe II: per esempio firewall, sistemi di rilevamento e prevenzione delle intrusioni, hypervisor e microprocessori resistenti alla manomissione. Qui l’organismo notificato o uno schema europeo di certificazione della cybersicurezza è obbligatorio.

Prodotti critici, allegato IV: il livello più severo, con organismo notificato o certificazione obbligatori. Le descrizioni tecniche delle categorie sono precisate dal regolamento di esecuzione (UE) 2025/2392.

La conclusione pratica è la stessa di ogni regolamento che coinvolge organismi notificati: classificare presto. Se un prodotto rientra nella classe II o nell’allegato IV, i tempi dell’organismo notificato diventano parte del piano di lancio e non una formalità finale.

Obblighi del fabbricante — che cosa fare concretamente

Requisiti essenziali, parte prima: proprietà del prodotto

L’allegato I parte I descrive come deve essere il prodotto. I punti chiave: immissione sul mercato senza vulnerabilità sfruttabili note, consegna con configurazione predefinita sicura e possibilità di ripristino allo stato di fabbrica, protezione di riservatezza, integrità e disponibilità dei dati, minimizzazione della superficie di attacco, limitazione della raccolta dati allo stretto necessario e possibilità di installare aggiornamenti di sicurezza, ove possibile in modo automatico e con chiara notifica all’utente.

Requisiti essenziali, parte seconda: gestione delle vulnerabilità

L’allegato I parte II descrive un processo che deve funzionare per tutto il periodo di supporto:

Un SBOM in formato leggibile da macchina, che copra almeno le dipendenze di primo livello, tenuto aggiornato. Non c’è obbligo di pubblicarlo agli utenti, ma va esibito alle autorità di vigilanza del mercato su richiesta.
Rimediare alle vulnerabilità senza indugio, anche mediante aggiornamenti di sicurezza.
Test e verifiche di sicurezza periodici.
Divulgazione pubblica delle informazioni sulle vulnerabilità corrette una volta disponibile l’aggiornamento.
Una politica di divulgazione coordinata delle vulnerabilità e un punto di contatto unico per le segnalazioni.
Distribuzione gratuita degli aggiornamenti di sicurezza senza ritardo.

Il periodo di supporto, un campo dati con effetti commerciali

È l’obbligo che sorprende più spesso. Il fabbricante stabilisce il periodo durante il quale gestisce efficacemente le vulnerabilità del prodotto, ma non può essere inferiore a cinque anni, salvo che la vita utile prevista sia più breve. La data di fine, precisa al mese e all’anno, deve essere chiaramente indicata al momento dell’acquisto.

Sopra questo si aggiunge un secondo orizzonte. Un aggiornamento di sicurezza, una volta rilasciato, deve restare disponibile per almeno dieci anni dalla messa a disposizione, oppure fino alla fine del periodo di supporto se questo termina più tardi. È un impegno infrastrutturale: qualcuno deve mantenere file e informazioni raggiungibili per un decennio, attraverso cambi di sistemi e di domini.

Segnalazione di vulnerabilità e incidenti: la data dell’11 settembre 2026

L’articolo 14 introduce gli obblighi che arrivano per primi e che riguardano anche i prodotti già sul mercato. Vanno segnalate le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza del prodotto, al CSIRT dello Stato membro dello stabilimento principale del fabbricante e all’ENISA, tramite una piattaforma unica di segnalazione.

Fase	Termine
Allerta precoce	24 ore
Notifica principale	72 ore
Relazione finale — vulnerabilità	14 giorni dalla disponibilità di una misura correttiva
Relazione finale — incidente grave	1 mese

Le 24 ore di allerta precoce sono un termine operativo, non un’astrazione giuridica. Significano che reperibilità, percorso di escalation e accesso alla piattaforma devono esistere in anticipo. Le microimprese e le piccole imprese non sono sanzionate per il mancato rispetto del termine di 24 ore, ma l’obbligo di segnalazione le riguarda comunque.

Informazioni per l’utente: allegato II

L’allegato II elenca le informazioni che devono accompagnare il prodotto: identificazione di tipo, lotto o numero di serie, dati del fabbricante con indirizzo e punto di contatto, un punto di contatto unico per segnalare vulnerabilità e l’indicazione di dove trovare la politica di divulgazione, la destinazione d’uso, le istruzioni per l’installazione e l’uso sicuri, le modalità per ottenere gli aggiornamenti di sicurezza e la data di fine del periodo di supporto.

Calendario

Data	Che cosa accade
10 dicembre 2024	Entrata in vigore del regolamento (UE) 2024/2847
11 giugno 2026	Applicazione delle disposizioni sugli organismi notificati (capo IV)
11 settembre 2026	Applicazione degli obblighi di segnalazione (art. 14), anche per prodotti già sul mercato
11 dicembre 2027	Applicazione piena: requisiti essenziali, valutazione della conformità, CE, documentazione
11 giugno 2028	Scadenza dei certificati di esame UE del tipo rilasciati nel periodo transitorio

I prodotti immessi sul mercato prima dell’11 dicembre 2027 sono soggetti ai requisiti pieni solo se modificati in modo sostanziale dopo tale data. Gli obblighi di segnalazione, invece, li riguardano comunque.

Vale la pena leggere queste date accanto al regolamento macchine (UE) 2023/1230, applicabile dal 20 gennaio 2027. Una macchina con elementi digitali rientra in entrambi i regimi nell’arco di meno di undici mesi: il regolamento macchine tratta la cybersicurezza come requisito di sicurezza funzionale, il CRA impone obblighi orizzontali a software, controllori e connettività. Sono due regimi complementari, non alternativi.

Che cosa significa per i dati di prodotto

Diciamolo chiaramente, perché spesso si confonde: il Cyber Resilience Act non istituisce un passaporto digitale di prodotto. Non contiene obbligo di passaporto, né supporto dati, né registro. L’obbligo di passaporto deriva dall’ESPR e dagli atti settoriali che lo impongono espressamente.

Ma l’insieme di doveri informativi che il CRA crea è un problema di gestione dei dati in misura difficile da ignorare:

Identità a livello di versione. L’SBOM cambia a ogni rilascio software. Una distinta base che non dice a quale versione si riferisce non serve come prova. È lo stesso principio di versionare invece di sovrascrivere su cui si regge il passaporto.
La data di fine supporto come campo, non come frase in un pieghevole. Va indicata all’acquisto, deve essere coerente su tutti i canali di vendita e verificabile anni dopo. Uno scostamento tra la scheda prodotto del proprio negozio e quella del distributore smette di essere cosmetico.
Un supporto dati risolvibile. Il punto di contatto per le vulnerabilità, la politica di divulgazione e le informazioni sugli aggiornamenti devono restare raggiungibili per tutto il periodo di supporto. Un codice che risolve al record corrente lo fa meglio di un indirizzo stampato su un manuale sei anni fa. Le varianti sono trattate nel nostro articolo su codice QR e GS1 Digital Link.
Multilinguismo. Le informazioni dell’allegato II devono essere comprensibili agli utenti dei paesi in cui il prodotto è messo a disposizione. Con la documentazione digitale non è un progetto di traduzione, ma un campo con versioni linguistiche.
Continuità per un decennio. Dieci anni di disponibilità di aggiornamenti e informazioni sono un impegno di servizio che sopravvive a migrazioni, rebranding e cambi di fornitore.

Per l’elettronica si aggiunge un argomento pratico. La stessa categoria di prodotti è contemporaneamente nel mirino dell’ESPR, della direttiva RoHS e delle norme sui rifiuti elettronici. Un’azienda che tiene separati i dati sulle sostanze, quelli sulla riparabilità e quelli sul supporto software mantiene tre registri sullo stesso prodotto. Mettere in ordine i dati di prodotto una volta serve a tutte queste direzioni — il punto di partenza è il nostro articolo su perché i dati di prodotto sono il fondamento del DPP.

Una precisazione onesta sui limiti del ruolo del fornitore: myDPP non esegue test di sicurezza, non genera né convalida SBOM, non gestisce il processo di trattamento delle vulnerabilità, non valuta la conformità al CRA, non è organismo notificato e non presenta le segnalazioni dell’articolo 14. Conserva, versiona e pubblica dati di prodotto verificati e mantiene il supporto che li apre. La responsabilità della conformità resta del fabbricante.

Preparazione: cinque passi

Classificate il portafoglio. Stabilite quali prodotti sono prodotti con elementi digitali e quali rientrano nell’allegato III classe I o II, oppure nell’allegato IV. Da questo dipende se serve un organismo notificato e quanto durerà la valutazione.
Attivate la capacità di segnalazione prima dell’11 settembre 2026. Nominate i responsabili, scrivete il percorso di escalation per l’allerta di 24 ore, registrate l’accesso alla piattaforma e provatelo su un caso di test. Questa scadenza non aspetta che il resto del progetto sia pronto.
Definite i periodi di supporto e registrateli come dati. Per ogni famiglia di prodotti fissate una data di fine supporto, motivatela con la vita utile prevista e inseritela nel sistema che alimenta negozio, distributori e documentazione, non solo in una presentazione commerciale.
Integrate la generazione dell’SBOM nel processo di rilascio. Una distinta base compilata a mano una volta a trimestre si scosterà dalla realtà alla prima release correttiva. Legare l’SBOM alla versione e all’esemplare è lavoro sul lato dati, non sul lato giuridico.
Mettete in ordine le informazioni dell’allegato II. Punto di contatto, politica di divulgazione, istruzioni per la configurazione sicura e data di fine supporto devono essere coerenti in tutte le lingue e su tutti i canali e raggiungibili per anni.

Il programma dati più ampio è trattato nella nostra checklist di implementazione del DPP.

Domande frequenti

Il CRA si applica ai prodotti venduti prima del 2027?

In parte. I requisiti pieni — essenziali, valutazione della conformità, CE — raggiungono un prodotto immesso sul mercato prima dell’11 dicembre 2027 solo se viene modificato in modo sostanziale dopo tale data. Gli obblighi di segnalazione dell’articolo 14 riguardano invece i prodotti già sul mercato dall’11 settembre 2026, indipendentemente dalla data di vendita.

Devo pubblicare l’SBOM per i miei clienti?

No. L’allegato I richiede di redigere e mantenere una distinta base leggibile da macchina che copra almeno le dipendenze di primo livello e di metterla a disposizione delle autorità di vigilanza del mercato su richiesta. Pubblicare l’SBOM agli utenti è una scelta commerciale, non un obbligo di legge.

Posso fissare un periodo di supporto inferiore a cinque anni?

Solo se la vita utile prevista del prodotto è inferiore a cinque anni, e occorre poterlo motivare. Negli altri casi cinque anni sono il minimo e, se il prodotto viene realmente usato più a lungo, il periodo di supporto dovrebbe corrispondere alla vita utile reale.

Il Cyber Resilience Act introduce un passaporto digitale di prodotto?

No. Il CRA non contiene un obbligo di passaporto né la prescrizione di un supporto dati. Impone però doveri informativi legati al prodotto e alla versione che devono restare disponibili per il periodo di supporto e per un decennio dopo il rilascio di un aggiornamento. I requisiti sui dati convergono con quelli del passaporto, quindi un solo riordino serve a entrambe le direzioni.

Continua a leggere

Fonti

Regolamento (UE) 2024/2847 — Cyber Resilience Act — EUR-Lex
Cyber Resilience Act — sintesi del testo legislativo — Commissione europea
Regolamento (UE) 2023/1230 — macchine — EUR-Lex
Regolamento (UE) 2024/1781 (ESPR) — EUR-Lex
Regolamento delegato (UE) 2022/30 — cybersicurezza nella direttiva apparecchiature radio — EUR-Lex