Cyber Resilience Act.
Sviluppare prodotti con elementi digitali sicuri, gestire le vulnerabilità e preparare l'attestazione di conformità adatta.
- Regolamento (UE) 2024/2847
- Di Derya Altinay
- Aggiornato al: 22/10/2026
- Tempo di lettura: 8 min.
Risposta breve.
Il Cyber Resilience Act è il regolamento UE sulla cybersicurezza dei prodotti con elementi digitali interessati. I fabbricanti sono responsabili della sicurezza nello sviluppo, nella fornitura e nel supporto. Gli obblighi di notifica dei fabbricanti si applicano dall'11 settembre 2026; gli obblighi generali sui prodotti dall'11 dicembre 2027. La base è il regolamento (UE) 2024/2847.
Cyber Resilience Act e scadenze CRA.
Il Cyber Resilience Act, in breve CRA o regolamento sulla ciberresilienza, disciplina la cybersicurezza dei prodotti. Il regolamento (UE) 2024/2847 collega requisiti di progettazione a obblighi durante il ciclo di vita del prodotto. L'oggetto considerato è il prodotto concreto, comprese componenti rilevanti ed elaborazione remota dei dati associata. Un programma aziendale di sicurezza può sostenere questo lavoro, ma da solo non risponde alle domande specifiche sul prodotto.
Le scadenze CRA sono scaglionate. Ai sensi dell'art. 71, par. 2 CRA, i requisiti generali iniziano l'11 dicembre 2027; le notifiche dei fabbricanti dell'art. 14 si applicano già dall'11 settembre 2026. Il capo IV sulla notifica degli organismi di valutazione della conformità si applica dall'11 giugno 2026. Questa data istituzionale non anticipa una scadenza CE generale per tutti i prodotti software.
I prodotti precedenti non sono generalmente esenti dalle notifiche dei fabbricanti. L'art. 69, par. 2 e 3 CRA distingue le regole transitorie sulla conformità dei prodotti dalle notifiche. Gli orientamenti della Commissione C(2026) 5252, sezione 9.1, spiegano questa distinzione anche per i prodotti immessi sul mercato prima di dicembre 2027. Gli orientamenti sono un ausilio interpretativo non vincolante; resta determinante il regolamento.
Quali prodotti e imprese sono interessati dal CRA.
Il CRA riguarda i prodotti hardware e software interessati messi a disposizione sul mercato UE che prevedono una connessione dati diretta o indiretta a un dispositivo o a una rete. Gli art. 2 e 3 CRA definiscono ambito e termini. Possono rientrarvi componenti offerte autonomamente. Verificate la funzione effettiva e le eccezioni previste dalla legge prima di classificare allo stesso modo tutto il portafoglio.
Il ruolo dell'impresa determina gli obblighi. Fabbricanti, importatori e distributori hanno compiti diversi; il ruolo di fabbricante può essere rilevante anche nella commercializzazione con il proprio marchio. Per il software open source occorre distinguere fornitura commerciale, contributi individuali e ruolo particolare dello steward di software open source. Una licenza libera non esenta in generale il fabbricante di un prodotto commerciale dalla responsabilità.
Un servizio SaaS non rientra o esce dal CRA per la sola denominazione commerciale. Contano i confini del prodotto e l'elaborazione remota dei dati associata. Gli orientamenti della Commissione, sezioni 2 e 8, distinguono prodotti software e servizi forniti da remoto. Registrate la motivazione per l'architettura concreta; una dichiarazione generale su tutte le offerte cloud sarebbe troppo ampia.
Gli ambiti principali dei requisiti CRA.
I requisiti CRA collegano la sicurezza dei prodotti basata sui rischi alla responsabilità continua. L'art. 13 e l'allegato I CRA costituiscono la base degli obblighi sui prodotti; l'art. 14 disciplina le notifiche dei fabbricanti applicabili in anticipo. Gli ambiti seguenti orientano senza sostituire i singoli requisiti legali.
Comprendere prodotto e rischi.
Una valutazione dei rischi di cybersicurezza sostiene le decisioni sulla sicurezza lungo il ciclo di vita. I fabbricanti considerano l'uso previsto e quello ragionevolmente prevedibile. Descrivete concretamente funzioni, interfacce e dipendenze del prodotto e le conseguenze che un problema di sicurezza può avere per gli utenti.
Prevedere la sicurezza nel prodotto.
Progettazione sicura e impostazioni predefinite sicure sono collegate. L'allegato I CRA comprende proprietà del prodotto come protezione degli accessi, protezione dei dati e limitazione delle superfici di attacco. Una politica redatta successivamente non può sostituire proprietà tecniche; le decisioni di sviluppo e la loro verifica devono essere coerenti con la valutazione dei rischi.
Integrare le componenti responsabilmente.
Le componenti integrate restano parte della valutazione del prodotto. I fabbricanti necessitano di informazioni tracciabili su ciò che distribuiscono e su come le vulnerabilità nelle dipendenze incidono sul prodotto. La Commissione descrive espressamente la dovuta diligenza verso le componenti di terzi; inoltrare semplicemente una dichiarazione del fornitore non risponde a ogni domanda sul prodotto.
Gestire vulnerabilità e aggiornamenti.
La gestione delle vulnerabilità è un compito continuo durante il periodo di supporto pertinente. Comprende canali di segnalazione raggiungibili, valutazione, rimedio e fornitura sicura degli aggiornamenti di sicurezza. Distinguete la gestione tecnica di un rilievo dalla valutazione legale sull'obbligo di notificare una vulnerabilità attivamente sfruttata o un incidente grave.
Definire supporto e informazioni agli utenti.
Il periodo di supporto dipende dai criteri dell'art. 13, par. 8 CRA e dall'uso previsto. In linea di principio sono previsti almeno cinque anni; per un uso atteso più breve vale tale durata, mentre un uso atteso più lungo può richiedere un periodo maggiore. Gli orientamenti della Commissione, sezione 5, chiariscono espressamente che cinque anni non sono un limite massimo generale.
Rendere possibili le notifiche dei fabbricanti.
L'art. 14 CRA distingue vulnerabilità attivamente sfruttate e incidenti di sicurezza gravi. I fabbricanti devono effettuare notifiche progressive dopo esserne venuti a conoscenza: senza indugio, con preallarme al più tardi entro 24 ore e ulteriori informazioni entro 72 ore. Le scadenze finali differiscono secondo l'evento scatenante. Un rilievo di uno scanner da solo non è quindi automaticamente una notifica obbligatoria né un motivo sufficiente per chiudere l'evento.
Preparare conformità e documentazione.
Documentazione tecnica e valutazione della conformità devono spiegare il prodotto offerto. L'art. 32 CRA e la categoria del prodotto determinano la procedura ammessa. Registrate la base di valutazione scelta insieme alla versione del prodotto; una raccolta generica di documenti senza collegamento tracciabile alla versione esaminata non costituisce una strategia pratica sufficiente di attestazione.
L'attuazione CRA come processo di prodotto.
Delimitare portafoglio e ruoli.
Come avvio pratico, rilevate prodotti offerti, funzioni rilevanti, entità giuridica responsabile e ruolo nel rispettivo canale di distribuzione.
Distinguere le fasi di applicazione.
Separate la preparazione alle notifiche dei fabbricanti già obbligatoria dalla preparazione della conformità generale del prodotto e verificate le transizioni per i prodotti esistenti.
Tradurre i rischi in decisioni sul prodotto.
Collegate la valutazione dei rischi a progettazione, scelta delle componenti e criteri di sicurezza verificabili per sviluppo e rilascio.
Provare i canali di notifica.
Individuate responsabili e sostituti e provate valutazione, escalation e trasmissione con informazioni incomplete entro i termini applicabili.
Definire supporto e percorso di attestazione.
Pianificate la manutenzione delle versioni supportate e chiarite in base alla categoria quale valutazione della conformità e documentazione tecnica saranno necessarie.
Marcatura CE del software e attestazione del prodotto.
L'attestazione CRA è una valutazione della conformità riferita al prodotto. Nelle spiegazioni sull'art. 32 CRA, la Commissione indica che per la categoria standard è possibile una valutazione interna. Per determinati prodotti importanti o critici si applicano procedure più rigorose con un organismo notificato o altri percorsi ammessi. La funzione effettiva del prodotto ne determina la categoria; un nome commerciale non basta.
La dichiarazione UE di conformità e la marcatura CE seguono la procedura applicabile. Non sono un certificato generale per tutta l'impresa né una promessa che il prodotto non avrà mai vulnerabilità. Una durata uniforme del certificato non descrive quindi adeguatamente il CRA: documentazione, gestione delle vulnerabilità e obblighi applicabili vanno considerati lungo il ciclo di vita pertinente.
Altri framework e obblighi autonomi.
ISO 27001 organizza un sistema di gestione della sicurezza delle informazioni; il relativo certificato da solo non conferma la conformità CRA di un prodotto. NIS2 considera i soggetti interessati e la loro organizzazione di sicurezza. Il GDPR protegge i dati personali, per cui un evento di prodotto può sollevare ulteriori questioni di protezione dei dati. Le procedure correlate possono essere coordinate, ma presupposti legali ed evidenze richiedono verifiche separate.
In Secani.
Secani contiene un catalogo redazionale di lavoro CRA con fonti, domande di verifica ed esempi di evidenze. Il profilo aziendale rileva, tra l'altro, ruoli e data di valutazione; i prerequisiti non chiariti restano visibili come necessità di verifica. Lo strumento sostiene l'organizzazione della verifica, ma non conferma né la classificazione giuridica né la conformità di un prodotto.
Iniziare con un prodotto delimitato.
Scegliete un prodotto concreto e chiarite prima i suoi confini, l'entità giuridica responsabile e le persone competenti per le notifiche di sicurezza. Verificate poi quali obblighi attuali e futuri lo riguardano. Questo avvio rende la preparazione gestibile ed evita che un progetto generale di conformità nasconda la preparazione alle notifiche già necessaria.
Fonti.
- Regolamento (UE) 2024/2847: Cyber Resilience Act
- Commissione europea: Cyber Resilience Act e date di applicazione
- Commissione europea: sintesi dell'atto
- Commissione europea: obblighi dei fabbricanti
- Commissione europea: valutazione della conformità
- Commissione europea: CRA e open source
- Commissione europea: orientamenti C(2026) 5252 con allegato
Domande frequenti.
Sì, per i fabbricanti interessati le notifiche dell'art. 14 CRA si applicano dall'11 settembre 2026. Gli obblighi generali sui prodotti iniziano l'11 dicembre 2027; ruoli particolari e transizioni richiedono verifiche separate.
No, la denominazione SaaS non determina l'ambito di applicazione. Verificate il prodotto software, le sue funzioni e l'elaborazione remota dei dati associata in base all'architettura concreta.
No, il trattamento particolare dei contributi open source a monte non esenta in generale il fabbricante del prodotto commerciale dai propri obblighi. Occorre distinguere ruolo di fabbricante ed eventuale ruolo di steward.
No, un certificato ISO 27001 riguarda un sistema di gestione delimitato. Il CRA richiede una valutazione separata del prodotto e la rispettiva attestazione di conformità applicabile.
Organizzare la sicurezza dei prodotti in modo tracciabile.
Gestire in modo strutturato requisiti CRA e relative verifiche con Secani.
Questa pagina illustra il Cyber Resilience Act in termini generali e non sostituisce la verifica giuridica del singolo prodotto. Fanno fede gli atti vigenti.