Cyber Resilience Act: notifica vulnerabilità in 24 ore

In sintesi

• Dall’11 settembre 2026 scatta l’obbligo di notifica entro 24 ore previsto dall’articolo 14 del Cyber Resilience Act.
• Riguarda chi rientra nella definizione di “fabbricante”: sviluppa, fa sviluppare o rivende software a proprio marchio, anche senza scriverne una riga di codice.
• Senza un processo di rilevazione già rodato, il primo incidente reale diventa il primo test, con un margine di errore vicino allo zero.
• Un’assistenza clienti che risponde ai ticket non è un processo di notifica regolatoria: sono due flussi diversi, con destinatari e tempi diversi.

Cosa dice davvero l’articolo 14

Il Cyber Resilience Act è già legge. Quello che cambia l’11 settembre 2026 non è il testo, ma la sua applicabilità: da quella data gli obblighi diventano concretamente esigibili, con sanzioni collegate.

Il regolamento stabilisce che il fabbricante “notifica, senza indebito ritardo e in ogni caso entro 24 ore dal momento in cui ne viene a conoscenza, qualsiasi vulnerabilità attivamente sfruttata contenuta nel prodotto con elementi digitali” all’autorità competente, che in Italia sarà l’ACN secondo l’architettura prevista dal regolamento. Le 24 ore non sono il tempo per risolvere la falla, sono il tempo per segnalarla, e questa distinzione va tenuta ferma perché è lì che si gioca tutto il disegno del processo interno: non serve avere pronta la correzione software in un giorno, serve sapere a chi scrivere, cosa scrivere e con quali dati entro un giorno.

È un obbligo che nasce da una logica comprensibile, quella di dare alle autorità visibilità tempestiva su falle sfruttate in natura, ma che scarica sulle organizzazioni più piccole un carico procedurale pensato più per chi ha già un team di sicurezza strutturato che per chi gestisce un gestionale verticale con tre persone in tutto. Chi sviluppa una piattaforma ecommerce proprietaria dovrebbe avere già oggi una bozza di template di notifica, un responsabile identificato per compilarla e un canale di escalation che non dipenda dalla disponibilità di una sola persona di sabato sera. Il regolamento non dice come costruire questo processo: lascia che sia l’azienda a inventarselo, e questo è forse il suo limite più concreto per chi non ha funzioni legali o compliance dedicate.

Chi è fabbricante anche senza scrivere codice

Il punto che genera più confusione riguarda la definizione di fabbricante. Non serve un team di sviluppo interno: chi commissiona un software a un fornitore esterno e lo distribuisce con il proprio marchio rientra comunque nella definizione, con tutti gli obblighi che ne derivano.

Prendiamo il caso di uno studio legale che ha fatto sviluppare un portale clienti da un’agenzia esterna, lo mette sotto il proprio dominio e lo presenta come servizio proprio. Secondo il regolamento quello studio è fabbricante, non l’agenzia che ha scritto il codice. Dire “non l’abbiamo scritto noi” non basta per uscire dall’obbligo di notifica, perché il criterio determinante è il marchio sotto cui il prodotto viene distribuito, non chi ha materialmente prodotto le righe di codice. Questo distingue il fabbricante dal semplice utilizzatore: se un’azienda usa un software in abbonamento gestito dal fornitore senza personalizzarlo a proprio marchio, l’obbligo ricade su chi lo fornisce. Ma la linea si sposta nel momento esatto in cui il prodotto esce con il nome dell’azienda sopra.

Questa distinzione tra chi fornisce il sistema e chi lo utilizza ricorre anche altrove nella normativa europea recente, con criteri diversi ma la stessa logica di responsabilità distribuita: nella classificazione fornitore o deployer dell’AI Act, capire in che ruolo si rientra determina quali obblighi si applicano.

Il gap tra assistenza clienti e notifica regolatoria

Molti studi e aziende hanno un help desk efficiente: un cliente segnala un malfunzionamento, si apre un ticket, interviene il tecnico. Questo flusso, per quanto ben rodato, non è un processo di notifica ai sensi del Cyber Resilience Act. Un ticket nasce per risolvere un problema del cliente, non per attivare una segnalazione verso un’autorità esterna entro una finestra oraria fissa.

Mancano due pezzi strutturali. Il primo è un criterio esplicito per distinguere un bug qualunque da una vulnerabilità di sicurezza attivamente sfruttata, cosa che richiede competenze che un helpdesk di primo livello spesso non ha. Il secondo è una catena di responsabilità che sposti l’informazione dal tecnico a chi ha il mandato di inviare la notifica formale. Senza questi due elementi lo scenario è prevedibile: la vulnerabilità viene scoperta, gestita internamente come priorità tecnica, risolta in qualche giorno, e la finestra delle 24 ore passa senza che nessuno se ne accorga.

Non è negligenza, è assenza di un processo che renda quella scadenza visibile a chi deve rispettarla. Succede in aziende che su tutto il resto sono organizzate bene. Ed è probabilmente qui che si misurerà l’efficacia reale del regolamento nei prossimi anni: non sulla capacità tecnica di risolvere le falle, che le aziende serie già hanno, ma sulla capacità organizzativa di accorgersi che il cronometro è partito. Un aspetto su cui, va detto, mancano ancora riscontri pubblici concreti: non ci sono precedenti noti di sanzioni comminate, né indicazioni operative dettagliate da parte dell’ACN su come dovrà essere strutturata la notifica. Le aziende si stanno preparando a un obbligo di cui conoscono la scadenza ma non ancora tutti i dettagli applicativi.

Cosa fare prima di settembre 2026

Il tempo rimasto va usato per costruire, non per rimandare. Il primo passo è capire se l’azienda rientra nella definizione di fabbricante secondo l’articolo 3 del regolamento: software sviluppato su commessa e distribuito a proprio marchio, oppure un prodotto rivenduto con il proprio logo anche se il codice è di terzi.

Se la risposta è sì, il passo successivo è mappare il flusso attuale di gestione degli incidenti di sicurezza e individuare dove si interrompe rispetto a una notifica regolatoria: chi riceve la prima segnalazione, chi decide se è una vulnerabilità sfruttabile, chi ha l’autorità di inviare la comunicazione formale all’autorità competente. A quel punto resta un solo passaggio operativo davvero decisivo, ed è quello che quasi tutte le aziende rimandano perché non ha una scadenza visibile come quella delle 24 ore: assegnare un responsabile unico per compilare e inviare la notifica, con un sostituto designato per weekend e assenze, e testare il processo con una simulazione interna prima che arrivi un incidente vero a farlo per conto proprio.

Domande correlate

Cosa succede se non rispetto le 24 ore?

Il regolamento prevede un regime sanzionatorio collegato alla mancata osservanza degli obblighi di notifica, con l’autorità nazionale competente che valuta caso per caso gravità e recidiva. Oltre alla sanzione, resta il rischio reputazionale e di responsabilità civile verso i clienti coinvolti.

Il Cyber Resilience Act riguarda anche le app mobili?

Sì, il regolamento si applica a prodotti con elementi digitali che includono software e hardware connessi, categoria che comprende app mobili distribuite a marchio proprio. Vale lo stesso criterio: se la distribuisci sotto il tuo nome, sei fabbricante indipendentemente da chi l’ha sviluppata.

Qual è la differenza tra Cyber Resilience Act e AI Act?

Sono due regolamenti distinti con oggetti diversi: il Cyber Resilience Act disciplina la sicurezza informatica dei prodotti digitali, l’AI Act disciplina i sistemi di intelligenza artificiale. Un’azienda può ricadere sotto entrambi se distribuisce software a proprio marchio che include componenti di AI.

Devo notificare anche vulnerabilità non ancora sfruttate?

L’obbligo delle 24 ore scatta specificamente per vulnerabilità attivamente sfruttate. Il regolamento prevede comunque obblighi di gestione e correzione per le vulnerabilità note non ancora sfruttate, con tempistiche diverse da quella stringente delle 24 ore.

Fonti:

• Dall’11 settembre 2026 si applicano gli obblighi di notifica previsti dall’articolo 14 del regolamento (UE) 2024/2847 (accesso ottobre 2026)
• Regolamento (UE) 2024/2847 - Cyber Resilience Act (accesso ottobre 2026)