Cyber Resilience Act: cosa cambia per chi sviluppa software e prodotti digitali

Per anni la sicurezza del software è stata trattata come un controllo dell’ultimo minuto, qualcosa da sistemare poco prima del rilascio o, peggio, da correggere quando il prodotto era già sul mercato e qualcuno aveva trovato la falla.

Oggi questo approccio non regge più. La crescente diffusione di prodotti connessi, software embedded, dispositivi IoT e sistemi industriali digitalizzati ha ampliato in modo significativo la superficie di attacco, trasformando la cybersecurity in un requisito progettuale prima ancora che tecnologico.

Con il Cyber Resilience Act, l’Unione Europea prende atto di questo cambiamento e introduce requisiti comuni di sicurezza informatica per i prodotti con elementi digitali, validi lungo tutto il loro ciclo di vita.

Per le aziende rappresenta molto più di un nuovo adempimento normativo. Il regolamento chiede di integrare la sicurezza nei processi di progettazione, sviluppo, aggiornamento e gestione del software, trasformandola da requisito finale a principio guida.

In questo articolo approfondiremo che cos’è il Cyber Resilience Act, a chi si applica, quali requisiti introduce e cosa cambia concretamente per chi sviluppa software e prodotti digitali, analizzando i principi di Cybersecurity by Design, Secure by Default e Vulnerability Management e Patch Management.

Cos’è il Cyber Resilience Act e cosa prevede

Un nuovo standard europeo per la sicurezza dei prodotti digitali

Il Cyber Resilience Act (CRA) è il regolamento europeo che introduce requisiti comuni di cybersecurity per i prodotti con elementi digitali immessi sul mercato dell’Unione. L’obiettivo è garantire che software, dispositivi connessi e altri prodotti digitali siano progettati, sviluppati e mantenuti secondo standard di sicurezza omogenei per tutto il tempo in cui restano in uso.

Entrato in vigore il 10 dicembre 2024, il regolamento prevede un’applicazione progressiva. Gli obblighi relativi alla segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi diventeranno applicabili dall’11 settembre 2026, mentre la maggior parte delle disposizioni entrerà in vigore l’11 dicembre 2027. È un periodo di transizione pensato per dare alle aziende il tempo di adeguare processi, prodotti e documentazione senza doversi muovere all’ultimo momento.

C’è una differenza sostanziale rispetto ad altre normative. Il GDPR disciplina i dati, la NIS2 la gestione della sicurezza aziendale, il CRA invece guarda direttamente al prodotto, definendo obblighi precisi per produttori, sviluppatori e operatori economici coinvolti nella sua commercializzazione.

Perché serviva una normativa comune

Il numero di prodotti con elementi digitali è cresciuto in modo esponenziale. Software, dispositivi IoT, macchine industriali connesse, sistemi embedded e applicazioni cloud sono ormai presenti in quasi ogni settore produttivo, e ognuno di essi rappresenta un potenziale punto di ingresso.

Vulnerabilità non gestite, aggiornamenti trascurati, componenti digitali privi di misure di sicurezza adeguate: sono tutte porte lasciate socchiuse, con impatti che possono estendersi da una singola azienda a intere infrastrutture, fino agli utenti finali.

Il Cyber Resilience Act nasce per ridurre questi rischi, introducendo un quadro normativo comune che favorisca lo sviluppo di prodotti digitali più sicuri e resilienti.

Qual è il legame tra Cyber Resilience Act e marcatura CE?

C’è un aspetto che rende il CRA impossibile da ignorare per chi vende in Europa. Per i prodotti che rientrano nel suo campo di applicazione, il rispetto dei requisiti diventerà una condizione necessaria per apporre la marcatura CE e commercializzare il prodotto nel mercato dell’Unione.

In altre parole, la marcatura CE non certificherà più soltanto la sicurezza elettrica, meccanica o la compatibilità elettromagnetica, ma anche la conformità ai requisiti di cybersecurity introdotti dal regolamento.

Per i produttori questo significa che la conformità CE dovrà essere dimostrata anche attraverso documentazione tecnica, procedure adeguate e attività di valutazione coerenti con quanto previsto dal CRA.

Le sanzioni: perché conviene muoversi per tempo

Il Cyber Resilience Act non si limita a indicare la strada, prevede conseguenze concrete per chi non la segue. Le violazioni dei requisiti essenziali di cybersecurity possono comportare sanzioni fino a 15 milioni di euro o al 2,5% del fatturato annuo mondiale, a seconda di quale importo sia più elevato. Per il mancato rispetto di altri obblighi le cifre scendono, ma restano significative, fino a 10 milioni di euro o al 2% del fatturato.

Sono numeri che spostano la questione dal piano tecnico a quello strategico, e che spiegano perché l’adeguamento al regolamento sia entrato nell’agenda delle direzioni aziendali e non solo dei team di sviluppo.

A chi si applica il Cyber Resilience Act

Il regolamento si applica a un’ampia gamma di prodotti con elementi digitali immessi sul mercato europeo. Non parliamo quindi solo di software house, ma di tutte le aziende che progettano, sviluppano, producono o commercializzano prodotti in cui il software è una componente essenziale del funzionamento.

Rientrano nel campo di applicazione, ad esempio, i software commerciali, i dispositivi IoT, i sistemi embedded, le macchine industriali connesse, gli apparati di rete e, più in generale, tutti i prodotti che elaborano dati o comunicano attraverso reti digitali. Un’azienda che sviluppa un gestionale destinato alla vendita, un costruttore di macchine che integra software di controllo, un produttore di dispositivi IoT o chi commercializza hardware connesso con il proprio marchio sono tutti casi che con ogni probabilità ricadono sotto il CRA.

Gli obblighi coinvolgono innanzitutto i produttori, chiamati a garantire che i propri prodotti soddisfino i requisiti di cybersecurity lungo l’intero arco di utilizzo. Tuttavia, anche altri operatori economici hanno responsabilità specifiche, tra cui importatori e distributori, che devono verificare il rispetto dei requisiti previsti prima di immettere un prodotto sul mercato.

Il regolamento, inoltre, non tratta tutti i prodotti allo stesso modo. Accanto alla categoria ordinaria, individua i prodotti “importanti“, a loro volta suddivisi in Classe I e Classe II, e i prodotti “critici“, per i quali il livello di rischio è più elevato.

Più un prodotto è sensibile dal punto di vista della cybersecurity (si pensi a password manager, firewall o sistemi di gestione degli accessi), più le procedure di valutazione della conformità richieste diventano articolate. Il punto determinante, insomma, non è il settore in cui opera l’azienda, ma la natura del prodotto e il ruolo che il software svolge al suo interno.

Il Cyber Resilience Act cambia il modo di progettare, sviluppare e mantenere il software

Con il Cyber Resilience Act la cybersecurity diventa una responsabilità distribuita e richiede processi strutturati, che accompagnano il prodotto dalla progettazione agli aggiornamenti successivi al rilascio.

Di seguito analizziamo i principi cardine introdotti dal regolamento e il loro impatto concreto sulle attività di sviluppo.

Cybersecurity by Design: progettare pensando alla sicurezza

Il principio di Security by Design prevede che la sicurezza entri in gioco fin dalle prime fasi di progettazione del software. Non si tratta semplicemente di aggiungere controlli prima del rilascio, ma di integrare questo requisito nelle decisioni che influenzano l’intera architettura del prodotto.

La gestione delle autorizzazioni, la scelta delle librerie software, la protezione dei dati, la validazione degli input e la definizione delle funzionalità sono tutti aspetti che devono essere valutati anche dal punto di vista della cybersecurity.

Il vantaggio è duplice. Si riduce il rischio di introdurre vulnerabilità durante lo sviluppo e si evitano gli interventi correttivi tardivi, che sono sempre i più complessi e costosi.

Secure by Default: configurazioni sicure fin dall’installazione

La sicurezza di un prodotto non dovrebbe dipendere da quanto è esperto chi lo configura. È l’idea alla base del principio Secure by Default, che richiede software e dispositivi distribuiti con impostazioni predefinite già orientate alla protezione.

In concreto, significa limitare i privilegi degli utenti quando non necessari, disabilitare servizi e funzionalità non indispensabili, richiedere un’attivazione esplicita per le opzioni che aumentano il livello di rischio.

L’obiettivo è fare in modo che il prodotto sia sicuro fin dalla prima installazione, senza bisogno di interventi aggiuntivi per raggiungere un livello di protezione adeguato. La sicurezza diventa una caratteristica intrinseca del prodotto e non dipende da una configurazione successiva o da scelte che potrebbero esporlo a rischi evitabili.

Vulnerability Management: gestire le vulnerabilità nel tempo

Nessun software può essere considerato definitivamente privo di vulnerabilità. Nuove minacce, librerie di terze parti, dipendenze software e tecniche di attacco in continua evoluzione rendono inevitabile la comparsa di nuovi rischi anche dopo il rilascio del prodotto.

Su questo, il Cyber Resilience Act è chiaro: il Vulnerability Management deve diventare un processo continuo e strutturato, non una reazione estemporanea. Le aziende devono essere in grado di individuare le vulnerabilità, valutarne l’impatto, stabilire la priorità e pianificare gli interventi correttivi in tempi adeguati al rischio.

Una gestione efficace richiede inoltre procedure documentate, ruoli e responsabilità ben definiti e strumenti che consentano di monitorare costantemente lo stato di sicurezza del software.

È qui che entra in gioco un elemento concreto introdotto dal regolamento, la SBOM (Software Bill of Materials), ovvero la distinta dei componenti software che compongono un prodotto. Sapere esattamente quali librerie e dipendenze si stanno utilizzando è la premessa per capire, quando emerge una nuova vulnerabilità, se e quanto quel prodotto è esposto.

Patch Management: garantire aggiornamenti tempestivi

Individuare e correggere una vulnerabilità non è sufficiente se l’aggiornamento non raggiunge rapidamente gli utenti. La normativa dedica, infatti, particolare attenzione al Patch Management: gli aggiornamenti di sicurezza devono essere sviluppati, testati, distribuiti e documentati in tempi compatibili con il livello di rischio, così da ridurre al minimo la finestra di esposizione.

Le organizzazioni devono predisporre procedure che assicurino affidabilità, tracciabilità e disponibilità delle patch. Un processo efficiente permette di intervenire in fretta quando emerge un nuovo rischio e contribuisce a mantenere il software conforme e protetto per tutto il suo ciclo di vita.

Dal requisito normativo al processo aziendale

Adeguarsi al Cyber Resilience Act non significa soltanto sviluppare prodotti più sicuri. Significa anche ripensare il modo in cui l’organizzazione gestisce l’intero processo di sviluppo e manutenzione del software.

Molti dei requisiti introdotti dal regolamento non riguardano infatti singole funzionalità o tecnologie, ma il modo in cui le aziende progettano, documentano, monitorano e governano le proprie attività. La conformità diventa quindi il risultato di processi strutturati, ripetibili e documentabili, non di interventi occasionali.

Non basta correggere una vulnerabilità o rilasciare un aggiornamento, è necessario poter dimostrare come le vulnerabilità vengono identificate, valutate e gestite, quali procedure vengono seguite, chi è responsabile delle diverse attività e come vengono documentate le decisioni.

Il regolamento introduce inoltre obblighi di notifica particolarmente stringenti. Quando viene individuata una vulnerabilità attivamente sfruttata o si verifica un incidente di sicurezza grave, il produttore deve trasmettere una notifica di allerta (early warning) a ENISA e al CSIRT competente entro 24 ore dalla presa di conoscenza dell’evento, per poi fornire aggiornamenti e informazioni più dettagliate secondo le tempistiche previste dal regolamento.

Entrano così in gioco aspetti che, fino a pochi anni fa, erano spesso considerati secondari rispetto allo sviluppo del prodotto vero e proprio: la definizione di ruoli e responsabilità, la gestione della documentazione tecnica, il monitoraggio continuo della sicurezza, la tracciabilità delle modifiche e la pianificazione degli aggiornamenti.

Per le aziende che dispongono già di processi maturi si tratta spesso di consolidare pratiche esistenti. Per altre, il Cyber Resilience Act è l’occasione per dare struttura ad attività finora gestite in modo informale.

Come stiamo affrontando il Cyber Resilience Act in beanTech

L’entrata in vigore del regolamento ci ha dato l’occasione di rileggere le nostre modalità di lavoro alla luce dei nuovi requisiti, valorizzando le pratiche già consolidate e individuando gli ambiti su cui continuare a crescere.

Molti dei principi alla base del regolamento fanno già parte del nostro modo di sviluppare software, dalla progettazione orientata alla sicurezza fino alla gestione delle vulnerabilità e degli aggiornamenti durante il ciclo di vita del prodotto.

Il CRA rappresenta però anche uno stimolo a compiere un ulteriore passo avanti. Stiamo infatti lavorando alla revisione e alla formalizzazione delle nostre modalità operative, per rafforzare la tracciabilità delle attività, rendere ancora più solida la documentazione tecnica e definire con maggiore chiarezza ruoli e responsabilità.

L’obiettivo non è solo rispondere agli obblighi, ma rendere più robuste le modalità con cui progettiamo, sviluppiamo e manteniamo le nostre soluzioni, a beneficio della qualità, dell’affidabilità e della manutenibilità dei prodotti che realizziamo.

In sintesi, cosa serve per adeguarsi al Cyber Resilience Act?

Per prepararsi al Cyber Resilience Act è necessario:

• integrare la cybersecurity fin dalle prime fasi di progettazione di software e prodotti digitali;
• adottare configurazioni sicure già dalla prima installazione, secondo il principio Secure by Default;
• gestire vulnerabilità e aggiornamenti durante tutto il ciclo di vita del prodotto, mantenendo una SBOM aggiornata;
• documentare attività, decisioni e interventi in modo tracciabile;
• definire ruoli, responsabilità e procedure a supporto della conformità;
• integrare la cybersecurity nei processi aziendali, non solo nel prodotto.

Prepararsi oggi significa essere pronti domani

Adeguarsi al Cyber Resilience Act richiede tempo. Iniziare adesso a valutare prodotti, modalità di sviluppo e processi interni permette di distribuire gli interventi con gradualità, evitando la corsa dell’ultimo minuto e riducendo il rischio di non conformità, con le sanzioni che ne conseguono.

Concretamente, significa verificare se le proprie soluzioni rientrano nel campo di applicazione del regolamento e in quale classe, analizzare come viene gestito il ciclo di vita del software, valutare i processi dedicati a vulnerabilità e aggiornamenti e assicurarsi che documentazione, ruoli e responsabilità siano definiti in modo chiaro.

Affrontare questi temi in anticipo trasforma un obbligo normativo in un’occasione per rafforzare qualità, sicurezza e affidabilità del software.