Dall'11 settembre 2026 chi sviluppa o produce software e hardware destinati al mercato europeo ha un nuovo obbligo legale: segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi che riguardano i propri prodotti, entro scadenze precise e attraverso un'unica piattaforma gestita da ENISA. È la prima parte del Cyber Resilience Act (Regolamento UE 2024/2847) a diventare pienamente operativa, quasi un anno e mezzo prima degli obblighi principali sulla sicurezza dei prodotti, che arriveranno l'11 dicembre 2027. Per chi lavora nel software, in particolare per le software house italiane che vendono in UE, è il momento in cui il CRA smette di essere una scadenza lontana e diventa un processo da avere già pronto.

Indice

Le tre date del Cyber Resilience Act

Il Cyber Resilience Act non ha un'unica data di entrata in vigore, e confonderle è l'errore più comune che si legge in giro. Il regolamento è stato pubblicato nella Gazzetta ufficiale dell'UE nel novembre 2024 ed è entrato in vigore il 10 dicembre 2024, ma quella data segna solo l'inizio del periodo transitorio. Da allora ci sono due scadenze operative distinte, e sono quelle che contano davvero per chi deve pianificare il lavoro.

La prima è l'11 settembre 2026: da questa data si applica l'articolo 14, quello sugli obblighi di segnalazione di vulnerabilità e incidenti. La seconda è l'11 dicembre 2027: da questa data si applicano i requisiti essenziali di sicurezza previsti dall'Allegato I, la marcatura CE dei prodotti con elementi digitali e il resto dell'impianto normativo. Sono obblighi diversi, con platee diverse e conseguenze diverse, ed è la seconda scadenza quella su cui si concentra la maggior parte della copertura mediatica del CRA. Ma è la prima, quella dell'11 settembre appena passata, quella già in vigore oggi.

Cosa bisogna segnalare da oggi

L'articolo 14 del CRA impone due tipi di segnalazione, entrambe legate a eventi che riguardano un "prodotto con elementi digitali" già sul mercato UE: la vulnerabilità attivamente sfruttata e l'incidente grave che ha un impatto sulla sicurezza del prodotto.

La distinzione conta. Non basta che una vulnerabilità esista: deve risultare sfruttata attivamente, cioè qualcuno la sta usando in un attacco reale, non solo teoricamente exploitabile. Un incidente grave, invece, è un evento che ha già avuto un impatto concreto sulla disponibilità, integrità o riservatezza del prodotto o dei dati che tratta. Chi gestisce un programma di vulnerability disclosure coordinato sa che la maggior parte dei report che riceve non rientra in nessuna delle due categorie: sono vulnerabilità potenziali, non ancora sfruttate. Il CRA non chiede di segnalare quelle. Chiede di segnalare quando smettono di essere teoriche.

Le scadenze: 24 ore, 72 ore, 14 giorni

Una volta che il produttore diventa consapevole di una vulnerabilità attivamente sfruttata o di un incidente grave, il CRA impone una sequenza di notifiche, non una segnalazione unica.

Fase Termine Contenuto
Early warning 24 ore dalla consapevolezza segnalazione minima, anche senza dettagli tecnici completi
Notifica 72 ore dalla consapevolezza informazioni più complete su natura e impatto
Report finale 14 giorni dopo la disponibilità di una misura correttiva (vulnerabilità) o 1 mese dopo la notifica (incidente grave) analisi completa, causa, misure adottate

Il dettaglio che passa spesso inosservato è che il termine parte dalla "consapevolezza", non dalla scoperta tecnica. Se il SOC individua un log anomalo ma ci vogliono tre giorni per confermare che si tratta di sfruttamento attivo di una vulnerabilità nel prodotto, le 24 ore partono da quando arriva la conferma, non da quando è comparso il primo indicatore. È un margine reale, ma richiede comunque un processo interno che sappia distinguere un sospetto da una consapevolezza confermata, perché è quel momento a far scattare l'orologio.

Dove si segnala: la Single Reporting Platform di ENISA

Prima del CRA, un produttore attivo in più stati membri avrebbe dovuto notificare separatamente ogni CSIRT nazionale coinvolto. La Single Reporting Platform (SRP), lo strumento online che ENISA ha messo in funzione proprio l'11 settembre 2026, elimina quella duplicazione: la segnalazione va fatta una sola volta, al CSIRT designato come coordinatore nel paese in cui il produttore prende le decisioni principali sulla sicurezza del prodotto, e la piattaforma la rende disponibile simultaneamente a ENISA e, quando serve, ai CSIRT degli altri stati membri coinvolti.

Per una software house italiana, il CSIRT coordinatore è di norma CSIRT Italia, sotto l'Agenzia per la Cybersicurezza Nazionale. L'accesso alla SRP richiede una registrazione preventiva come Assigned Representative, un passaggio che conviene completare prima di averne bisogno: farlo nel mezzo di una finestra di 24 ore già in corso è la situazione peggiore in cui trovarsi.

Chi è un "manufacturer" secondo il CRA

Il CRA usa il termine "manufacturer" in un senso molto più ampio di quanto suggerisca la traduzione italiana "produttore". Rientra nella definizione chiunque sviluppi o faccia sviluppare un prodotto con elementi digitali e lo metta sul mercato con il proprio nome o marchio, a pagamento o gratuitamente. Una software house che vende un'applicazione SaaS con il proprio brand è un manufacturer secondo il CRA, esattamente come un'azienda che produce router o telecamere IP: quello che determina l'obbligo è mettere sul mercato UE un prodotto con codice proprio sotto il proprio nome, indipendentemente dal settore.

Chi sviluppa software su commissione per un singolo cliente, senza metterlo sul mercato con il proprio marchio, resta fuori da questa definizione specifica: l'obbligo di segnalazione si sposta su chi quel software lo rivende o lo distribuisce con il proprio nome. Questa distinzione va verificata caso per caso quando il modello di business non è un chiaro prodotto a catalogo.

Un caso a parte è quello degli open-source software steward, i soggetti che sostengono in modo sistematico e continuativo lo sviluppo di progetti open source usati in attività commerciali. Per loro il CRA prevede un regime più leggero e, soprattutto, tempi diversi: gli obblighi di segnalazione per gli steward partono dall'11 dicembre 2027, non da adesso. Chi mantiene una libreria open source senza un modello di business commerciale attorno resta fuori dal perimetro del regolamento a prescindere dalla data.

Cosa non è ancora obbligatorio

È qui che si annida la maggior parte della confusione che si legge online in questi giorni. L'11 settembre 2026 riguarda esclusivamente l'articolo 14: segnalazione di vulnerabilità attivamente sfruttate e incidenti gravi. Non riguarda ancora:

  • i requisiti di sicurezza essenziali dell'Allegato I (secure by design, gestione delle vulnerabilità per tutto il ciclo di vita, aggiornamenti di sicurezza)
  • la marcatura CE dei prodotti con elementi digitali
  • la valutazione di conformità da parte di organismi notificati per i prodotti considerati critici
  • la documentazione tecnica e la dichiarazione di conformità UE

Tutti questi obblighi si applicano dall'11 dicembre 2027. Fino a quella data un prodotto può non avere ancora nessuno dei requisiti dell'Allegato I ed essere comunque legalmente sul mercato, ma se in quel prodotto viene sfruttata attivamente una vulnerabilità, va segnalata da oggi. I due binari corrono in parallelo, con velocità diverse, e trattarli come un'unica scadenza porta a sottovalutare quella più vicina o a farsi prendere dal panico per quella più lontana.

Il rischio di conformità nascosto

Diversi osservatori del settore hanno segnalato un problema pratico: molte aziende, soprattutto piccole e medie, non hanno ancora un processo interno che distingua chiaramente tra "abbiamo ricevuto un report di vulnerabilità" e "abbiamo consapevolezza di uno sfruttamento attivo". Senza quella distinzione, il rischio concreto non è tanto ignorare l'obbligo, quanto applicarlo nel modo sbagliato: segnalare in massa qualunque report ricevuto, sovraccaricando CSIRT Italia di notifiche che non soddisfano la soglia richiesta dal CRA, oppure ritardare una segnalazione dovuta perché nessuno in azienda ha la responsabilità esplicita di riconoscerla come tale.

Il tempo speso a definire internamente cosa conta come sfruttamento attivo confermato per il proprio prodotto, prima che succeda, è probabilmente l'investimento con il ritorno più immediato di questa fase del CRA.

Come prepararsi da subito

Chi non ha ancora avviato nulla può concentrarsi su un numero limitato di cose concrete. La registrazione alla Single Reporting Platform come Assigned Representative viene prima di tutto, perché senza quella non esiste modo di rispettare le 24 ore quando servirà. Va identificato un referente interno, o un piccolo team, con la responsabilità esplicita di valutare se un report di sicurezza ricevuto soddisfa la soglia di vulnerabilità attivamente sfruttata o di incidente grave, perché quella valutazione è il momento in cui parte l'orologio, e non può essere una decisione presa ad hoc sotto pressione. Il canale di ricezione delle segnalazioni di sicurezza va reso pubblico e monitorato con continuità: un file security.txt che punta a un indirizzo controllato regolarmente, non a una casella email dimenticata, è la base minima. E la politica di coordinated vulnerability disclosure, già buona prassi in molte aziende, va rivista tenendo conto che ora esiste anche una scadenza legale specifica dopo la conferma di sfruttamento attivo.

Nessuno di questi passaggi richiede una ristrutturazione organizzativa. Richiedono che qualcuno, prima che arrivi la prima notifica reale, abbia già deciso chi fa cosa nelle prime 24 ore.

Risorse

  1. Commissione Europea - Cyber Resilience Act, obblighi di segnalazione
  2. ENISA - Single Reporting Platform (SRP)
  3. ENISA - Comunicato sull'attivazione della SRP
  4. Regolamento (UE) 2024/2847 - testo integrale su EUR-Lex
  5. Commissione Europea - Cyber Resilience Act, sintesi del testo legislativo
  6. ACN - FAQ CSIRT Italia