Cyber Resilience Act: obblighi e verifiche tecniche per prodotti digitali

Il Cyber Resilience Act (Regolamento UE 2024/2847, abbreviato CRA) stabilisce requisiti orizzontali di cybersecurity per i prodotti con elementi digitali immessi sul mercato europeo. Riguarda software, hardware, dispositivi IoT, componenti digitali e prodotti connessi: non solo il momento del rilascio, ma l’intero ciclo di vita del prodotto.

Per produttori, OEM, software house, startup hardware, system integrator e aziende che commercializzano dispositivi connessi, il punto diventa poter dimostrare che il prodotto è stato progettato, testato e mantenuto con un livello di cybersecurity adeguato al rischio.

Le scadenze sono già definite: il regolamento è entrato in vigore il 10 dicembre 2024, gli obblighi di reporting si applicano dall’11 settembre 2026 e gli obblighi principali dall’11 dicembre 2027.

ISGroup interviene come partner tecnico-offensivo per produrre evidenze attraverso penetration test, security assessment, firmware analysis, reverse engineering, code review e validazione delle superfici esposte.

Perché esiste il Cyber Resilience Act

Fino a oggi, molti prodotti software e hardware sono arrivati sul mercato con vulnerabilità già note, password di default, aggiornamenti non firmati, firmware estraibile, API esposte, interfacce di debug lasciate attive, librerie obsolete o processi di gestione delle vulnerabilità non strutturati.

Con il CRA, l’Unione Europea afferma un principio preciso: un prodotto digitale o connesso deve essere sicuro non solo al momento del rilascio, ma lungo il suo ciclo di vita. Il testo ufficiale del regolamento stabilisce requisiti per progettazione, sviluppo, produzione, gestione delle vulnerabilità e sorveglianza del mercato, e introduce obblighi per tutti gli operatori economici coinvolti.

In altre parole, correggere vulnerabilità quando emergono non è più sufficiente. Serve dimostrare di aver previsto, testato e governato il rischio.

Cosa sono i prodotti con elementi digitali

Il CRA si applica ai prodotti con elementi digitali messi a disposizione sul mercato europeo quando il loro uso previsto, o ragionevolmente prevedibile, include una connessione logica o fisica, diretta o indiretta, a un dispositivo o a una rete. Il regolamento definisce questi prodotti come software o hardware, comprese le soluzioni di elaborazione dati da remoto e i componenti immessi separatamente sul mercato.

Categoria	Esempi
Dispositivi IoT	Sensori, gateway, smart device, apparati connessi
Prodotti industriali connessi	Edge gateway, HMI, sistemi di telemetria, componenti per macchine connesse
Software	Applicazioni desktop, mobile app, software embedded, componenti commercializzati separatamente
Hardware digitale	Apparati elettronici che elaborano, trasmettono o archiviano dati
Componenti	Moduli software, librerie, firmware, componenti hardware integrabili
Soluzioni cloud collegate al prodotto	Backend, API o servizi remoti senza i quali il prodotto non svolge una delle sue funzioni

Un aspetto rilevante riguarda le soluzioni di elaborazione dati da remoto. Se un dispositivo connesso dipende da un’API, da un database o da un servizio cloud sviluppato dal produttore, e senza quel servizio il prodotto non può svolgere una delle sue funzioni, quella parte remota può rientrare nel perimetro del CRA. Questo interessa in modo diretto chi sviluppa dispositivi IoT, gateway industriali, apparati wireless, sistemi di telemetria, prodotti smart home, piattaforme software collegate a prodotti fisici, dashboard cloud per controllo o manutenzione remota, e prodotti embedded con firmware aggiornabile.

Chi è coinvolto: produttori, importatori e distributori

Gli obblighi principali sono rivolti ai produttori, cioè ai soggetti che sviluppano, fabbricano o fanno sviluppare o fabbricare un prodotto con elementi digitali e lo commercializzano con il proprio nome o marchio. Ma nel perimetro rientrano anche altri operatori economici.

Soggetto	Perché deve considerare il CRA
Produttore	Deve progettare, sviluppare, testare, documentare e mantenere il prodotto secondo i requisiti CRA
Importatore	Deve verificare che il prodotto rispetti i requisiti prima di immetterlo sul mercato UE
Distributore	Deve verificare marcatura CE, informazioni e istruzioni prima della messa a disposizione
Integratore o soggetto che modifica il prodotto	In alcuni casi può assumere obblighi assimilabili a quelli del produttore
Azienda che vende con proprio marchio	Può essere considerata responsabile come produttore anche se non sviluppa internamente tutto il prodotto

Il regolamento prevede casi in cui importatori o distributori possono essere considerati produttori, per esempio quando immettono un prodotto sul mercato con il proprio nome o marchio, oppure effettuano una modifica sostanziale di un prodotto già immesso sul mercato.

Le scadenze da conoscere

Data	Cosa succede
10 dicembre 2024	Il Cyber Resilience Act entra in vigore
11 giugno 2026	Si applicano le disposizioni relative alla notifica degli organismi di valutazione della conformità
11 settembre 2026	Entrano in applicazione gli obblighi di reporting per vulnerabilità attivamente sfruttate e incidenti gravi
11 dicembre 2027	Si applicano gli obblighi principali del regolamento

Aspettare il 2027 per iniziare a lavorare sulla sicurezza del prodotto è una scelta rischiosa. Firmware, architetture embedded, aggiornamenti sicuri, gestione delle vulnerabilità, backend, API, mobile app e componenti hardware non si correggono sempre in poche settimane. Un test fatto tardi può produrre non solo una lista di vulnerabilità, ma ritardi di roadmap, redesign, blocchi commerciali o problemi di documentazione.

Gli obblighi principali per i produttori

Il CRA chiede ai produttori di progettare, sviluppare e produrre prodotti con elementi digitali in modo da garantire un livello di cybersecurity adeguato al rischio. Gli obblighi essenziali sono raccolti nell’Annex I del regolamento, diviso in requisiti relativi alle proprietà del prodotto e requisiti relativi alla gestione delle vulnerabilità. Tra i principali:

• Progettare, sviluppare e produrre il prodotto secondo un livello di cybersecurity adeguato al rischio;
• Mettere il prodotto sul mercato senza vulnerabilità note sfruttabili;
• Prevedere una configurazione sicura di default;
• Proteggere da accessi non autorizzati con controlli adeguati;
• Proteggere confidenzialità, integrità e disponibilità di dati, comandi, programmi e configurazioni;
• Limitare le superfici d’attacco, incluse le interfacce esterne;
• Ridurre l’impatto degli incidenti con misure di mitigazione;
• Registrare e monitorare attività rilevanti per la sicurezza;
• Gestire vulnerabilità e aggiornamenti di sicurezza;
• Prevedere processi di divulgazione coordinata delle vulnerabilità;
• Effettuare test e revisioni regolari della sicurezza del prodotto.

L’Annex I richiede esplicitamente ai produttori di applicare test e revisioni regolari ed efficaci della sicurezza del prodotto con elementi digitali. È qui che la compliance smette di essere solo documentazione e diventa verifica tecnica.

Dal requisito all’evidenza tecnica

Il CRA non si limita a chiedere buone intenzioni. Il produttore deve svolgere una valutazione del rischio cybersecurity, che deve informare l’implementazione dei requisiti essenziali, e la documentazione tecnica deve includere sia il risk assessment sia i mezzi scelti per soddisfare i requisiti, come chiarisce la sintesi della Commissione europea.

Se un prodotto ha firmware, API, app mobile, backend, protocolli di comunicazione, accesso remoto o componenti hardware esposti, occorre poter spiegare e dimostrare come sono stati verificati.

Area CRA	Cosa richiede in pratica	Evidenza tecnica utile
Sicurezza by design	Sicurezza considerata in progettazione, sviluppo e produzione	Threat model, security review architetturale, secure code review
Nessuna vulnerabilità nota sfruttabile	Il prodotto non deve arrivare sul mercato con vulnerabilità già note e sfruttabili	Vulnerability assessment, penetration test, dependency review
Configurazione sicura di default	Il prodotto deve essere rilasciato con impostazioni sicure	Hardening review, configuration review, test credenziali e servizi esposti
Protezione da accessi non autorizzati	Autenticazione, autorizzazione e controllo accessi devono essere robusti	Penetration test su API, backend, mobile app, interfacce amministrative
Protezione dati	Dati archiviati, trasmessi o trattati devono essere protetti	Test crittografia, review protocolli, verifica data exposure
Integrità di comandi e configurazioni	Comandi, firmware, programmi e configurazioni non devono essere alterabili da soggetti non autorizzati	Firmware analysis, test update mechanism, reverse engineering
Limitazione superfici d’attacco	Le interfacce esterne devono essere ridotte e controllate	Attack surface assessment, test porte e servizi, protocol testing
Gestione vulnerabilità	Vulnerabilità identificate, documentate, corrette e comunicate	Vulnerability management process review, re-test, remediation tracking
Aggiornamenti sicuri	Gli update devono essere distribuiti in modo sicuro e tempestivo	Test firma aggiornamenti, rollback, update tampering, secure boot
Test regolari	La sicurezza deve essere verificata in modo periodico	Penetration test ricorrenti, firmware review, hardware e software security test

Quali verifiche tecniche servono

Un prodotto con elementi digitali raramente è un oggetto singolo: è un ecosistema. Un dispositivo IoT, per esempio, può includere hardware, firmware, bootloader, sistema operativo embedded, servizi di rete, protocolli industriali o radio, applicazione mobile, backend cloud, API, portale web, sistema di aggiornamento, meccanismi di autenticazione, logging e diagnostica, interfacce di manutenzione e componenti di terze parti. Un assessment efficace deve quindi guardare il prodotto da più angolazioni.

Penetration test applicativo. Verifica API, portali web, backend, mobile app e superfici accessibili da rete. Identifica vulnerabilità come autenticazione debole, controllo accessi insufficiente, esposizione dati, IDOR, injection, session management errato e logiche di autorizzazione difettose.

Firmware security assessment. Valuta firmware, binari, configurazioni, credenziali hardcoded, servizi nascosti, librerie vulnerabili, file system embedded, meccanismi di update e protezioni anti-manomissione.

Reverse engineering. Necessario quando occorre analizzare binari, protocolli proprietari, firmware non documentato, meccanismi di cifratura, funzioni di debug, update package o logiche interne non visibili dal solo comportamento esterno.

Hardware security testing. Verifica interfacce fisiche, debug port, storage, seriali, JTAG, UART, protezioni hardware, accesso fisico al dispositivo e possibilità di estrarre informazioni sensibili.

Protocol security testing. Testa comunicazioni, messaggi, autenticazione, cifratura, replay, manipolazione dei comandi, parsing, fuzzing controllato e robustezza dei protocolli.

Source code review. Quando è disponibile il codice sorgente, permette di identificare vulnerabilità logiche, errori crittografici, controlli insufficienti, gestione insicura delle credenziali, vulnerabilità memory-related e problemi di secure coding.

Verifica del meccanismo di aggiornamento. Punto centrale per il CRA: se un prodotto deve ricevere security update, occorre verificare che il processo sia sicuro in termini di firma, integrità, autenticità, gestione rollback, canale di distribuzione, controllo versione e resilienza a manomissioni.

Impatto su IoT, OT e Industrial IoT

Il CRA ha un impatto particolarmente forte nei contesti IoT, Industrial IoT e OT. In questi ambienti, un prodotto connesso può controllare una macchina, raccogliere dati di produzione, aprire un accesso remoto, inviare comandi, integrare sensori o gateway, esporre una dashboard cloud e collegare ambienti IT e OT. Il rischio non è quindi limitato al data breach: può tradursi in fermo operativo, manipolazione di parametri, accesso non autorizzato a reti industriali, pivoting verso sistemi OT, compromissione di gateway o HMI, abuso di accessi remoti, alterazione di telemetria, perdita di integrità dei comandi o compromissione della supply chain.

Una vulnerabilità in un firmware, in un’API o in un accesso remoto non resta confinata al prodotto: può diventare un punto di ingresso verso l’ambiente del cliente finale. Un IoT/OT Security Assessment permette di verificare il prodotto come lo vedrebbe un attaccante, prima che venga immesso sul mercato, integrato in una macchina, installato in campo o collegato a una rete industriale.

Marcatura CE e valutazione della conformità

Il CRA si inserisce nel quadro della marcatura CE. I prodotti porteranno la marcatura CE per indicare la conformità ai requisiti CRA, e le autorità nazionali di sorveglianza del mercato faranno enforcement delle regole, come indicato dalla Commissione europea. Prima di immettere un prodotto sul mercato, il produttore deve effettuare la procedura di valutazione della conformità applicabile, redigere la dichiarazione UE di conformità e apporre la marcatura CE. Per molti prodotti può essere prevista una procedura di controllo interno; per prodotti importanti o critici possono applicarsi procedure più articolate, incluse valutazioni tramite organismi notificati o schemi di certificazione.

Il ruolo di ISGroup è diverso e complementare rispetto agli enti certificatori: produrre evidenze tecniche di sicurezza tramite assessment, penetration test, reverse engineering e validazione offensiva del prodotto. Chi deve affrontare il CRA ha bisogno non solo di interpretare la norma, ma di sapere se il prodotto, il firmware, il backend, le API, l’hardware e gli aggiornamenti resistono a scenari di attacco realistici.

Obblighi di reporting: perché settembre 2026 è più vicino di quanto sembri

Dall’11 settembre 2026, i produttori devono notificare vulnerabilità attivamente sfruttate e incidenti gravi che impattano la sicurezza dei prodotti con elementi digitali. La Commissione europea specifica che è richiesta una early warning entro 24 ore dalla conoscenza, una notifica completa entro 72 ore e un report finale secondo le tempistiche previste.

Per notificare correttamente una vulnerabilità o un incidente, l’organizzazione deve sapere quali prodotti e versioni sono coinvolti, quali componenti sono vulnerabili, quali ambienti potrebbero essere impattati, se esiste exploitability reale, quali mitigazioni o correzioni sono disponibili e come distribuire aggiornamenti sicuri. Senza test tecnici, asset inventory, vulnerability handling e processi di remediation strutturati, il reporting rischia di diventare una corsa disordinata.

Checklist di preparazione tecnica

Questa checklist serve a valutare se il prodotto è tecnicamente pronto per essere verificato in ottica CRA. Non sostituisce una valutazione legale o certificativa.

1. Il prodotto ha una mappa chiara di hardware, firmware, software, API, backend, mobile app e componenti di terze parti?
2. È stato eseguito un threat model del prodotto e delle sue superfici d’attacco?
3. Sono state testate le interfacce esterne, incluse porte, servizi, protocolli e API?
4. Il firmware è stato analizzato per credenziali hardcoded, librerie vulnerabili, servizi nascosti o configurazioni insicure?
5. Il meccanismo di aggiornamento è firmato, integro e resistente a manomissioni?
6. L’autenticazione è robusta su dispositivo, app, cloud, API e interfacce amministrative?
7. I dati in transito e a riposo sono protetti con meccanismi adeguati?
8. Esiste un processo per ricevere, valutare, correggere e comunicare vulnerabilità?
9. Sono previsti test di sicurezza regolari, non solo prima del primo rilascio?
10. Dopo una remediation viene eseguito un re-test tecnico?

Se la risposta è “no” o “non lo sappiamo” a più di una di queste domande, il problema non è solo documentale: è tecnico.

CRA, NIS2, Regolamento Macchine e IEC 62443

Il CRA non vive isolato. La Commissione europea chiarisce che il regolamento completa altre normative in ambito cybersecurity, in particolare la Direttiva NIS2.

Norma o standard	Focus principale	Rilevanza per chi produce o usa prodotti connessi
Cyber Resilience Act	Prodotto con elementi digitali	Richiede cybersecurity by design, gestione vulnerabilità, evidenze e marcatura CE
NIS2	Organizzazione e gestione del rischio	Spinge aziende essenziali e importanti a verificare anche supply chain e ambienti OT
Regolamento Macchine 2023/1230	Macchine, sicurezza, modifiche sostanziali	Rilevante per macchine connesse, software, accessi remoti e rischio cyber-safety
IEC 62443	Standard tecnico per ambienti industriali e IACS	Aiuta a tradurre requisiti cyber industriali in controlli tecnici, zone, conduit e security level
RED Delegated Act / EN 18031	Dispositivi radio	Rilevante per dispositivi wireless, gateway e prodotti radio connessi

Il denominatore comune è uno: servono evidenze tecniche. Dichiarare che il prodotto è sicuro non è sufficiente; occorre dimostrarlo attraverso test, analisi, review, tracciabilità e remediation.

Come interviene ISGroup

ISGroup supporta aziende che sviluppano, integrano, commercializzano o utilizzano prodotti con elementi digitali con attività tecniche che includono:

• IoT Security Assessment e OT Security Assessment;
• Penetration test hardware e software;
• Firmware security assessment;
• Reverse engineering;
• Source code review;
• API security testing;
• Mobile app security testing;
• Backend security assessment;
• Protocol security testing;
• Vulnerability assessment;
• Analisi forense;
• Validazione post-remediation;
• Assessment ricorrenti a ogni nuova release, modifica o integrazione.

L’approccio è tecnico, offensivo e controllato: verificare il prodotto come farebbe un attaccante, con metodologia, perimetro autorizzato, attenzione al contesto industriale e output utilizzabili dai team R&D, IT, OT, security e compliance.

ISGroup produce report tecnici, executive summary e remediation plan, supporta re-test e validazione delle correzioni, e fornisce evidenze tecniche integrabili in percorsi di audit, qualifica, certificazione o conformità. ISGroup non rilascia certificazioni CRA, non sostituisce organismi notificati e non fornisce pareri legali.

Assessment una tantum o ricorrente

Un singolo penetration test prima del rilascio è utile, ma non sufficiente se il prodotto evolve. Ogni nuova release firmware, modifica software, integrazione cloud, nuova API, cambio di protocollo, aggiornamento hardware o apertura di un accesso remoto può introdurre nuove vulnerabilità. In ottica CRA, la sicurezza non è un deliverable statico: è un processo verificabile.

Un approccio maturo prevede test prima del rilascio sul mercato, prima di una certificazione o qualifica, dopo modifiche firmware o software, dopo l’introduzione di nuove API o accessi remoti, dopo remediation importanti, periodicamente durante il support period e prima dell’integrazione in ambienti OT o macchine connesse.

Richiedi una valutazione tecnica del prodotto connesso

Il Cyber Resilience Act sta trasformando la cybersecurity dei prodotti digitali in un requisito di mercato. Se l’organizzazione sviluppa, integra o commercializza dispositivi IoT, software, firmware, componenti embedded, gateway industriali, prodotti connessi o soluzioni cloud collegate al prodotto, il momento per verificare la sicurezza è prima che una vulnerabilità diventi un problema operativo, commerciale o regolatorio.

ISGroup verifica hardware, firmware, software, API, protocolli e superfici esposte con metodologie offensive controllate, producendo evidenze tecniche utili per audit, roadmap di remediation e percorsi di conformità.

Domande frequenti sul Cyber Resilience Act

• Il Cyber Resilience Act riguarda anche il software?
• Sì. Il CRA riguarda prodotti con elementi digitali, inclusi prodotti software e hardware, componenti e soluzioni di elaborazione dati da remoto quando rientrano nel perimetro del regolamento.
• Quando si applicano gli obblighi principali?
• Il CRA è entrato in vigore il 10 dicembre 2024. Gli obblighi di reporting si applicano dall’11 settembre 2026 e gli obblighi principali dall’11 dicembre 2027, come indicato dalla Commissione europea.
• Il CRA impone penetration test obbligatori?
• Il regolamento non prescrive uno specifico tipo di test, ma l’Annex I richiede test e revisioni regolari ed efficaci della sicurezza del prodotto. Per molti prodotti connessi, un penetration test tecnico, un firmware assessment o una security review sono tra le evidenze più concrete per dimostrare che la sicurezza è stata verificata.
• Il CRA richiede una SBOM?
• L’Annex I prevede che i produttori identifichino e documentino vulnerabilità e componenti, anche tramite una software bill of materials in formato comunemente usato e machine-readable, almeno per le dipendenze di primo livello.
• ISGroup certifica la conformità al CRA?
• No. ISGroup non rilascia certificazioni CRA e non sostituisce organismi notificati o consulenti legali. ISGroup produce evidenze tecniche attraverso penetration test, security assessment, reverse engineering, firmware analysis e validazione delle superfici esposte.
• Quando conviene eseguire un assessment tecnico?
• Prima del rilascio, prima di una certificazione o qualifica, dopo modifiche firmware o software, dopo l’introduzione di nuove API o accessi remoti, dopo remediation significative e periodicamente durante il ciclo di vita del prodotto.

Approfondimenti utili

• Pianificare le scadenze CRA 2026-2027
• Differenze tra CRA e NIS2 per produttori e operatori
• IEC 62443 come riferimento tecnico per l’assessment
• Verifica di firmware e componenti embedded