Chi rientra nel Cyber Resilience Act? Quali prodotti sono soggetti al CRA? Il regolamento si applica anche ai software, alle app, ai SaaS o ai prodotti sviluppati per un solo cliente?
Sono probabilmente queste le domande che oggi interessano maggiormente imprenditori, software house, aziende manifatturiere e responsabili compliance. Il motivo è semplice. Il Cyber Resilience Act – CRA, Regolamento (UE) 2024/2847 introduce requisiti obbligatori di cybersicurezza per i prodotti con elementi digitali messi a disposizione sul mercato europeo. Ma il suo perimetro non si individua utilizzando soltanto il settore dell’azienda o la sua dimensione.
Ed è proprio qui che nasce buona parte della confusione.
Negli ultimi anni GDPR, NIS2 e DORA hanno abituato le imprese a chiedersi innanzitutto se appartengono a una determinata categoria di soggetti o a uno specifico settore. Con il Cyber Resilience Act la domanda iniziale è diversa.
Quali prodotti hardware o software mettiamo a disposizione sul mercato europeo e come funzionano?
Il CRA è infatti una disciplina orizzontale applicabile ai prodotti con elementi digitali. Il perimetro comprende prodotti hardware e software e può comprendere anche componenti separatamente commercializzati. a rientra nel Cyber Resilience Act è quindi necessario partire dal prodotto.
Chi rientra nel Cyber Resilience Act? Non soltanto le aziende informatiche
Uno dei primi errori è associare il Cyber Resilience Act esclusivamente alle software house, ai produttori di firewall o alle imprese specializzate in cybersecurity. Il CRA ha un perimetro decisamente più ampio. Un’azienda manifatturiera può produrre macchinari dotati di software e capacità di connessione. Un produttore di apparecchiature elettroniche può integrare moduli di comunicazione o funzioni di gestione remota.
Una software house può commercializzare applicazioni desktop o mobile.
Un’impresa può fare sviluppare un prodotto da un soggetto terzo e venderlo con il proprio marchio.
In ciascuno di questi casi il Cyber Resilience Act può essere rilevante.
La Commissione europea richiama tra gli esempi di prodotti interessati anche applicazioni mobile, programmi informatici e diversi dispositivi dotati di elementi digitali. Il CRA riguarda infatti prodotti software e hardware con elementi digitali, con l’obiettivo di introdurre requisiti di cybersicurezza lungo il loro ciclo di vita. da, quindi, non è da solo il criterio decisivo. Bisogna analizzare il prodotto.**
Come capire se un prodotto rientra nel CRA: il test in tre domande
Per una prima verifica del perimetro Cyber Resilience Act è utile procedere attraverso tre domande.
1. Esiste un prodotto hardware o software?
Il CRA utilizza la nozione di prodotto con elementi digitali.
Il regolamento riguarda prodotti software e hardware e le relative soluzioni di elaborazione remota dei dati previste dalla disciplina. Anche componenti software o hardware messi separatamente a disposizione sul mercato possono assumere rilevanza. prodotto CRA può essere un dispositivo fisico, ma anche un programma informatico.
Può trattarsi, ad esempio, di un software gestionale commercializzato come prodotto, di un’applicazione mobile, di un firmware, di un modulo elettronico o di una componente destinata a essere integrata in altri prodotti. La presenza di un involucro fisico non è necessaria.
Allo stesso modo, la circostanza che il software non svolga una funzione di cybersecurity non determina alcuna esclusione automatica.
2. Il prodotto viene messo a disposizione sul mercato dell’Unione europea?
Il secondo elemento è spesso sottovalutato.
Il Cyber Resilience Act disciplina i prodotti messi a disposizione sul mercato.
La nozione riguarda la fornitura di un prodotto per la distribuzione o l’uso sul mercato dell’Unione nel corso di un’attività commerciale. La disciplina può assumere rilevanza anche quando la fornitura avviene gratuitamente. La Commissione precisa invece che i prodotti con elementi digitali non messi a disposizione sul mercato, perché non forniti nel corso di un’attività commerciale, non sono soggetti al CRA. è l’unico criterio.
Distribuire gratuitamente un software può comunque assumere rilevanza quando ciò avviene nel contesto di un’attività commerciale. All’opposto, sviluppare o utilizzare internamente un prodotto digitale non determina automaticamente l’applicazione del CRA.
È un passaggio particolarmente importante per le imprese che sviluppano software.
Software utilizzato internamente e software fornito a clienti non sono necessariamente la stessa cosa sotto il profilo del Cyber Resilience Act.
3. Il prodotto prevede una connessione a un dispositivo o a una rete?
Il terzo elemento riguarda la connessione.
Il CRA si applica ai prodotti con elementi digitali messi a disposizione sul mercato quando la loro finalità prevista o il loro utilizzo ragionevolmente prevedibile comprende una connessione dati, logica o fisica, diretta o indiretta, a un dispositivo o a una rete. Non bisogna quindi limitare l’analisi ai prodotti permanentemente collegati a Internet.
Un prodotto può dialogare con altri dispositivi, può scambiare dati attraverso una rete locale, può utilizzare un’applicazione associata, può dipendere da componenti software o da funzioni remote per eseguire determinate attività.
La domanda corretta non è semplicemente: “il prodotto ha il Wi-Fi?”.
La verifica deve riguardare l’architettura reale del prodotto, le sue funzioni e gli scenari di utilizzo ragionevolmente prevedibili.
Il CRA non coincide con l’IoT
Un prodotto non deve necessariamente essere presentato commercialmente come “smart” o “IoT” per rientrare nel Cyber Resilience Act. Occorre verificare insieme la natura hardware o software del prodotto, la sua messa a disposizione sul mercato nel corso di un’attività commerciale e la presenza di una connessione rilevante ai sensi del CRA.
Quali prodotti rientrano nel Cyber Resilience Act?
Una volta compreso il criterio generale, il perimetro dei prodotti CRA diventa più chiaro.
In funzione delle caratteristiche concrete possono rientrare nel Cyber Resilience Act:
- software applicativi commercializzati a clienti;
- applicazioni mobile;
- firmware e software integrati in apparecchiature;
- dispositivi connessi e apparecchiature elettroniche;
- componenti hardware o software commercializzati separatamente;
- sistemi e componenti utilizzati in ambienti industriali;
- dispositivi di rete;
- sistemi operativi e altre componenti software;
- prodotti che dipendono da specifiche funzioni di elaborazione remota.
La Commissione europea descrive il CRA come una disciplina applicabile ai prodotti hardware e software con elementi digitali e richiama espressamente, tra gli esempi, applicazioni e varie categorie di prodotti digitali. uriera l’analisi non dovrebbe quindi fermarsi al prodotto commerciale nel suo complesso.
Bisogna ricostruire la sua architettura digitale. Rispondi a queste domande per farlo:
- Quale firmware è presente?
- Esistono funzioni di teleassistenza?
- Il macchinario comunica con un’applicazione?
- Sono previsti aggiornamenti da remoto?
- Il cliente installa un software di controllo?
- Una parte delle funzionalità dipende da sistemi remoti gestiti dal fabbricante?
In molte aziende la risposta al quesito “rientriamo nel CRA?” non è circoscritta ad un unico ufficio/funzione. Serve il confronto tra chi conosce il prodotto, chi lo sviluppa, chi gestisce la cybersecurity, chi segue la compliance e chi conosce il modello contrattuale e commerciale.
CRA e software: il software applicativo rientra nel Cyber Resilience Act?
Sì, può rientrare. Non esiste una generale esclusione del software applicativo dal CRA.
La Commissione indica anche le applicazioni mobile tra gli esempi di prodotti della categoria generale soggetti alla disciplina. Le fonti istituzionali sul Cyber Resilience Act fanno riferimento a prodotti software e hardware con elementi digitali. stare l’analisi attraverso una distinzione rigida tra sistemi operativi e firmware, da una parte, e applicazioni aziendali, dall’altra.
Il vero punto è verificare se il software:
- costituisce un prodotto con elementi digitali;
- viene fornito per la distribuzione o l’uso sul mercato dell’Unione nell’ambito di un’attività commerciale;
- presenta la connessione richiesta dal regolamento.
Se queste condizioni ricorrono, il software applicativo può trovarsi nel perimetro CRA.
Il software sviluppato per un solo cliente rientra nel CRA?
Anche in questo caso è necessaria cautela.
Il fatto che un’applicazione sia stata sviluppata per un unico cliente non costituisce, di per sé, un’esclusione dal Cyber Resilience Act. La disciplina sulla messa a disposizione sul mercato guarda alla fornitura del prodotto nel corso di un’attività commerciale. oftware su commessa non è quindi prudente concludere: “è un software custom, il CRA non si applica”. Occorre esaminare il rapporto concreto e chiedersi:
- L’impresa sta prestando esclusivamente un servizio professionale di sviluppo?
- Oppure sta fornendo al cliente un prodotto software?
- Chi assume la responsabilità dello sviluppo?
- Chi commercializza il risultato?
- Sotto quale nome o marchio?
- Il prodotto viene successivamente riutilizzato, licenziato o distribuito?
La risposta richiede un’analisi del modello tecnico, commerciale e contrattuale.
Il numero dei clienti non è, da solo, un criterio sufficiente per escludere il CRA.
SaaS e Cyber Resilience Act: i servizi cloud sono esclusi?
Quello del SaaS e CRA è probabilmente uno dei punti sui quali è più facile creare confusione. Un servizio SaaS non diventa automaticamente un prodotto soggetto al Cyber Resilience Act soltanto perché viene erogato attraverso Internet. Il CRA è una disciplina dei prodotti con elementi digitali e non una normativa generale applicabile a qualsiasi servizio digitale o cloud. Ma da questo non deriva la regola opposta secondo cui tutto ciò che è SaaS o remoto sarebbe sempre escluso dal CRA.
Il regolamento considera anche determinate soluzioni di elaborazione remota dei dati collegate ai prodotti con elementi digitali. In particolare, l’analisi deve considerare le soluzioni di elaborazione remota progettate e sviluppate dal fabbricante, o sotto la sua responsabilità, quando la loro assenza impedirebbe al prodotto con elementi digitali di svolgere una delle proprie funzioni.
La distinzione tra prodotto software, servizio SaaS e soluzione di elaborazione remota è oggi uno dei temi più delicati nell’applicazione del CRA. Anche la Commissione europea ha dedicato attenzione specifica alle remote data processing solutions nei propri lavori interpretativi sull’attuazione del regolamento. hardware commercializzato insieme a una piattaforma remota senza la quale una funzione del prodotto non potrebbe essere eseguita.
In una situazione di questo tipo l’analisi non dovrebbe separare artificialmente l’hardware dalla componente remota. Bisogna comprendere l’architettura funzionale complessiva.
“SaaS” è un modello di erogazione, non una risposta automatica sul CRA
Prima di escludere una soluzione cloud occorre verificare se esiste un prodotto con elementi digitali e quale ruolo svolge l’elaborazione remota rispetto alle funzioni del prodotto.
Cyber Resilience Act e open source: il software open source è escluso?
Anche sull’open source bisogna evitare formule eccessivamente semplici.
Il CRA adotta una disciplina specifica per il software libero e open source.
Il software free and open source che non viene messo a disposizione sul mercato nel corso di un’attività commerciale beneficia della disciplina prevista dal regolamento. La Commissione chiarisce inoltre che il CRA non intende trattare il singolo sviluppatore che contribuisce a un progetto open source come un fabbricante per il solo fatto di avere fornito codice. erò, che l’utilizzo di componenti open source renda un prodotto commerciale estraneo al CRA.
Una software house può integrare librerie e componenti open source nel proprio prodotto. La natura open source della singola componente non elimina la necessità di conoscere e governare i componenti dai quali dipende il prodotto commercializzato.
“È una libreria open source” non è una manleva sulla sicurezza del prodotto.
La governance delle dipendenze software, la conoscenza delle componenti utilizzate e la gestione delle vulnerabilità diventano quindi elementi centrali del ciclo di vita del prodotto.
Cyber Resilience Act: quali prodotti e settori sono esclusi?
Sul tema delle esclusioni dal Cyber Resilience Act è necessaria una precisazione metodologica. Non sempre è corretto affermare che un intero settore sia escluso dal CRA. In diversi casi il legislatore europeo esclude determinati prodotti perché già soggetti a specifiche discipline dell’Unione.
È quindi più corretto analizzare il prodotto e la normativa settoriale applicabile, anziché affidarsi esclusivamente al codice ATECO o al mercato nel quale opera l’impresa.
Dispositivi medici
Il CRA prevede specifiche esclusioni per prodotti coperti dalla normativa europea sui dispositivi medici e sui dispositivi medico-diagnostici in vitro. Le fonti istituzionali dell’Unione richiamano i dispositivi medici già coperti da specifica normativa europea tra le categorie escluse dal perimetro CRA. sere un’azienda del settore medicale non significa che qualsiasi software o prodotto sviluppato dall’impresa sia automaticamente escluso dal Cyber Resilience Act.**
Occorre verificare se il singolo prodotto rientra effettivamente nel campo di applicazione della normativa settoriale rilevante. Un prodotto digitale dell’azienda che non abbia tale qualificazione deve essere analizzato separatamente.
Aviazione civile
Il CRA prevede un coordinamento con la specifica disciplina europea sulla sicurezza dell’aviazione civile. Anche in questo caso il criterio non è la semplice appartenenza dell’impresa alla filiera aeronautica. Conta il prodotto e la sua effettiva copertura da parte del quadro normativo settoriale previsto dall’Unione.
Automotive e veicoli
La disciplina dei prodotti destinati ai veicoli richiede particolare attenzione. Le fonti europee indicano specifiche esclusioni e meccanismi di coordinamento con la normativa dell’Unione applicabile ai prodotti automotive. ponentistica il messaggio è chiaro: non utilizzare automaticamente la formula “automotive escluso dal CRA”. Bisogna verificare quale prodotto viene commercializzato e quale specifica disciplina europea ne regola i requisiti di cybersicurezza.
Equipaggiamento marittimo
Il regolamento contiene una specifica esclusione per le apparecchiature rientranti nel quadro normativo europeo sull’equipaggiamento marittimo. Anche qui l’esclusione è collegata al prodotto e alla presenza di una disciplina settoriale europea.
Difesa, sicurezza nazionale e informazioni classificate
Sono previste esclusioni per determinati prodotti sviluppati o modificati esclusivamente per finalità di sicurezza nazionale o difesa e per prodotti destinati al trattamento di informazioni classificate. La natura esclusiva della destinazione è importante. Un prodotto commerciale genericamente utilizzabile anche in contesti sensibili non diventa automaticamente un prodotto escluso dal Cyber Resilience Act.
Determinati pezzi di ricambio
Il CRA disciplina inoltre il caso di determinati pezzi di ricambio destinati alla sostituzione di componenti identici e realizzati secondo le medesime specifiche. È un tema particolarmente rilevante per le aziende manifatturiere che mantengono per anni cataloghi di componenti destinati alla manutenzione di prodotti già commercializzati. Anche in questo caso l’esclusione deve essere verificata rispetto alle condizioni previste dal regolamento.
Siti web, portali e servizi professionali rientrano nel CRA?
Un sito corporate, una pagina informativa o un servizio professionale non rientrano nel Cyber Resilience Act semplicemente perché utilizzano strumenti digitali. Il CRA riguarda prodotti con elementi digitali messi a disposizione sul mercato. Una società di consulenza che utilizza un portale per comunicare con i clienti non diventa, per questo solo fatto, fabbricante CRA del portale.
Allo stesso modo, davanti a un servizio digitale bisogna distinguere il servizio dal software eventualmente fornito e commercializzato come prodotto. È una distinzione particolarmente importante per le aziende che descrivono genericamente la propria offerta come “piattaforma”, “ecosistema”, “soluzione cloud” o “servizio digitale”. Il nome commerciale non determina l’applicazione del CRA, occorre invece capire cosa viene concretamente fornito al cliente.
Prodotti CRA standard, importanti e critici: come funziona la classificazione?
Stabilire che un prodotto rientra nel Cyber Resilience Act è soltanto il primo passaggio.
Bisogna successivamente verificare la categoria del prodotto e il relativo percorso di valutazione della conformità. Il CRA distingue la categoria generale dei prodotti e specifiche categorie di prodotti importanti e critici. Le modalità di valutazione della conformità variano anche in funzione di tale classificazione. le dei prodotti CRA
La maggioranza dei prodotti che non rientra nelle categorie specifiche previste dal regolamento resta nella categoria generale. Essere nella categoria generale non significa essere esclusi dal CRA. Significa che il prodotto segue il percorso di conformità previsto per tale categoria.
Autovalutazione non significa assenza di requisiti di cybersicurezza.
Il prodotto deve comunque rispettare i requisiti essenziali applicabili. Cambia la procedura attraverso la quale il fabbricante dimostra la conformità.
Prodotti importanti
Il CRA individua categorie di prodotti considerate particolarmente rilevanti sotto il profilo della cybersicurezza.
Tra gli esempi frequentemente richiamati nelle fonti istituzionali e di settore figurano sistemi operativi, software antivirus, router e firewall. e del prodotto e delle condizioni previste dal regolamento, il percorso di valutazione della conformità può diventare più rigoroso.
Prodotti critici
Per i prodotti critici il livello di garanzia richiesto aumenta ulteriormente. La classificazione del prodotto è quindi una fase sostanziale dell’analisi CRA. Non basta sapere che un prodotto contiene software o componenti digitali. Bisogna verificare la sua funzione e il suo eventuale inquadramento nelle categorie previste dal regolamento.
CRA e white label: chi è il fabbricante responsabile?
Il Cyber Resilience Act concentra obblighi particolarmente rilevanti sul fabbricante. Ma la nozione di fabbricante non coincide necessariamente con l’impresa che materialmente assembla il prodotto o scrive il codice. Per molte aziende italiane questo è uno dei temi più delicati.
Un’impresa può acquistare un prodotto tecnologico da un produttore esterno, personalizzarlo commercialmente e immetterlo sul mercato con il proprio nome o marchio.
Pensare che tutta la responsabilità CRA rimanga automaticamente presso il fornitore tecnico può essere un errore. Il quadro CRA attribuisce specifici obblighi agli operatori economici coinvolti nella produzione, importazione e distribuzione dei prodotti con elementi digitali. getto white label o private label occorre quindi verificare il ruolo assunto dall’impresa ai sensi del regolamento.
Lo stesso vale per i componenti di terzi. La supply chain resta importante, ma non sostituisce l’analisi della responsabilità sul prodotto commercializzato.
Le scadenze del Cyber Resilience Act: settembre 2026 e dicembre 2027
Le date del CRA da tenere in agenda sono ormai molto vicine.
Il Cyber Resilience Act è entrato in vigore nel dicembre 2024 e la sua applicazione generale è prevista dall’11 dicembre 2027.
Gli obblighi di segnalazione relativi alle vulnerabilità attivamente sfruttate e agli incidenti gravi si applicano invece dall’11 settembre 2026. e 2026 rende poco prudente l’idea di rimandare ogni attività al 2027.
Un fabbricante che oggi non dispone di un inventario dei propri prodotti, di un processo di gestione delle vulnerabilità e di un meccanismo interno capace di individuare ed escalare gli eventi rilevanti potrebbe trovarsi in difficoltà prima della piena applicazione del regolamento.
Sanzioni CRA: il rischio non è soltanto economico
Le violazioni del Cyber Resilience Act possono comportare sanzioni amministrative molto rilevanti.
Ma concentrare un progetto CRA esclusivamente sulla possibilità di ricevere una sanzione sarebbe riduttivo.
Il Cyber Resilience Act interviene sulla conformità dei prodotti digitali immessi sul mercato europeo e introduce requisiti obbligatori di cybersicurezza lungo il loro ciclo di vita. odotto entra quindi direttamente nella sua governance.
Non è più soltanto una buona pratica gestita dal reparto IT.
Per molte imprese il rischio più significativo può essere commerciale.
Clienti soggetti alla NIS2 o ad altri obblighi di gestione del rischio cyber stanno aumentando l’attenzione verso la sicurezza della propria catena di fornitura.
Un prodotto scarsamente governato sotto il profilo delle vulnerabilità, degli aggiornamenti e della sicurezza può quindi diventare un problema anche nelle relazioni B2B.
Come prepararsi al CRA: da dove dovrebbe partire un’azienda?
Il primo progetto di conformità al Cyber Resilience Act non dovrebbe iniziare con la scrittura di una nuova policy.
Dovrebbe iniziare dall’inventario dei prodotti.
Per ogni linea di prodotto l’impresa dovrebbe ricostruire:
- quale prodotto hardware o software viene effettivamente messo a disposizione sul mercato;
- chi lo sviluppa e sotto la responsabilità di quale soggetto;
- con quale nome o marchio viene commercializzato;
- quali componenti hardware e software sono integrate;
- quali connessioni a dispositivi o reti sono previste o ragionevolmente prevedibili;
- se esistono funzioni remote necessarie al funzionamento del prodotto;
- quale normativa settoriale europea si applica;
- se ricorre una specifica esclusione dal CRA;
- se il prodotto appartiene a una categoria importante o critica;
- quali processi di gestione delle vulnerabilità sono già presenti.
Soltanto dopo questa ricognizione ha senso passare al cybersecurity risk assessment del prodotto, ai requisiti di sicurezza applicabili, alla documentazione tecnica e alla procedura di valutazione della conformità.
La domanda da portare al prossimo comitato compliance
Non chiedete soltanto all’IT: “siamo conformi al CRA?”.
Chiedete a prodotto, R&D, cybersecurity, legal e compliance: “quali prodotti digitali mettiamo sul mercato, con quale architettura e sotto la responsabilità di chi?”.
È da questa risposta che inizia realmente il progetto Cyber Resilience Act.
Cyber Resilience Act: prima capire chi rientra, poi costruire la conformità
Il Cyber Resilience Act non è semplicemente la “NIS2 dei prodotti” e non può essere affrontato copiando un assessment organizzativo di cybersecurity.
La NIS2 guarda alla gestione del rischio e alla resilienza di determinati soggetti.
Il CRA introduce requisiti di cybersicurezza sul prodotto e sul suo ciclo di vita.
Per molte imprese la difficoltà iniziale non sarà implementare un controllo tecnico.
Sarà capire quali prodotti appartengono realmente al perimetro CRA, quale ruolo assume l’azienda e quale percorso di conformità deve essere applicato alle diverse famiglie di prodotti.
Classificare in modo errato un software come semplice servizio, dare per scontata un’esclusione settoriale, ignorare una componente remota necessaria al funzionamento o ritenere che il fornitore white label assorba automaticamente ogni responsabilità può condizionare l’intero percorso di adeguamento.
Per questo il Cyber Resilience Act dovrebbe essere affrontato partendo da una gap analysis di perimetro e di prodotto, capace di integrare compliance, cybersecurity e conoscenza tecnica dell’offerta aziendale.
Domande frequenti sul Cyber Resilience Act
Il Cyber Resilience Act si applica alle PMI?
Sì. Il CRA non utilizza la dimensione aziendale come criterio generale per stabilire se un prodotto con elementi digitali rientra nel proprio perimetro. Una PMI che commercializza un prodotto hardware o software soggetto al regolamento deve quindi valutare i propri obblighi.
Il CRA si applica ai software gestionali?
Può applicarsi. La definizione di prodotto con elementi digitali comprende il software. Bisogna verificare la messa a disposizione sul mercato, il funzionamento del prodotto e la connessione prevista o ragionevolmente prevedibile.
Un SaaS è sempre escluso dal Cyber Resilience Act?
No. Non è corretto usare la qualificazione SaaS come criterio automatico di esclusione. Occorre distinguere un servizio cloud da un prodotto con elementi digitali e verificare l’eventuale presenza di soluzioni di elaborazione remota necessarie alle funzioni del prodotto.
Un prodotto fabbricato da terzi e venduto con il mio marchio può creare obblighi CRA?
Sì, il modello white label o private label deve essere analizzato con particolare attenzione. Il soggetto che commercializza un prodotto con il proprio nome o marchio non può dare per scontato che tutti gli obblighi CRA rimangano in capo al produttore tecnico.
FinData supporta imprese manifatturiere, software house e organizzazioni tecnologiche nell’analisi del perimetro Cyber Resilience Act, nella classificazione dei prodotti con elementi digitali e nella definizione del percorso di adeguamento CRA.
Il primo obiettivo non è produrre nuova documentazione.
È stabilire, prodotto per prodotto, cosa rientra nel Cyber Resilience Act, perché vi rientra e quali obblighi ne derivano.