L’11 settembre 2026 segna una data importante per il Cyber Resilience Act (CRA). Non perché il Regolamento inizi improvvisamente ad applicarsi in ogni sua parte: la maggior parte degli obblighi arriverà infatti dall’11 dicembre 2027. Ma perché da settembre diventano operativi i primi obblighi di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi per i fabbricanti di prodotti con elementi digitali.

E questa prima scadenza ci ricorda una cosa importante: il CRA non riguarda soltanto la compliance. Riguarda il modo in cui software e prodotti digitali vengono progettati, sviluppati e mantenuti nel tempo.

Prima domanda: il CRA riguarda anche noi?

Quando si parla di “prodotti con elementi digitali” è facile pensare soltanto a dispositivi IoT o apparecchiature connesse. Il perimetro è però molto più ampio e comprende anche numerosi prodotti software.

Per questo una delle prime attività da fare non è scrivere una nuova policy, ma capire quali prodotti dell’azienda rientrano effettivamente nel perimetro del Regolamento e quale ruolo ricopre l’organizzazione: sviluppiamo software che viene commercializzato? Produciamo dispositivi con componenti digitali? Integriamo componenti software di terze parti nei nostri prodotti, oppure li importiamo o distribuiamo?

Sono domande apparentemente semplici, ma dalle risposte dipende buona parte del percorso successivo.

Dall’11 settembre bisogna essere pronti a segnalare

Uno dei primi obblighi a diventare operativo riguarda la gestione delle vulnerabilità e degli incidenti. Quando un fabbricante viene a conoscenza di una vulnerabilità attivamente sfruttata contenuta nel proprio prodotto o di un incidente grave che ne compromette la sicurezza, deve attivare il processo di segnalazione previsto dal CRA.

La prima comunicazione deve avvenire senza ritardi ingiustificati e, comunque, entro 24 ore. Segue poi una comunicazione più completa entro 72 ore. La segnalazione avverrà attraverso la Single Reporting Platform di ENISA, la cui attivazione è prevista per l’11 settembre come punto di accesso unico per questo processo a livello europeo. Tempi così brevi fanno emergere subito una questione molto pratica. Per segnalare un problema entro 24 ore bisogna prima essere in grado di accorgersi che il problema esiste, capire quali prodotti sono coinvolti, valutarne l’impatto e sapere chi deve prendere una decisione. Se tutto questo deve essere deciso mentre l’incidente è già in corso, probabilmente è troppo tardi.

Non si improvvisa in 24 ore: consulente e manager discutono la segnalazione del CRA

Il cambiamento vero è nel ciclo di vita del prodotto

La segnalazione degli incidenti è però soltanto una parte del CRA. Il cambiamento più importante riguarda il principio secondo cui la cybersecurity deve accompagnare il prodotto durante tutto il suo ciclo di vita. Significa considerare la sicurezza già durante la progettazione e lo sviluppo, valutare i rischi, conoscere le componenti utilizzate, gestire le vulnerabilità che emergono nel tempo e rendere disponibili gli aggiornamenti necessari.

Significa anche poter ricostruire cosa è stato fatto: quali vulnerabilità sono state individuate, come sono state valutate, quali componenti sono presenti nel prodotto, come vengono distribuiti gli aggiornamenti di sicurezza e per quanto tempo il prodotto sarà supportato.

Sono aspetti che molte aziende già gestiscono, almeno in parte. Il CRA li porta però dentro un quadro più strutturato e verificabile. La security by design, in altre parole, smette progressivamente di essere soltanto una buona pratica. Diventa parte dei requisiti del prodotto.

Il cambiamento del CRA: il ciclo di vita del prodotto, dalla progettazione al supporto

Un esempio concreto

Una software house sviluppa e commercializza un gestionale installato presso i propri clienti. Un ricercatore esterno segnala una vulnerabilità già sfruttata attivamente in una versione del prodotto. In azienda nessuno sa bene chi deve valutare la segnalazione, chi deve verificare che ricorrano le condizioni previste dal CRA e chi deve effettuare la comunicazione. Passano due giorni solo per capire chi se ne deve occupare: il termine delle 24 ore è già trascorso.

Stessa situazione, azienda diversa. Esiste già un referente per la gestione delle vulnerabilità, un processo definito per valutarle e sono già chiare le responsabilità e le modalità di segnalazione attraverso la piattaforma prevista dal CRA. La prima comunicazione parte entro 24 ore, quella più completa entro 72. Non perché il rischio sia minore, ma perché il processo era già pronto prima che arrivasse la notizia.

Il 2027 sembra lontano. Ma non così tanto

La maggior parte degli obblighi del Cyber Resilience Act sarà applicabile dall’11 dicembre 2027. A prima vista c’è ancora tempo. Ma adeguarsi non significa semplicemente arrivare a quella data con qualche documento in più.

Se dall’analisi emergesse la necessità di modificare il processo di sviluppo, introdurre controlli di sicurezza nel ciclo DevOps, migliorare il vulnerability management, censire le componenti software utilizzate, rivedere i rapporti con i fornitori o organizzare il processo di gestione degli aggiornamenti, il percorso potrebbe richiedere diversi mesi.

E alcune attività potrebbero richiedere cambiamenti che coinvolgono sviluppo, cybersecurity, prodotto, procurement, legal e management. Per questo aspettare il 2027 per iniziare a occuparsene rischia di essere una scelta poco prudente.

Da dove partire oggi?

Non serve partire dal Regolamento articolo per articolo. Serve prima di tutto costruire una fotografia concreta.

  • Quali prodotti potrebbero rientrare nel CRA?
  • Chi ne è responsabile durante il ciclo di vita?
  • Come gestiamo oggi vulnerabilità e aggiornamenti di sicurezza?
  • Saremmo realmente in grado di riconoscere e segnalare una vulnerabilità attivamente sfruttata entro 24 ore?
  • Sappiamo quali componenti software utilizziamo e da quali fornitori dipendiamo?

Se a qualcuna di queste domande la risposta è “non lo sappiamo”, è probabilmente quello il punto da cui iniziare.

Come lavoriamo, in Alterabit

Aiutiamo le aziende a capire, prima di tutto, se e dove i propri prodotti rientrano nel perimetro del CRA e quale ruolo ricoprono: fabbricante, importatore o distributore. Da lì costruiamo insieme il processo di gestione delle vulnerabilità e degli incidenti, definendo chi valuta, chi decide e chi effettua la segnalazione, così che la scadenza delle 24 ore non colga nessuno impreparato.

Non ci fermiamo alla segnalazione. Lavoriamo sul percorso più ampio verso l’11 dicembre 2027: security by design, gestione del ciclo di vita del prodotto, censimento delle componenti software, gestione degli aggiornamenti. Un percorso costruito sulla situazione reale dell’azienda, non su un modello standard.

Il CRA non chiede soltanto prodotti più sicuri al momento della vendita. Chiede alle aziende di continuare a prendersi cura della loro sicurezza anche dopo averli messi sul mercato. Ed è forse questo il cambiamento più importante da iniziare a preparare oggi.

Fonti

Le immagini a corredo dell’articolo sono state realizzate con il supporto di strumenti di intelligenza artificiale.