Il CRA non chiede di rendere il tuo software “perfetto”. Chiede che ogni prodotto con elementi digitali sia progettato per la sicurezza e che le vulnerabilità vengano gestite e segnalate per tutta la sua vita. È il momento in cui “ho un canale di supporto” non basta più.

Che cos’è e perché conta 🔍

Il Regolamento (UE) 2024/2847 — noto come Cyber Resilience Act (CRA) o “legge sulla ciberresilienza” — è la prima normativa orizzontale europea che impone requisiti essenziali di cibersicurezza per tutti i prodotti con elementi digitali. È stato adottato il 23 ottobre 2024 e pubblicato nella Gazzetta ufficiale dell’Unione europea il 20 novembre 2024 (GU L 2024/2847).

È un regolamento: direttamente applicabile in tutti gli Stati membri senza recepimento nazionale. È entrato in vigore l’11 dicembre 2024 (ventesimo giorno dopo la pubblicazione) e si applica a decorrere dall’11 dicembre 2027, con alcune disposizioni operative già da prima (vedi Timeline e scadenze).

L’obiettivo è dichiarato senza giri di parole: la cibersicurezza non finisce più dove finisce il software di un’azienda. Ogni prodotto connesso — dal router al frigorifero smart, dal firewall al software gestionale — deve essere sicuro per progettazione, rimanere aggiornato durante il suo ciclo di vita e segnalare vulnerabilità e incidenti alle autorità.

Il CRA colma il “buco” tra le normative: NIS 2 regola le organizzazioni che gestiscono infrastrutture, il GDPR i dati personali, ma nessuno regolava i prodotti digitali in sé. Ora tocca a loro.

A chi si applica 🎯

Cosa è un “prodotto con elementi digitali” 📦

Definizione ampia (Art. 3): qualsiasi prodotto software o hardware — e le relative soluzioni di elaborazione dati da remoto — compresi i componenti software o hardware immessi sul mercato separatamente, la cui finalità prevista o il cui uso ragionevolmente prevedibile include una connessione dati (logica o fisica, diretta o indiretta) a un dispositivo o a una rete.

In pratica: quasi tutto ciò che ha un firmware, un’app o una API verso l’esterno. Un’app mobile, un dispositivo IoT, un router, un ERP connesso, un SDK. Se “parla” con qualcosa, il CRA è rilevante.

Chi sono i soggetti obbligati 👤

• Fabbricante (Art. 3.13): chi sviluppa o fa sviluppare un prodotto con elementi digitali e lo commercializza con il proprio nome o marchio, a titolo oneroso, di monetizzazione o gratuito;
• Rappresentante autorizzato, importatore, distributore (per i prodotti di fabbricanti di paesi terzi);
• Gestore di software open source (Art. 3.14): entità che fornisce sostegno sistematico e duraturo per lo sviluppo di prodotti open source destinati ad attività commerciali, garantendone la sostenibilità economica.

Il richiamo commerciale della definizione di fabbricante non è casuale: l’uso gratuito non ti salva. Anche un’app gratuita con pubblicità o telemetria rientra nella commercializzazione.

Esclusioni principali (Art. 2) ⛔

• Dispositivi medici (Regolamento 2017/745) e medico-diagnostici in vitro (2017/746);
• Veicoli a motore (2019/2144) e aeromobili certificati (2018/1139);
• Equipaggiamento marittimo (2014/90);
• Pezzi di ricambio per sostituire componenti identici;
• Prodotti sviluppati o modificati esclusivamente per sicurezza nazionale, difesa o trattamento di informazioni classificate.

Settori regolati da altro diritto UE (es. dispositivi medici) restano soggetti alle proprie normative, ma il CRA si applica horizontalmente a tutto il resto. Le due filiere software/hardware che non ne vengono toccate sono davvero poche.

I requisiti essenziali di cibersicurezza 📋

Il cuore del CRA è l’Allegato I, diviso in due parti.

Parte I — Proprietà del prodotto 🧱

Il prodotto deve essere progettato, sviluppato e prodotto per garantire un livello adeguato di cibersicurezza in base al rischio. Tra i requisiti:

• venduto senza vulnerabilità sfruttabili note;
• configurazione sicura per impostazione predefinita (secure by default), senza password di default;
• aggiornamenti di sicurezza gestibili, preferibilmente automatici con possibilità di rinvio;
• protezione da accessi non autorizzati (autenticazione, gestione identità);
• crittografia dei dati a riposo e in transito, protezione di riservatezza e integrità;
• minimizzazione dei dati: trattare solo i dati necessari alla finalità;
• disponibilità delle funzioni essenziali anche dopo un incidente, resilienza anti-DoS;
• limitazione delle superfici di attacco (interfacce esterne), attenuazione dello sfruttamento;
• log e monitoraggio delle attività interne accessibili all’utilizzatore;
• possibilità di rimozione sicura e definitiva dei dati.

Parte II — Gestione delle vulnerabilità 🐛

Il fabbricante deve:

• identificare e documentare vulnerabilità e componenti, redigendo una distinta base del software (SBOM) in formato leggibile da dispositivo automatico, con le dipendenze di primo livello;
• affrontare e correggere le vulnerabilità con aggiornamenti di sicurezza, separati dagli aggiornamenti di funzionalità ove tecnicamente fattibile;
• effettuare prove e riesami di sicurezza periodici;
• divulgare pubblicamente le vulnerabilità corrette con descrizione, impatto, gravità e istruzioni per la correzione;
• adottare una politica di divulgazione coordinata delle vulnerabilità (coordinated vulnerability disclosure);
• mettere a disposizione un punto di contatto unico per la segnalazione delle vulnerabilità;
• distribuire gli aggiornamenti in modo sicuro;
• fornire gli aggiornamenti tempestivamente e gratuitamente (salvo accordi per prodotti su misura).

La SBOM non è un’opzione: è il modo concreto di “sapere cosa c’è dentro”. Se non hai l’elenco delle dipendenze in formato machine-readable, il CRA ti obbliga a costruirlo.

Gli obblighi dei fabbricanti (Art. 13) 🏭

Oltre ai requisiti essenziali, il fabbricante deve:

1. Valutazione del rischio di cibersicurezza documentata, aggiornata durante il periodo di assistenza;
2. Dovuta diligenza sui componenti di terzi, compreso l’open source integrato: segnalare le vulnerabilità dei componenti e condividere codice/correttivi con chi lo mantiene;
3. Periodo di assistenza (support period): almeno 5 anni dalla data di immissione sul mercato, o corrispondente alla durata prevista d’uso se inferiore. Quando il prodotto è destinato a uso prolungato (router, sistemi operativi, schede madri), il periodo deve superare i 5 anni;
4. Mantenere disponibili gli aggiornamenti di sicurezza per almeno 10 anni dal rilascio (o il restante periodo di assistenza, se maggiore);
5. Documentazione tecnica (art. 31, Allegato VII) e dichiarazione di conformità UE (Art. 28) + marcatura CE (Art. 30);
6. Conservare documentazione e dichiarazione per 10 anni;
7. Punto di contatto unico per le segnalazioni degli utenti; identificazione del prodotto (numero di tipo/lotto/serie); informazioni e istruzioni all’utente in linguaggio chiaro, conservate per 10 anni;
8. Notifica della fine del periodo di assistenza e, in caso di cessazione dell’attività, informativa alle autorità e agli utenti;
9. Misure correttive in caso di non conformità (ritiro o richiamo del prodotto).

La segnalazione di vulnerabilità e incidenti (Art. 14) 🚨

Il pezzo più operativo per chi fa software è l’obbligo di segnalazione simultanea al CSIRT designato come coordinatore e all’ENISA, tramite la piattaforma unica di segnalazione (Art. 16).

Vulnerabilità attivamente sfruttata 📢

• Preallarme entro 24 ore dalla conoscenza;
• Notifica entro 72 ore con informazioni generali su prodotto, natura dello sfruttamento, misure correttive adottate e grado di sensibilità;
• Relazione finale entro 14 giorni dalla messa a disposizione di una misura correttiva: descrizione, gravità, impatto, soggetto malintenzionato (se noto), aggiornamento di sicurezza.

Incidente grave con impatto sulla sicurezza del prodotto 🧯

Considerato grave se incide (o può incidere) sulla capacità del prodotto di proteggere disponibilità, autenticità, integrità o riservatezza di dati o funzioni sensibili, oppure se ha portato (o può portare) all’introduzione di codice maligno nel prodotto o nei sistemi dell’utilizzatore (Art. 14.5).

• Preallarme entro 24 ore;
• Notifica entro 72 ore con natura dell’incidente e valutazione iniziale;
• Relazione finale entro 1 mese dall’invio della notifica.

In entrambi i casi il fabbricante deve informare gli utilizzatori del prodotto interessato (Art. 14.8).

Nota operativa: la segnalazione va fatta con i terminali del CSIRT dello Stato membro dello stabilimento principale del fabbricante; per i fabbricanti extra-UE, secondo criteri di priorità (rappresentante autorizzato, importatore, distributore, maggior numero di utilizzatori). Se non hai stabilito “chi notifica dove”, è il momento di deciderlo.

Esistono anche obblighi di segnalazione volontaria (Art. 15) per vulnerabilità e minacce non coperte dall’obbligo.

Valutazione della conformità e classificazione ✅

Il CRA introduce una graduazione del rigore in base alla natura del prodotto:

Categoria	Esempi	Procedura di valutazione
Prodotti generali	App, software gestionale, dispositivi IoT comuni	Autovalutazione (controllo interno, Allegato VIII)
Prodotti importanti — Classe I (Allegato III)	Password manager, browser, VPN, antivirus, SIEM, sistemi operativi, router/modem	Autovalutazione (controllo interno)
Prodotti importanti — Classe II (Allegato III)	Firewall, sistemi di rilevamento/prevenzione intrusioni, hypervisor, runtime container	Valutazione da parte terza (organismo notificato)
Prodotti critici (Allegato IV)	Moduli hardware di sicurezza, gateway contatori smart, smart card	Certificazione europea di cibersicurezza (EUCC) obbligatoria

Sebbene i prodotti “generali” e di Classe I possano autovalutarsi, la documentazione (art. 31, Allegato VII) deve comunque dimostrare la conformità: i requisiti restano gli stessi, cambia solo chi verifica.

Regola d’oro: se il tuo prodotto è un firewall o un hypervisor, sei in Classe II e hai bisogno di un organismo notificato. Non è una valutazione di comodo: è marcatura CE con terza parte, come per i dispositivi medici.

Impatto per le aziende 🏢

Se produci o distribuisci software/hardware nel mercato UE, il percorso di conformità è:

1. Inventario prodotti: identificare tutti i prodotti con elementi digitali (inclusi componenti e SDK);
2. Classificazione: determinare se il prodotto è generale, importante (Classe I/II) o critico;
3. Gap analysis vs Allegato I: proprietà del prodotto + gestione vulnerabilità;
4. Valutazione del rischio di cibersicurezza documentata;
5. SBOM + politica di divulgazione coordinata + punto di contatto unico;
6. Procedura di valutazione della conformità (autovalutazione o organismo notificato);
7. Documentazione tecnica + dichiarazione di conformità UE + marcatura CE;
8. Periodo di assistenza definito e comunicato; aggiornamenti disponibili.

Sanzioni (Art. 64 — massimi stabiliti a livello UE, poi applicati dagli Stati membri):

Violazione	Sanzione massima
Mancata conformità ai requisiti essenziali (Allegato I) e agli obblighi di cui agli artt. 13 e 14	€15.000.000 o 2,5% del fatturato mondiale
Mancata conformità ad altri obblighi (documentazione, dichiarazione, marcatura, obblighi operatori)	€10.000.000 o 2% del fatturato mondiale
Informazioni inesatte, incomplete o fuorvianti agli organismi/autorità	€5.000.000 o 1% del fatturato mondiale

Esenzioni mirate (Art. 64.10): le sanzioni non si applicano ai gestori di software open source (per violazioni del regolamento) e ai fabbricanti micro/piccole imprese per il mancato rispetto delle scadenze di preallarme (24h). Non è un salvacondotto: le altre violazioni restano sanzionabili.

La previsione di copertura del periodo di assistenza di almeno 5 anni e della disponibilità degli aggiornamenti per 10 anni cambia i modelli di business: chi rilascia “software abbandonato” dopo la vendita non potrà più farlo impunemente.

Impatto per gli sviluppatori 💻

Il CRA cambia il daily work molto più di NIS 2 o GDPR:

• Secure by default: niente password di default, configurazione sicura preimpostata, aggiornamenti automatici con opt-out;
• SBOM: l’elenco delle dipendenze in formato machine-readable (es. CycloneDX, SPDX) non è più un lusso, è un requisito;
• Vulnerability management: processo strutturato per ricevere, valutare, correggere e divulgare le vulnerabilità; politica di coordinated disclosure;
• Prove e riesami periodici di sicurezza: non basta scrivere test funzionali, servono test di sicurezza ripetuti;
• Notifica incidenti/vulnerabilità nei tempi: 24h/72h + relazione finale (14 giorni / 1 mese) verso CSIRT ed ENISA;
• Documentazione di conformità: documentazione tecnica, dichiarazione di conformità UE, conservazione 10 anni;
• Componenti open source: dovuta diligenza quando li integri, segnalazione delle vulnerabilità ai manutentori, condivisione dei correttivi.

L’esempio pratico che fa capire tutto: un’app mobile che si aggiorna da sola, gira su HTTPS, non tiene password in chiaro e salva un registro dei login probabilmente soddisfa già la Parte I. Della Parte II, la parte più nuova è “sai esattamente quali librerie hai dentro e cosa fai quando una ha una falla?”.

Timeline e scadenze 📆

Data	Cosa si applica
11 dicembre 2024	Entrata in vigore (20 giorni dopo la pubblicazione del 20.11.2024)
11 giugno 2026	Capo IV (articoli 35-51: vigilanza del mercato, ENISA, notifiche)
11 settembre 2026	Art. 14 — obblighi di segnalazione di vulnerabilità e incidenti
11 dicembre 2027	Applicazione a regime del regolamento
Dal 11 dicembre 2027	I prodotti immessi sul mercato prima dell'11/12/2027 sono soggetti solo se subiscono una modifica sostanziale — ma gli obblighi di segnalazione Art. 14 restano applicabili a tutti i prodotti esistenti
Certificati UE esistenti	Validi fino all’11 giugno 2028

In pratica: dal settembre 2026 hai già l’obbligo di segnalare vulnerabilità e incidenti anche sui prodotti già sul mercato. Il resto degli obblighi (progettazione, documentazione, marcatura) scatta a regime col 2027.

Checklist di conformità ✅

Checklist sintetica per sviluppatori e aziende.

Prodotto e design

• Prodotto identificato (tipo/lotto/numero di serie)
• Nessuna vulnerabilità sfruttabile nota al rilascio
• Configurazione sicura per default, niente password di default
• Aggiornamenti di sicurezza gestibili (meglio automatici con opt-out)
• Autenticazione e gestione accessi; log degli accessi
• Crittografia dati a riposo e in transito
• Minimizzazione dei dati; rimozione sicura dei dati
• Resilienza anti-DoS e limitazione superfici di attacco

Vulnerabilità e ciclo di vita

• Valutazione del rischio di cibersicurezza documentata
• SBOM in formato machine-readable
• Politica di divulgazione coordinata delle vulnerabilità
• Punto di contatto unico per segnalazioni
• Processo di patch + aggiornamenti gratuiti nel periodo di assistenza
• Prove e riesami periodici di sicurezza
• Governato il support period (≥5 anni) e comunicata la fine

Notifica e conformità

• Decisione firmata: chi notifica, dove (CSIRT + ENISA), entro quando
• Runbook 24h/72h + relazione finale (14 giorni / 1 mese)
• Informativa degli utilizzatori in caso di incidente/vulnerabilità
• Documentazione tecnica (Allegato VII) aggiornata
• Dichiarazione di conformità UE + marcatura CE
• Documentazione conservata per 10 anni
• Classificazione del prodotto (generale / importante I-II / critico)

Collegamenti utili 🔗

• Testo del Cyber Resilience Act (EUR-Lex) — Regolamento (UE) 2024/2847
• Pagina CRA della Commissione europea — Fatti chiave e orientamenti
• ENISA — Piattaforma unica di segnalazione e rapporti tecnici
• Rete CSIRT / CSIRT Italia — Contatti per la segnalazione in Italia
• EUCC — Sistema europeo di certificazione — Per i prodotti critici
• CycloneDX / SPDX — Formati per la SBOM interopali sulla vulnerabilità

Vedi anche 📖

• NIS 2 — Cybersecurity — La sicurezza delle organizzazioni: il CRA completa il quadro a livello di prodotto
• AI Act — Requisiti di cybersicurezza per l’IA ad alto rischio, complementari al CRA
• GDPR — Dati personali: la minimizzazione richiesta dal CRA è lo stesso principio GDPR
• Data Act — Il diritto alla portabilità dei dati generati dai prodotti con elementi digitali
• Legge AI Italiana — Il piano nazionale sull’IA per chi sviluppa in Italia