Il Cyber Resilience Act spiegato: sicurezza nei prodotti digitali

Il Cyber Resilience Act — Regolamento (UE) 2024/2847 — è la prima normativa europea che impone requisiti di cybersicurezza orizzontali ai prodotti con elementi digitali immessi sul mercato dell’Unione. Approvato nel 2024, si applica a partire dal 2027, con alcuni obblighi (in particolare quelli di segnalazione) anticipati. Essendo un regolamento, è direttamente applicabile in tutti gli Stati membri senza bisogno di recepimento nazionale.

La logica è quella della sicurezza dei prodotti che l’Europa già conosce — come la marcatura CE — estesa al software e all’hardware connesso. In pratica: se mette sul mercato un prodotto che può connettersi a una rete o a un altro dispositivo, deve poter dimostrare che è progettato e mantenuto in modo sicuro per tutto il suo ciclo di vita.

A chi si applica

Il perimetro è ampio: rientrano i prodotti con elementi digitali, ovvero qualsiasi prodotto software o hardware la cui destinazione d’uso include una connessione logica o fisica a un dispositivo o a una rete. Vi rientrano quindi router e telecamere IP, ma anche sistemi operativi, librerie e applicazioni. Gli obblighi ricadono principalmente sul fabbricante, con responsabilità proporzionate anche per importatori e distributori.

Ci sono esclusioni rilevanti: prodotti già regolati da normative settoriali equivalenti (per esempio dispositivi medici, aeronautica, veicoli) e — punto spesso frainteso — il software libero e open source sviluppato al di fuori di un’attività commerciale. Il CRA introduce inoltre la figura dello steward del software open source, con obblighi più leggeri.

Security-by-design come requisito di legge

Il cuore del regolamento è l’Allegato I, che elenca i requisiti essenziali di cybersicurezza. Il prodotto deve essere immesso sul mercato senza vulnerabilità note sfruttabili, con una configurazione sicura per impostazione predefinita, con la possibilità di ripristinare lo stato di fabbrica, con protezione dei dati e minimizzazione della superficie di attacco, con capacità di registrare gli eventi di sicurezza rilevanti. Non è un manifesto di buone intenzioni: è un elenco di proprietà verificabili che il fabbricante deve garantire e documentare.

Questo cambia il modo di lavorare a monte. La sicurezza non può più essere aggiunta a valle: va progettata, e va provata attraverso una valutazione di conformità la cui severità dipende dalla criticità del prodotto (con categorie di prodotti importanti e critici soggette a requisiti più stringenti).

Gestione delle vulnerabilità lungo il ciclo di vita

Il secondo pilastro è la gestione delle vulnerabilità per tutto il periodo di supporto, che di norma è di almeno cinque anni salvo prodotti con vita utile più breve. Il fabbricante deve identificare e documentare le vulnerabilità e i componenti — anche attraverso una distinta base del software, la SBOM — distribuire aggiornamenti di sicurezza tempestivi e gratuiti, e adottare una politica di divulgazione coordinata delle vulnerabilità.

È qui che molte aziende scoprono un debito nascosto: non sanno con precisione cosa contengono i loro prodotti. La SBOM smette di essere una buona pratica e diventa il presupposto per poter rispettare la legge.

C’è poi una conseguenza organizzativa che si tende a sottovalutare: un obbligo di supporto pluriennale ricade su un prodotto che magari verrà venduto per pochi anni, ma che va mantenuto sicuro ben oltre. Significa pianificare risorse di manutenzione già in fase di progettazione, prevedere come si distribuiranno gli aggiornamenti anche a installazioni datate, e decidere cosa accade quando un componente di terze parti smette di essere manutenuto a monte. Sono scelte di prodotto, non solo di sicurezza.

Obblighi di segnalazione a ENISA

Il CRA introduce obblighi di segnalazione stringenti. Il fabbricante deve notificare le vulnerabilità attivamente sfruttate e gli incidenti gravi che impattano la sicurezza del prodotto attraverso una piattaforma unica di notifica coordinata da ENISA, che smista alle autorità nazionali competenti (i CSIRT). I tempi sono serrati: un primo pre-allarme entro 24 ore, seguito da notifiche più complete nei giorni successivi. La ratio è dare all’ecosistema europeo visibilità in tempo reale sulle minacce che si stanno propagando attraverso prodotti diffusi.

Cosa fare adesso

Il 2027 sembra lontano ma il ciclo di sviluppo di un prodotto non lo è. Conviene partire da tre azioni: mappare il proprio portafoglio prodotti rispetto all’ambito e alle categorie di criticità; costruire o consolidare una SBOM e un processo di gestione delle vulnerabilità con canali di divulgazione; e definire fin da subito politiche di supporto e aggiornamento realistiche, perché il periodo di supporto è un impegno contrattuale e regolatorio, non uno slogan di marketing.

In sintesi

Il CRA porta nel software la stessa disciplina che l’Europa applica da decenni alla sicurezza dei prodotti fisici. Non premia chi documenta meglio, ma chi progetta e mantiene meglio. Per chi produce, la domanda non è più se rendere sicuri i prodotti, ma come dimostrarlo — e la risposta si costruisce ora, nel modo in cui si sviluppa e si tiene in vita ciò che si vende.