Salta al contenuto

Cos'è il Cyber Resilience Act e cosa cambia per chi sviluppa software?

Regolamento UE che impone requisiti di cybersicurezza obbligatori ai prodotti con elementi digitali: SBOM, notifica vulnerabilità, marcatura CE.

Il Cyber Resilience Act (CRA) è il regolamento UE entrato in vigore il 10 dicembre 2024 che introduce requisiti di cybersicurezza obbligatori per i prodotti con elementi digitali, hardware e software, immessi sul mercato europeo. La marcatura CE, finora legata a sicurezza fisica ed elettrica, da ora certifica anche la sicurezza informatica del prodotto: senza i requisiti del CRA, quel prodotto non può essere venduto legalmente nell'Unione Europea. Il regolamento copre una gamma amplissima di prodotti: un router domestico, un'app mobile scaricata da uno store, un macchinario industriale connesso o persino un giocattolo intelligente rientrano tutti nella stessa logica normativa, purché abbiano una connessione, diretta o indiretta, a una rete o a un altro dispositivo. Per chi produce software questo significa che anche un prodotto apparentemente innocuo, penso a un'app di fitness che sincronizza dati con il cloud, deve dimostrare di aver applicato pratiche di sicurezza by design fin dalla progettazione, non aggiunte in un secondo momento come toppa.

Leggi anche: security.txt · File pubblicato in /.well-known/security.txt che indica, in forma leggibile da macchina, a chi segnalare una vulnerabilità.

A chi si applica davvero

Non riguarda solo le grandi aziende tech. Il CRA si applica a chiunque produca o distribuisca software con elementi digitali destinato al mercato UE: software house, produttori di dispositivi connessi, ma anche chi integra componenti di terzi (incluse librerie open source) nei propri prodotti. Il software offerto come servizio (SaaS) in genere resta fuori: rientra solo l'elaborazione remota dei dati senza la quale il prodotto non svolgerebbe una delle sue funzioni. Una PMI che vende un'app o un dispositivo IoT in Europa è in scope tanto quanto un grande vendor, e la responsabilità di verificare la propria condizione di conformità ricade sul produttore, non sull'autorità.

Gli obblighi pratici principali

Il primo è la SBOM (Software Bill of Materials): un inventario documentato, in formato leggibile da macchina, dei componenti software usati nel prodotto, incluse le dipendenze open source almeno di primo livello. Senza SBOM non si può dimostrare cosa contiene il proprio software, né reagire in fretta quando una libreria terza risulta vulnerabile. Il secondo è la notifica delle vulnerabilità attivamente sfruttate: dall'11 settembre 2026 vale l'obbligo di segnalarle a ENISA, l'agenzia europea per la cybersicurezza, e al CSIRT nazionale, la squadra pubblica che gestisce gli incidenti informatici, entro una finestra molto stretta, nell'ordine delle 24 ore dalla presa di conoscenza, con un report più dettagliato a seguire e uno finale a chiusura. Il terzo è la sicurezza by design lungo tutto il ciclo di vita del prodotto, non solo al momento del rilascio: aggiornamenti di sicurezza, gestione delle patch, fine vita comunicata ai clienti. La piena applicabilità dei requisiti essenziali e della conformità, incluso il marchio CE, arriva l'11 dicembre 2027.

L'angolo pratico

Per un'azienda che sviluppa software o lo integra nei propri prodotti, il CRA non è prima di tutto un tema legale: è un processo tecnico da costruire per tempo. Serve sapere quali componenti (e quali dipendenze di terzi) finiscono in produzione, avere un processo per generare e mantenere la SBOM a ogni release, e un canale operativo per la divulgazione delle vulnerabilità che rispetti i tempi stretti richiesti. Chi aspetta il 2027 per iniziare arriva tardi: mappare le proprie dipendenze software è un lavoro che richiede mesi, non settimane.

Perché conta insieme alla NIS2

Il CRA e la NIS2 sono regolamenti complementari, non sovrapposti: la NIS2 impone la sicurezza a livello di organizzazione (chi la usa, come la gestisce), il CRA impone la sicurezza a livello di prodotto (cosa viene venduto, cosa contiene). Un'azienda soggetta a entrambi deve trattarli come due binari dello stesso programma di cybersicurezza, con owner e processi che si parlano.

Questa voce è informativa e non costituisce consulenza legale: per decisioni su conformità e marcatura CE coinvolgi il tuo ufficio legale o un consulente specializzato.

Domande frequenti

L'obbligo di segnalare a ENISA e al CSIRT nazionale le vulnerabilità attivamente sfruttate è operativo dall'11 settembre 2026, con una finestra di notifica molto stretta, nell'ordine delle 24 ore dalla presa di conoscenza.

Il CRA copre in generale i prodotti con elementi digitali, hardware e software. Il SaaS puro in genere è escluso: rientra solo l'elaborazione remota dei dati progettata dal produttore e necessaria perché il prodotto svolga una sua funzione, come il backend cloud di un'app o di un dispositivo connesso. La verifica va fatta caso per caso.
  • security.txt · File pubblicato in /.well-known/security.txt che indica, in forma leggibile da macchina, a chi segnalare una vulnerabilità.
  • AI governance · Politiche, ruoli e controlli con cui un'azienda governa l'uso dell'AI: inventario dei sistemi, classificazione del rischio, approvazioni e monitoraggio.
  • DevSecOps · Estensione del DevOps che integra la sicurezza come responsabilità condivisa nella pipeline CI/CD, non come controllo finale separato.
  • SBOM (Software Bill of Materials) · La SBOM è l'inventario machine readable dei componenti software di un prodotto, generato ad ogni release.
  • Secure by design · Principio per cui la sicurezza è progettata nel prodotto fin dall'origine, non aggiunta dopo il rilascio.

Vedi nell'universo

Se è un rischio per la tua azienda, ti dico da dove partire senza venderti paura.

VEDI SICUREZZA E CONFORMITÀ

Oppure scrivimi.