L'obbligo di notifica del Cyber Resilience Act è operativo. I processi della maggior parte dei produttori sono ancora pura facciata.

Oggi, 11 settembre 2026, l’obbligo di notifica del Cyber Resilience Act entra in vigore in tutta l’Unione europea. Non a dicembre 2027, quando arriveranno i requisiti essenziali sui prodotti e a tutti è stato detto di aspettarsi la vera resa dei conti. Oggi. Se produci un prodotto con elementi digitali e lo vendi nell’UE, il conto alla rovescia per la tua prima notifica parte da questo momento, che la tua organizzazione abbia segnato la data oppure no.

A luglio ho scritto che il Cyber Resilience Act era la normativa che nessuno stava osservando con la dovuta attenzione, quella capace di togliere un prodotto dal mercato invece di limitarsi a sanzionare l’azienda che lo produce. Quel pezzo si concentrava sul quadro generale della compliance: ambito di applicazione, categorizzazione, il rapporto con la NIS2. Questo riguarda l’obbligo molto più circoscritto e molto più netto che è appena diventato operativo, e il divario scomodo tra quanti produttori dicono di conoscerlo e quanti sono davvero in grado di agire nelle ore che la legge concede.

La data che nessuno stava osservando

Gran parte della copertura mediatica sul CRA ruota ancora attorno a dicembre 2027, e comprensibilmente, dato che è allora che i requisiti essenziali di cybersecurity e gli obblighi di valutazione della conformità si applicano in pieno. Ma l’articolo 14 del regolamento ha ritagliato una data separata e anticipata specificamente per la notifica: dall’11 settembre 2026 i produttori devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi che riguardano i loro prodotti, e questo obbligo si applica ai prodotti già presenti sul mercato, non solo ai nuovi lanci.

La Commissione europea ha pubblicato le sue linee guida pratiche in merito il 27 luglio 2026, solo poche settimane prima che la data entrasse in vigore. È una finestra stretta per un obbligo con una prima scadenza di 24 ore attaccata. I requisiti essenziali di dicembre 2027 danno ai produttori circa quindici mesi di margine da questo momento. L’obbligo di notifica ne ha dati molti meno.

Cosa devi segnalare esattamente?

Questa è la domanda che manda in confusione, e vale la pena rispondere con precisione anziché in termini generici.

Segnali una vulnerabilità attivamente sfruttata, cioè quando esistono prove credibili che qualcuno la stia usando contro il tuo prodotto in questo momento. Segnali un incidente grave, cioè qualcosa che compromette davvero la sicurezza del tuo prodotto, non una semplice debolezza teorica. Ciò che non segnali è ogni CVE assegnato al tuo codice, ogni risultato del tuo penetration test o ogni segnalazione arrivata tramite il tuo programma di responsible disclosure o bug bounty, a meno che non ci siano prove che sia stata effettivamente sfruttata. Il webinar che il Ministero olandese degli Affari economici e della Politica climatica e il National Cyber Security Centre (NCSC) hanno tenuto il 27 agosto è stato netto su questa distinzione, e per una buona ragione: senza di essa, i produttori finirebbero per sommergere il loro CSIRT nazionale di rumore oppure, peggio, per dare per scontato che ogni segnalazione di vulnerabilità richieda la stessa urgenza delle 24 ore e per esaurire il team che dovrebbe gestire quelle che contano davvero.

Puoi comunque segnalare i casi a severità più bassa su base volontaria, e ci sono buone ragioni per costruire questa abitudine. Ma l’obbligo legale si concentra specificamente sullo sfruttamento attivo e sugli incidenti gravi, e sapere dove cade quella linea è la prima cosa che il tuo processo di incident response deve fare bene.

Il conto alla rovescia non si ferma per la riunione del tuo incident response

Una volta che sai, la tempistica è scandita e non perdona. Un preavviso deve partire entro 24 ore da quando ne vieni a conoscenza. Una notifica più completa segue entro 72 ore, coprendo ciò che sai a quel punto sulla natura, l’impatto e le misure di mitigazione. Una relazione finale chiude il caso: quattordici giorni dopo che una misura correttiva diventa disponibile per una vulnerabilità, o un mese per un incidente grave, secondo le linee guida della Commissione europea.

L’analisi di Freshfields sul nuovo obbligo mette in luce un punto su cui vale la pena soffermarsi: i periodi di notifica iniziano nel momento in cui ne vieni a conoscenza, e il conto alla rovescia non si ferma nei fine settimana o nei giorni festivi. Non c’è alcun periodo di tolleranza per il fatto che il tuo responsabile della sicurezza fosse a una conferenza, o che l’incidente sia avvenuto un venerdì sera. Se la tua organizzazione non ha già un processo definito su chi valuta una segnalazione, chi decide che supera la soglia e chi la invia, quel processo lo stai costruendo per la prima volta sotto una scadenza attiva di 24 ore, che è esattamente il momento sbagliato per costruire qualsiasi cosa.

La notifica stessa passa attraverso il tuo CSIRT nazionale, l’NCSC nei Paesi Bassi, e la piattaforma unica di notifica a livello UE, il Single Reporting Platform gestito da ENISA, così un produttore in Belgio, in Germania o in qualsiasi altro punto dell’UE segue la stessa tempistica scandita attraverso il proprio punto di contatto nazionale. I meccanismi differiscono leggermente da uno Stato membro all’altro; l’obbligo e le scadenze no.

Perché i numeri sulla preparazione sono così brutti?

È qui che l’affermazione secondo cui “i processi della maggior parte dei produttori sono pura facciata” deve guadagnarsi il suo posto, e i dati delle indagini la confermano in modo più netto di quanto mi aspettassi.

Il SME Cyber Resilience Maturity Assessment Model di ENISA, pubblicato il 13 luglio 2026 e basato su un lavoro sul campo con 194 organizzazioni in 31 paesi, ha rilevato un’alta consapevolezza del CRA ma una preparazione pratica costantemente scarsa, con l’incident response e la gestione del ciclo di vita del prodotto come i due ambiti più deboli in assoluto. Essere consapevoli che una legge esiste non è la stessa cosa che avere un processo in grado di agire entro una finestra di 24 ore.

La ricerca 2026 sulla prontezza al CRA di Linux Foundation e OpenSSF, condotta su 843 rispondenti, racconta una storia simile da un’angolazione diversa. Il sessantasei percento ancora non sapeva cosa doveva effettivamente fare per essere conforme, un dato che si era mosso appena rispetto al 62 percento dell’anno prima. Solo il 41 percento dei produttori si aspettava di raggiungere la piena conformità entro la scadenza di dicembre 2027, e solo il 34 percento aveva identificato correttamente quella data. Tra i rispondenti che erano consapevoli del CRA, il 54 percento ancora non riusciva a distinguere chiaramente tra gli obblighi di un produttore e quelli di uno steward.

Niente di tutto questo è una critica a un singolo team di compliance. Riflette una normativa che è passata dall’astratto all’operativo più in fretta di quanto la maggior parte dei processi organizzativi riuscisse a seguire. Ma significa comunque che una quota significativa dei produttori che stanno leggendo ha superato la linea dell’11 settembre senza alcun processo testato alle spalle, che è esattamente lo scenario che l’obbligo di notifica è stato progettato per smascherare.

Chi deve effettivamente segnalare?

In base al CRA, l’obbligo di notifica ricade sul produttore, il soggetto che immette sul mercato dell’UE un prodotto con elementi digitali con il proprio nome o marchio, e la dimensione dell’organizzazione non ti esonera. Un importatore o un distributore in genere non ha un obbligo di notifica autonomo, a meno che non venda con il proprio marchio o modifichi sostanzialmente il prodotto, nel qual caso diventa di fatto il produttore per quel prodotto. Gli steward di software open source affrontano una versione più leggera dello stesso obbligo, che riflette il diverso rapporto che hanno con i prodotti che mantengono. Anche le piccole e microimprese rientrano pienamente nell’ambito; l’unica concessione che l’NCSC olandese ha confermato è che non c’è alcuna sanzione per il mancato rispetto della rigida finestra di 24 ore in quella categoria, il che è una mitigazione, non un’esenzione.

Un dettaglio che vale la pena segnalare perché genera vera confusione: il CRA in sé non richiede alcuna registrazione preventiva prima di poter segnalare. Non ti serve un account o un login per inviare una notifica. È una scelta di progettazione deliberata, distinta dall’obbligo di registrazione che esiste ai sensi della Cyberbeveiligingswet (il recepimento olandese della NIS2) per le organizzazioni che ricadono anche sotto quella legge. I due obblighi corrono in parallelo, non come un unico processo combinato, e confonderli è un errore facile da commettere.

Cosa significa davvero essere “pronti”?

Prepararsi all’obbligo di notifica del CRA non è complicato in linea di principio. È impegnativo nella pratica, che è un problema diverso.

Parti da un inventario onesto di cosa c’è davvero nei tuoi prodotti, idealmente attraverso una Software Bill of Materials (SBOM), perché non puoi valutare se una vulnerabilità segnalata ti riguarda se non sai quali componenti spedisci. Stabilisci in anticipo le tue soglie interne per cosa conta come sfruttamento attivo o incidente grave, così quella decisione non viene presa per la prima volta sotto pressione. Costruisci un percorso di escalation con ruoli assegnati: chi segnala, chi decide, chi invia. Prepara ora i modelli per il preavviso, per la notifica a 72 ore e per la relazione finale, mentre nessuno è sotto scadenza. E allinea tutto questo con qualsiasi altro obbligo di notifica già in vigore per te, dato che un buon numero dei produttori che stanno leggendo ricade anche sotto la Cyberbeveiligingswet o l’AVG, e gestire tre processi di notifica non coordinati è di per sé un rischio.

Questa è, non a caso, la stessa disciplina per cui ho argomentato a luglio quando ho scritto delle richieste di compliance più ampie del CRA: sappi cosa hai, categorizzalo onestamente e costruisci la documentazione prima che il regolatore la chieda. L’obbligo di notifica ha semplicemente spostato quell’argomento da “prima o poi” a “adesso”.

Se un cliente ti dicesse stamattina che qualcuno sta attivamente sfruttando una vulnerabilità nel tuo prodotto, la tua organizzazione saprebbe, entro 24 ore, esattamente chi prende in carico quella segnalazione? Se la risposta onesta è “ce la caveremmo in qualche modo”, l’obbligo di notifica non è diventato operativo oggi per niente.

Fonti

• European Commission, Cyber Resilience Act, Reporting obligations, Shaping Europe’s Digital Future: digital-strategy.ec.europa.eu/en/policies/cra-reporting
• ENISA, SME Cyber Resilience Maturity Assessment Model, published 13 July 2026.
• Linux Foundation Research, Linux Foundation Europe, and OpenSSF, “The CRA Readiness Reality: What Changed (and What Didn’t) Between 2025 and 2026?”, June 2026: linuxfoundation.org
• Freshfields, “Cyber Resilience Act reporting obligations take effect on 11 September 2026”: freshfields.com
• Ministry of Economic Affairs and Climate Policy and National Cyber Security Centre (NCSC), Cyber Resilience Act, Themasessie Meldplicht (webinar), 27 August 2026.