Cyber Resilience Act (CRA): Sicurezza Obbligatoria per Software e Hardware IoT

Nota metodologica. La presente analisi è aggiornata al 17 giugno 2026. Il Regolamento (UE) 2024/2847 (Cyber Resilience Act) è entrato in vigore il 10 dicembre 2024. Gli obblighi di notifica delle vulnerabilità attivamente sfruttate e degli incidenti si applicano dall'11 settembre 2026. Gli obblighi principali (progettazione sicura, vulnerability handling, CE marking) si applicano dall'11 dicembre 2027. Il contenuto ha finalità esclusivamente informativa e non costituisce parere legale.

Fonti primarie: Reg. UE 2024/2847 (CRA), EUR-Lex · EU Commission, CRA · ENISA, CRA

1. Perché il CRA è rilevante per ogni sviluppatore software

Prima del CRA, non esisteva un obbligo normativo generale per i produttori di software di progettare i propri prodotti con criteri di cybersecurity. Il CRA cambia radicalmente questo scenario, introducendo l'obbligo di security by design per tutti i prodotti con elementi digitali, analogamente a quanto il GDPR ha fatto per la privacy by design.

Il CRA si inserisce nel quadro della legislazione europea sulla cybersicurezza, complementando NIS2 (sicurezza dei processi organizzativi) con requisiti di sicurezza del prodotto (progettazione, sviluppo e manutenzione).

2. A chi si applica il CRA

Esclusioni importanti

• Servizi SaaS: esclusi dall'ambito CRA perché regolati da NIS2/DORA, ma il software client del servizio SaaS (es. app mobile, desktop) è coperto
• Software open source sviluppato al di fuori di un'attività commerciale: il CRA si applica solo se il software è distribuito "nell'ambito di un'attività commerciale" (Art. 2.8 CRA)
• Dispositivi già regolamentati: medici (MDR), aeronautici, automotive, veicoli, già soggetti a regolamentazioni settoriali di sicurezza

3. I requisiti principali per i produttori

3.1 Progettazione e sviluppo sicuri (Artt. 10-13)

Il prodotto deve essere progettato, sviluppato e prodotto in modo da garantire un livello di sicurezza adeguato al rischio. Questo significa:

• Principio di minimizzazione delle superfici di attacco: ridurre al minimo le porte di ingresso accessibili
• Gestione degli accessi: autenticazione forte, controllo degli accessi basato sui ruoli
• Crittografia: cifratura dei dati a riposo e in transito, gestione sicura delle chiavi
• Integrità del software: aggiornamenti firmati digitalmente, protezione contro il rolling back a versioni vulnerabili
• Configurazione sicura di default: password univoche per ogni dispositivo, servizi non necessari disattivati

3.2 Vulnerability handling policy (Art. 14)

Il produttore deve istituire una procedura documentata per la gestione delle vulnerabilità che includa:

• Un canale di ricezione delle segnalazioni di vulnerabilità (es. indirizzo email security@, modulo web, piattaforma HackerOne)
• Un processo di triage, valutazione e prioritizzazione delle vulnerabilità
• L'obbligo di rilasciare patch di sicurezza per le vulnerabilità note per l'intero "periodo di supporto" dichiarato
• La pubblicazione delle vulnerabilità risolte dopo il rilascio della patch (coordinated disclosure)

3.3 Notifica delle vulnerabilità e incidenti (Art. 16), dall'11 settembre 2026

Il produttore deve notificare all'ENISA e, in Italia, al CSIRT Italia:

1. Vulnerabilità attivamente sfruttate presenti nel prodotto
2. Incidenti che hanno un impatto sulla sicurezza del prodotto
3. Minacce imminenti con potenziale impatto sul prodotto

La notifica va effettuata entro 24 ore per la pre-notifica (allerta precoce) e 72 ore per la notifica completa. I dettagli sono stabiliti nel Regolamento di esecuzione adottato dalla Commissione.

3.4 Dichiarazione di conformità e marcatura CE (Artt. 25-28)

Il produttore deve:

• Redigere una dichiarazione di conformità UE che attesti il rispetto dei requisiti CRA
• Apporre la marcatura CE sul prodotto o sul suo imballaggio
• Predisporre la documentazione tecnica completa (architettura, specifiche di sicurezza, risultati dei test)

3.5 Valutazione di conformità

Il CRA suddivide i prodotti in tre categorie con diversi livelli di controllo:

4. Sanzioni

5. CRA e open source: cosa cambia per gli sviluppatori

Uno degli aspetti più dibattuti del CRA è il trattamento del software open source. Il Regolamento adotta un approccio differenziato:

• Sviluppatore individuale o comunità che distribuisce software open source senza scopo di lucro: esente dagli obblighi CRA, purché il software sia "sviluppato e fornito al di fuori di un'attività commerciale"
• Impresa che distribuisce software open source nell'ambito della propria attività commerciale (es. una startup che sviluppa un database open source ma offre anche servizi premium): soggetta agli obblighi CRA
• Contributore a un progetto open source: non è responsabile per il prodotto finito (la responsabilità è del produttore che immette il prodotto sul mercato)

Per gli sviluppatori individuali, la soglia di esenzione è il non esercizio di un'attività economica: la semplice ricezione di donazioni o sponsorizzazioni non configura attività commerciale, ma il rapporto di lavoro con un'azienda che distribuisce il software sì.

6. Cosa fare subito

1. Dall'11 settembre 2026 (tra 3 mesi): predisporre il processo di notifica delle vulnerabilità attivamente sfruttate verso ENISA/CSIRT Italia
2. Predisporre la vulnerability handling policy: canale di segnalazione, processo di triage, SLA per il rilascio di patch
3. Avviare l'adeguamento tecnico: security by design, crittografia, aggiornamenti firmati, configurazioni sicure di default
4. Documentare la conformità: redigere la documentazione tecnica necessaria per la dichiarazione di conformità CE
5. Per software critici: identificare se è necessaria una certificazione di terza parte e avviare le attività di assessment

Domande Frequenti (FAQ)

Il CRA si applica alle app mobile sviluppate da una startup italiana? Sì, le app mobile sono "prodotti con elementi digitali" ai sensi del CRA. La startup deve garantire la sicurezza dell'app (crittografia, aggiornamenti, gestione vulnerabilità) e potrà autocertificare la conformità se l'app non rientra nelle categorie critiche.

Cosa succede se un prodotto conforme viene venduto prima dell'11 dicembre 2027? I prodotti immessi sul mercato prima dell'11 dicembre 2027 non sono soggetti agli obblighi principali del CRA (Art. 64). Tuttavia, gli aggiornamenti software sostanziali rilasciati dopo tale data potrebbero far scattare l'applicazione delle nuove regole (come già previsto dalla nuova PLD per le modifiche sostanziali).

Il CRA si applica ai sistemi AI? I sistemi AI sono "prodotti con elementi digitali" e rientrano nell'ambito del CRA. Tuttavia, i sistemi AI ad alto rischio ai sensi dell'AI Act sono considerati conformi ai requisiti CRA per gli aspetti già coperti dall'AI Act (presunzione di conformità, Art. 7 CRA). Il produttore deve comunque soddisfare i requisiti CRA non coperti dall'AI Act (es. vulnerability handling, notifica di vulnerabilità).

Un revisore di sicurezza (penetration tester) ha obblighi CRA? No. I servizi di penetration testing e vulnerability assessment non sono prodotti con elementi digitali, ma servizi professionali. I tester che sviluppano strumenti software nell'ambito della loro attività commerciale potrebbero invece esservi soggetti.

Approfondimenti consigliati:

• NIS2: Supply Chain, Notifica Incidenti e Board Liability
• DORA: Resilienza Operativa Digitale
• Data Breach e Mancata Notifica: Sanzioni del Garante
• Nuova PLD: Responsabilità per Danni da Software e IA

Fonti: Reg. UE 2024/2847 (CRA), EUR-Lex; EU CRA Page; ENISA, EU Cybersecurity.