Il Cyber Resilience Act introduce dall’11 settembre 2026 gli obblighi di segnalazione previsti dall’articolo 14. Per i fabbricanti interessati significa organizzarsi per comunicare vulnerabilità attivamente sfruttate e incidenti gravi che incidono sulla sicurezza dei prodotti con elementi digitali.
Non basta sapere che esiste una scadenza: occorre stabilire chi riceve un allarme, chi lo valuta e chi può inviare la notifica. Per una piccola software house, una segnalazione ricevuta il venerdì sera può mettere alla prova l’intera organizzazione.
Aggiornamento: 1° settembre 2026. Fonti ufficiali: Commissione europea, ENISA ed EUR-Lex.
Le date del Cyber Resilience Act: settembre 2026 e dicembre 2027
Il regolamento (UE) 2024/2847 è entrato in vigore il 10 dicembre 2024. Il calendario distingue tre passaggi: dall’11 giugno 2026 si applica il capitolo sugli organismi di valutazione della conformità; dall’11 settembre 2026 l’articolo 14 sul reporting; dall’11 dicembre 2027 la disciplina si applica in via generale. Presentare settembre 2026 come l’avvio di tutti i requisiti CRA sarebbe quindi inesatto. Fonte: sintesi della Commissione europea.
Quali aziende devono verificare il proprio ruolo
Il CRA riguarda prodotti hardware e software con elementi digitali messi a disposizione sul mercato dell’Unione, con connessioni dirette o indirette a dispositivi o reti. Il perimetro comprende, alle condizioni previste, anche componenti commercializzati separatamente e soluzioni di elaborazione remota necessarie alle funzioni del prodotto.
Gli obblighi dell’articolo 14 riguardano i fabbricanti. Un’impresa che usa un gestionale non diventa per questo il suo fabbricante. Chi sviluppa o fa sviluppare un prodotto e lo commercializza con il proprio nome deve invece esaminare attentamente il proprio ruolo. Importatori, distributori e soggetti che modificano prodotti richiedono una valutazione distinta.
Un sito web o un servizio SaaS non rientra automaticamente nel CRA: conta il rapporto con un prodotto e con le sue funzioni. Anche l’open source richiede distinzioni: esistono esclusioni per attività non commerciali e un regime specifico per gli open-source software stewards. Riferimento: regolamento, articoli 2, 3 e 24 e considerando 11–19.
Le piccole dimensioni non costituiscono un’esenzione generale. Inoltre, il reporting interessa anche prodotti già immessi sul mercato prima dell’11 dicembre 2027. Perciò il censimento deve considerare anche le versioni precedenti, non soltanto i nuovi lanci. Fonte: Commissione europea, disposizioni transitorie.
Che cosa segnalare e con quali tempi
Non ogni difetto rilevato da uno scanner comporta una notifica obbligatoria. Le categorie centrali sono le vulnerabilità attivamente sfruttate, supportate da prove affidabili di sfruttamento malevolo, e gli incidenti gravi che incidono sulla sicurezza del prodotto. La sola gravità numerica di una CVE non sostituisce questa valutazione.
| Fase | Vulnerabilità attivamente sfruttata | Incidente grave |
|---|---|---|
| Preallarme | Entro 24 ore dalla conoscenza | Entro 24 ore dalla conoscenza |
| Notifica | Entro 72 ore dalla conoscenza | Entro 72 ore dalla conoscenza |
| Relazione finale | Entro 14 giorni dalla disponibilità della misura correttiva | Entro un mese dall’invio della notifica delle 72 ore |
Preallarme e notifica vanno effettuati senza indebito ritardo: le 24 e le 72 ore sono limiti massimi, non tempi da attendere. Le due finestre decorrono dalla conoscenza dell’evento rilevante; non si sommano. La relazione finale segue invece le decorrenze specifiche indicate nella tabella. Fonte: Commissione europea, reporting CRA; articolo 14, paragrafi 2 e 4.
Dove si inviano le segnalazioni
Il canale previsto è la Single Reporting Platform (SRP) gestita da ENISA: la segnalazione raggiunge il CSIRT coordinatore competente ed è, di regola, resa disponibile anche a ENISA. La Commissione indica l’operatività della piattaforma entro l’11 settembre 2026. Fonte ufficiale.
Le FAQ ENISA aggiornate al 31 agosto indicano che il rappresentante deve disporre di un account personale EU Login con autenticazione a due fattori. È possibile preparare questo accesso in anticipo; ENISA consiglia invece di avviare registrazione e validazione nella SRP quando occorre inviare una notifica. L’associazione con il fabbricante viene validata dal CSIRT e la validazione pendente non impedisce l’invio iniziale. Le stesse FAQ precisano che nella fase iniziale non sono previste API: non bisogna basare il processo su un’integrazione automatica non disponibile. Fonte: FAQ ENISA, punti 9 e 15.
Una checklist pratica per prepararsi
Le attività seguenti sono una proposta organizzativa: aiutano a trasformare la scadenza in un processo utilizzabile anche da un team piccolo.
- Censire prodotti e versioni. Preparare una scheda con nome commerciale, responsabile, versioni distribuite, componenti principali e Paesi serviti. Annotare i dubbi di perimetro da chiarire.
- Nominare un referente e un sostituto. Indicare chi decide sulla segnalazione, chi raccoglie le evidenze e chi dispone degli accessi. Prevedere assenze e fine settimana.
- Rendere riconoscibile il canale di sicurezza. Stabilire dove arrivano le segnalazioni di clienti e ricercatori, con un controllo regolare e un percorso di escalation.
- Registrare la cronologia. Conservare ora di ricezione, verifiche, evidenze di sfruttamento, decisioni e motivazioni. Separare i fatti accertati dalle ipotesi ancora da verificare.
- Preparare un modello di raccolta dati. Includere prodotto, versioni coinvolte, impatto, mitigazioni disponibili, referente tecnico e informazioni ancora mancanti.
- Provare il flusso con un’esercitazione. Simulare una segnalazione urgente e verificare se il sostituto riesce a reperire le informazioni. Non inviare notifiche reali per fare una prova.
- Organizzare la comunicazione agli utenti. Predisporre avvisi comprensibili, istruzioni per mitigare il rischio e un canale per distribuire aggiornamenti e chiarimenti.
Un esempio per una piccola software house
Immaginiamo una società che distribuisce un’applicazione installabile. Un cliente segnala accessi anomali e fornisce elementi che suggeriscono lo sfruttamento di una vulnerabilità. Il team deve verificare il prodotto e le versioni interessate, raccogliere le evidenze e coinvolgere il referente incaricato. Attendere la patch definitiva prima di affrontare il reporting può rendere il processo tardivo.
Un’organizzazione preparata dispone già della scheda prodotto, dei contatti e del modello di raccolta dati. L’analisi tecnica prosegue mentre il referente gestisce scadenze e aggiornamenti, senza confondere una valutazione iniziale con una relazione conclusiva.
Che cosa fare se l’azienda utilizza soltanto prodotti di terzi
Per l’impresa utilizzatrice, il primo passo pratico è chiedere ai fornitori dove pubblicano gli avvisi di sicurezza e come comunicano le versioni coinvolte. Conviene mantenere un inventario aggiornato, assegnare la gestione delle patch e documentare gli interventi. Un avviso ricevuto ma non assegnato a nessuno resta un rischio operativo.
Per rivedere inventario, aggiornamenti e procedure interne puoi consultare i servizi informatici di Informanet. L’inquadramento del singolo prodotto e degli obblighi applicabili richiede una valutazione specifica: questo articolo offre un orientamento operativo, non una certificazione di conformità.