Cyber Resilience Act: come la nuova normativa UE ridefinisce la sicurezza dei prodotti digitali

Perché oggi si parla sempre più di protezione dai rischi informatici e di nuovi regolamenti europei in materia di cybersicurezza?
La risposta è semplice: in un contesto in cui la complessità delle tecnologie cresce insieme alla loro superficie di attacco, la sicurezza informatica non può più essere delegata solo agli utenti finali, ma richiede un approccio strutturato e condiviso lungo tutta la supply chain del settore tech.

• • • • Cos’è il Cyber Resilience Act?
        • Come nasce il Cyber Resilience Act?
      • La classificazione dei prodotti secondo il Cyber Resilience Act
      • Quali sono le scadenze fissate dal Cyber Resilience Act?
      • Le principali conseguenze del Cyber Resilience Act
        • Cosa cambia per i produttori di hardware e software?
        • Quali sono gli obblighi specifici introdotti dalla direttiva?
      • In che modo il Cyber Resilience Act va ad impattare sul mondo dell’open source e del software libero?
      • Bonus: SBOM, CVE e KEV fai da te per dispositivi basati su Yocto
        • Generazione della SBOM
        • Analisi CVE e KEV
      • Prepararsi per tempo a una trasformazione in atto
      • FAQ

Il Cyber Resilience Act (CRA) è il nuovo regolamento dell’Unione Europea che introduce requisiti obbligatori e omogenei di cybersecurity per la progettazione e la produzione di tutti i prodotti contenenti elementi digitali commerciati all’interno dei confini dell’Unione.
Si tratta, dunque, di una direttiva che estende anche al mondo della cybersecurity la marcatura CE, una certificazione rilasciata da enti notificati solo per i prodotti conformi ai requisiti del CRA.
Poiché la normativa riguarda la sicurezza delle soluzioni digitali che prima non erano coperte da altre leggi, il Cyber Resilience Act viene spesso considerato come la prima legge al mondo dedicata alla sicurezza dell’“Internet delle cose” (IoT).

Secondo il report OT Cyberattacks: Trends and Insights 2025 di Fortinet, nel 2024 gli attacchi con conseguenze fisiche sulle infrastrutture sono cresciuti del 146%, passando da 412 a oltre 1.000 casi. Un dato che evidenzia come la sicurezza digitale non riguardi più solo i sistemi informativi, ma anche processi produttivi, servizi essenziali e infrastrutture critiche.

In particolare, il regolamento si fonda su due principi chiave che guidano l’intera impostazione normativa:

• security by design: la sicurezza deve essere integrata fin dalle prime fasi di progettazione e sviluppo del prodotto, diventando parte strutturale dell’architettura del sistema;
• security by default: i prodotti devono essere forniti con configurazioni sicure già attive, evitando impostazioni iniziali deboli o esposte a rischio.

Questi due principi segnano un cambiamento significativo rispetto all’approccio tradizionale alla cybersecurity, spostando l’attenzione dalla reazione agli incidenti alla prevenzione sistemica delle vulnerabilità.

Il Cyber Resilience Act non rappresenta in realtà il primo intervento dell’Unione Europea in materia di sicurezza digitale. Al contrario, il regolamento si inserisce in un percorso normativo più ampio, volto a rafforzare la protezione di cittadini, imprese e istituzioni rispetto ai rischi informatici.
Tra i principali provvedimenti che hanno preparato il terreno al CRA troviamo:

• il GDPR (2018), che ha introdotto un quadro strutturato per la protezione dei dati personali e rafforzato gli obblighi di sicurezza nel trattamento delle informazioni;
• il Cybersecurity Act (2019), che ha definito un sistema europeo di certificazione della sicurezza per prodotti, servizi e processi ICT;
• la Direttiva NIS2 (2022), che ha esteso gli obblighi di gestione del rischio cyber e di notifica degli incidenti alle organizzazioni operanti nei settori essenziali e strategici.

Come si evince dalla tabella, maggiore è il livello di criticità del prodotto, più stringenti diventano gli obblighi di sicurezza e le procedure di certificazione richieste. In questo modo il regolamento cerca di bilanciare innovazione e sicurezza, adattando i requisiti al rischio effettivo dei diversi sistemi digitali.

Come spesso accade per i regolamenti europei, anche il CRA prevede un periodo di transizione che consente alle imprese di adeguarsi progressivamente ai nuovi obblighi.
L’implementazione del regolamento seguirà, infatti, un percorso graduale, che accompagnerà le imprese dall’introduzione dei primi requisiti alla piena applicazione.

Le tappe principali che condurranno verso la piena operatività del Cyber Resilience Act sono:

• 11 giugno 2026: sono entrate in vigore le disposizioni relative agli organismi di certificazione e ai processi di valutazione della conformità;
• 11 settembre 2026: scatterà l’obbligo per i produttori di notificare il verificarsi di vulnerabilità attivamente sfruttate e incidenti di sicurezza gravi entro tempi molto rapidi, fino a 24 ore dalla loro individuazione;
• 11 dicembre 2027: il regolamento acquisirà validità nella sua interezza, da questa data tutti i prodotti digitali immessi sul mercato dell’Unione Europea dovranno essere conformi ai requisiti previsti dal CRA.

La normativa introduce, infatti, nuovi obblighi organizzativi che modificano profondamente il modo in cui software e hardware vengono progettati e gestiti nel tempo.

Con il Cyber Resilience Act cambia in modo significativo la distribuzione delle responsabilità lungo la filiera digitale: non sono più solo gli utenti finali e le organizzazioni utilizzatrici a dover valutare i rischi e tutelarsi dalle vulnerabilità, ma entrano in gioco obblighi diretti per chi immette prodotti digitali sul mercato europeo.

L’impatto sarà particolarmente rilevante per le piccole e medie imprese, che potrebbero dover sostenere investimenti aggiuntivi in competenze, strumenti e attività di compliance. L’adeguamento ai nuovi requisiti potrebbe, infatti, comportare costi organizzativi non trascurabili e una revisione dei processi operativi e organizzativi all’interno delle aziende.
Allo stesso tempo, il regolamento può, però, essere visto anche come un’opportunità: in un contesto in cui la sicurezza informatica è un criterio sempre più importante per la scelta di clienti e partner, la capacità di dimostrare la conformità ai requisiti europei può contribuire a rafforzare la fiducia nel prodotto e nell’azienda che lo realizza.

Prima dell’introduzione del Cyber Resilience Act, le pratiche previste dal regolamento erano considerate per lo più raccomandazioni o buone prassi da seguire all’interno del settore. Attraverso il regolamento, invece, questi diventano requisiti operativi vincolanti per i produttori, trasformando in modo sostanziale i processi di progettazione e sviluppo di questi prodotti.

In particolare, il CRA richiede ai produttori di intervenire su tre aree fondamentali.

• Security by design: come menzionato precedentemente, software e hardware devono essere progettati tenendo conto dei requisiti di sicurezza fin dalle prime fasi di sviluppo, riducendo il più possibile il rischio di vulnerabilità.
• Tracciabilità dei componenti: le aziende devono documentare in modo strutturato tutti i componenti utilizzati nel prodotto – incluse librerie, framework e software di terze parti – attraverso una Software Bill of Materials (SBOM).
• Servizi di assistenza post-vendita e gestione continua del prodotto: i produttori sono tenuti ad assicurare aggiornamenti di sicurezza costanti e a mantenere un presidio continuo per l’individuazione e la correzione delle vulnerabilità.
  All’interno di questo ambito rientrano diversi obblighi operativi, tra cui:

• • gestione degli aggiornamenti del prodotto, per tutto il ciclo di vita previsto, con rilascio tempestivo di patch di sicurezza e correzioni delle vulnerabilità;
  • notifica degli incidenti di sicurezza alle autorità competenti, secondo tempistiche definite a livello europeo: entro 24 ore in caso di vulnerabilità sfruttate attivamente o incidenti con impatto significativo; entro 72 ore con un report dettagliato sulle misure adottate; entro 14 giorni con aggiornamenti sulle vulnerabilità (dopo il rilascio di una patch) e infine entro 1 mese con la relazione finale sull’incidente.

Il Cyber Resilience Act introduce alcune novità significative anche per l’ecosistema open source e del software libero, un ambito tradizionalmente basato su collaborazione e sviluppo distribuito. In questo contesto, uno degli aspetti più rilevanti riguarda il campo di applicazione del regolamento, che distingue tra utilizzo commerciale e non commerciale.

In base a questo principio, quindi, sono esclusi dal perimetro della normativa:

• sviluppatori indipendenti e contributi volontari;
• progetti finanziati tramite donazioni;
• iniziative basate esclusivamente sul recupero dei costi.

Al contrario, rientrano nell’ambito della normativa i casi in cui il software open source o libero venga integrato in attività commerciali, come:

• aziende che integrano componenti open source nei propri prodotti o servizi;
• modelli open core o servizi cloud con funzionalità a pagamento.

Un ulteriore elemento introdotto dal regolamento è la figura dell’open source software steward, un soggetto incaricato di supportare la gestione coordinata delle vulnerabilità e facilitare il dialogo con le autorità competenti. Si tratta di un ruolo di coordinamento e supporto, non di certificazione, pensato per tenere conto delle specificità del software libero e open source utilizzato anche in contesti commerciali.

Per i produttori che utilizzano Yocto Project (ad oggi la soluzione più diffusa per Linux embedded custom), il Cyber Resilience Act è affrontabile tecnicamente, ma è fondamentale poter contare su processi strutturati e automatizzati. Ecco un esempio di come intervenire in modo concreto.

Yocto supporta nativamente la generazione di SBOM in formato SPDX (raccomandato) e CycloneDX.
Nel file local.conf o nella distribuzione:

INHERIT += “create-spdx”

Oppure la classe più recente spdx / vex
Al termine del build si ottengono file come IMAGE_NAME.rootfs.spdx.json completi di tutti i pacchetti, versioni, hash, licenze e dipendenze.
È buona pratica versionare e archiviare sempre le SBOM insieme a ogni release del firmware.

Yocto include il meccanismo cve-check (o la più moderna sbom-cve-check di Bootlin).
Per abilitarlo:

OE_FRAGMENTS += “core/yocto/sbom-cve-check”

O integrare il layer meta-sbom-cve-check.
Lo strumento confronta la SBOM con i database NVD (National Vulnerability Database), filtra le CVE (Common Vulnerabilities and Exposures) rilevanti per la propria configurazione e genera report di vulnerabilità note (inclusa la KEV Catalog – Known Exploited Vulnerabilities del CISA, particolarmente critica per il reporting CRA).
Le best practice operative da tenere in considerazione sono:

• integrare la generazione di SBOM e il cve-check nelle procedure di build e rilascio;
• automatizzare il monitoraggio periodico delle nuove CVE/KEV;
• produrre VEX (Vulnerability Exploitability eXchange) statements per documentare quali vulnerabilità non sono applicabili o sono mitigate;
• mantenere una tracciabilità completa tra build, SBOM e aggiornamenti di sicurezza.

Questi strumenti permettono di dimostrare la compliance in fase di audit e di reagire rapidamente alle eventuali vulnerabilità attivamente sfruttate.

Come abbiamo visto, le prossime scadenze relative all’applicazione del Cyber Resilience Act non sono lontane. Già dopo questa estate, precisamente l’11 settembre, entrerà in vigore l’obbligo di segnalazione a carico dei fabbricanti in caso si rilevino vulnerabilità attivamente sfruttate o incidenti gravi che incidono sulla sicurezza dei prodotti da loro commercializzati. La piena applicabilità della norma, fissata all’11 dicembre 2027, sembra lontana, ma la portata dei cambiamenti introdotti dal CRA non è da sottovalutare: solo preparandosi per tempo le aziende produttrici di prodotti digitali saranno pronte a rispettare i nuovi requisiti necessari per la commercializzazione degli stessi nell’UE. È necessario avviare per tempo, fin da ora, una valutazione dei propri prodotti, dei processi di lavoro e delle collaborazioni esterne in essere. Prepararsi fin da oggi ad affrontare le scadenze future in materia potrà fare la differenza per individuare eventuali gap di conformità e gli interventi necessari da attuare, non rischiando di arrivare impreparati alla data di piena applicazione della norma.