Un dispositivo connesso, un programma per la gestione aziendale o una videocamera IP possono diventare un punto d’accesso per attacchi informatici anche molto tempo dopo la vendita. Il Cyber Resilience Act (CRA) nasce per affrontare questo problema alla radice: chiede che la sicurezza venga considerata durante progettazione, sviluppo, vendita e manutenzione dei prodotti digitali, non soltanto dopo la scoperta di un incidente.
Per utenti, imprese e produttori il cambiamento è significativo. La sicurezza non è più solo una caratteristica aggiuntiva da valutare al momento dell’acquisto. Diventa un insieme di requisiti verificabili, accompagnati da responsabilità precise per chi immette un prodotto sul mercato europeo.
Che cos’è il Cyber Resilience Act (CRA)
Il Cyber Resilience Act è un regolamento europeo dedicato ai prodotti con elementi digitali. È entrato in vigore il 10 dicembre 2024 e stabilisce requisiti comuni di cybersicurezza per hardware e software venduti o distribuiti nell’Unione europea.
L’idea centrale è semplice: un prodotto che si collega direttamente o indirettamente a una rete, oppure che può essere aggiornato digitalmente, non dovrebbe essere commercializzato se presenta difetti di sicurezza evitabili. Il regolamento interviene quindi su password predefinite, aggiornamenti, correzione delle vulnerabilità, documentazione tecnica e comunicazione degli incidenti.
Non introduce una promessa assoluta di invulnerabilità. Nessun software può offrirla. Richiede invece che i rischi prevedibili siano valutati, ridotti e gestiti per l’intero periodo di supporto dichiarato dal fabbricante.
Quali prodotti rientrano nelle nuove regole
Il campo di applicazione è ampio. Rientrano, in linea generale, i prodotti hardware e software con elementi digitali messi a disposizione sul mercato europeo. Alcuni esempi sono router, smartwatch, sistemi domotici, telecamere connesse, applicazioni mobili, sistemi operativi, programmi di contabilità, dispositivi industriali e componenti software integrati in altri prodotti.
La distinzione decisiva non è tra prodotto destinato ai privati e prodotto per aziende. Conta piuttosto la presenza di elementi digitali e la possibilità che un difetto di sicurezza abbia conseguenze per utenti, reti o dati.
Esistono però eccezioni e sovrapposizioni. Alcune categorie già disciplinate da norme settoriali specifiche, come determinati dispositivi medici o prodotti dell’aviazione, seguono regole proprie. Anche il software open source merita attenzione: quello sviluppato e distribuito fuori da un’attività commerciale può beneficiare di un trattamento diverso, mentre soggetti che lo curano e lo distribuiscono in modo organizzato possono avere obblighi specifici. Per questo, definire il perimetro richiede di valutare il singolo prodotto e il ruolo di chi lo fornisce.
Un servizio online puro non rientra automaticamente nel CRA. Se però il servizio è necessario al funzionamento di un prodotto digitale, oppure viene fornito insieme a esso, la valutazione può cambiare. È uno dei casi in cui affidarsi soltanto al nome commerciale del servizio può portare a conclusioni sbagliate.
Gli obblighi principali per i fabbricanti
Il fabbricante, cioè il soggetto che sviluppa o fa sviluppare il prodotto e lo commercializza con il proprio nome o marchio, ha la parte più rilevante delle responsabilità. Prima della vendita deve eseguire una valutazione dei rischi di cybersicurezza e predisporre documentazione tecnica capace di dimostrare come siano stati rispettati i requisiti applicabili.
Tra le aspettative più concrete rientrano l’uso di impostazioni sicure, la riduzione della superficie di attacco, la protezione da accessi non autorizzati e la gestione degli aggiornamenti. Se un aggiornamento è necessario per correggere una vulnerabilità, deve poter essere distribuito in modo sicuro e senza imporre ostacoli irragionevoli all’utente.
Il regolamento pone molta enfasi anche sulla gestione delle vulnerabilità. Non basta attendere le segnalazioni. Le organizzazioni devono disporre di un processo per riceverle, analizzarle, correggerle e comunicare informazioni chiare agli utenti coinvolti. La documentazione dovrebbe includere anche un elenco dei componenti software, spesso chiamato SBOM, utile per capire rapidamente se una vulnerabilità nota interessa un prodotto.
Il periodo di supporto deve essere dichiarato in modo comprensibile. Per molti prodotti, il riferimento è un periodo di almeno cinque anni, salvo che la durata d’uso prevista sia inferiore. Questo aspetto può incidere su prezzi, contratti, pianificazione tecnica e disponibilità delle risorse necessarie a mantenere prodotti meno recenti.
Dopo la verifica di conformità, il prodotto può riportare la marcatura CE. Non è un’etichetta generica di qualità: indica che il fabbricante dichiara il rispetto dei requisiti applicabili e si assume le relative responsabilità.
Importatori, distributori e aziende utilizzatrici
Il CRA non riguarda esclusivamente chi scrive codice. Importatori e distributori devono verificare, secondo il proprio ruolo, che i prodotti immessi o resi disponibili rispettino gli obblighi previsti, rechino le informazioni necessarie e non presentino irregolarità evidenti.
Un distributore che rileva un problema non può semplicemente ignorarlo perché non ha progettato il prodotto. Può dover sospendere la disponibilità del bene, collaborare con il fabbricante e fornire informazioni alle autorità competenti. Chi modifica in modo sostanziale un prodotto o lo immette sul mercato con il proprio marchio può assumere responsabilità paragonabili a quelle di un fabbricante.
Per le imprese che acquistano tecnologia, il regolamento non trasferisce automaticamente tutti gli obblighi del produttore. Offre però un criterio pratico per selezionare fornitori più affidabili. Nei capitolati e nelle richieste di offerta può diventare utile chiedere durata del supporto, modalità di aggiornamento, canale per la segnalazione delle vulnerabilità, responsabilità contrattuali e documentazione disponibile.
Segnalazione degli incidenti e delle vulnerabilità
Una delle novità più operative riguarda la segnalazione delle vulnerabilità sfruttate attivamente e degli incidenti gravi che incidono sulla sicurezza del prodotto. Il fabbricante deve comunicare tempestivamente le situazioni rilevanti attraverso i canali previsti a livello europeo.
Le tempistiche sono strette. In linea generale, è prevista un’allerta iniziale entro 24 ore dalla conoscenza dell’evento, una notifica più dettagliata entro 72 ore e una relazione finale entro 14 giorni, con possibili adattamenti in base allo sviluppo del caso. Lo scopo non è punire chi scopre un problema, ma favorire una risposta coordinata prima che il danno si estenda.
Questa parte richiede preparazione concreta: registri aggiornati dei prodotti distribuiti, contatti interni reperibili, procedure di analisi e un piano di comunicazione. Senza questi elementi, rispettare una scadenza di 24 ore diventa difficile, soprattutto nelle piccole organizzazioni dove sviluppo, assistenza e gestione tecnica coincidono spesso nella stessa persona.
Le scadenze da conoscere
L’applicazione del regolamento avviene in modo graduale. Dal 11 settembre 2026 si applicano gli obblighi relativi alla segnalazione di vulnerabilità e incidenti. Dal 11 dicembre 2027 entra in applicazione la maggior parte degli obblighi per i prodotti con elementi digitali.
Può sembrare un orizzonte distante, ma per chi sviluppa prodotti complessi non lo è affatto. Adeguare un ciclo di sviluppo significa rivedere requisiti, contratti con fornitori, sistemi di test, procedure di rilascio e assistenza post-vendita. Se un componente di terze parti è essenziale, occorre inoltre capire chi fornirà correzioni e per quanto tempo.
I prodotti cosiddetti critici possono essere soggetti a percorsi di valutazione più rigorosi. La classificazione dipende dalla funzione svolta e dal potenziale impatto sulla sicurezza, non dalla sola dimensione dell’azienda che li produce.
Come prepararsi senza creare burocrazia inutile
Per una piccola software house o un produttore di dispositivi, l’approccio più utile è partire da ciò che esiste già. Una certificazione o un documento compilato solo alla fine del progetto raramente risolve problemi strutturali. È più efficace inserire controlli essenziali nel lavoro quotidiano.
Il primo passo è costruire un inventario dei prodotti, delle versioni distribuite e delle dipendenze software. Il secondo è indicare chiaramente chi gestisce gli aggiornamenti e le segnalazioni di sicurezza. Il terzo è verificare che ogni prodotto abbia un periodo di supporto realistico, coerente con le capacità dell’organizzazione e con gli accordi presi con i fornitori.
Vale la pena esaminare anche aspetti apparentemente semplici: le password iniziali sono uniche o facilmente modificabili? Gli aggiornamenti sono firmati? Un utente può sapere quando termina il supporto? Esiste un indirizzo di contatto per ricercatori e clienti che individuano una vulnerabilità? Risposte vaghe a queste domande indicano spesso un processo da migliorare.
Il costo dell’adeguamento dipenderà dalla maturità di partenza. Per un prodotto aggiornato regolarmente e sviluppato con pratiche di sicurezza, il lavoro potrebbe consistere soprattutto nel formalizzare processi e documentazione. Per prodotti datati, privi di manutenzione o basati su componenti non tracciati, il cambiamento può essere più impegnativo e rendere necessarie decisioni commerciali sulla fine del ciclo di vita.
La domanda utile non è se il CRA aggiungerà lavoro, perché lo farà. È se quel lavoro verrà affrontato quando un prodotto è ancora gestibile oppure soltanto dopo che una vulnerabilità avrà trasformato un difetto tecnico in un problema per clienti, utenti e organizzazione.
