Il Cyber Resilience Act (CRA) estende ai prodotti digitali requisiti di sicurezza che coprono l’intero ciclo di vita. Per le imprese significa valutare come si progettano i prodotti, quali componenti integrano e come sostenerne la sicurezza dopo la vendita. Nell’intervista con The Innovation Group, Luca Moroni, Co-Founder, CSA SRL Società Benefit, richiama gli effetti di questo cambiamento su organizzazione, competenze, filiera e modello di business. Il tema sarà presentato nel corso del CISO PANEL PADOVA, il prossimo 10 novembre.
Perché il Cyber Resilience Act dovrebbe entrare oggi nell’agenda di CEO e Consigli di amministrazione? Qual è il cambiamento più significativo che introduce nel modo di progettare, commercializzare e mantenere sicuri i prodotti?
Luca Moroni. Il CRA è ormai un elemento strategico per le aziende che producono prodotti con componenti digitali[1]. Come nel caso del Regolamento Macchine, la sicurezza entra tra i requisiti da considerare per commercializzare i prodotti, con un perimetro però più esteso. La conformità al CRA comprenderà la valutazione secondo la procedura applicabile, la documentazione tecnica, la dichiarazione UE di conformità e la marcatura CE. È anche un baluardo rispetto a importazioni da Paesi extra UE, che possono essere più convenienti proprio perché non rispettano alcuni parametri di sicurezza. Avere un prodotto più sicuro diventa quindi un fattore qualificante.
Il cambiamento più significativo introdotto dal CRA, però, è la spinta a una sicurezza “fin dalla progettazione”, a un security by design. Un prodotto oggi viene sviluppato e integrato, ma soltanto in occasione di verifiche successive emergono debolezze che richiedono interventi costosi. Correggere un’architettura già realizzata può risultare più oneroso che affrontare il rischio durante la progettazione, inoltre il costo dell’adeguamento non deve più essere attribuito al cliente.
Il problema comincia dalla scelta dei componenti: una libreria software, un’interfaccia o un componente reperito su GitHub non dovrebbe essere selezionato soltanto perché svolge la funzione richiesta o riduce i costi iniziali. Una volta integrato, contribuisce alla sicurezza del prodotto finale e alle difficoltà che l’impresa potrà incontrare nel mantenerlo. La scelta deve quindi comprendere anche aggiornabilità, manutenzione e affidabilità del progetto o del fornitore.
Il CRA spinge a considerare fin dall’inizio come un prodotto possa essere compromesso e come intervenire quando emergeranno nuove vulnerabilità. La valutazione del rischio è centrale nell’applicazione della norma, e deve informare pianificazione, progettazione, sviluppo, produzione, consegna e manutenzione. Il regolamento non impone un’unica metodologia, ma richiede che rischi e misure adottate siano documentabili. Le non conformità sono di 3 tipi e possono comportare sanzioni fino a 15 milioni di Euro o 2,5% del fatturato annuo se superiore.
Quali produttori italiani devono verificare se rientrano nel perimetro del CRA?
Luca Moroni. Non sono coinvolti tutti i prodotti: il regolamento prevede un elenco allegato, con una logica proporzionale al rischio, analoga a quella del Regolamento Macchine, dove le componenti più attenzionate sono quelle legate alla sicurezza.
La normativa distingue tra prodotti importanti (Classe I e classe II; Allegato III) e prodotti critici (Allegato IV). I primi svolgono funzioni essenziali per la cybersicurezza di altri prodotti, reti o servizi, oppure funzioni che comportano un rischio significativo di effetti negativi, per intensità e capacità di perturbare, controllare o danneggiare un gran numero di altri prodotti, o per la salute, la sicurezza e l’incolumità degli utenti. I secondi sono legati alla dipendenza critica dei soggetti essenziali NIS2: i loro incidenti potrebbero causare gravi perturbazioni nelle catene di approvvigionamento critiche del mercato interno. Fornire un prodotto a un ente essenziale, quindi, ne innalza la criticità.
Gli elettrodomestici, per esempio, sono nel perimetro?
Luca Moroni. Dipende dalla funzione. Se c’è un microcontrollore con funzionalità legate alla sicurezza, il discorso cambia: in un frigorifero, se qualcuno lo spegne o ne modifica la temperatura, l’impatto è reale. Per identificare i prodotti coinvolti bisogna elencarli e valutarli, sempre in funzione del rischio e della safety delle persone. Rientrano, per esempio, i prodotti per la casa intelligente con funzionalità di sicurezza, i giocattoli connessi a internet e i dispositivi indossabili[2].
Il punto importante è che ogni azienda dovrebbe partire da un’analisi del portafoglio e da una gap analysis, per confrontare la situazione attuale con i requisiti da soddisfare, come avviene per il Regolamento Macchine. È un’attività che richiede di conoscere componenti, funzionalità, connessioni e contesti d’impiego. Ma c’è anche un criterio di buon senso, «da buon padre di famiglia»: al di là del fatto che il prodotto rientri o meno in un determinato allegato, immettere sul mercato un prodotto insicuro è eticamente scorretto, e rendere il proprio software più sicuro non è certo un errore.
Quali sono gli obblighi più rilevanti e quelli che le imprese rischiano di sottovalutare?
Luca Moroni. C’è anzitutto l’introduzione del concetto di rischio: il risk assessment è un passaggio fondamentale. Poi c’è la gestione del ciclo di vita del prodotto: non si può consegnarlo e dimenticarsene, la sicurezza va garantita nel tempo, tenendo conto del fatto che la segnalazione di un problema può arrivare anche da un soggetto terzo[3]. In ogni caso il produttore è tenuto a correggere il problema.
Il cambiamento importante è che si passa da produttore di un prodotto a un soggetto che, di fatto, ne è integratore e deve mantenerne la sicurezza lungo tutto il ciclo di vita. Cambiano quindi le competenze e le risorse necessarie in azienda: un conto è avere il programmatore (che tipicamente non si preoccupa di compliance), un conto è disporre di una figura che si occupa di sicurezza e di garantire che il prodotto resti sicuro nel tempo.
C’è poi il tema dei tempi, che sono molto stringenti: 72 ore per la notifica di un incidente che comprende le misure per gli utenti, con la produzione entro 1 mese di una relazione con l’analisi completa della causa radice (cause root), della gravità e dell’impatto. Questo costringe a elevare i requisiti sull’intera catena di fornitura: chi ti consegna un componente software, che tu assembli e rivendi, deve garantirti sicurezza e patching in tempi altrettanto stretti. Non basta acquistare il componente, assemblarlo e trasferire al cliente il rischio delle sue debolezze: bisogna ottenere dai fornitori collaborazione e capacità di produrre correzioni in tempi adeguati. È un meccanismo simile a quello della NIS2: anche chi non è in perimetro, lo diventa automaticamente come fornitore di un cliente NIS2, che lo inserisce nella propria lista fornitori.
Considerando gli impatti del CRA, quanto l’adeguamento può incidere sul modello di business? Quali conseguenze bisogna considerare per costi di sviluppo, tempi di lancio, durata del supporto e gestione del portafoglio prodotti?
Luca Moroni. Il prodotto non digitale ormai tende a sparire: tutti hanno componenti digitali, per profilazione, per metering e così via. Il modello classico era «l’ho fatto, funziona, lo vendo e ho finito»: ora devo mantenere la sicurezza per tutto il tempo in cui il cliente tiene il prodotto. E’ una trasformazione che potrebbe mettere in crisi alcuni modelli di business, perché molte aziende non sono strutturate per assicurare un supporto a regime sulla sicurezza di ciò che hanno rilasciato.
Significa dare supporto continuo e avere un legame molto più stretto con il cliente, prevedere gli aggiornamenti e gestire i casi di richiamo: se il prodotto non si può aggiornare da remoto, se non si è fatta una valutazione del rischio che includesse la nuova vulnerabilità, non resta che il rientro. E quasi nessuno ci ha mai pensato.
L’adeguamento può incidere su costi di sviluppo, selezione dei componenti, personale e rapporto con il cliente: il prodotto non si può più vendere senza sicurezza, i commerciali dovranno essere capaci di spiegare perché un prodotto progettato e mantenuto in sicurezza comporti costi diversi da uno che non prevede queste attività. Questo non significa trasformare ogni aggiornamento di sicurezza in un servizio da vendere separatamente. Nel quadro del CRA gli aggiornamenti di sicurezza devono essere diffusi gratuitamente, salvo l’eccezione prevista per prodotti su misura concordati con un utente commerciale; ove tecnicamente fattibile, devono inoltre essere separati dagli aggiornamenti funzionali. L’impresa deve quindi incorporare i costi degli obblighi nel modello economico del prodotto, distinguendoli dagli eventuali servizi aggiuntivi.
A tutti dico: preoccupatevi della normativa, ma prima ancora preoccupatevi della sicurezza di ciò che immettete sul mercato. Se non ve ne occupate, il rischio è reputazionale: prima o poi qualcuno si accorgerà che il vostro prodotto è inaffidabile e può essere sfruttato, com’è accaduto le telecamere connesse attaccate dal worm Mirai che hanno contribuito a bloccare buona parte del traffico internet negli Stati Uniti[4].
Chi dovrebbe guidare il percorso di adeguamento all’interno dell’azienda? Quali decisioni devono restare in capo al vertice?
Luca Moroni. È una scelta che richiede nuove competenze e più sicurezza a tutti i livelli, ma a guidare deve essere il vertice, perché è il vertice a essere responsabilizzato. Le decisioni necessarie riguardano budget, competenze, scelte di prodotto e organizzazione del supporto. Per CEO e Board il compito è assicurare che l’azienda disponga di un programma credibile, con responsabilità chiare e coordinamento tra sviluppo, cybersecurity, legale, acquisti e commerciale. E la responsabilità non ricade in generale solo su aziende che producono: se un importatore o un distributore vende un prodotto insicuro, anche lui ne risponde.
Considerando le diverse scadenze del regolamento, da dove dovrebbe partire un’azienda oggi?
Luca Moroni. Il regolamento è già in essere e così come l’obbligo di notifica degli incidenti dall’11 Settembre 2026, il che è problematico già solo per un motivo: bisogna rendersene conto. Nell’ambiente di fabbrica, qualche anno fa, si diceva che un incidente lo si scopriva forse dieci anni dopo. Oggi non è più così: la segnalazione può arrivare anche da altri, e da quel momento il tempo per reagire e porre rimedio è molto ridotto. L’urgenza è legata ai tempi di risposta: l’impresa deve poter riconoscere una segnalazione rilevante, raccogliere informazioni e coinvolgere rapidamente chi può intervenire, inclusi i fornitori[5].
Quali sono, dunque, le azioni prioritarie da avviare?
Luca Moroni. Bisogna innanzi tutto puntare a un cambiamento culturale in azienda: per molte organizzazioni la security by design è ancora un principio astratto, ma accorgersi delle debolezze soltanto quando il prodotto è pronto restringe le possibilità di intervento. Inoltre, nell’industria i cicli di sviluppo e produzione possono essere lunghi. Scegliere componenti più adatti, modificare un’architettura o rendere aggiornabile un dispositivo richiede tempo e investimenti.
Serve poi testare la sicurezza dei propri prodotti prima di immetterli nel mercato, per capire dove risiedono eventuali criticità e dare concretezza alla valutazione del rischio, al di là delle norme. Esistono studi che dimostrano che esistono vulnerabilità riscontrare anche nei prodotti certificati[6]
Infine, occorre individuare la corretta procedura di valutazione della conformità. Il percorso della compliance va dall’autovalutazione all’intervento di una terza parte. Il CRA prevede il controllo interno per molti prodotti della categoria ordinaria, mentre per le categorie importanti e critiche valgono condizioni e procedure specifiche, con un maggiore coinvolgimento di organismi notificati o, dove applicabile, schemi europei di certificazione.
A cura di: Elena Vaciago, Research Manager, The Innovation Group
Punti chiave dell’intervista
- Il CRA ha un perimetro molto più ampio del Regolamento Macchine: riguarda tutti i prodotti con elementi digitali immessi sul mercato europeo.
- Il cambiamento più profondo è la security by design: la sicurezza va pensata in fase di progetto, perché rimediare dopo costa di più.
- Il produttore è il soggetto che deve garantire la sicurezza del prodotto per tutto il suo ciclo di vita, con tempi di reazione stretti e nuove competenze.
- Il primo passo è mettere sotto stress il prodotto e fare una valutazione del rischio, a prescindere dall’inquadramento normativo.
[1] Gli obblighi principali del regolamento si applicheranno dall’11 dicembre 2027, mentre una parte rilevante degli obblighi di segnalazione è già applicabile. Fonte: Commissione europea, The Cyber Resilience Act — Summary of the legislative text; Regolamento (UE) 2024/2847. https://digital-strategy.ec.europa.eu/en/policies/cra-summary
[2] Le “Frequently asked questions on the Cyber Resilience Act implementation” della Commissione Europea aiutano a precisare il perimetro: il CRA riguarda prodotti con elementi digitali messi a disposizione sul mercato la cui destinazione d’uso o il cui uso ragionevolmente prevedibile comprende una connessione dati, logica o fisica, diretta o indiretta, a un dispositivo o a una rete, fatte salve le esclusioni previste. Non è dunque necessario che il prodotto si colleghi direttamente a Internet, anche software autonomi, firmware e componenti commercializzati separatamente possono rientrare nel perimetro.
[3] https://webgate.ec.europa.eu/single-market-compliance-space/market-surveillance
[4] Attacco DDoS contro il provider DNS Dyn del 21 ottobre 2016, vedi l’articolo “DDoS attack that disrupted internet was largest of its kind in history, experts say”, https://www.theguardian.com/technology/2016/oct/26/ddos-attack-dyn-mirai-botnet
[5] Gli obblighi dell’articolo 14 del CRA per i fabbricanti si applicano dall’11 settembre 2026 e riguardano vulnerabilità attivamente sfruttate e incidenti gravi che incidono sulla sicurezza del prodotto. È prevista una preallerta entro 24 ore dalla conoscenza e una notifica entro 72 ore. La relazione finale segue scadenze diverse: entro 14 giorni dalla disponibilità di una misura correttiva per le vulnerabilità attivamente sfruttate, entro un mese dalla notifica delle 72 ore per gli incidenti gravi. Fonte: Commissione europea, Cyber Resilience Act — Reporting obligations, 11 settembre 2026. https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
