Nella percezione diffusa il Cyber Resilience Act è una scadenza del 2027. È l’anno in cui i prodotti con elementi digitali dovranno esibire la marcatura CE anche in ragione della loro sicurezza informatica, l’anno della dichiarazione di conformità, del fascicolo tecnico, dei requisiti essenziali dell’Allegato I. È anche l’anno che, nelle roadmap di conformità circolate in questi mesi, consente di rinviare le decisioni difficili.
Il calendario del Regolamento (UE) 2024/2847 racconta però una storia diversa. Il regolamento è in vigore dal 10 dicembre 2024. Il Capo IV, relativo alla notifica degli organismi di valutazione della conformità, si applica dall’11 giugno 2026. L’articolo 14, che disciplina gli obblighi di segnalazione dei fabbricanti, si applica dall’11 settembre 2026. La piena applicazione arriva l’11 dicembre 2027. La prima data che produce obblighi sanzionabili in capo alle imprese, dunque, è quella di settembre, e non riguarda i prodotti del futuro.
Indice degli argomenti
La clausola di salvaguardia e la sua eccezione
L’articolo 69 del regolamento contiene le disposizioni transitorie. Il comma 2 stabilisce che i prodotti con elementi digitali immessi sul mercato prima dell’11 dicembre 2027 sono soggetti ai requisiti del regolamento soltanto se, a partire da quella data, sono oggetto di una modifica sostanziale. È la clausola di salvaguardia che l’industria ha letto con sollievo: ciò che è già stato venduto resta fuori, salvo interventi che ne alterino la destinazione d’uso o ne innalzino il profilo di rischio.
Il comma 3 dello stesso articolo introduce però una deroga secca. In deroga al comma 2, gli obblighi previsti dall’articolo 14 si applicano a tutti i prodotti con elementi digitali rientranti nell’ambito di applicazione del regolamento che sono stati immessi sul mercato prima dell’11 dicembre 2027. La sintesi della Commissione europea è, se possibile, ancora più netta: gli obblighi di segnalazione si applicano a tutti i prodotti con elementi digitali messi a disposizione sul mercato dell’Unione, compresi quelli già immessi sul mercato prima dell’11 dicembre 2027.
Vale la pena fermarsi sulla nozione di immissione sul mercato, perché è la fonte di gran parte degli equivoci. Nel diritto europeo dei prodotti si tratta di un evento puntuale, che si verifica una sola volta e riguarda la singola unità: la prima messa a disposizione di quell’esemplare sul mercato dell’Unione. Non è uno stato che si rinnova finché il prodotto resta in commercio o in uso. Ne discende che la clausola di salvaguardia protegge davvero il parco installato, ma non lo protegge dall’articolo 14.
Il risultato è un regime asimmetrico, e la parola giusta non è retroattività. Il regolamento non impone a un prodotto del passato di conformarsi a requisiti tecnici del presente. Impone al suo fabbricante un obbligo procedurale nuovo, che si attiva al verificarsi di un evento futuro.
Che cosa scatta, esattamente
L’articolo 14 non si attiva per ogni vulnerabilità, e ha due presupposti distinti. Il primo è la vulnerabilità attivamente sfruttata: l’articolo 3, punto 42, la definisce come quella per cui esistono prove attendibili che un utente malevolo l’abbia effettivamente sfruttata in un sistema reale. La formula è più stretta di quanto sembri. Non basta che la falla sia stata scoperta, resa pubblica o dimostrata da un ricercatore: conviene pensarla come un incidente più che come un difetto, perché qualcosa è già accaduto a un cliente, come un alert che segnala il prodotto usato come via d’ingresso in una rete, una violazione confermata in cui la vulnerabilità ha avuto un ruolo. Ciò che il ricercatore scopre in laboratorio, o il proof-of-concept che circola online, resta nel perimetro della normale gestione delle vulnerabilità. Il secondo presupposto è l’incidente grave che incide sulla sicurezza del prodotto: un evento sul versante dell’organizzazione, come la compromissione della catena di sviluppo o del canale di aggiornamento, capace di ripercuotersi sulla sicurezza di ciò che il fabbricante ha immesso sul mercato.
Quando l’obbligo scatta, però, i tempi sono quelli di una crisi. Il fabbricante che viene a conoscenza di una vulnerabilità attivamente sfruttata nel proprio prodotto deve trasmettere un allarme rapido entro ventiquattro ore; una notifica più circostanziata entro settantadue ore, con le informazioni disponibili sul prodotto interessato, sulla natura dello sfruttamento e sulle misure correttive o di mitigazione; una relazione finale entro quattordici giorni dal momento in cui una misura correttiva è disponibile. Per gli incidenti gravi che incidono sulla sicurezza del prodotto la relazione finale è dovuta entro un mese dalla notifica delle settantadue ore.
Le notifiche vanno trasmesse simultaneamente al CSIRT designato come coordinatore e all’ENISA, attraverso la piattaforma unica di segnalazione prevista dall’articolo 16. Il CSIRT competente è quello dello Stato membro in cui il fabbricante ha lo stabilimento principale, individuato dal luogo in cui sono assunte le decisioni relative alla cibersicurezza dei prodotti. A questo si aggiunge, per effetto dell’articolo 14, paragrafo 8, l’obbligo di informare gli utenti interessati della vulnerabilità o dell’incidente e delle misure di mitigazione che possono adottare.
L’articolo 64 colloca la violazione degli obblighi dell’articolo 14 nella fascia sanzionatoria più elevata, insieme all’inosservanza dei requisiti essenziali dell’Allegato I: fino a quindici milioni di euro o, per le imprese, fino al 2,5% del fatturato mondiale totale annuo dell’esercizio precedente, se superiore. Alle microimprese e alle piccole imprese è riconosciuta un’esenzione circoscritta al solo mancato rispetto del termine di ventiquattro ore per l’allarme rapido: tutto il resto del regime di notifica si applica anche a loro.
Il regolamento chiede l’esito, non il mezzo
Qui si apre il punto che merita attenzione, e che la comunicazione di mercato di questi mesi ha tendenzialmente confuso gran parte di aziende. L’articolo 14 non impone di monitorare. Non impone di dotarsi di una politica di divulgazione coordinata delle vulnerabilità, non impone di mantenere una distinta dei componenti software, non impone di correlare il proprio portafoglio con le fonti pubbliche sulle vulnerabilità sfruttate. Tutti questi obblighi esistono, ma stanno altrove: nella Parte II dell’Allegato I, dedicata alla gestione delle vulnerabilità, che diventa applicabile l’11 dicembre 2027.
L’obbligo di segnalazione, invece, si radica su un presupposto soggettivo: il fabbricante deve notificare la vulnerabilità attivamente sfruttata di cui viene a conoscenza. Fra l’11 settembre 2026 e l’11 dicembre 2027 il regolamento pretende dunque l’esito — la notifica in ventiquattro ore — senza pretendere ancora i mezzi che quell’esito rendono possibile. Per quindici mesi l’ordinamento europeo domanda l’output senza domandare l’input.
Sarebbe un errore leggere questa asimmetria come una franchigia. Il presupposto della conoscenza non è controllato dal fabbricante. La notizia che una vulnerabilità del proprio prodotto è oggetto di sfruttamento attivo arriva dall’esterno: da un CSIRT nazionale, dal catalogo delle vulnerabilità sfruttate, dalla banca dati europea gestita da ENISA, da un cliente colpito, da un ricercatore, dalla stampa specializzata. Nel momento in cui arriva, il cronometro delle ventiquattro ore parte, e parte per un’organizzazione che non ha un canale di ricezione, non ha stabilito chi decide che la notifica è dovuta, non sa quale sia il proprio CSIRT e non ha mai aperto la piattaforma unica.
Non guardare, in altri termini, non riduce l’esposizione: la sposta. La riduce sul piano della conoscenza, la aggrava su quello della reazione.
Chi è fabbricante senza sapere di esserlo
A rendere il problema meno teorico di quanto sembri è la definizione di fabbricante. L’articolo 3, punto 13, comprende qualsiasi persona fisica o giuridica che sviluppa o fabbrica prodotti con elementi digitali, oppure li fa progettare, sviluppare o fabbricare, e li commercializza con il proprio nome o marchio, a titolo oneroso, a fini di monetizzazione o gratuitamente.
La qualifica va determinata prodotto per prodotto. Ne discende che vi rientrano l’azienda manifatturiera che vende un macchinario con firmware sviluppato da un terzo ma marchiato in proprio; il fornitore che rivende in white label una soluzione altrui; il gruppo industriale in cui una società sviluppa e un’altra commercializza. Nessuno di questi soggetti si descriverebbe come fabbricante di software. Tutti sono fabbricanti ai sensi del regolamento. E, per effetto dell’articolo 24, paragrafo 3, un perimetro analogo di obblighi di segnalazione tocca gli steward di software libero e open source, nella misura in cui siano coinvolti nello sviluppo dei prodotti rilevanti.
La combinazione fra la deroga dell’articolo 69, comma 3, e l’ampiezza della nozione di fabbricante produce un esito preciso: l’esposizione normativa si concentra proprio dove la capacità di rilevazione è più bassa. Il portafoglio legacy — i prodotti che l’azienda non sviluppa più, che riceve al massimo qualche correzione, per i quali nessuno ha mai costruito un inventario dei componenti — è la parte del catalogo che nessuno strumenta. Ed è la parte che l’articolo 14 raggiunge per prima.
Una domanda aperta e una scadenza concreta
Resta un punto che il testo non chiarisce con la nettezza che le imprese vorrebbero: fino a quando l’obbligo di segnalazione accompagna un prodotto immesso sul mercato molti anni fa e non più supportato. L’articolo 69, comma 3, non contiene limiti temporali espressi verso il passato, mentre il periodo di supporto è una nozione che il regolamento costruisce altrove e per finalità diverse. È una questione che meriterà l’attenzione degli orientamenti della Commissione, e che nel frattempo consiglia prudenza interpretativa a chi ritenga di potersi considerare al di fuori del perimetro.
Quel che invece non richiede interpretazione è che cosa convenga fare da qui a settembre. E la risposta non è produrre documenti. I documenti serviranno nel 2027. Ciò che serve adesso è un elenco dei prodotti ancora presenti sul mercato dell’Unione e degli esemplari ancora in uso presso clienti europei, con l’indicazione di chi ne è fabbricante ai sensi dell’articolo 3. Serve un canale attraverso cui una segnalazione esterna raggiunga in poche ore qualcuno che possa agire, e non una casella di posta generica. Serve la designazione, nominativa, del soggetto che decide se la soglia dell’articolo 14 è superata e di quello che firma l’allarme rapido. Serve sapere quale sia il CSIRT coordinatore competente, il che presuppone aver individuato lo stabilimento principale del gruppo. Serve, infine, aver visto la piattaforma unica prima del giorno in cui la si deve usare.
Sono decisioni organizzative, non tecniche, e nessuna di esse richiede di anticipare gli investimenti del 2027. Richiedono però di essere prese prima dell’evento che le renderà necessarie, perché il termine di ventiquattro ore non è compatibile con un’escalation interna che comincia il giorno stesso.
La vera scadenza del Cyber Resilience Act, per la maggior parte delle imprese italiane, non è dunque l’11 dicembre 2027. È l’11 settembre 2026, e riguarda i prodotti che hanno già venduto.
Partecipa alla community