Cyber Resilience Act: le 24 ore partono oggi

Cybersecurity

Consulenza CISO-as-a-service: postura, roadmap di remediation, supporto continuativo.

Scopri →

Intelligenza Artificiale

Consulenza EU AI Act: classificazione dei sistemi, policy, governance AI, formazione.

Scopri →

A fine luglio, commentando le linee guida della Commissione, avevamo scritto che mancavano sei settimane alla prima scadenza con obblighi applicabili. Sono finite. Da oggi, 11 settembre 2026, si applica l’articolo 14 del regolamento (UE) 2024/2847.

Le date le fissa l’articolo 71, e conviene rileggerlo perché è controintuitivo: il regolamento “si applica dall’11 dicembre 2027”, ma “l’articolo 14 si applica a decorrere dall’11 settembre 2026 e il capo IV (articoli da 35 a 51) si applica a decorrere dall’11 giugno 2026”. Quindi oggi entra in funzione un pezzo di un regolamento che per il resto vale fra quindici mesi.

Cosa fa partire l’orologio

Questa è la parte che nella maggior parte delle sintesi salta, ed è quella che decide se dovete fare qualcosa oggi o no.

L’obbligo non scatta perché esiste un CVE. Non scatta per un punteggio CVSS alto. L’articolo 3 definisce la vulnerabilità attivamente sfruttata come “una vulnerabilità per la quale esistono prove attendibili che un soggetto malintenzionato l’ha sfruttata in un sistema senza l’autorizzazione del proprietario del sistema”.

È un criterio di evidenza di sfruttamento, non di gravità teorica. Da un lato restringe molto il campo, e chi temeva di dover notificare ogni bollettino può stare tranquillo. Dall’altro sposta il problema su una domanda più difficile: come fate a sapere che una cosa è sfruttata davvero e a saperlo abbastanza presto da avere ancora 24 ore davanti.

Il secondo binario è l’incidente grave che ha un impatto sulla sicurezza del prodotto, definito al paragrafo 5: incide o può incidere negativamente sulla capacità del prodotto di proteggere disponibilità, autenticità, integrità o riservatezza di dati o funzioni sensibili, oppure ha portato o può portare all’introduzione o esecuzione di codice maligno nel prodotto o nei sistemi di un utilizzatore.

I tre orologi, che non sono quelli di NIS2

Le finestre sono queste, e le riportiamo con il loro punto di partenza perché è lì che si sbaglia.

Vulnerabilità attivamente sfruttata (art. 14, par. 2):

• Preallarme entro 24 ore da quando il fabbricante ne è venuto a conoscenza, con l’indicazione degli Stati membri dove il prodotto è stato messo a disposizione.
• Notifica entro 72 ore da quando ne è venuto a conoscenza, con natura generale dello sfruttamento e della vulnerabilità, misure correttive o di attenuazione adottate e quelle che gli utilizzatori possono adottare.
• Relazione finale entro 14 giorni dalla messa a disposizione di una misura correttiva. Non dalla scoperta e non dalla notifica: dal momento in cui il rimedio è disponibile.

Incidente grave (art. 14, par. 4): preallarme entro 24 ore, che deve precisare come minimo se si sospetta che l’incidente derivi da atti illegittimi o malevoli; notifica entro 72 ore; relazione finale entro un mese dalla notifica delle 72 ore.

Chi conta di riusare i flussi NIS2 faccia attenzione a questo punto. Le prime due finestre coincidono, la terza no. In NIS2 la relazione finale è a un mese dalla notifica dell’incidente; nel CRA quella sulle vulnerabilità è a 14 giorni ancorati alla disponibilità della correzione, che è un evento sotto il vostro controllo e quindi va tracciato come tale. Sono due timer diversi che partono da due fatti diversi.

C’è poi il paragrafo 6: il CSIRT coordinatore che ha ricevuto per primo la notifica può chiedere una relazione intermedia con gli aggiornamenti della situazione. Va messo in conto nel dimensionare chi presidia il canale.

L’obbligo verso gli utilizzatori, che è separato

Il paragrafo 8 è quello che nelle discussioni di questi giorni vediamo citato meno e che pesa di più sul prodotto.

Dal momento in cui viene a conoscenza della vulnerabilità sfruttata o dell’incidente grave, il fabbricante informa gli utilizzatori interessati e, se del caso, tutti gli utilizzatori, insieme alle misure che possono adottare, “se del caso in un formato strutturato, leggibile da un dispositivo automatico e che possa essere facilmente elaborato automaticamente”.

Due conseguenze concrete. La prima è che serve un canale verso i vostri utenti che esista già e che sia raggiungibile in giornata, cioè un feed di security advisory e non una pagina di news. La seconda è che il formato leggibile da macchina non è un dettaglio estetico: chi riceve l’avviso deve poterlo ingerire in automatico, ed è la ragione per cui esistono formati come CSAF e VEX.

Il comma finale aggiunge un incentivo che vale la pena leggere per intero: se il fabbricante non informa tempestivamente gli utilizzatori, i CSIRT coordinatori che hanno ricevuto la notifica possono farlo al posto suo, quando lo ritengono proporzionato e necessario. Il controllo sulla comunicazione al proprio mercato, se non lo esercitate voi, lo esercita qualcun altro.

Dove si segnala e perché la registrazione va fatta prima

Le notifiche passano dalla piattaforma unica di segnalazione istituita dall’articolo 16, realizzata e gestita da ENISA, usando il terminale di notifica elettronica del CSIRT designato come coordinatore dello Stato membro dello stabilimento principale.

Lo stabilimento principale, dice il paragrafo 7, è lo Stato membro “in cui sono prevalentemente adottate le decisioni relative alla cibersicurezza” dei prodotti; se non è determinabile, quello con il maggior numero di dipendenti nell’Unione. Per chi nell’Unione non è stabilito c’è una cascata in quattro passi: rappresentante autorizzato, importatore, distributore, infine lo Stato con il maggior numero di utilizzatori. Per un fabbricante italiano l’interlocutore è CSIRT Italia, dentro l’Agenzia per la Cybersicurezza Nazionale.

Qui c’è il dettaglio operativo che rende il resto eseguibile o no. La piattaforma di ENISA apre oggi, lo stesso giorno in cui l’obbligo diventa esigibile, e prevede una registrazione preventiva dei rappresentanti abilitati a inviare le notifiche. Una registrazione non si fa in ventiquattro ore mentre si gestisce un incidente. Se la vostra organizzazione rientra e non ha ancora un’utenza attiva, questa è la cosa da fare oggi, prima di qualunque altra.

Se fate open source

L’articolo 24 riguarda i gestori di software open source, definiti all’articolo 3 come persone giuridiche diverse dal fabbricante che forniscono “un sostegno sistematico e duraturo” allo sviluppo di prodotti open source destinati ad attività commerciali e ne garantiscono la sostenibilità economica. I singoli sviluppatori volontari restano fuori.

Il paragrafo 3 dice una cosa precisa e vale la pena riportarla per esteso, perché circola l’idea che gli steward siano esenti dal reporting. Gli obblighi dell’articolo 14, paragrafo 1 si applicano ai gestori “nella misura in cui sono coinvolti nello sviluppo dei prodotti con elementi digitali”. Gli obblighi dei paragrafi 3 e 8 si applicano “nella misura in cui incidenti gravi […] incidano sui sistemi informativi e di rete forniti da tali gestori […] per lo sviluppo di tali prodotti”.

Tradotto: un gestore che sostiene un progetto usato commercialmente notifica le vulnerabilità attivamente sfruttate nella parte che sviluppa, e notifica gli incidenti gravi quando colpiscono l’infrastruttura di sviluppo che mette a disposizione. La seconda ipotesi è esattamente la forge compromessa, cioè lo scenario che abbiamo visto materializzarsi più volte quest’estate. La documentazione di ENISA sulla piattaforma nomina infatti fabbricanti e gestori di software open source fra gli utenti.

Chi invece integra componenti open source in un prodotto proprio resta fabbricante a tutti gli effetti sul prodotto finito, qualunque sia l’origine del codice. È il punto che avevamo già messo a fuoco in SBOM e reporting del CRA.

Il nodo italiano e la cosa che non si applica ancora

Sull’Italia gira una semplificazione che vale la pena correggere. La legge 17 marzo 2026, n. 36, cioè la legge di delegazione europea 2025, contiene all’articolo 15 una delega al Governo per l’adeguamento della normativa nazionale al regolamento sulla ciberresilienza. È una delega, non una designazione: l’individuazione formale dell’autorità di vigilanza del mercato e il regime sanzionatorio nazionale arrivano con il decreto legislativo delegato, che a oggi non risulta pubblicato.

Questo non sospende niente, perché un regolamento è direttamente applicabile e l’articolo 14 vale da oggi indipendentemente da cosa fa Roma. Ma spiega l’asimmetria del momento, ed è lo stesso schema che avevamo trovato guardando i decreti italiani sull’AI Act: l’obbligo europeo morde mentre l’attuazione nazionale è ancora in viaggio.

Sulle sanzioni va detta una cosa con precisione. L’articolo 64 prevede per la violazione degli articoli 13 e 14 sanzioni fino a 15 milioni di euro o al 2,5% del fatturato mondiale totale annuo, il maggiore dei due. L’articolo 64 però non è fra le eccezioni elencate dall’articolo 71: le uniche anticipazioni sono l’articolo 14 e il capo IV. La lettura testuale è quindi che l’obbligo di segnalare è esigibile da oggi mentre l’apparato sanzionatorio segue il calendario generale dell’11 dicembre 2027. Non è un rinvio dell’obbligo, ed è una distinzione che serve a pianificare, non a rilassarsi: le notifiche mancate di oggi restano fatti documentati quando la vigilanza del mercato comincerà a guardare indietro.

Un’obiezione tecnica che non va archiviata

Durante i lavori sul regolamento un gruppo di ricercatori e organizzazioni della società civile sollevò un punto che resta valido: concentrare in un unico sistema le vulnerabilità attivamente sfruttate e non ancora corrette di tutti i fabbricanti europei crea un archivio di valore offensivo notevole, perché descrive in tempo reale cosa è aggredibile e dove.

Il testo finale una risposta la dà, all’articolo 16, paragrafo 2: la diffusione di una notifica agli altri CSIRT può essere ritardata per motivi connessi alla cibersicurezza, per il tempo strettamente necessario, in particolare su richiesta del fabbricante e quando la vulnerabilità è in divulgazione coordinata. È un mitigante sulla propagazione, non sull’accumulo: il dato resta comunque nella piattaforma e nei CSIRT nazionali. Da oggi quell’infrastruttura è, di fatto, uno degli obiettivi più sensibili d’Europa, e il livello di protezione che le si chiede è quello che il regolamento chiede ai fabbricanti.

Cosa fare oggi, in ordine

Per chi mette prodotti con elementi digitali sul mercato europeo, la lista è corta e ordinata per dipendenza.

1. Registrarsi sulla piattaforma. Nominare i rappresentanti abilitati e verificare che l’utenza funzioni, oggi, a freddo. Senza questo, i tre orologi non sono rispettabili.

2. Scrivere chi decide che una vulnerabilità è “attivamente sfruttata”. Serve un nome, un sostituto e una regola di decisione. Le 24 ore corrono da quando l’organizzazione ne è venuta a conoscenza, non da quando il comitato si riunisce.

3. Collegare le fonti che danno l’evidenza di sfruttamento. In pratica CISA KEV, i feed di threat intelligence, i vostri log e le segnalazioni che vi arrivano dal campo. Il punteggio CVSS qui non serve: serve sapere se qualcuno la sta usando.

4. Preparare il canale verso gli utilizzatori, in formato leggibile da macchina. Un advisory pubblicabile in giornata, con struttura stabile.

5. Tenere il registro dei due timer diversi. Quello a 14 giorni si aggancia alla data di rilascio della correzione: va tracciato nel processo di rilascio, non nel processo di incident response.

6. Usare l’inventario che dovreste già avere. Senza sapere quali componenti girano nei vostri prodotti, la domanda “questa vulnerabilità sfruttata ci riguarda?” non ha risposta in 24 ore. È lo stesso argomento dei numeri che avevamo messo in fila in 432 CVE del kernel Linux in due giorni.

Cosa ne pensiamo

Il punto interessante di questa scadenza è che sposta l’asse della conformità dalla documentazione alla reattività. I requisiti essenziali del 2027 si preparano scrivendo; l’articolo 14 si rispetta solo se il lunedì mattina qualcuno vede una cosa, la riconosce e la porta su una piattaforma entro sera. È la parte del regolamento che non si può delegare a un documento.

C’è anche un aspetto che ci sembra sottovalutato nel dibattito: il criterio delle prove attendibili di sfruttamento rende l’evidenza il vero oggetto della norma. Non basta sapere di avere una vulnerabilità, bisogna sapere se è usata, e questo è un problema di telemetria e di fonti, non di compliance documentale. Chi non ha visibilità sul proprio perimetro non è in ritardo sulla carta: è nell’impossibilità pratica di sapere se l’obbligo è scattato.

È il terreno su cui lavoriamo. CyberAgent tiene la superficie sotto osservazione continua e correla ogni vulnerabilità con CVE, EPSS e CISA KEV oltre che con il contesto dell’ambiente, che è precisamente il segnale su cui l’articolo 14 fa partire il conteggio. Con il pentest automatizzato verifica poi cosa è davvero sfruttabile, invece di consegnare una lista ordinata per CVSS. DataGovern tiene il lato documentale: mappa gli obblighi sui processi reali, ha i moduli di notifica sulle finestre 24 e 72 ore, conserva l’audit trail e la memoria delle decisioni, cioè le evidenze che servono a dimostrare quando avete saputo una cosa e cosa avete fatto. Gira on-premise con LLM open weight, che per dati di vulnerabilità non corrette è una proprietà architetturale e non una preferenza.

Come scriviamo ogni volta, nessuno dei due produce conformità automatica: riducono il lavoro manuale e rendono ripetibile la parte che va dimostrata, mentre la responsabilità formale resta di chi immette il prodotto sul mercato. Il quadro completo delle nostre soluzioni e la consulenza CISO servono a decidere quale dei due pezzi vi manca davvero.

Un pezzo resta aperto ed è utile saperlo mentre si costruisce il processo. Il paragrafo 10 dell’articolo 14 lascia alla Commissione la facoltà di specificare con atti di esecuzione il formato e le procedure di trasmissione delle notifiche, per questo articolo come per il 15 e il 16. Chi mette in piedi il flusso interno in questi giorni farebbe bene a tenere separato quello che registra da come lo trasmette: i campi che servono a ricostruire quando avete saputo una cosa non cambieranno, il modulo con cui li consegnate può cambiare.

Il lavoro che porta a rispettare una scadenza come questa sta tutto a monte, e con i nostri clienti lo seguiamo da giugno, quando abbiamo cominciato a leggere il regolamento articolo per articolo: inventario delle dipendenze, fonti che danno l’evidenza di sfruttamento, ruoli nominati con un sostituto, un canale di advisory che funziona in giornata. La tappa successiva è l’11 dicembre 2027, con i requisiti essenziali e l’SBOM nella documentazione tecnica. L’inventario costruito oggi per poter rispondere in 24 ore è la stessa base che servirà allora: è la parte che conviene fare bene una volta sola.

Fonti

• Regolamento (UE) 2024/2847, testo in italiano
• ENISA, Single Reporting Platform
• Commissione europea, CRA reporting obligations
• Legge 17 marzo 2026, n. 36, legge di delegazione europea 2025
• Cyber Security 360, Cyber Resilience Act: cosa cambia dall’11 settembre
• ICT Security Magazine, il rischio nascosto nell’obbligo di segnalazione
• Cyber Resilience Act: guida pratica dopo i chiarimenti della Commissione
• Cyber Resilience Act: SBOM e reporting vulnerabilità in arrivo