Vulnerabilità attivamente sfruttata: che cosa significa nel Cyber Resilience Act e quando fa scattare l'obbligo
«Attivamente sfruttata» è l'espressione che, dall'11 settembre 2026, decide se un fabbricante deve segnalare una vulnerabilità entro 24 ore oppure no. Non vuol dire «grave», né «nota», né «sfruttabile in teoria»: vuol dire che qualcuno la sta già usando. Questa guida spiega la definizione del regolamento (UE) 2024/2847, come si distingue dagli altri casi, da dove arriva l'informazione e che cosa fare nelle prime ore.
La definizione, parola per parola
Il regolamento definisce «vulnerabilità attivamente sfruttata» una vulnerabilità per la quale esistono prove attendibili che un soggetto malintenzionato l'abbia sfruttata in un sistema senza l'autorizzazione del proprietario (articolo 3, punto 42). Tre elementi contano.
- Prove attendibili. Non basta un sospetto o un articolo di stampa: serve un'evidenza credibile, per esempio un avviso di un'autorità, un rapporto di un fornitore di sicurezza, un'analisi dei log di un cliente colpito, una segnalazione circostanziata.
- Sfruttata. È accaduto almeno una volta, da qualche parte. Un codice di attacco pubblicato ma mai usato rende la vulnerabilità «sfruttabile», non «sfruttata».
- Senza autorizzazione. Un test di penetrazione commissionato dal proprietario del sistema non è uno sfruttamento attivo.
A questa definizione si lega l'obbligo dell'articolo 14: il fabbricante notifica «qualsiasi vulnerabilità attivamente sfruttata contenuta nel prodotto con elementi digitali di cui viene a conoscenza». Due condizioni insieme: la vulnerabilità è sfruttata, e sta nel tuo prodotto.
Nota, sfruttabile, sfruttata: tre cose diverse
| Situazione | Che cosa significa | Che cosa devi fare |
|---|---|---|
| Vulnerabilità nota | È pubblicata (ha un numero CVE) in un componente che usi | Valutarla: ti riguarda? È raggiungibile nel tuo prodotto? Documentare la risposta (anche con una dichiarazione VEX) |
| Vulnerabilità sfruttabile | Nel tuo prodotto può essere usata per un attacco; può esistere un codice dimostrativo | Dare priorità alla correzione; aggiornamento di sicurezza; nessun obbligo di notifica a ENISA, finché non ci sono prove di sfruttamento |
| Vulnerabilità attivamente sfruttata | Ci sono prove attendibili che qualcuno la usa, e il tuo prodotto la contiene | Preallarme entro 24 ore, notifica entro 72, relazione finale; informare gli utilizzatori; correggere |
Gli orientamenti della Commissione europea del 27 luglio 2026 aggiungono una precisazione importante: se la vulnerabilità è sfruttata in giro, ma nel tuo prodotto non può esserlo (per esempio perché la funzione vulnerabile del componente non è usata o non è raggiungibile), l'obbligo di notifica non scatta. La valutazione va però fatta, e va fatta subito.
Da dove arriva l'informazione
Nessun fabbricante scopre da solo che una vulnerabilità è sfruttata. L'informazione arriva da fuori, da fonti diverse, e il problema è vederla in tempo.
- Cataloghi di vulnerabilità sfruttate. L'agenzia americana CISA tiene un elenco pubblico (KEV, Known Exploited Vulnerabilities) che a fine 2025 contava circa 1.480 voci. ENISA gestisce dal 2025 la banca dati europea delle vulnerabilità (EUVD), che segnala anche lo sfruttamento.
- Avvisi dei fornitori di componenti. Chi produce il sistema operativo, la libreria o il controllore che integri pubblica avvisi di sicurezza, spesso con l'indicazione «sfruttata in attacchi reali».
- Autorità e CSIRT. CSIRT Italia e gli altri centri nazionali diffondono bollettini; possono anche contattare direttamente un fabbricante.
- Clienti e ricercatori. Un cliente che subisce un incidente, un ricercatore che ti scrive al contatto per le vulnerabilità: per questo il regolamento chiede di avere un contatto pubblico e una politica di divulgazione.
- Fornitori di informazioni sulle minacce. Servizi che aggregano prove di sfruttamento e punteggi di probabilità (come l'EPSS), utili per dare priorità.
Un dato aiuta a capire l'urgenza: nel 2025 circa il 29% delle vulnerabilità sfruttate lo è stato il giorno stesso della pubblicazione o prima (VulnCheck, 2026). Quando l'informazione arriva, spesso l'attacco è già in corso.
Tre esempi su prodotti industriali
I casi sono immaginari, ma tipici.
- Il router per l'assistenza remota. Il fornitore del modulo di accesso remoto integrato nella tua macchina pubblica un avviso: una vulnerabilità del suo firmware è usata per entrare negli impianti dei clienti. La macchina contiene quel modulo, esposto in rete: la vulnerabilità è attivamente sfruttata nel tuo prodotto. Scattano le 24 ore. Anche se la correzione la deve fare il fornitore, la notifica per il tuo prodotto è tua.
- La libreria di rete nel controllore. Una libreria che usi nel firmware ha una falla sfruttata in attacchi contro server web. Nel tuo controllore la libreria serve solo per una funzione di diagnostica locale, non raggiungibile dalla rete. Valuti, documenti (dichiarazione VEX «non applicabile», con la motivazione), correggi al prossimo rilascio: nessuna notifica obbligatoria.
- Il pannello operatore con il codice dimostrativo. Un ricercatore pubblica un codice che mostra come bloccare il pannello da remoto. Non ci sono prove che qualcuno lo abbia usato: la vulnerabilità è sfruttabile, non sfruttata. Priorità alta alla correzione, informazione ai clienti, nessuna notifica a ENISA. Se un cliente ti segnala un attacco riuscito, la situazione cambia e il conto delle 24 ore parte da lì.
Che cosa fare nelle prime ore
Le 24 ore partono da quando «vieni a conoscenza» della vulnerabilità sfruttata: secondo gli orientamenti della Commissione, quando, dopo una prima valutazione, hai una ragionevole certezza. La prima valutazione, però, va fatta immediatamente. Sei passi, nell'ordine.
- Annota l'ora. Quando è arrivata l'informazione, da chi, in che forma. È la prima riga del registro.
- Verifica se ti riguarda. Il componente è nei tuoi prodotti? In quali versioni? La SBOM serve esattamente a questo.
- Verifica se è sfruttabile nel tuo prodotto. La funzione vulnerabile è usata? È raggiungibile? Chi conosce il prodotto risponde in poche ore; senza questa persona si perde la giornata.
- Decidi, e scrivi chi ha deciso. Notificare o no: è la decisione del fabbricante. Se sì, preallarme sulla piattaforma ENISA entro 24 ore dalla ragionevole certezza.
- Prepara la notifica delle 72 ore. Natura della vulnerabilità, prodotti e versioni interessati, gravità, misure correttive o di attenuazione disponibili.
- Informa gli utilizzatori. Il regolamento chiede di avvisare chi usa il prodotto e, dove serve, di indicare le misure da prendere (articolo 14, paragrafo 8).
Dopo l'emergenza: relazione finale entro 14 giorni dalla disponibilità della correzione, aggiornamento di sicurezza gratuito, nuova SBOM per la versione corretta.
Gli errori più comuni
- Confondere la gravità con lo sfruttamento. Una vulnerabilità «critica» sulla carta ma mai usata non è da notificare; una «media» usata in attacchi reali sì.
- Notificare per prudenza ogni cosa. Intasa il processo e non è ciò che il regolamento chiede. La prudenza giusta è valutare tutto e documentare.
- Non sapere che cosa c'è nei prodotti venduti. Senza SBOM, la verifica del passo 2 diventa una ricerca a mano, prodotto per prodotto. È il motivo per cui l'obbligo di segnalazione, già in vigore, rende urgente la SBOM prima del 2027.
- Lasciare la decisione all'informatica aziendale. La domanda è sul prodotto: servono chi lo conosce e chi ne segue la conformità.
Domande frequenti
Chi stabilisce che le prove sono «attendibili»?
Il fabbricante, con una valutazione ragionevole e documentata. Un avviso di un'autorità, del fornitore del componente o di un cliente colpito è di norma sufficiente; una voce non circostanziata no.
La vulnerabilità è sfruttata, ma in un prodotto di un altro fabbricante che usa lo stesso componente. Devo notificare?
Solo se la vulnerabilità è sfruttabile anche nel tuo prodotto. La valutazione va fatta subito e annotata; la notifica scatta se la risposta è sì.
Sono una piccola impresa: le 24 ore valgono anche per me?
Sì. Il regolamento prevede solo che le micro e piccole imprese non siano sanzionate per il mancato rispetto del termine delle 24 ore (articolo 64, paragrafo 10); restano le 72 ore, la relazione finale e tutti gli altri obblighi.
Il prodotto è fuori assistenza da anni.
Secondo gli orientamenti della Commissione l'obbligo di segnalazione continua anche dopo la fine del periodo di assistenza, per i prodotti che rientrano nel regolamento.
Da dove cominciare
Per rispondere in 24 ore alla domanda «ci riguarda?» servono due cose: sapere che cosa c'è nei prodotti venduti, e avere un canale che porti l'informazione alla persona giusta. Il configuratore di Assiduo parte da qui: quali prodotti, quali ruoli, a che punto sei con la SBOM. È gratuito, non chiede di caricare file e mostra il risultato prima della registrazione.
Fonti: regolamento (UE) 2024/2847, articoli 3, 14, 64 e 69; orientamenti della Commissione europea C(2026) 5252 del 27 luglio 2026; CISA, catalogo KEV; ENISA, EUVD; VulnCheck, rapporto 2026 sullo sfruttamento delle vulnerabilità. Leggi anche: la procedura di segnalazione passo per passo · vulnerabilità di prodotto.