Il Cyber Resilience Act (Regolamento UE 2024/2847) introduce requisiti orizzontali di cybersecurity per i prodotti con elementi digitali — software, hardware, firmware, dispositivi IoT, prodotti embedded, gateway industriali, componenti digitali, applicazioni e soluzioni remote collegate al prodotto — con una roadmap progressiva articolata in tre date operative distinte che impatta produttori, importatori, distributori e aziende che sviluppano, commercializzano o integrano questi prodotti.
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, come confermato dalla Commissione Europea.
Attendere dicembre 2027 per avviare test su firmware, software, API, aggiornamenti, gestione delle vulnerabilità e processi di sicurezza comporta rischi concreti: un redesign del meccanismo di aggiornamento, una code review estesa, una remediation critica o un re-test non si completano nelle ultime settimane prima della scadenza.
ISGroup interviene sulla parte tecnica — non come ente certificatore, non come consulente legale, non come organismo notificato — ma come partner per produrre evidenze tecniche attraverso penetration test, security assessment, firmware analysis, reverse engineering, source code review, hardware e software testing, API security testing e validazione post-remediation.
Le tre date operative del CRA
| Data | Cosa succede | Impatto operativo |
|---|---|---|
| 10 dicembre 2024 | Il CRA entra in vigore | Inizia il periodo di transizione: i produttori devono preparare processi, roadmap e verifiche tecniche |
| 11 giugno 2026 | Si applica il Capitolo IV sugli organismi di valutazione della conformità | Diventa operativo il quadro relativo agli organismi di valutazione della conformità |
| 11 settembre 2026 | Si applicano gli obblighi di reporting dell’articolo 14 | I produttori devono notificare vulnerabilità attivamente sfruttate e incidenti gravi secondo le tempistiche definite |
| 11 dicembre 2027 | Si applicano gli obblighi principali del regolamento | Diventano pienamente applicabili i requisiti essenziali di cybersecurity per prodotti con elementi digitali |
L’articolo 71 del Regolamento (UE) 2024/2847 stabilisce che il regolamento si applica dall’11 dicembre 2027, con due eccezioni: l’articolo 14 sul reporting si applica dall’11 settembre 2026 e il Capitolo IV sugli organismi di valutazione della conformità dall’11 giugno 2026. Per molte aziende, la prima prova operativa concreta arriva quindi a settembre 2026, non a dicembre 2027.
Obblighi di reporting dall’11 settembre 2026
Dall’11 settembre 2026 i produttori devono notificare le vulnerabilità attivamente sfruttate presenti in prodotti con elementi digitali e gli incidenti gravi che impattano la sicurezza del prodotto. Le tempistiche previste dal regolamento sono molto strette.
| Evento | Prima notifica | Notifica completa | Rapporto finale |
|---|---|---|---|
| Vulnerabilità attivamente sfruttata | Entro 24 ore dalla conoscenza | Entro 72 ore dalla conoscenza | Entro 14 giorni dalla disponibilità di una misura correttiva o mitigativa |
| Incidente grave sulla sicurezza del prodotto | Entro 24 ore dalla conoscenza | Entro 72 ore dalla conoscenza | Entro un mese dalla notifica dell’incidente |
La pagina dedicata agli obblighi di reporting della Commissione Europea conferma le tempistiche: segnalazione preliminare entro 24 ore, notifica completa entro 72 ore e rapporto finale secondo le scadenze previste per vulnerabilità e incidenti. Il testo del regolamento specifica inoltre che per una vulnerabilità attivamente sfruttata il rapporto finale è dovuto entro 14 giorni dalla disponibilità della misura correttiva, mentre per un incidente grave il termine è di un mese dalla notifica.
Per rispettare questi tempi non basta disporre di un canale per le segnalazioni. Serve sapere quali prodotti e versioni sono coinvolti, quali componenti sono vulnerabili, se la vulnerabilità è realmente sfruttabile, quali installazioni potrebbero essere esposte, se esiste una mitigazione temporanea e come coordinare sviluppo, security, supporto, legale e management in tempi molto brevi. In assenza di test tecnici, inventario di prodotto, processi di gestione delle vulnerabilità e procedure di risposta agli incidenti, il reporting CRA rischia di diventare una gestione disordinata dell’emergenza.
Obblighi principali dall’11 dicembre 2027
Dall’11 dicembre 2027 si applicano gli obblighi principali del Cyber Resilience Act. Il Regolamento (UE) 2024/2847 introduce requisiti orizzontali di cybersecurity per i prodotti con elementi digitali, che includono requisiti essenziali per progettazione, sviluppo e produzione, oltre a requisiti per la gestione delle vulnerabilità durante l’intero periodo di utilizzo previsto del prodotto.
Entro dicembre 2027 un produttore deve essere in grado di dimostrare che il prodotto è stato progettato, sviluppato, testato, mantenuto e aggiornato tenendo conto della cybersecurity. Le aree tecniche da presidiare includono: progettazione sicura per impostazione predefinita, gestione delle vulnerabilità, aggiornamenti di sicurezza, controllo degli accessi, protezione dei dati, riduzione della superficie d’attacco, integrità di firmware e software, logging e monitoraggio, gestione dei componenti, documentazione tecnica e test regolari.
Il problema del lead time tecnico
La scadenza del 2027 può sembrare lontana, ma per un prodotto con elementi digitali i tempi tecnici sono spesso lunghi. Un problema su un’API può essere corretto in settimane, mentre un problema nel firmware può richiedere mesi. Un meccanismo di aggiornamento debole può richiedere un redesign architetturale; l’assenza di avvio sicuro può dipendere dall’hardware; una chiave condivisa tra dispositivi può richiedere una nuova architettura di provisioning. Una vulnerabilità in un componente embedded già distribuito può richiedere piano di remediation, comunicazione ai clienti, patch, test e re-test.
Per questo la roadmap CRA va costruita a ritroso, partendo dalle scadenze ufficiali e risalendo fino alle attività tecniche da avviare con anticipo sufficiente.
Roadmap tecnica verso settembre 2026
L’obiettivo di settembre 2026 è essere pronti a gestire reporting, vulnerabilità sfruttate e incidenti gravi in modo credibile e tracciabile. Le aree da preparare e le verifiche tecniche utili sono le seguenti.
| Area | Cosa preparare | Verifica tecnica utile |
|---|---|---|
| Inventario di prodotto | Elenco prodotti, versioni firmware/software, componenti e release attive | Mappatura della superficie d’attacco del prodotto |
| Ricezione delle vulnerabilità | Canale per ricevere, classificare e tracciare vulnerabilità | Revisione del processo di gestione delle vulnerabilità |
| Gestione degli incidenti | Processo per valutare incidenti gravi sul prodotto | Simulazione tecnica di risposta agli incidenti |
| Valutazione della sfruttabilità | Capacità di determinare se una vulnerabilità è sfruttabile | Penetration test mirato, security review |
| Mappatura delle versioni | Collegamento tra vulnerabilità, versione prodotto e clienti impattati | Revisione dell’inventario firmware/software |
| Processo di aggiornamento | Capacità di rilasciare correzioni sicure | Revisione del meccanismo di aggiornamento sicuro |
| Raccolta delle evidenze | Raccolta di evidenze tecniche e decisioni | Rapporto tecnico, tracciamento della remediation |
| Coordinamento interno | Coordinamento tra R&D, security, supporto e management | Simulazione del processo di notifica |
| Logging e telemetria | Dati utili a capire impatto e diffusione | Revisione dei flussi di log e dati |
| Re-test | Verifica delle correzioni | Rapporto di re-test |
Le verifiche tecniche prioritarie in questa fase sono: firmware security assessment sui prodotti più critici, API e backend security testing, revisione del meccanismo di aggiornamento sicuro, revisione del processo di gestione delle vulnerabilità e penetration test mirato sulle superfici esposte.
Roadmap tecnica verso dicembre 2027
L’obiettivo di dicembre 2027 è più ampio: dimostrare che prodotto, processi e ciclo di vita soddisfano i requisiti essenziali di cybersecurity applicabili.
| Area CRA | Cosa serve | Evidenza tecnica utile |
|---|---|---|
| Progettazione sicura | Sicurezza integrata nel ciclo di sviluppo | Threat model, revisione dell’architettura di sicurezza |
| Configurazione sicura per impostazione predefinita | Configurazioni iniziali robuste | Revisione dell’hardening, test delle configurazioni predefinite |
| Riduzione della superficie d’attacco | Servizi, porte, API e funzioni esposte limitati | Attack surface assessment |
| Controllo degli accessi | Autenticazione e autorizzazione robuste | Test API, test applicativo, revisione dei privilegi |
| Integrità software e firmware | Protezione da alterazioni non autorizzate | Firmware analysis, revisione dell’avvio sicuro |
| Aggiornamenti sicuri | Aggiornamenti firmati, integri e controllati | Test del meccanismo di aggiornamento |
| Protezione dei dati | Dati protetti in transito e a riposo | Revisione crittografica, test di esposizione dei dati |
| Gestione delle vulnerabilità | Processo per ricevere, valutare e correggere vulnerabilità | Revisione del vulnerability management |
| Componenti software e hardware | Mappatura dei componenti rilevanti | Revisione delle dipendenze e dei componenti |
| Test regolari | Verifiche periodiche della sicurezza | Penetration test, re-test, code review |
| Documentazione tecnica | Evidenze coerenti con il percorso di prodotto | Pacchetto di evidenze tecniche |
Tra settembre 2026 e giugno 2027 la priorità è consolidare la remediation e integrare la sicurezza nel ciclo di vita: correggere le vulnerabilità critiche emerse, ridurre la superficie d’attacco, migliorare le configurazioni predefinite, introdurre processi di re-test, verificare app mobile, backend, cloud e API, e formalizzare il tracciamento della remediation. Le verifiche utili in questa fase includono source code review, revisione dell’architettura di sicurezza, IoT penetration testing, firmware re-test, cloud e API security assessment e mobile app security testing.
Nella fase finale, da giugno a dicembre 2027, la priorità è validare le evidenze e chiudere i finding aperti: ripetere il penetration test sulle release finali, consolidare la documentazione tecnica, verificare i prodotti più importanti con il percorso appropriato e preparare il materiale tecnico integrabile in percorsi di audit, qualifica o conformità.
Priorità tecniche: cosa verificare per primo
Quando il tempo disponibile è limitato, conviene partire dal rischio tecnico concreto. I prodotti da testare per primi sono quelli con connessione Internet, accesso remoto, API pubbliche, dashboard cloud, app mobile, firmware aggiornabile, utenti enterprise, installazioni industriali, dati sensibili o funzioni critiche.
Meccanismo di aggiornamento. Un meccanismo debole è uno dei problemi più costosi da correggere tardi. Vanno verificati firma, integrità, autenticità, gestione del rollback e del downgrade, revoca, distribuzione e gestione dei fallimenti.
Firmware. Le verifiche principali riguardano credenziali hardcoded, servizi nascosti, librerie vulnerabili, interfacce di debug, configurazioni, chiavi e certificati, file system e protezioni di integrità.
API e backend. Vanno verificati autenticazione, autorizzazione, IDOR, esposizione dei dati, gestione delle sessioni, rate limiting, logging, ruoli e gestione dei dispositivi.
App mobile. Le verifiche riguardano token, storage locale, comunicazioni, certificate pinning dove appropriato, reverse engineering dell’app, autorizzazioni e legame con API e dispositivo.
Gestione delle vulnerabilità. Vanno verificati ricezione delle segnalazioni, classificazione, valutazione della sfruttabilità, remediation, comunicazione, re-test e tracciabilità.
Configurazioni predefinite. Vanno verificate le impostazioni iniziali del prodotto per assicurarsi che siano robuste senza richiedere intervento manuale dell’utente finale.
Checklist di preparazione per settembre 2026
- L’organizzazione dispone di un inventario completo dei prodotti con elementi digitali, incluse versioni firmware, software, API e backend?
- Sono stati identificati i prodotti più esposti?
- Esiste un canale per ricevere segnalazioni di vulnerabilità e un processo per determinare se una vulnerabilità è attivamente sfruttata?
- Sono disponibili template e ruoli per la segnalazione preliminare entro 24 ore e la notifica completa entro 72 ore?
- Esiste un processo per definire mitigazioni e correzioni, con re-test successivo?
- Sono già stati testati il meccanismo di aggiornamento e il firmware?
- Sono disponibili log, telemetria o dati tecnici utili a valutare l’impatto?
- Esiste un responsabile chiaro per le decisioni tecniche e le comunicazioni verso le autorità?
Checklist di preparazione per dicembre 2027
- Il prodotto è stato progettato con un threat model e la configurazione predefinita è sicura?
- La superficie d’attacco è stata mappata e ridotta?
- Firmware, software, API, backend e app mobile sono stati testati?
- Gli aggiornamenti sono firmati e verificati, con gestione del rollback?
- Le credenziali sono gestite in modo sicuro e i dati sono protetti in transito e a riposo?
- Le vulnerabilità sono gestite lungo il ciclo di vita, con remediation tracciata e re-test?
- Le evidenze tecniche sono raccolte, aggiornate e coerenti con il percorso di prodotto?
- Il prodotto viene testato a ogni release rilevante e le modifiche sostanziali vengono rivalutate?
- Il periodo di supporto è coerente con i processi di aggiornamento e gestione delle vulnerabilità?
Output di un assessment pre-conformità CRA
Un assessment pre-conformità identifica le lacune tecniche prima che emergano in audit, sul mercato o durante un incidente. Non certifica il prodotto e non sostituisce organismi notificati o consulenti legali.
| Output | Utilità |
|---|---|
| Executive summary | Sintesi per management, product owner e qualità |
| Rapporto tecnico | Evidenze tecniche per R&D e security team |
| Mappa della superficie d’attacco | Firmware, software, API, backend, app, cloud e superfici esposte |
| Risultati firmware | Credenziali, aggiornamenti, servizi, librerie, configurazioni |
| Risultati API e backend | Autenticazione, autorizzazione, esposizione dei dati, logiche applicative |
| Risultati app mobile | Token, storage, comunicazioni, interazioni con backend |
| Revisione del meccanismo di aggiornamento | Evidenze su firma, integrità, rollback, flusso di aggiornamento |
| Revisione della gestione delle vulnerabilità | Capacità di ricevere, classificare e correggere vulnerabilità |
| Piano di remediation | Priorità e interventi tecnici |
| Rapporto di re-test | Evidenza della correzione |
| Pacchetto di evidenze tecniche | Materiale tecnico integrabile in percorsi di audit, qualifica o conformità |
Per il CRA, un test una tantum può essere utile ma non sufficiente se il prodotto evolve. L’assessment va ripetuto a ogni nuova release significativa, dopo modifiche a firmware, API o backend, dopo l’introduzione di un’app mobile, dopo cambio hardware, dopo aggiornamenti del meccanismo di aggiornamento, dopo remediation critica, prima dell’immissione sul mercato e periodicamente sui prodotti più critici durante il periodo di supporto.
Errori frequenti nella roadmap CRA
Attendere dicembre 2027. Settembre 2026 arriva prima e riguarda il reporting. Per notificare correttamente, è necessario sapere già cosa si ha, cosa è vulnerabile, cosa è sfruttabile e cosa si può correggere.
Partire solo dalla documentazione. La documentazione è necessaria, ma se firmware, aggiornamenti, API o accessi presentano debolezze tecniche, il problema resta tecnico e non si risolve con le procedure.
Testare solo il frontend. Un prodotto con elementi digitali può includere firmware, hardware, app, cloud, backend, API, componenti e remote data processing: tutte superfici da verificare.
Non eseguire il re-test. Senza re-test non è possibile verificare se la remediation è efficace.
Ignorare i prodotti già sul mercato. I prodotti immessi sul mercato prima dell’11 dicembre 2027 sono soggetti ai requisiti del regolamento solo se subiscono una modifica sostanziale da quella data. Tuttavia, gli obblighi di reporting dell’articolo 14 del regolamento si applicano anche ai prodotti già immessi sul mercato che rientrano nel perimetro del CRA.
Confondere assessment tecnico e certificazione. ISGroup produce evidenze tecniche. Non certifica la conformità CRA e non sostituisce organismi notificati o consulenti legali.
Il ruolo di ISGroup
ISGroup supporta aziende che sviluppano, integrano o commercializzano prodotti con elementi digitali con attività tecniche utili a costruire una roadmap CRA concreta. Le attività includono IoT e OT Security Assessment, penetration test su prodotti connessi, firmware security assessment, reverse engineering, hardware e software security testing, source code review, API security testing, mobile app security testing, backend security assessment, revisione del meccanismo di aggiornamento sicuro, revisione della gestione delle vulnerabilità, threat modeling, security auditing, piano di remediation e re-test.
ISGroup non vende adeguamento CRA chiavi in mano, non rilascia certificazioni CRA e non sostituisce organismi notificati, consulenti legali o compliance advisor. Il valore è tecnico: trasformare le scadenze CRA in una roadmap di verifiche, remediation e re-test, producendo evidenze reali sulla sicurezza del prodotto.
Per pianificare un assessment pre-conformità CRA su firmware, software, API, backend, meccanismo di aggiornamento, gestione delle vulnerabilità o superfici esposte, è possibile contattare ISGroup direttamente.
Domande frequenti sul Cyber Resilience Act
- Quando si applicano gli obblighi del Cyber Resilience Act?
- Il CRA è entrato in vigore il 10 dicembre 2024. Gli obblighi di reporting dell’articolo 14 si applicano dall’11 settembre 2026; gli obblighi principali, inclusi i requisiti essenziali di cybersecurity, si applicano dall’11 dicembre 2027.
- Cosa cambia dall’11 settembre 2026?
- Da settembre 2026 i produttori devono notificare vulnerabilità attivamente sfruttate e incidenti gravi che impattano la sicurezza del prodotto. Il processo prevede una segnalazione preliminare entro 24 ore, una notifica completa entro 72 ore e un rapporto finale entro 14 giorni dalla disponibilità della misura correttiva (per le vulnerabilità) o entro un mese (per gli incidenti gravi).
- Il CRA si applica anche ai prodotti già immessi sul mercato?
- I prodotti immessi sul mercato prima dell’11 dicembre 2027 sono soggetti ai requisiti principali solo se subiscono una modifica sostanziale da quella data. Gli obblighi di reporting dell’articolo 14, tuttavia, si applicano anche ai prodotti già in commercio che rientrano nel perimetro del regolamento.
- Un assessment pre-conformità CRA certifica il prodotto?
- No. Un assessment tecnico identifica vulnerabilità, produce evidenze e supporta la remediation, ma non certifica la conformità al CRA e non sostituisce organismi notificati o consulenti legali.
- Da dove conviene iniziare se il tempo è limitato?
- La priorità va ai prodotti più esposti: quelli con connessione Internet, API pubbliche, firmware aggiornabile, app mobile o installazioni industriali. Le prime verifiche tecniche utili riguardano il meccanismo di aggiornamento, il firmware, le API e il processo di gestione delle vulnerabilità.
Approfondimenti utili
- Obblighi CRA per prodotti con elementi digitali
- Rapporto tra CRA e NIS2 per produttori e operatori
- Dispositivi radio e requisiti EN 18031
- Firmware security e reverse engineering: priorità di remediation
2 risposte
[…] Pianificare le scadenze CRA 2026-2027 […]
[…] Preparare le scadenze CRA 2026-2027 […]