In sintesi
Dall'11 settembre 2026, l'articolo 14 del Cyber Resilience Act dell'UE obbliga i fabbricanti di prodotti con elementi digitali a segnalare all'ENISA e ai Computer Security Incident Response Team (CSIRT) nazionali le vulnerabilità attivamente sfruttate entro 24 ore dalla loro scoperta. Un rapporto di triage con un percorso di risoluzione deve seguire entro 72 ore; un rapporto di rimedio finale è dovuto entro 14 giorni. L'obbligo riguarda ogni fabbricante che distribuisce software o hardware connesso nell'UE, comprese le aziende con sede negli Stati Uniti.
Il CRA è entrato in vigore l'11 dicembre 2024. I suoi requisiti di conformità completi — marcatura CE, valutazioni di conformità, distinte base del software — si applicano soltanto dall'11 dicembre 2027. La scadenza dell'11 settembre 2026 è il primo checkpoint operativamente significativo, e arriva tra pochi giorni, non mesi. I team che non hanno ancora costruito flussi di lavoro di gestione delle vulnerabilità e audit di sicurezza allineati alle scadenze del CRA dovrebbero considerarlo il segnale per agire subito.
Cosa cambia l'11 settembre
Il Cyber Resilience Act (Regolamento (UE) 2024/2847) ha introdotto un quadro di requisiti di cybersicurezza per qualsiasi prodotto dotato di una componente digitale venduto nell'UE. Il regolamento è strutturato per ondate: gli obblighi più pesanti — valutazioni di conformità, marcatura CE, manutenzione delle distinte base del software — non si applicano fino a dicembre 2027. L'ondata delle segnalazioni arriva per prima, e arriva questo mese.
L'articolo 14 copre due categorie di eventi. In primo luogo, le vulnerabilità attivamente sfruttate: falle di sicurezza nel prodotto di un fabbricante che attori malevoli stanno attualmente sfruttando, in qualsiasi contesto di distribuzione, non solo contro i clienti del fabbricante stesso. In secondo luogo, gli incidenti di sicurezza gravi: eventi con un impatto significativo sulla sicurezza di un prodotto, inclusi quelli in grado di compromettere la protezione dei dati, introdurre codice malevolo in una catena di fornitura o compromettere un ambiente di sviluppo o di produzione. In entrambi i casi, il trigger è il momento in cui il fabbricante viene a conoscenza — non esiste alcun periodo di grazia per un'indagine interna prima che l'orologio delle 24 ore inizi.
L'ENISA gestirà una Piattaforma unica di segnalazione che inoltrerà ogni invio all'ENISA stessa e al CSIRT nazionale dello Stato membro in cui il fabbricante è stabilito o, per i fabbricanti non europei, allo Stato membro designato come punto di contatto unico. La piattaforma è progettata per accettare notifiche leggibili dalla macchina e per evitare che i fabbricanti debbano presentare quattro rapporti separati in quattro portali diversi per un singolo incidente.
L'orologio 24 h / 72 h / 14 giorni
Il calendario è preciso. Non appena un fabbricante è a conoscenza di un evento qualificato:
- 24 ore — Allerta precoce. Una notifica preliminare all'ENISA e al CSIRT nazionale. Il regolamento non richiede un'analisi tecnica completa in questa fase, ma la notifica deve confermare l'evento, il prodotto interessato e la valutazione preliminare dell'impatto. L'obiettivo è fornire alle autorità visibilità prima che l'informazione si diffonda, non esigere un rapporto di incidente completo nel giro di una notte.
- 72 ore — Rapporto di triage. Una presentazione più dettagliata che include la valutazione della gravità, le misure di attenuazione iniziali adottate e un percorso di risoluzione. Se è già disponibile una patch, va segnalato; in caso contrario, va descritto il piano per produrla.
- 14 giorni — Rapporto finale (vulnerabilità) / 30 giorni (incidenti). Un resoconto completo della vulnerabilità o dell'incidente, delle misure correttive applicate e della loro efficacia. Per gli incidenti, la finestra si estende a 30 giorni da quando il fabbricante è venuto a conoscenza dell'evento.
Per i team abituati alla finestra di notifica di violazione di 72 ore del GDPR, il rapporto iniziale di 24 ore del CRA è significativamente più breve. Per i team abituati alle scadenze di divulgazione coordinata delle vulnerabilità (CVD) di 90 giorni o più, il contrasto è ancora più netto. La conseguenza pratica è che il rilevamento delle vulnerabilità e l'escalation interna non possono essere processi lenti: nel momento in cui il team di sicurezza conferma uno sfruttamento attivo, i team legali e di conformità devono essere coinvolti nel giro di ore, non di giorni.
Chi deve conformarsi — inclusi i vendor americani
Gli obblighi del CRA ricadono sui fabbricanti: aziende che progettano, sviluppano o producono prodotti con elementi digitali — o li fanno progettare, sviluppare o produrre — e poi li immettono sul mercato europeo con il proprio nome o marchio. La definizione è volutamente ampia. Comprende software commerciale preconfezionato, piattaforme SaaS, applicazioni mobili, dispositivi IoT per consumatori, sistemi di controllo industriale, firmware embedded e apparecchiature di rete.
Importatori e distributori hanno obblighi più leggeri ma reali: devono verificare la conformità del fabbricante e, in alcune circostanze, agire come entità responsabile se un fabbricante al di fuori dell'UE non può essere identificato. Ma il nucleo dell'obbligo di segnalazione dell'articolo 14 grava sul fabbricante.
Il trigger geografico è il mercato europeo, non la sede nell'UE. Un vendor software con sede negli Stati Uniti il cui prodotto è accessibile a clienti aziendali o privati in Germania, Francia o qualsiasi altro Stato membro è un fabbricante ai sensi del CRA. Lo stesso vale per le aziende britanniche post-Brexit, i fornitori canadesi di SaaS e qualsiasi altra entità non europea. Se il vostro prodotto è venduto o distribuito nell'UE, siete nell'ambito di applicazione e avete bisogno di un percorso di segnalazione verso la SRP dell'ENISA prima dell'11 settembre.
Sovrapposizioni con GDPR, NIS2 e DORA
Il CRA è il quarto grande framework europeo di conformità digitale, accanto a GDPR, NIS2 e DORA, e i quattro condividono abbastanza DNA architetturale — allerte precoci a 24 ore, rapporti di follow-up a più livelli, notifica alle autorità designate — da creare rischi di coordinamento se trattati come programmi separati.
Un attacco ransomware su un dispositivo connesso potrebbe ad esempio innescare simultaneamente: un rapporto CRA articolo 14 all'ENISA (entro 24 ore, come incidente grave); una notifica GDPR articolo 33 all'autorità di controllo (entro 72 ore, se sono interessati dati personali); un rapporto di incidente significativo NIS2 (entro 24 ore, se il fabbricante è un'entità essenziale o importante); e, per i vendor SaaS del settore finanziario, un rapporto di incidente grave DORA (entro 4 ore per gli eventi ad alta criticità). Ogni notifica va a un'autorità diversa, segue un modello leggermente diverso e ha scadenze di follow-up diverse.
Il rischio concreto non è che i team dimentichino di segnalare; è che costruiscano quattro silos indipendenti e manchino una finestra di segnalazione perché il team sbagliato era responsabile della notifica, o inviino informazioni contraddittorie sullo stesso evento a diversi regolatori. L'architettura giusta è un unico processo di triage degli incidenti che prende in ingresso il fatto confermato di un incidente e produce in uscita le notifiche corrette alle autorità corrette nei tempi corretti. Questo processo deve essere mappato, documentato e testato prima dell'11 settembre — perché il primo vero incidente è un pessimo momento per scoprire che il processo non funziona. La costruzione di un programma unificato di conformità GDPR e multi-regolamentare è il modo in cui i team che operano in Europa gestiscono tipicamente questa sfida; il CRA aggiunge una nuova corsia a un'autostrada esistente invece di costruire una strada completamente nuova.
Cosa significa per i team software
Il cambiamento operativo è reale e vale la pena nominarlo con precisione. Prima dell'11 settembre, un vendor software con una vulnerabilità attivamente sfruttata nel suo prodotto poteva gestire i tempi di divulgazione al proprio ritmo: i processi CVD concedevano tipicamente mesi; la divulgazione volontaria alle autorità era esattamente questo, volontaria. Dall'11 settembre, lo Stato ha un primo diritto obbligatorio su quei tempi — 24 ore, ogni volta, che il vendor sia pronto o meno, che la patch sia pronta o meno, che l'exploit sia pubblico o meno.
Per i team di engineering, l'implicazione è la strumentazione: non si può segnalare una vulnerabilità attivamente sfruttata che non si conosce. Il monitoraggio continuo dei feed di threat intelligence, degli avvisi dei vendor e della propria telemetria per individuare segnali di sfruttamento non è più una best practice per i team maturi; ai sensi dell'articolo 14 è un prerequisito di conformità. Lo stesso vale per avere una chiara definizione interna di cosa significhi “venire a conoscenza” — perché l'orologio inizia quando la vostra organizzazione lo sa, non quando il CISO redige il briefing.
Per i product manager e i fondatori di prodotti SaaS rivolti all'Europa, l'implicazione è la responsabilità di processo: l'obbligo di segnalazione del CRA grava sul fabbricante, non sul cliente, non sul cloud provider e non sul consulente di sicurezza. Se il vostro prodotto rientra nell'ambito, la vostra persona giuridica è quella con l'orologio delle 24 ore, e avete bisogno di una persona nominalmente designata che sappia cosa presentare e dove.
La lettura strategica d'insieme è che il CRA sta innalzando gli standard di cybersicurezza europei verso ciò che gli acquirenti aziendali maturi nei settori regolamentati — banche, sanità, infrastrutture critiche — richiedono da anni. I team che già gestiscono programmi SOC 2 Type II o processi di risposta agli incidenti allineati al GDPR troveranno i meccanismi del CRA familiari. I team che hanno gestito la sicurezza in modo informale scopriranno che il CRA è il fattore catalizzante che trasforma la pratica informale in processo documentato e verificabile.
Cosa fare prima dell'11 settembre
La checklist non è lunga, ma ogni punto deve essere effettivamente completato, non solo pianificato.
- Confermare l'ambito. Elencate ogni prodotto che la vostra azienda immette sul mercato europeo. Se ha una componente digitale — software, firmware, connettività — rientra probabilmente nell'ambito. I prodotti legacy già presenti sul mercato prima dell'entrata in vigore del CRA possono essere coperti anche se ricevono aggiornamenti software.
- Definire internamente “venire a conoscenza”. Stabilite una soglia chiara a partire dalla quale la vostra organizzazione è considerata a conoscenza di una vulnerabilità attivamente sfruttata. Questo determina quando inizia il conto alla rovescia delle 24 ore. L'ambiguità qui crea rischio di conformità.
- Costruire un monitoraggio continuo. Non si può segnalare ciò che non si può rilevare. Stabilite o contrattualizzate il monitoraggio di threat intelligence e telemetria per individuare segnali di sfruttamento attivo nell'intero portfolio di prodotti.
- Assegnare un responsabile della notifica. Designate la persona (e un sostituto) incaricata di presentare i rapporti CRA. Deve avere l'autorità di notificare le autorità senza una lunga catena di approvazione interna che ridurrebbe la finestra di 24 ore.
- Registrarsi sulla SRP dell'ENISA. La Piattaforma unica di segnalazione apre l'11 settembre 2026. Pre-registratevi se l'ENISA apre l'accesso anticipato; verificate almeno che le credenziali di accesso siano pronte prima della scadenza.
- Preparare modelli di rapporto. La struttura di segnalazione in tre fasi dell'articolo 14 è prevedibile. Preparate ora modelli per l'allerta precoce a 24 ore, il rapporto di triage a 72 ore e il rapporto finale a 14 giorni, così che il vostro team sotto pressione inserisca i fatti invece di scrivere il formato.
- Mappare le sovrapposizioni tra regimi. Se avete anche obblighi NIS2, DORA o GDPR, verificate che un incidente scatenante del CRA confluisca correttamente in tutti i flussi di notifica applicabili.
Domande frequenti
Cosa richiede il CRA dall'11 settembre 2026?
Dall'11 settembre 2026, i fabbricanti di prodotti con elementi digitali immessi sul mercato europeo devono trasmettere un'allerta precoce all'ENISA e al proprio CSIRT nazionale entro 24 ore dalla presa di conoscenza di una vulnerabilità attivamente sfruttata o di un grave incidente di sicurezza. Un rapporto di triage con un percorso di risoluzione deve seguire entro 72 ore, e un rapporto finale è dovuto entro 14 giorni dalla disponibilità di una patch (30 giorni per gli incidenti).
A chi si applica l'obbligo di segnalazione del CRA?
A qualsiasi fabbricante che immette sul mercato europeo prodotti con elementi digitali — inclusi software, SaaS, app mobili, dispositivi IoT e sistemi embedded. Importatori e distributori hanno obblighi più leggeri. La regola si applica in base al luogo di vendita del prodotto, non al luogo di stabilimento del fabbricante: le aziende statunitensi, britanniche e altre entità non europee che distribuiscono software o dispositivi in Europa sono pienamente soggette all'obbligo.
Cosa si intende per vulnerabilità attivamente sfruttata ai sensi del CRA?
Una falla di sicurezza nel prodotto di un fabbricante che attori malevoli stanno attivamente sfruttando — in qualsiasi ambiente di distribuzione, non solo contro i clienti del fabbricante. Il regolamento copre anche gli incidenti di sicurezza gravi, inclusi gli eventi che possono compromettere la protezione dei dati, introdurre codice malevolo in una catena di fornitura o compromettere ambienti di sviluppo o produzione.
Come si interseca la segnalazione CRA con GDPR, NIS2 e DORA?
Tutti e quattro i framework condividono una struttura di allerta precoce a 24 ore, ma si rivolgono ad autorità diverse e hanno scadenze di follow-up distinte. Un singolo incidente può innescare simultaneamente obblighi sotto più regimi. Costruite un unico processo di triage degli incidenti che identifichi i regimi applicabili e produca la notifica corretta a ciascun regolatore nel tempo corretto, invece di gestire processi di conformità separati per ciascun framework.
Cosa devono fare i team software prima dell'11 settembre 2026?
Confermare quali prodotti rientrano nell'ambito; definire internamente quando inizia il conto alla rovescia delle 24 ore; costruire o contrattualizzare un monitoraggio continuo delle vulnerabilità; designare un responsabile della notifica con autorità diretta per la presentazione; registrarsi sulla Piattaforma unica di segnalazione dell'ENISA; preparare modelli di rapporto a 24 ore, 72 ore e 14 giorni; e mappare gli obblighi sovrapposti con GDPR, NIS2 e DORA per evitare notifiche mancate o contraddittorie.
Fonti
Commissione europea — Obblighi di segnalazione del CRA (fonte normativa primaria)
DLA Piper — La regola delle 24 ore del CRA: prepararsi agli obblighi di segnalazione di settembre 2026 (agosto 2026)
Crowell & Moring — CRA UE: scadenza di segnalazione dell'11 settembre 2026