CRA (Cyber Resilience Act): guida completa alla conformità per aziende e prodotti digitali

Parliamo di prodotti digitali, cioè dispositivi hardware e soluzioni software, inclusi i loro componenti, e, in alcuni casi, anche di soluzioni di elaborazione dati da remoto quando costituiscono parte funzionale del prodotto.

Il 3 marzo 2026 la Commissione europea ha pubblicato la bozza della prima guida applicativa al Cyber Resilience Act (“CRA”), Regolamento UE 2024/2847, aprendola alla consultazione degli stakeholder fino al 31 marzo 2026. È un passaggio atteso e strategico. Arriva nel momento in cui le imprese devono smettere di chiedersi se il CRA le riguardi e iniziare a chiedersi come adeguarsi, con quali priorità e con quale urgenza.

Il CRA non si rivolge solo all’industria tech. Si rivolge a qualunque operatore economico che metta a disposizione sul mercato europeo un prodotto con elementi digitali. Questo include fabbricanti, importatori e distributori, e non dipende dal fatto che il destinatario finale sia un consumatore o un’impresa. In altre parole, il regolamento non è confinato al B2C. Ha un impatto pieno anche sulle filiere B2B.

Cos’è il Cyber Resilience Act: sicurezza nel prodotto, non intorno al prodotto

Il CRA è entrato in vigore il 10 dicembre 2024 ed è il primo quadro normativo europeo che impone requisiti obbligatori di cybersicurezza a chi progetta, sviluppa, produce, importa o distribuisce prodotti con elementi digitali.

Il principio cardine è la security by design. La sicurezza non deve essere aggiunta a valle, ma incorporata nel prodotto fin dalla progettazione, dal codice, dall’architettura e dalle scelte tecniche iniziali. Allo stesso modo, la security by default impone che il prodotto arrivi all’utente con impostazioni sicure già attive, senza dipendere da interventi manuali di hardening successivi.

Il CRA si affianca alla Direttiva NIS2 e al Cybersecurity Act ma con una logica diversa. NIS2 riguarda la gestione del rischio cyber delle organizzazioni nei settori coperti. Il CRA interviene invece sui requisiti di cybersicurezza dei prodotti con elementi digitali immessi sul mercato. Il risultato è un doppio livello di responsabilità. Le organizzazioni devono gestire in modo adeguato la propria esposizione al rischio cyber. I prodotti che comprano, integrano o vendono devono a loro volta rispettare requisiti specifici di sicurezza. Per le imprese che sono insieme utilizzatrici e fabbricanti, questi due livelli non si sostituiscono. Si sommano

B2B e B2C: il perimetro reale del CRA

Una delle letture più diffuse, e più fuorvianti, è che il CRA serva soprattutto a proteggere il consumatore finale che acquista router, videocamere IP, smart speaker o altri dispositivi connessi. È una lettura parziale: il regolamento si applica ai prodotti con elementi digitali messi a disposizione sul mercato nel corso di un’attività commerciale. Questa formula non distingue tra B2C e B2B.

In termini pratici, software gestionale, soluzioni di monitoraggio industriale, componenti IoT, firmware, librerie distribuite separatamente e molti altri elementi digitali utilizzati in ambito business possono rientrare nel perimetro CRA, se qualificabili come prodotti con elementi digitali o come componenti messi a disposizione sul mercato.

Più delicato è il tema del cloud e del SaaS. Non ogni servizio cloud o SaaS rientra automaticamente nel CRA. Il punto decisivo è se si tratti di una soluzione di elaborazione remota progettata dal fabbricante, o sotto la sua responsabilità, la cui assenza impedirebbe al prodotto di svolgere una sua funzione. Solo in questi casi il legame con il prodotto può farla rientrare nella logica del regolamento.

Questo ha effetti immediati sulla supply chain digitale. Un’impresa che integra nel proprio prodotto componenti software o hardware di terzi deve esercitare adeguata due diligence, perché la responsabilità della conformità del prodotto finale resta in capo al fabbricante che lo immette sul mercato. Il CRA, da questo punto di vista, trasforma la cybersicurezza in una variabile contrattuale e industriale. Non più semplice buona pratica, ma requisito da governare anche nei rapporti B2B, come già avviene per qualità, sicurezza del prodotto e marcatura CE.

Il 2027 è già adesso: perché i tempi industriali contano più della data formale

La data dell’11 dicembre 2027, quando il CRA diventerà pienamente applicabile nella gran parte dei suoi obblighi, è quella che compare più spesso nelle comunicazioni ufficiali. Ed è proprio quella che induce molte imprese a rimandare. È un errore.

Il CRA impone la security by design, abbiamo detto. Questo significa che la conformità non può essere aggiunta all’ultimo momento a un prodotto già definito nella sua architettura, nei suoi componenti, nelle sue logiche di aggiornamento, nei suoi meccanismi di autenticazione o nella sua gestione delle vulnerabilità. Per molti prodotti hardware connessi e per molti software complessi, attendere il 2027 significa arrivare tardi dal punto di vista tecnico, organizzativo e contrattuale, anche se non ancora formalmente inadempienti. Il 2026 è quindi, in termini industriali, l’anno decisivo per chi non ha ancora avviato analisi, classificazione del portafoglio e riprogettazione.

A questo si aggiunge un ulteriore livello di complessità. Il CRA richiede che i prodotti siano progettati, sviluppati e mantenuti in modo da ridurre le vulnerabilità e da gestirle lungo tutto il ciclo di vita. Questo rende essenziale, sul piano operativo, disporre di un inventario affidabile dei componenti software utilizzati, anche tramite SBOM (una sorta di lista dei sotto-componenti di un software), come base per l’analisi del rischio, la gestione delle dipendenze e il vulnerability management. Non si tratta di un adempimento una tantum. È un processo continuativo che va costruito con anticipo, perché incide su procurement, sviluppo, test, documentazione tecnica, aggiornamenti e supporto post-vendita.

Cosa chiarisce la guida europea

La bozza di guida pubblicata dalla Commissione il 3 marzo 2026 interviene soprattutto su alcuni nodi interpretativi che, per le imprese, sono anche i più delicati.

Il primo riguarda il rapporto tra prodotto e servizi remoti. La guida chiarisce meglio quando una soluzione di elaborazione remota costituisce parte funzionale del prodotto e quando invece resta un servizio autonomo. È un punto decisivo per produttori di dispositivi connessi, system integrator, OEM e fornitori di piattaforme che erogano funzioni essenziali da remoto.

Il secondo nodo riguarda il software free e open source. La questione non si risolve dicendo semplicemente che l’open source è escluso o incluso. Il criterio reale è se il software venga messo a disposizione sul mercato nel corso di un’attività commerciale, oppure integrato in un prodotto commerciale. Chi integra componenti open source in prodotti distribuiti sul mercato non può trattarli come elementi neutri o fuori perimetro. Deve considerarli dentro il proprio processo di conformità, valutazione del rischio e gestione delle vulnerabilità.

Il terzo nodo riguarda il periodo di supporto. Il CRA richiede che il fabbricante gestisca le vulnerabilità e metta a disposizione aggiornamenti di sicurezza per il periodo di supporto del prodotto. Questo periodo, in linea di principio, non può essere inferiore a cinque anni, salvo che il prodotto sia ragionevolmente destinato a un uso più breve. È un punto con impatto diretto su contratti di manutenzione, service level, lifecycle management, disponibilità di patch e rapporti con fornitori e clienti.

Le scadenze che le imprese non possono ignorare

La scadenza del dicembre 2027 non è l’unica da tenere presente. C’è una data intermedia molto rilevante: gli obblighi di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi, previsti dall’articolo 14 del CRA, si applicano dall’11 settembre 2026. Questo significa che i processi interni di rilevazione, classificazione, escalation e notifica non possono essere costruiti all’ultimo trimestre del 2027. Devono essere operativi prima.

È questo il punto che molte imprese sottovalutano. La conformità CRA non è solo documentazione tecnica e dichiarazione finale. È anche capacità organizzativa di monitorare vulnerabilità, trattare dipendenze software, ricevere segnalazioni, valutare impatti, rilasciare correzioni e comunicare nei tempi previsti. In assenza di questi processi, il rischio non è solo sanzionatorio. È anche commerciale, reputazionale e contrattuale.

Le sanzioni: struttura graduata, impatto concreto

Il regime sanzionatorio del CRA è strutturato su più livelli. Per la violazione dei requisiti essenziali di cybersicurezza, le sanzioni possono arrivare fino a 15 milioni di euro o al 2,5 per cento del fatturato mondiale annuo, se superiore. Per la violazione di alcuni obblighi diversi dai requisiti essenziali, compresi quelli documentali e procedurali, il massimale può arrivare a 10 milioni di euro o al 2 per cento del fatturato. Per la comunicazione di informazioni inesatte, incomplete o fuorvianti alle autorità competenti, il massimale può arrivare a 5 milioni di euro o all’1 per cento del fatturato. Le microimprese e le piccole imprese beneficiano di criteri proporzionati ma non di un’esenzione.

Cosa fare adesso: le priorità per le imprese

La prima priorità è mappare il portafoglio prodotti. Bisogna capire quali prodotti rientrino nel perimetro CRA, quali siano i componenti rilevanti, se il prodotto sia ordinario, importante di classe I o II, oppure critico, quali dipendenze di terze parti siano presenti, e quali evidenze di conformità siano già disponibili o mancanti.

La seconda priorità è avviare subito una gap analysis rispetto ai requisiti essenziali del CRA. Occorre capire se sono state progettate in modo coerente con i requisiti del regolamento, se il prodotto può essere aggiornato in sicurezza, se le vulnerabilità possono essere gestite correttamente, se l’autenticazione e la configurazione iniziale siano adeguate, se esista una documentazione tecnica utilizzabile in sede di valutazione di conformità.

La terza priorità è strutturare vulnerability management e gestione dei componenti software. Questo significa: registro delle dipendenze, criteri di valutazione del rischio, canali di ricezione delle segnalazioni, responsabilità interne chiare, tempi di risposta definiti, integrazione tra sviluppo, sicurezza, qualità, legale e compliance.

La quarta priorità è contrattuale. Nei rapporti con fornitori di componenti, software, firmware, servizi gestiti e manutenzione, servono clausole coerenti con il CRA. Questo include obblighi informativi sulle vulnerabilità, trasparenza sulle dipendenze, gestione dei periodi di supporto, disponibilità di patch, cooperazione documentale e allocazione chiara delle responsabilità