Cyber Resilience Act Reg. (UE) 2024/2847

Il Cyber Resilience Act si applica ai prodotti con elementi digitali messi a disposizione sul mercato UE la cui finalità prevista, o il cui uso ragionevolmente prevedibile, include una connessione dati diretta o indiretta a un dispositivo o a una rete. La definizione copre qualsiasi prodotto software o hardware, le relative soluzioni di elaborazione dati da remoto e i componenti venduti separatamente: un’applicazione, una libreria commerciale, un firmware, un dispositivo connesso.

Gli obblighi pesano soprattutto sul fabbricante, ma il regolamento ne assegna di propri anche a importatori (art. 19) e distributori (art. 20). Chi immette un prodotto con il proprio nome o marchio, o vi apporta una modifica sostanziale, diventa fabbricante a sua volta (artt. 21 e 22).

Restano fuori i prodotti già disciplinati da regole settoriali: dispositivi medici e diagnostici in vitro (Reg. (UE) 2017/745 e 2017/746), veicoli a motore (Reg. (UE) 2019/2144), prodotti certificati per l’aviazione (Reg. (UE) 2018/1139), equipaggiamento marittimo, e i prodotti sviluppati esclusivamente per sicurezza nazionale o difesa (art. 2).

Il regolamento chiede sicurezza sia del prodotto sia del processo che lo mantiene nel tempo. Prima di immettere il prodotto sul mercato, il fabbricante:

• valuta i rischi di cibersicurezza e ne tiene conto in pianificazione, progettazione, sviluppo, produzione, consegna e manutenzione (art. 13, par. 2);
• rispetta i requisiti essenziali di cibersicurezza del prodotto (Allegato I, parte I) e quelli di gestione delle vulnerabilità (Allegato I, parte II);
• redige la documentazione tecnica (art. 31, Allegato VII), esegue la valutazione della conformità (art. 32), firma la dichiarazione di conformità UE e appone la marcatura CE (art. 13, par. 12);
• fissa un periodo di assistenza che rifletta la durata d’uso prevista, di almeno cinque anni, o pari alla durata d’uso prevista se inferiore (art. 13, par. 8), e tiene disponibili gli aggiornamenti di sicurezza per almeno dieci anni dal rilascio (art. 13, par. 9).

Il livello di verifica dipende dalla categoria. Per la maggior parte dei prodotti basta il controllo interno del fabbricante (modulo A). I prodotti importanti dell’Allegato III (classe I: per esempio sistemi operativi, browser, gestori di password, VPN, SIEM, router; classe II: ipervisori e runtime di container, firewall, sistemi di rilevamento delle intrusioni) e i prodotti critici dell’Allegato IV (per esempio smart card ed elementi sicuri) seguono procedure più rigorose.

Dall’11 settembre 2026 il fabbricante notifica contemporaneamente al CSIRT designato come coordinatore e all’ENISA ogni vulnerabilità attivamente sfruttata e ogni incidente grave che ha un impatto sulla sicurezza del prodotto, tramite la piattaforma unica di segnalazione gestita dall’ENISA, operativa da quella data. Il CSIRT di riferimento è quello dello Stato membro dello stabilimento principale nell’Unione.

Le 24 ore servono a dare l’allarme, non a risolvere. Il fabbricante deve anche informare gli utilizzatori interessati e le misure che possono adottare (art. 14, par. 8). Le sanzioni pecuniarie non si applicano a micro e piccole imprese per il solo mancato rispetto del termine del preallarme (art. 64, par. 10): l’obbligo di segnalare resta. Chi deve segnalare, da quale evento parte l’orologio e cosa preparare prima è il tema della pagina Dall’11 settembre hai 24 ore per segnalare.

Lo SBOM è un obbligo, non una buona pratica: dall’11 dicembre 2027 il fabbricante identifica e documenta i componenti del prodotto redigendo una distinta base del software in un formato di uso comune e leggibile da una macchina, con almeno le dipendenze di primo livello (Allegato I, parte II, punto 1). La documentazione tecnica dell’Allegato VII lo comprende, insieme alla descrizione dell’architettura, alla politica di divulgazione coordinata delle vulnerabilità e alle relazioni delle prove; va conservata per almeno dieci anni (art. 13, par. 13).

Il fabbricante risponde dell’intero prodotto, componenti di terzi compresi. Quando trova una vulnerabilità in un componente, anche open source, la segnala a chi lo mantiene e la corregge (art. 13, par. 6). Il gestore di software open source (una persona giuridica che sostiene in modo sistematico lo sviluppo di software libero destinato ad attività commerciali) ha un regime leggero: politica di cibersicurezza documentata, cooperazione con le autorità, nessuna sanzione pecuniaria (artt. 24 e 64).

Lo stesso SBOM serve anche altrove: è un elemento di prova per la responsabilità da prodotto e un artefatto di audit nella proposta CADA. Ne parla la pagina sulla sovranità tecnologica.

Il CRA è un regolamento e si applica direttamente; l’Italia deve però stabilire autorità e sanzioni. Il 2 ottobre 2026 il Consiglio dei ministri ha approvato in esame preliminare lo schema di decreto legislativo di adeguamento (comunicato n. 191). Secondo il comunicato:

• l’ACN è autorità di notifica per gli organismi di valutazione della conformità;
• la vigilanza del mercato è ripartita fra ACN in via generale, Banca d’Italia, CONSOB e IVASS per gli istituti finanziari e Garante per la protezione dei dati personali per quanto di competenza;
• i consumatori possono segnalare direttamente a CSIRT Italia vulnerabilità e incidenti; le violazioni entrano fra le materie delle azioni rappresentative a tutela degli interessi collettivi;
• sono previsti un canale di supporto per micro e piccole e medie imprese e uno spazio di sperimentazione normativa (Sandbox-CRA).

È uno schema: il testo può cambiare fino all’approvazione definitiva e alla pubblicazione in Gazzetta. I massimi delle sanzioni li fissa già il regolamento.

Un prodotto con AI dentro è un prodotto con elementi digitali. Se lo vendi o lo distribuisci, il CRA guarda al software e alle sue dipendenze come a qualsiasi altro prodotto: librerie di inferenza, componenti di retrieval e ogni altra dipendenza software entrano nello SBOM e nella gestione delle vulnerabilità.

Con l’AI Act c’è un ponte esplicito. L’art. 12 del CRA stabilisce che un sistema di AI ad alto rischio che rispetta i requisiti essenziali dell’Allegato I, e lo dimostra nella dichiarazione di conformità UE, è considerato conforme ai requisiti di cibersicurezza dell’art. 15 dell’AI Act, fermi i requisiti di accuratezza e robustezza. Un solo lavoro sulla sicurezza, se progettato bene, serve a due regolamenti.

Il periodo di assistenza è una promessa da dieci anni. Gli aggiornamenti di sicurezza restano disponibili almeno dieci anni dal rilascio e la documentazione tecnica si conserva altrettanto. Un componente di terzi senza manutenzione garantita diventa un tuo debito.

Anche non segnalare è una decisione. Il termine di 24 ore parte da quando il fabbricante viene a conoscenza della vulnerabilità o dell’incidente. Chi lo decide, e come lo registra, va scritto prima.

Il CRA regola il prodotto; altre norme regolano chi lo usa e chi ne risponde quando si rompe:

• NIS2 — i soggetti essenziali e importanti devono curare la sicurezza della catena di approvvigionamento, tenendo conto delle pratiche di sviluppo sicuro dei propri fornitori (art. 24, c. 3, D.Lgs. 138/2024): ciò che il CRA ti obbliga a documentare è quello che i clienti NIS devono valutare.
• Direttiva prodotti difettosi — il software è un prodotto anche ai fini della responsabilità per danno: la stessa vulnerabilità può essere un obbligo di segnalazione e un difetto.
• AI Act — per i sistemi ad alto rischio l’art. 12 del CRA collega i due regimi sulla cibersicurezza.
• CADA — la proposta su cloud e AI usa lo SBOM come artefatto di audit; è ancora una proposta.

• «Il CRA parte nel 2027». L’applicazione piena è dell’11 dicembre 2027, ma l’art. 14 si applica dall’11 settembre 2026, anche ai prodotti già sul mercato.
• «Facciamo software, non dispositivi». Il software è un prodotto con elementi digitali, comprese le soluzioni di elaborazione dati da remoto legate al prodotto.
• «La vulnerabilità è in una libreria open source, non è un problema nostro». Il fabbricante risponde dei componenti che integra: segnala la vulnerabilità a chi mantiene il componente e la corregge nel proprio prodotto.
• «Lo SBOM va pubblicato». Va redatto e tenuto nella documentazione tecnica, consegnato all’autorità su richiesta motivata; renderlo disponibile agli utilizzatori è una scelta del fabbricante.
• «Siamo una piccola impresa, siamo esenti». Le micro e piccole imprese sono escluse solo dalle sanzioni pecuniarie per il mancato rispetto del termine di preallarme; tutti gli altri obblighi restano.