Cyber Resilience Act: obblighi, scadenze e impatto sulla protezione dei dati aziendali

Il Cyber Resilience Act non è semplicemente un’altra direttiva europea da archiviare nella cartella della compliance. È un cambiamento strutturale nel modo in cui l’Unione Europea intende la sicurezza dei prodotti digitali, e le sue implicazioni riguardano non solo chi sviluppa software, ma anche chi lo acquista, lo integra e lo utilizza ogni giorno per gestire dati sensibili.

Per le aziende che operano in settori regolamentati come bancario, sanitario e pubblica amministrazione, il Cyber Resilience Act introduce nuove responsabilità concrete: dalla valutazione dei fornitori alla protezione dei file e delle email, fino alla necessità di dimostrare che i dati aziendali sono trattati con strumenti conformi ai requisiti essenziali di sicurezza. Questa guida analizza il regolamento CRA in modo pratico, con focus sulle scadenze del 2026, sugli obblighi reali e su come la crittografia e la protezione dei dati diventano leve fondamentali per costruire una conformità solida e duratura.

Cos’è il Cyber Resilience Act e perché cambia le regole del gioco

Il Cyber Resilience Act, formalmente il Regolamento UE 2024/2847, è stato pubblicato nella Gazzetta Ufficiale dell’Unione Europea il 20 novembre 2024 ed è entrato in vigore il 10 dicembre 2024. Il suo obiettivo principale è garantire che tutti i prodotti con elementi digitali immessi sul mercato europeo rispettino requisiti minimi di cybersecurity per l’intero ciclo di vita, dalla progettazione al ritiro.

Prima del CRA, la sicurezza informatica dei prodotti digitali era regolata in modo frammentato: alcune normative settoriali, standard volontari e un quadro normativo che lasciava ampi margini di discrezionalità. Il CRA introduce per la prima volta un obbligo orizzontale e vincolante: i prodotti digitali devono essere sicuri by design e by default, e i fabbricanti devono garantire la gestione attiva delle vulnerabilità per tutto il periodo di supporto dichiarato.

Il perimetro del regolamento è ampio. Sono coinvolti fabbricanti (inclusi i produttori di software), importatori e distributori che operano nel mercato europeo. Ma, come si vedrà più avanti, anche le aziende acquirenti hanno obblighi indiretti che non possono essere ignorati.

Quali prodotti e software rientrano nel CRA

Il CRA si applica ai “prodotti con elementi digitali”: qualsiasi prodotto hardware o software che include componenti digitali in grado di comunicare con reti o dispositivi. Rientrano nell’ambito applicativo i software standalone, i sistemi operativi, le applicazioni, i firmware, ma anche dispositivi fisici con componenti connesse.

Il regolamento distingue tre categorie principali:

• Prodotti standard: la maggior parte dei prodotti digitali, soggetti a valutazione di conformità tramite autovalutazione (Modulo A).
• Prodotti importanti (Allegato III): divisi in Classe I e Classe II, includono browser, gestori di password, firewall, sistemi di controllo industriale, VPN e altri strumenti con impatto significativo sulla sicurezza. Richiedono percorsi di conformità più rigorosi.
• Prodotti critici (Allegato IV): hardware e software con impatto critico sulle infrastrutture, come smartcard, HSM e sistemi di autenticazione avanzata. Richiedono obbligatoriamente il coinvolgimento di un organismo notificato.

Alcune esclusioni rilevanti: prodotti già coperti da normative settoriali specifiche (come dispositivi medici regolati dall’MDR o veicoli a motore), software open source sviluppato al di fuori di attività commerciali, e servizi cloud puri non incorporati in un prodotto. Attenzione, però: il software SaaS che costituisce parte integrante di un prodotto con elementi digitali può rientrare nell’ambito del CRA. La distinzione non è sempre immediata e richiede un’analisi caso per caso.

Il calendario degli obblighi CRA: le scadenze chiave del 2026 e del 2027

Il CRA prevede un’entrata in vigore progressiva, con tre date fondamentali che le aziende devono tenere sotto controllo:

11 giugno 2026: entrata in vigore del Capitolo IV

Da questa data diventano applicabili le disposizioni relative alle autorità di vigilanza del mercato e alla notifica degli organismi notificati. Gli Stati membri devono aver designato le autorità competenti e i canali di supervisione. Per le aziende, questa data segna l’inizio del periodo in cui la governance della conformità deve essere già operativa.

11 settembre 2026: obblighi di segnalazione vulnerabilità e incidenti

Da questa data diventano vincolanti gli obblighi di notifica delle vulnerabilità attivamente sfruttate e degli incidenti di sicurezza. I fabbricanti devono inviare un early warning entro 24 ore dalla scoperta di una vulnerabilità attivamente sfruttata, seguita da una notifica completa entro 72 ore e da un report finale entro 14 giorni. I canali di notifica primari sono ENISA e le autorità nazionali competenti (in Italia, l’ACN – Agenzia per la Cybersicurezza Nazionale).

11 dicembre 2027: piena applicazione di tutti i requisiti

Questa è la data in cui tutti i requisiti del CRA diventano pienamente applicabili, inclusi i requisiti essenziali di cybersecurity, gli obblighi documentali, la marcatura CE e le valutazioni di conformità. I prodotti immessi sul mercato dopo questa data devono essere conformi in ogni aspetto.

Il messaggio operativo è chiaro: le aziende non hanno fino al 2027 per iniziare a prepararsi. Settembre 2026 è già dietro l’angolo e richiede processi di incident management e vulnerability disclosure già rodati.

Gli obblighi strutturali per fabbricanti e fornitori di software

Per chi produce o distribuisce software, il CRA introduce obblighi sostanziali che trasformano l’approccio allo sviluppo e al mantenimento dei prodotti.

I requisiti essenziali di cybersecurity impongono che i prodotti siano progettati e sviluppati secondo il principio di security by design: nessuna vulnerabilità nota al momento dell’immissione sul mercato, configurazioni predefinite sicure (by default), superficie di attacco minimizzata, protezione dei dati in transito e a riposo, meccanismi di autenticazione robusti, e possibilità di aggiornamenti di sicurezza automatici.

Sul fronte documentale, i fabbricanti devono predisporre un fascicolo tecnico completo che dimostri la conformità ai requisiti essenziali. Questo fascicolo include la descrizione del prodotto, le analisi dei rischi di cybersecurity, i test effettuati, la politica di gestione delle vulnerabilità e la Software Bill of Materials (SBOM).

SBOM e trasparenza della supply chain software

La Software Bill of Materials è uno degli obblighi più impattanti del CRA per le aziende software. Si tratta di un inventario dettagliato di tutti i componenti software inclusi in un prodotto: librerie di terze parti, dipendenze open source, moduli commerciali. L’obbligo di produrre e mantenere aggiornata la SBOM risponde a un’esigenza concreta: la maggior parte delle vulnerabilità critiche degli ultimi anni ha sfruttato componenti di terze parti non monitorati (si pensi a Log4Shell o a vulnerabilità nelle librerie open source più diffuse).

Per le aziende che acquistano software e lo integrano nei propri sistemi, la SBOM diventa uno strumento di valutazione dei fornitori: poter richiedere e analizzare la SBOM di un prodotto prima dell’acquisto è una pratica che il CRA incoraggia indirettamente e che i team di sicurezza dovrebbero adottare sistematicamente.

Se acquisti software e non lo produci: gli obblighi CRA che ti riguardano comunque

La narrativa dominante sul CRA si concentra sui fabbricanti. Ma le aziende che acquistano, integrano o distribuiscono software hanno responsabilità concrete che non possono essere delegate al fornitore.

Importatori e distributori hanno obblighi espliciti nel regolamento: devono verificare che i prodotti che immettono sul mercato europeo siano conformi al CRA, che rechino la marcatura CE, che la documentazione tecnica sia disponibile e che i fabbricanti abbiano implementato processi di gestione delle vulnerabilità. Se un importatore o distributore immette sul mercato un prodotto non conforme, ne risponde direttamente.

Anche le aziende che non rientrano formalmente nella categoria di importatori o distributori, ma che acquistano software per uso interno, hanno un interesse diretto nella conformità dei loro fornitori: un prodotto non conforme al CRA introduce rischi di sicurezza che ricadono sull’organizzazione acquirente, con potenziali implicazioni anche rispetto al GDPR e alla NIS2.

In pratica, un CIO o un CISO di una banca, di un ospedale o di un ente pubblico deve aggiornare i propri processi di vendor assessment per includere verifiche di conformità CRA, richiedere ai fornitori software la documentazione tecnica e la politica di gestione delle vulnerabilità, e inserire nei contratti clausole specifiche che garantiscano la continuità della conformità nel tempo.

Contratti con i fornitori software: le clausole da aggiornare per essere CRA-compliant

Nessun competitor ha affrontato in modo concreto questo tema, eppure è uno dei più urgenti per le aziende acquirenti. I contratti con i fornitori software stipulati prima del CRA non contengono le garanzie necessarie per una governance della conformità efficace. Ecco le aree contrattuali da aggiornare con priorità:

• Garanzie di conformità CRA: il fornitore deve dichiarare esplicitamente che il prodotto è conforme al Regolamento UE 2024/2847 e che manterrà la conformità per tutta la durata del contratto.
• Obbligo di notifica delle vulnerabilità: il fornitore deve impegnarsi a comunicare tempestivamente qualsiasi vulnerabilità rilevante che riguardi il prodotto fornito, con tempi allineati agli obblighi CRA (early warning entro 24 ore, notifica completa entro 72 ore).
• Fornitura della SBOM: il contratto deve prevedere l’obbligo di fornire e aggiornare la Software Bill of Materials, con frequenza definita e in formato standardizzato (ad esempio SPDX o CycloneDX).
• Periodo di supporto e aggiornamenti di sicurezza: deve essere specificato il periodo minimo di supporto durante il quale il fornitore si impegna a rilasciare patch di sicurezza.
• Diritto di audit: l’acquirente dovrebbe avere il diritto di richiedere evidenza documentale della conformità CRA, incluso l’accesso al fascicolo tecnico o a una sintesi certificata dello stesso.
• Clausola di risoluzione per non conformità: in caso di accertata non conformità al CRA da parte del fornitore, l’acquirente deve poter risolvere il contratto senza penali.

Valutazione di conformità, marcatura CE e Notified Body

Il percorso di conformità al CRA dipende dalla categoria del prodotto. Per i prodotti standard, il fabbricante può procedere con un’autovalutazione (Modulo A), documentando internamente la conformità ai requisiti essenziali. Per i prodotti importanti di Classe I, è possibile seguire norme tecniche armonizzate o standard europei di cybersecurity per giustificare l’autovalutazione. Per i prodotti importanti di Classe II e per i prodotti critici, è obbligatorio il coinvolgimento di un organismo notificato (Notified Body), che esegue una valutazione indipendente della conformità.

La marcatura CE per i prodotti digitali conformi al CRA non è un semplice bollino: è la dichiarazione pubblica che il prodotto soddisfa i requisiti essenziali di cybersecurity e che il fabbricante ha completato il percorso di valutazione previsto. Per le aziende acquirenti, la presenza della marcatura CE diventa un criterio di selezione nei processi di acquisto IT.

Sul fronte delle norme tecniche armonizzate, il processo di standardizzazione europeo è ancora in corso: gli organismi di normazione (CENELEC, ETSI) stanno lavorando agli standard che forniranno presunzione di conformità ai requisiti CRA. Le aziende devono monitorare l’evoluzione di questo quadro, poiché le norme armonizzate semplificheranno significativamente i percorsi di autovalutazione.

Il CRA impatta la governance aziendale: cosa cambia per CIO, CISO e compliance

Il CRA ridisegna le responsabilità interne nelle organizzazioni che producono o utilizzano prodotti digitali. Il CISO non è più solo il custode della sicurezza operativa: diventa un attore chiave nella governance della conformità normativa, con responsabilità che si estendono alla supply chain software, alla gestione documentale e ai processi di incident response.

Per i team di acquisti IT, il CRA introduce nuovi criteri di valutazione dei fornitori che devono essere integrati nei processi di procurement. La conformità CRA di un prodotto software deve diventare un requisito contrattuale, non un’opzione.

Sul fronte dell’integrazione normativa, il CRA non opera nel vuoto. Le aziende nei settori bancario, sanitario e della pubblica amministrazione devono già fare i conti con GDPR, NIS2 e, per il settore finanziario, DORA. Il CRA si aggiunge a questo quadro con obblighi specifici sui prodotti digitali, creando potenziali sovrapposizioni ma anche sinergie che, se gestite correttamente, possono ridurre il carico complessivo di compliance.

CRA vs GDPR: dove si sovrappongono e come costruire una compliance unica

La sovrapposizione tra CRA e GDPR è reale ma gestibile. La tabella seguente illustra le aree di intersezione più rilevanti:

Area	GDPR	CRA	Sinergia pratica
Privacy/security by design	Art. 25: privacy by design e by default	Requisiti essenziali: security by design e by default	Un’unica analisi dei rischi può coprire entrambi i framework
Notifica incidenti	72 ore per data breach al Garante	24 ore (early warning) + 72 ore (notifica) per vulnerabilità a ENISA/ACN	Processo unificato di incident response con canali differenziati
Documentazione	Registro trattamenti, DPIA	Fascicolo tecnico, SBOM, dichiarazione di conformità	Architettura documentale integrata con referenti comuni
Crittografia	Misura tecnica raccomandata per proteggere i dati personali	Requisito essenziale: protezione dei dati in transito e a riposo	La crittografia soddisfa entrambi i framework contemporaneamente
Gestione fornitori	Art. 28: contratti con responsabili del trattamento	Obblighi su importatori, distributori e clausole contrattuali CRA	Contratti con i fornitori aggiornati per coprire entrambi i requisiti

Il principio guida per costruire una compliance unica è evitare la duplicazione degli sforzi: un’analisi dei rischi ben strutturata, una politica di sicurezza che incorpori i requisiti di entrambi i framework, e una governance documentale integrata consentono di soddisfare CRA e GDPR con un investimento organizzativo ottimizzato.

Il quadro sanzionatorio: tre livelli di penalità

Il CRA prevede un sistema sanzionatorio graduato in tre livelli:

• Sanzione massima: fino a 15 milioni di euro o il 2,5% del fatturato mondiale annuo (si applica il valore più alto) per violazioni dei requisiti essenziali di cybersecurity e degli obblighi fondamentali dei fabbricanti.
• Sanzione intermedia: fino a 10 milioni di euro o il 2% del fatturato mondiale per violazioni di altri obblighi del regolamento, inclusi quelli relativi a importatori e distributori.
• Sanzione minore: fino a 5 milioni di euro o l’1% del fatturato mondiale per la fornitura di informazioni inesatte, incomplete o fuorvianti alle autorità di vigilanza.

Importatori e distributori sono espressamente soggetti al quadro sanzionatorio: non è possibile scaricare la responsabilità sul fabbricante se si è immesso consapevolmente sul mercato un prodotto non conforme.

Crittografia e protezione dei dati: come soddisfare i requisiti essenziali del CRA

Tra i requisiti essenziali del CRA, la protezione dei dati in transito e a riposo è uno dei più espliciti e verificabili. La crittografia non è solo una best practice: è un requisito normativo diretto che i fabbricanti devono implementare e che le aziende acquirenti devono verificare nei prodotti che utilizzano.

Per le organizzazioni che gestiscono dati sensibili, come istituti bancari, strutture sanitarie e pubbliche amministrazioni, la crittografia dei file e delle email rappresenta la prima linea di difesa contro le violazioni dei dati e, al tempo stesso, uno strumento concreto per dimostrare la conformità al CRA. Un sistema di data protection che cifra i file a riposo, protegge le comunicazioni email e garantisce il controllo degli accessi soddisfa simultaneamente requisiti CRA, GDPR e, in molti casi, NIS2.

Le soluzioni di protezione dei dati più efficaci in un contesto CRA-compliant devono garantire:

• Cifratura end-to-end dei file, indipendentemente dal canale di condivisione (email, cloud, dispositivi rimovibili).
• Controllo granulare degli accessi, con possibilità di revocare l’accesso ai file anche dopo la condivisione.
• Audit trail completo delle operazioni sui file, per soddisfare i requisiti di tracciabilità e documentazione.
• Compatibilità con ambienti on-premises e cloud ibridi, per adattarsi alle architetture IT esistenti senza richiedere migrazioni rischiose.
• Integrazione con i sistemi di identity management e autenticazione multifattore, allineandosi ai requisiti di autenticazione robusta del CRA.

File, email e dati aziendali: cosa cambia nella gestione quotidiana con il CRA

Il CRA non riguarda solo i team di sviluppo software o i responsabili della compliance. Ha impatti concreti sulla gestione quotidiana dei dati aziendali, in particolare per le organizzazioni che trattano informazioni sensibili.

Sul fronte della posta elettronica, il CRA impone che i prodotti software utilizzati per la gestione delle email soddisfino i requisiti essenziali di sicurezza. Questo significa che le soluzioni di email security adottate devono garantire la protezione dei dati in transito, meccanismi di autenticazione robusti e aggiornamenti di sicurezza continuativi. Le aziende devono verificare che i loro provider di email security siano conformi al CRA e richiedere la relativa documentazione.

Per la condivisione dei file, il CRA rafforza l’esigenza di soluzioni che cifrino i dati prima della condivisione e mantengano il controllo sull’accesso ai file anche dopo che questi hanno lasciato il perimetro aziendale. In un contesto di lavoro ibrido, dove i file transitano tra dispositivi personali, cloud e reti aziendali, la protezione end-to-end non è più un’opzione avanzata: è un requisito di base per la conformità.

Per i team IT, il CRA introduce anche l’obbligo di monitorare attivamente le vulnerabilità nei software utilizzati internamente e di agire tempestivamente quando vengono rilasciate patch di sicurezza. I processi di patch management, spesso trascurati o rallentati da vincoli operativi, devono essere formalizzati e documentati.

Checklist CRA per settori regolamentati: banche, sanità e pubblica amministrazione

Le organizzazioni nei settori più regolamentati hanno esigenze specifiche che richiedono un piano d’azione strutturato. Di seguito una checklist operativa differenziata per settore.

Banche e istituti finanziari (con integrazione DORA)

• Mappare tutti i software e prodotti digitali utilizzati, classificandoli secondo le categorie CRA.
• Verificare la conformità CRA dei fornitori software critici, richiedendo fascicolo tecnico e SBOM.
• Aggiornare i contratti con i fornitori con clausole CRA-ready (vedi sezione dedicata).
• Integrare gli obblighi di notifica CRA (24/72 ore) con i processi di incident reporting già previsti da DORA.
• Implementare soluzioni di crittografia per file e comunicazioni che soddisfino sia i requisiti CRA che quelli DORA.
• Formare i team IT e compliance sulle nuove responsabilità introdotte dal CRA.

Strutture sanitarie e gestori di dati sanitari

• Identificare i dispositivi medici con componenti digitali e verificare se rientrano nel CRA o nel MDR.
• Verificare la conformità CRA dei software gestionali, EHR e applicazioni cliniche.
• Implementare la cifratura dei dati sanitari a riposo e in transito, come requisito CRA e GDPR.
• Definire procedure di vulnerability disclosure per i sistemi critici, con tempistiche allineate al CRA.
• Aggiornare la DPIA (Data Protection Impact Assessment) per includere la valutazione dei rischi CRA.
• Verificare che i fornitori di soluzioni cloud sanitarie abbiano processi di gestione delle vulnerabilità documentati.

Pubblica Amministrazione

• Avviare una ricognizione del parco software in uso, identificando i prodotti soggetti al CRA.
• Inserire requisiti di conformità CRA nei bandi di gara e nei capitolati tecnici per l’acquisto di software.
• Verificare la conformità dei fornitori attuali e pianificare la rinegoziazione dei contratti in scadenza.
• Integrare gli obblighi CRA con le misure di sicurezza già richieste dalle linee guida ACN e dalle misure minime AgID.
• Implementare soluzioni di protezione dei dati che garantiscano la cifratura dei documenti amministrativi sensibili.
• Definire un piano di formazione per i responsabili IT e i funzionari di compliance sugli obblighi CRA.

FAQ: le domande più frequenti sul Cyber Resilience Act

Il Cyber Resilience Act si applica anche al software SaaS e cloud?

Il CRA non si applica ai servizi cloud puri, che sono già regolati dalla NIS2 e da altri framework. Tuttavia, il software SaaS che costituisce parte integrante di un prodotto con elementi digitali, o che viene fornito come componente di un prodotto fisico, può rientrare nell’ambito del CRA. La distinzione richiede un’analisi caso per caso, tenendo conto di come il software viene distribuito e integrato. Le aziende che utilizzano SaaS devono comunque verificare che i loro fornitori abbiano implementato misure di sicurezza adeguate.

Cosa deve fare un’azienda che acquista software ma non lo produce per conformarsi al CRA?

Le aziende acquirenti devono aggiornare i processi di vendor assessment per includere verifiche di conformità CRA, richiedere ai fornitori la documentazione tecnica e la SBOM, aggiornare i contratti con clausole CRA-ready, e implementare soluzioni di protezione dei dati che soddisfino i requisiti essenziali di sicurezza. Non è sufficiente affidarsi alla conformità del fornitore: l’organizzazione acquirente ha una responsabilità propria nella gestione del rischio associato ai prodotti digitali che utilizza.

Quali sono le sanzioni previste dal Cyber Resilience Act per la non conformità?

Il CRA prevede tre livelli sanzionatori: fino a 15 milioni di euro o il 2,5% del fatturato mondiale per le violazioni più gravi, fino a 10 milioni o il 2% per altre violazioni degli obblighi, e fino a 5 milioni o l’1% per informazioni inesatte fornite alle autorità. Le sanzioni si applicano a fabbricanti, importatori e distributori.

Come si integrano CRA e GDPR nella gestione dei dati aziendali?

CRA e GDPR si integrano su più livelli: entrambi richiedono security by design, entrambi prevedono obblighi di notifica degli incidenti (con tempistiche diverse), e la crittografia è una misura tecnica che soddisfa requisiti di entrambi i framework. Un approccio integrato, con un’unica analisi dei rischi e una governance documentale condivisa, consente di ottimizzare gli sforzi di compliance.

Entro quando le aziende devono essere conformi al Cyber Resilience Act?

La piena conformità è richiesta entro l’11 dicembre 2027. Tuttavia, gli obblighi di notifica delle vulnerabilità e degli incidenti diventano vincolanti già dall’11 settembre 2026. Le disposizioni sulle autorità di vigilanza entrano in vigore dall’11 giugno 2026. La preparazione deve iniziare subito, senza attendere le scadenze finali.

La crittografia dei dati è sufficiente per soddisfare i requisiti essenziali del CRA?

La crittografia è un elemento fondamentale dei requisiti essenziali del CRA, ma non è sufficiente da sola. Il regolamento richiede un approccio complessivo alla sicurezza che include: autenticazione robusta, gestione delle vulnerabilità, minimizzazione della superficie di attacco, aggiornamenti di sicurezza, e documentazione tecnica. La crittografia soddisfa direttamente il requisito di protezione dei dati in transito e a riposo, ma deve essere parte di una strategia di sicurezza più ampia.

Prepararsi al CRA: la via della protezione dei dati come fondamento della conformità

Il Cyber Resilience Act non è un ostacolo burocratico: è un’opportunità per le organizzazioni che vogliono costruire una postura di sicurezza solida e dimostrabile. Per le aziende che operano in settori regolamentati, la conformità al CRA non si aggiunge a un quadro normativo già complesso, ma si integra con esso, rafforzando le misure di sicurezza già richieste da GDPR, NIS2 e DORA.

La crittografia e la protezione dei dati aziendali, dei file e delle comunicazioni email non sono solo misure tecniche: sono la risposta concreta ai requisiti essenziali del CRA e il fondamento su cui costruire una compliance duratura. Le organizzazioni che investono oggi in soluzioni di data protection robuste, compatibili con ambienti on-premises e cloud, si trovano in una posizione di vantaggio rispetto alle scadenze del 2026 e del 2027.

Il percorso verso la conformità al CRA inizia con una mappatura chiara dei prodotti digitali in uso, una valutazione dei fornitori basata su criteri di sicurezza verificabili, e l’implementazione di soluzioni tecniche che soddisfino i requisiti essenziali del regolamento. Non c’è tempo da perdere: settembre 2026 è vicino, e i processi di incident management e vulnerability disclosure devono essere già operativi prima di quella data.