Cyber Resilience Act: le domande che contano

Il CRA riguarda i "prodotti con elementi digitali" — hardware o software la cui destinazione d’uso include una connessione dati, diretta o indiretta, con un altro dispositivo o una rete — resi disponibili sul mercato dell’Unione. Il perimetro è quindi ampio: non solo device connessi, ma anche il software che li fa funzionare. Restano fuori i prodotti già coperti da normative settoriali equivalenti (dispositivi medici, aeronautica, auto).

La regola pratica: se vendi in UE qualcosa che si connette o comunica, parti dal presupposto che rientri, e verifica le esclusioni, non il contrario.

Il software immesso sul mercato come prodotto rientra, anche se venduto separatamente dall’hardware. I servizi cloud/SaaS in quanto servizi non sono l’oggetto del CRA (la sicurezza del servizio è territorio di NIS2), ma le "soluzioni di elaborazione dati remota" necessarie al funzionamento del prodotto — la parte server senza cui il device non fa il suo lavoro — rientrano nel perimetro del prodotto.

La distinzione che conta non è "on-premise vs cloud", ma "prodotto vs servizio": conta cosa immetti sul mercato.

Il software libero e open source sviluppato o fornito al di fuori di un’attività commerciale non rientra. Quando invece è monetizzato o integrato in un prodotto commerciale, gli obblighi tornano in capo a chi lo immette sul mercato. Il CRA introduce anche la figura dell’"open source software steward" (fondazioni, enti che sostengono progetti usati in prodotti commerciali) con un regime più leggero e proporzionato.

Per chi costruisce prodotti: usare una libreria open source non sposta la responsabilità CRA sull’upstream. Resta tua, sul prodotto finito.

Sì, se il prodotto viene reso disponibile sul mercato dell’Unione. Il CRA segue il prodotto, non la sede del produttore. Nella catena, importatori e distributori hanno obblighi propri di verifica (marcatura CE, documentazione, periodo di supporto dichiarato) e non possono immettere prodotti non conformi.

In pratica un produttore extra-UE deve avere una controparte nella catena europea che risponda di questi obblighi.

Da questa data si applica l’articolo 14: l’obbligo di segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi, con tempi in ore — early warning entro 24h, notifica entro 72h, relazione finale entro 14 giorni. Vale anche per i prodotti già sul mercato.

Cosa devi aver fatto non è "avere il prodotto conforme", ma avere il processo: chi è autorizzato a notificare, un account EU Login già attivo, il canale verso la piattaforma unica di ENISA, e un registro tracciabile. Un’azienda senza questo processo non è in ritardo sul CRA: è esposta a una scadenza già attiva.

La SBOM (Software Bill of Materials) è l’inventario dei componenti software del prodotto, comprese le dipendenze di terze parti. Il CRA chiede di redigerla e mantenerla in formato leggibile da una macchina, almeno al livello superiore delle dipendenze, e di usarla per gestire le vulnerabilità. Non c’è un obbligo generale di pubblicarla: serve ad avere sotto controllo cosa c’è dentro il prodotto e a reagire quando un componente diventa vulnerabile.

Per tutto il "periodo di supporto", che il produttore fissa in base a quanto ci si aspetta che il prodotto sia usato. Il riferimento della Commissione è di almeno cinque anni, a meno che la vita attesa del prodotto sia più breve. Durante quel periodo gli aggiornamenti di sicurezza vanno forniti in modo tempestivo e gratuito. Il periodo di supporto va dichiarato: diventa un’informazione che accompagna il prodotto, non una scelta interna.

Dipende dalla classe del prodotto. Per la maggior parte dei prodotti (classe "default") basta l’autovalutazione della conformità. Per i prodotti "importanti" (Allegato III) serve applicare le norme armonizzate — che danno presunzione di conformità — oppure passare da una terza parte. Per i prodotti "critici" (Allegato IV) è previsto il percorso più stringente, fino alla certificazione europea. La classe non la decidi tu a intuito: la ricavi dagli allegati.

Il regolamento è in vigore dal 10 dicembre 2024, ma si applica in modo scaglionato. Tre date: dall’11 giugno 2026 possono essere designati gli organismi notificati; dall’11 settembre 2026 scatta l’obbligo di segnalazione dell’articolo 14; dall’11 dicembre 2027 si applicano tutti i requisiti sostanziali e la marcatura CE. Vanno lette in ordine di urgenza, non di calendario: settembre 2026 è un problema di processo da risolvere adesso, dicembre 2027 un problema di progettazione da vincere prima.

Le sanzioni sono su più livelli. La violazione dei requisiti essenziali di cibersicurezza e degli obblighi di gestione delle vulnerabilità arriva fino a 15 milioni di euro o al 2,5% del fatturato mondiale annuo, se superiore. Per altri obblighi le soglie sono più basse, e informazioni false o incomplete alle autorità hanno una sanzione a sé. Sono massimali: la sanzione effettiva è proporzionata, ma l’ordine di grandezza dice che il CRA non è un adempimento formale.

Una modifica è sostanziale quando cambia la conformità del prodotto ai requisiti essenziali o ne altera la destinazione d’uso in modo da introdurre nuovi rischi: a quel punto il prodotto va rivalutato come se fosse nuovo. Gli aggiornamenti di sicurezza che si limitano a correggere vulnerabilità, senza cambiare le funzioni, non sono modifiche sostanziali. È una distinzione che conta nel ciclo di vita: evita di far ripartire la valutazione a ogni patch, ma la impone quando cambi davvero il prodotto.

No. Un sistema qualità certificato è un vantaggio sull’impianto documentale e di processo che il CRA richiede — versioning, gestione dei fornitori, tracciabilità — ma la ISO 9001 non parla di sicurezza del prodotto: non copre la gestione delle vulnerabilità, i requisiti dell’Allegato I, il periodo di supporto. È una base su cui appoggiare parte del lavoro, non una scorciatoia che chiude la conformità.

Sì, e lavorano su piani diversi. NIS2 riguarda la sicurezza dell’organizzazione e dei servizi di un soggetto essenziale o importante; il CRA riguarda la sicurezza del prodotto che immetti sul mercato. Un produttore industriale può essere soggetto a entrambi: NIS2 per come gestisce la propria azienda, CRA per come progetta e mantiene ciò che vende. Non si sostituiscono e non si annullano: vanno mappati insieme per non fare due volte lo stesso lavoro né lasciare buchi.

La IEC 62443 è lo standard tecnico su cui si appoggia gran parte del lavoro CRA per prodotti e sistemi industriali: la 62443-4-1 sul processo di sviluppo sicuro e la 62443-4-2 sui requisiti tecnici dei componenti danno un linguaggio già pronto per soddisfare i requisiti dell’Allegato I. La presunzione di conformità vera e propria arriverà dalle norme armonizzate europee, ma chi lavora già con la 62443 parte con un impianto coerente, non da zero.

Sì, per i dispositivi radio. I requisiti di cibersicurezza legati alla Direttiva RED cessano di applicarsi l’11 dicembre 2027 e il CRA diventa il riferimento unico, evitando che lo stesso dispositivo debba rispondere a due set di requisiti paralleli. È una semplificazione, ma travestita da scadenza: chi usava la RED come ancora cyber deve spostarla sul CRA, che è più ampio e continuativo.