Il 31 marzo 2026 è scaduta la consultazione pubblica sulle linee guida operative del Cyber Resilience Act, il regolamento europeo che introduce requisiti vincolanti di sicurezza per i prodotti digitali immessi sul mercato dell’Unione. La bozza pubblicata dalla Commissione europea entra nel merito delle procedure di conformità e chiarisce come i produttori dovranno dimostrare, documentare e mantenere nel tempo la sicurezza dei propri prodotti connessi.
Il CRA stabilisce un principio semplice: se un prodotto digitale non è progettato, mantenuto e aggiornato in modo sicuro, non può essere venduto nell’Unione europea. Questo vale per software, dispositivi IoT, componenti industriali. Vale anche per chi integra componenti di terzi. La sicurezza diventa una condizione di accesso, al pari delle normative su sicurezza elettrica o compatibilità elettromagnetica.
Indice degli argomenti
Cyber Resilience Act, la conformità lungo tutto il ciclo di vita
Le linee guida pubblicate dalla Commissione entrano nel dettaglio operativo. La valutazione della conformità non è più un esercizio documentale da chiudere prima della commercializzazione, si estende lungo tutto il ciclo di vita del prodotto. Il produttore deve dimostrare di avere processi attivi per identificare vulnerabilità, correggerle e comunicarle. Non basta dichiarare che il prodotto è sicuro, serve anche dimostrare come si mantiene tale nel tempo.
Per i prodotti a rischio standard è prevista un’autovalutazione. Per quelli classificati come importanti di Classe II — quali sistemi operativi, hypervisor, firewall e soluzioni di gestione delle identità (elencati nell’allegato I del regolamento di esecuzione UE 2025/2392) — o per i prodotti critici (allegato II), intervengono organismi notificati. Questo introduce un livello di controllo esterno che finora era limitato ad ambiti specifici. La sicurezza del software entra in una logica simile a quella delle certificazioni industriali.
Gestione delle vulnerabilità e componenti open source
Un elemento centrale è la gestione delle vulnerabilità. Il CRA richiede processi strutturati, non attività occasionali. Significa avere inventari aggiornati dei componenti, monitorare le vulnerabilità note, rilasciare patch in tempi definiti. Secondo dati Synopsys, il 96% delle applicazioni commerciali contiene componenti open source, con una media di circa 595 componenti open source per codebase (dato OSSRA 2023), che costituiscono in media il 77% del codice sorgente totale. Ogni dipendenza introduce una superficie di rischio che deve essere gestita e documentata.
La supply chain è il punto in cui queste complessità emergono con più evidenza. Il CRA non distingue tra vulnerabilità proprie e vulnerabilità ereditate. Il produttore resta responsabile. Le linee guida suggeriscono l’adozione sistematica di SBOM, elenchi dettagliati dei componenti software utilizzati. La richiesta di SBOM e trasparenza sulle dipendenze è già presente nei processi di procurement di grandi organizzazioni europee, soprattutto nei settori regolati. Parallelamente, si osserva un aumento delle clausole contrattuali che impongono tempi di patching, obblighi di notifica e requisiti minimi di sicurezza ai fornitori.
Notifiche, documentazione tecnica e marcatura CE
La segnalazione degli incidenti introduce tempistiche stringenti. Entro 24 ore dalla scoperta di una vulnerabilità attivamente sfruttata, il produttore deve notificare il CSIRT dello Stato membro in cui ha il proprio stabilimento principale, tramite la piattaforma unica di comunicazione (SRP) gestita da ENISA, che riceve le segnalazioni in parallelo. Entro 72 ore deve fornire un’analisi più completa. Questo avvicina il mondo dei prodotti a quello delle infrastrutture critiche, già regolato dalla direttiva NIS2. Il confine tra sicurezza IT e sicurezza dei prodotti si riduce.
La documentazione tecnica assume un ruolo probatorio. Non si tratta di produrre documenti per la conformità, ma di costruire evidenze verificabili: architetture, analisi dei rischi, risultati di test, procedure di aggiornamento. Tutto deve essere tracciabile e aggiornato.
La marcatura CE diventa il segno visibile di questo processo. Senza conformità al CRA, non c’è marcatura. Senza marcatura, non c’è mercato.
Cyber Resilience Act e rischio supply chain
Il contesto è quello di un rischio sistemico crescente. Nel report ENISA sul Threat Landscape for Supply Chain Attacks, il 66% degli attacchi analizzati mirava al codice dei fornitori, e nella stessa percentuale di casi i fornitori non erano consapevoli di come fossero stati compromessi — dato circoscritto a quel campione specifico, non generalizzabile all’insieme degli incidenti significativi europei. Episodi come SolarWinds hanno mostrato come una singola vulnerabilità possa propagarsi su scala globale. Il CRA interviene proprio su questo punto, imponendo standard minimi comuni e responsabilità distribuite lungo la catena.
C’è un aspetto che le linee guida toccano solo indirettamente ma che diventa determinante nella pratica: la formazione sulla cybersecurity awareness. I processi richiesti dal CRA non funzionano senza persone che sappiano applicarli. La gestione delle vulnerabilità richiede competenze tecniche specifiche. La documentazione richiede rigore metodologico. La segnalazione degli incidenti richiede consapevolezza operativa.
La cybersecurity awareness entra qui in modo concreto, non più solo campagne informative o simulazioni di phishing, ma parte integrante della capacità dell’organizzazione di rispettare obblighi normativi. Errori di sviluppo, configurazioni errate e ritardi nella gestione delle vulnerabilità restano tra le principali cause di esposizione, come evidenziato dai report Verizon DBIR e ENISA. La formazione continua riduce questi fattori, migliorando la capacità di prevenzione e risposta.
Sanzioni e scadenze del Cyber Resilience Act
Sul piano sanzionatorio, il CRA prevede sanzioni fino a 15 milioni di euro o al 2,5% del fatturato globale annuo per le violazioni principali — un deterrente di rilievo per le imprese. Sul piano temporale, le scadenze operative sono due: settembre 2026 per gli obblighi di segnalazione di vulnerabilità e incidenti, e l’11 dicembre 2027 come termine di piena applicazione del regolamento. Quest’ultima data è il riferimento operativo centrale per qualsiasi piano di adeguamento aziendale.
Le aziende hanno una finestra temporale limitata per adeguarsi. Le linee guida cercheranno di chiarire le modalità operative, ma la complessità resta… e chi non integra questi requisiti nei propri processi resta fuori dal perimetro. Non più per scelta tecnologica, ma per vincolo normativo.
Partecipa alla community