Dall’11 settembre 2026 il Cyber Resilience Act entra in una fase operativa importante, ma non significa che da quella data si applichi già tutto il regolamento. Scattano gli obblighi di comunicazione previsti dall’articolo 14 per vulnerabilità attivamente sfruttate e incidenti gravi che riguardano prodotti con elementi digitali. La piena applicazione del CRA resta fissata all’11 dicembre 2027.
Per aziende che producono software, router, videocamere, dispositivi IoT, wearable, applicazioni e altri prodotti hardware o software venduti nell’Unione europea, il punto più urgente è il tempo: il primo avviso può dover partire entro 24 ore da quando il fabbricante viene a conoscenza dell’evento. Ma non ogni CVE e non ogni bug fanno partire automaticamente quel conto alla rovescia.
Cosa cambia l’11 settembre 2026
La Commissione europea chiarisce gli obblighi di reporting del Cyber Resilience Act: da questa data i fabbricanti devono notificare due categorie precise di eventi.
- Vulnerabilità attivamente sfruttate: deve esistere evidenza affidabile che un attore malevolo abbia sfruttato la vulnerabilità nel prodotto interessato.
- Incidenti gravi: eventi che producono un impatto grave sulla sicurezza del prodotto con elementi digitali, per esempio su disponibilità, autenticità, integrità o riservatezza.
Questo dettaglio evita uno degli equivoci più frequenti: il CRA non dice che qualunque vulnerabilità scoperta debba essere comunicata entro 24 ore. La presenza di una CVE in una libreria usata dal prodotto, da sola, non equivale automaticamente a un evento soggetto al reporting anticipato.
24 ore, 72 ore e rapporto finale: la timeline
| Evento | Primo avviso | Notifica completa | Rapporto finale |
|---|---|---|---|
| Vulnerabilità attivamente sfruttata | entro 24 ore | entro 72 ore | entro 14 giorni dalla disponibilità della misura correttiva |
| Incidente grave | entro 24 ore | entro 72 ore | entro un mese dalla notifica completa |
Il primo avviso serve a mettere rapidamente a conoscenza le autorità competenti dell’esistenza dell’evento. La notifica successiva contiene informazioni più complete, mentre il rapporto finale documenta cause, conseguenze e misure correttive secondo il tipo di evento.
Non ogni CVE fa partire il conto alla rovescia
Un esempio aiuta. Se una libreria open source contiene una vulnerabilità nota ma il componente vulnerabile non è raggiungibile o sfruttabile nella configurazione del prodotto, non basta la semplice presenza della CVE per concludere che sia scattato l’obbligo delle 24 ore.
La situazione cambia se emergono prove affidabili di sfruttamento nel prodotto interessato oppure se si verifica un incidente che raggiunge la soglia di gravità prevista dal regolamento. Per un produttore significa avere un processo capace di distinguere velocemente segnalazione tecnica, vulnerabilità applicabile, sfruttamento attivo e incidente grave.
La differenza è concreta anche rispetto alle normali notizie di sicurezza. Abbiamo seguito casi come una vulnerabilità Linux critica che richiede patch rapide e gli attacchi attivi contro Microsoft SharePoint: con il CRA il fabbricante deve aggiungere alla risposta tecnica anche una valutazione regolatoria sull’obbligo di comunicazione.
Cos’è la Single Reporting Platform di ENISA
Le comunicazioni non devono essere inviate separatamente a ogni Stato membro. ENISA sta preparando la Single Reporting Platform del Cyber Resilience Act, prevista operativa dall’11 settembre 2026.
La piattaforma funziona come punto unico di ingresso. Il report viene indirizzato al CSIRT competente e, secondo le regole del CRA, le informazioni vengono condivise con ENISA e con gli altri CSIRT interessati quando necessario.
| Domanda | Risposta |
|---|---|
| Il CRA si applica pienamente dall’11 settembre 2026? | No, scattano gli obblighi di reporting. La piena applicazione resta al dicembre 2027. |
| Ogni CVE va notificata entro 24 ore? | No, il trigger riguarda vulnerabilità attivamente sfruttate e incidenti gravi. |
| Dove si invia la notifica? | Tramite la Single Reporting Platform di ENISA. |
| Entro quanto parte il primo avviso? | 24 ore da quando il fabbricante viene a conoscenza dell’evento soggetto a reporting. |
| Quando arriva la notifica completa? | 72 ore. |
| Il CRA riguarda solo hardware? | No, comprende prodotti hardware e software con elementi digitali messi a disposizione sul mercato UE. |
Chi deve prepararsi adesso
Il regolamento usa il concetto di prodotto con elementi digitali. In termini generali comprende hardware e software messi a disposizione sul mercato dell’Unione, inclusi prodotti finali e componenti distribuiti separatamente.
- produttori di router, videocamere, sistemi smart home e dispositivi IoT;
- aziende che commercializzano software e applicazioni come prodotti;
- produttori di wearable, hardware connesso e dispositivi industriali;
- organizzazioni che integrano componenti software in prodotti commercializzati nell’UE;
- nei casi previsti, soggetti che svolgono il ruolo di open-source software steward.
La qualificazione giuridica precisa dipende però dal ruolo svolto e dal modo in cui il prodotto viene immesso sul mercato. Una guida editoriale non sostituisce la valutazione legale del singolo caso.
Cosa dovrebbe avere pronto un team tecnico prima dell’11 settembre
Il problema principale delle 24 ore non è compilare un modulo. È riuscire a capire abbastanza rapidamente chi decide che il trigger di reporting è stato raggiunto.
- un canale interno per ricevere vulnerability report, alert di threat intelligence e segnalazioni dei clienti;
- un responsabile o un team che possa determinare se la vulnerabilità riguarda realmente il prodotto;
- una procedura per verificare evidenze di sfruttamento attivo;
- tracciamento di componenti e versioni interessate;
- contatti interni fra security, engineering, legale e comunicazione;
- accesso e responsabilità definite per la Single Reporting Platform;
- una procedura di escalation che funzioni anche fuori dall’orario di ufficio.
L’11 settembre non introduce da solo un obbligo separato di acquistare uno specifico vulnerability scanner. Scanner, SBOM, software composition analysis e threat intelligence possono essere strumenti molto utili per capire cosa contiene un prodotto e reagire più rapidamente, ma non vanno confusi con il trigger giuridico del reporting anticipato.
Cosa non entra ancora pienamente in applicazione
L’11 settembre è quindi una data importante, ma non va confusa con la scadenza finale. La Commissione indica questa sequenza:
- 11 giugno 2026: applicazione delle disposizioni relative alla notifica degli organismi di valutazione della conformità;
- 11 settembre 2026: applicazione degli obblighi di reporting dell’articolo 14;
- 11 dicembre 2027: piena applicazione del Cyber Resilience Act.
Questo significa che un’azienda non dovrebbe leggere la data del 2027 come motivo per rinviare tutto. Il processo di reporting deve essere pronto prima, mentre gli altri requisiti del CRA continuano verso la piena applicazione successiva.
La domanda pratica: scopri una vulnerabilità il 12 settembre, cosa fai?
Non partire automaticamente dal modulo. Prima bisogna qualificare l’evento.
- Verifica se la vulnerabilità interessa realmente il prodotto e la configurazione commercializzata.
- Raccogli le evidenze disponibili sul possibile sfruttamento.
- Determina se esiste evidenza affidabile di sfruttamento attivo oppure un incidente grave.
- Se il trigger è soddisfatto, avvia il processo per rispettare la finestra delle 24 ore.
- Continua contemporaneamente l’analisi tecnica, la mitigazione e la preparazione della notifica delle 72 ore.
Il valore della preparazione è qui: le 24 ore non sono il tempo disponibile per iniziare a chiedersi chi debba occuparsi del problema. Ruoli, contatti, prove da conservare e responsabilità devono essere definiti prima.
Perché questa scadenza riguarda anche chi segue la tecnologia da utente
Per l’utente finale il CRA dovrebbe tradursi nel tempo in prodotti con requisiti di sicurezza più omogenei, processi di gestione delle vulnerabilità più strutturati e maggiore trasparenza sugli aggiornamenti. Dal settembre 2026 il cambiamento più visibile avviene però dietro le quinte: quando un prodotto subisce un evento grave o una vulnerabilità viene sfruttata attivamente, il produttore entra in un processo di segnalazione con tempi definiti.
La data da ricordare è quindi doppia: 11 settembre 2026 per il reporting, 11 dicembre 2027 per la piena applicazione. Confondere le due scadenze porta sia a sottovalutare ciò che parte ora sia a sopravvalutare ciò che è già obbligatorio.
