Dall'11 settembre 2026 entra in applicazione la prima parte operativa del Regolamento (UE) 2024/2847, il Cyber Resilience Act. Non è l'intero regolamento: la gran parte delle disposizioni — marcatura CE, valutazione di conformità, requisiti essenziali di sicurezza — diventerà applicabile solo dall'11 dicembre 2027. Quello che scatta fra pochi giorni è l'obbligo di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi.

È una scelta deliberata del legislatore europeo, e va letta per quello che è: l'Unione chiede ai produttori di dichiarare i problemi prima ancora di aver imposto loro l'obbligo di prevenirli.

Chi deve segnalare, cosa e in quanto tempo

L'obbligo ricade sul fabbricante di un prodotto con elementi digitali, cioè chi sviluppa (o fa sviluppare) hardware o software e lo immette sul mercato UE con il proprio nome o marchio. Non conta se lo sviluppo è esternalizzato, se il firmware è comprato da un fornitore terzo o se il prodotto è distribuito gratuitamente nell'ambito di un'attività commerciale: la responsabilità resta al fabbricante.

I termini sono stretti e a cascata:

  • 24 ore dalla conoscenza del fatto per una prima segnalazione di allerta;
  • 72 ore per una notifica più completa, con la valutazione dell'impatto e le misure correttive disponibili;
  • 14 giorni dalla disponibilità di una patch o mitigazione per il rapporto finale su una vulnerabilità attivamente sfruttata;
  • un mese dalla notifica delle 72 ore per il rapporto finale su un incidente grave.

Le comunicazioni passano attraverso la Single Reporting Platform gestita da ENISA. Il fabbricante effettua un solo invio, indirizzato al CSIRT designato come coordinatore — per un'azienda italiana, il CSIRT Italia dell'ACN — e reso disponibile in contemporanea a ENISA, salvo circostanze eccezionali.

Un punto che sfugge a molti: il reporting si applica anche ai prodotti già sul mercato prima dell'11 dicembre 2027. Non c'è un periodo di grazia legato alle nuove immissioni. Se un prodotto venduto tre anni fa è ancora nel periodo di supporto e domani emerge una vulnerabilità sfruttata, l'orologio delle 24 ore parte comunque.

Cosa significa per le aziende italiane

La reazione istintiva di molte PMI italiane è "non ci riguarda, non siamo produttori di software". Nella maggior parte dei casi è sbagliata, e per tre ragioni.

Primo: la definizione di fabbricante è più larga di quanto sembri. Chi commercializza un'app, un gestionale verticale, un dispositivo IoT o una macchina connessa con il proprio marchio è fabbricante ai sensi del CRA, anche se il codice l'ha scritto un fornitore esterno. Il tessuto industriale italiano è pieno di aziende meccaniche, elettromedicali, di automazione e di macchinari che vendono prodotti con firmware sviluppato da terzi: sono loro il soggetto obbligato, non il fornitore.

Secondo: le 24 ore sono un problema organizzativo, non tecnico. Rispettare quel termine richiede tre cose che quasi nessuno ha già pronte: un inventario aggiornato delle versioni in campo (quali release sono ancora in uso e presso chi), una SBOM che permetta di collegare rapidamente una CVE di una libreria di terze parti ai prodotti interessati, e una catena decisionale che possa autorizzare una notifica alle autorità in un giorno, festivi compresi. Chi scopre l'11 settembre di dover segnalare entro 24 ore e deve prima capire chi in azienda ha la firma, ha già perso.

Terzo: si sovrappone, ma non si sostituisce, agli obblighi che già esistono. Un'azienda soggetta a NIS2 notifica al CSIRT Italia gli incidenti significativi che colpiscono i propri servizi; con il CRA notifica le vulnerabilità sfruttate nei propri prodotti venduti a terzi. Sono due catene di notifica distinte, con soggetti e presupposti diversi, e possono attivarsi contemporaneamente sullo stesso evento. Se poi l'incidente comporta una violazione di dati personali, si aggiunge la notifica al Garante entro 72 ore ex art. 33 GDPR. Tre orologi, tre destinatari, un solo fatto.

Va segnalato anche il nodo che diversi analisti hanno sollevato: concentrare in una piattaforma europea le informazioni su vulnerabilità sfruttate e ancora non corrette crea un archivio di enorme valore per un attaccante. Il regolamento prevede tutele e la possibilità di differire alcune comunicazioni, ma il rischio di aggregazione resta reale ed è uno dei motivi per cui la qualità del contenuto delle segnalazioni conta quanto la tempestività.

Le sanzioni, e l'unica attenuante per le piccole imprese

Per la violazione dei requisiti essenziali e dei principali obblighi del fabbricante il CRA prevede sanzioni amministrative fino a 15 milioni di euro o al 2,5% del fatturato mondiale annuo, a seconda di quale importo sia più elevato. Le autorità di vigilanza del mercato possono inoltre limitare la commercializzazione, ordinare il ritiro o il richiamo del prodotto.

C'è una sola attenuante rilevante per il tessuto produttivo italiano: microimprese e piccole imprese non possono essere sanzionate per il solo mancato rispetto del termine di 24 ore della prima segnalazione. È una tutela sul ritardo iniziale, non un'esenzione dall'obbligo: la notifica va comunque fatta, e le 72 ore e il rapporto finale restano pienamente esigibili.

Cosa fare subito

  • Stabilire se si è fabbricanti. Verificare per ogni prodotto venduto se è immesso sul mercato UE con il proprio marchio. Se sì, si è soggetti obbligati anche a sviluppo esternalizzato.
  • Censire le versioni in campo. Serve sapere quali release sono installate e presso quali clienti, altrimenti l'analisi di impatto in 24 ore è impossibile.
  • Produrre una SBOM in formato leggibile da macchina (SPDX o CycloneDX) con almeno le dipendenze di primo livello, e agganciarla al monitoraggio delle CVE.
  • Nominare un responsabile della segnalazione con delega a firmare, e un sostituto. Definire per iscritto la catena di escalation, weekend e periodi di chiusura inclusi.
  • Registrarsi in anticipo sulla Single Reporting Platform di ENISA e verificare le credenziali prima di averne bisogno.
  • Pubblicare una policy di coordinated vulnerability disclosure e un canale di contatto per i ricercatori: è un obbligo del CRA ed è anche il modo più economico per venire a sapere dei problemi prima degli attaccanti.
  • Fare una prova a secco. Simulare la notifica di una vulnerabilità sfruttata e misurare quanto tempo serve davvero per arrivare dalla scoperta al testo pronto per l'invio.
  • Allineare le procedure con NIS2 e GDPR, mappando quale evento attiva quale notifica e verso chi, per evitare di scoprirlo durante un incidente.

Dieci giorni non bastano a costruire un processo di gestione delle vulnerabilità da zero. Bastano però a sapere se si è soggetti obbligati e a mettere per iscritto chi fa cosa entro 24 ore: è il minimo indispensabile per non trovarsi a improvvisare al primo caso reale.