La pubblicazione di una proof of concept su GitHub fa scattare l’obbligo di preallarme entro 24 ore
Alle 14:37 di un martedì qualunque, un ricercatore pubblica su GitHub una proof of concept per una vulnerabilità zero-day in un dispositivo IoT industriale. Da quel momento scatta un timer di 24 ore. Non è un film, ma la realtà che attende i produttori a partire dall’11 settembre 2026, quando entreranno in vigore gli obblighi di segnalare vulnerabilità attivamente sfruttate e incidenti gravi che hanno un impatto sulla sicurezza dei prodotti con elementi digitali.
Il Cyber Resilience Act — il regolamento europeo che ridisegna la cybersicurezza come requisito di prodotto — è legge dal 10 dicembre 2024, ma il suo meccanismo più dirompente, l’obbligo di notifica rapida, diventa operativo tra poco più di un mese. Chi progetta, distribuisce o manutiene dispositivi connessi, sensori industriali o apparecchiature medicali digitali farà i conti con scadenze che non ammettono proroghe: il preallarme va presentato entro 24 ore dalla presa di coscienza della vulnerabilità, la notifica completa entro 72 ore. E il timer parte dal momento in cui l’organizzazione viene a conoscenza del problema — che la segnalazione arrivi da un repository pubblico, da un cliente o dal CSIRT di riferimento.
24 ore per non sbagliare
La scansione temporale è tassativa. Entro 24 ore dalla presa di coscienza: early warning, una notifica sintetica che segnali l’esistenza del problema. Entro 72 ore: notifica completa, con i dettagli tecnici disponibili, la valutazione di impatto e le prime contromisure adottate. Non finisce qui: per le vulnerabilità attivamente sfruttate, una relazione finale deve essere presentata entro 14 giorni dalla disponibilità di una misura correttiva; per gli incidenti gravi, il termine si allunga a un mese. Se i consumatori potrebbero subire danni, scatta un obbligo ulteriore: il produttore deve emettere comunicazioni separate rivolte direttamente ai consumatori — un adempimento che, per un’azienda con decine di migliaia di clienti, comporta oneri organizzativi non trascurabili.
Che cosa significa «presa di coscienza»? Il CRA non lascia margini all’interpretazione restrittiva: il momento in cui un dipendente, un contractor o un sistema di monitoraggio rileva la condizione di sfruttamento attivo coincide con l’avvio del cronometro. E la pubblicazione di una proof of concept su una piattaforma pubblica, notificata o meno che sia, è sufficiente a far scattare il dovere di diligenza. La SRP, peraltro, sarà l’unico canale accettato: non bastano comunicazioni informali ai CSIRT nazionali o a ENISA via e-mail; occorre utilizzare la piattaforma, che standardizzerà i formati e smisterà le segnalazioni agli organismi competenti.
La lente europea su Silicon Valley
E mentre il timer parte, Bruxelles guarda ben oltre i confini dell’Unione. Il paradosso — o forse la strategia — è sotto gli occhi di chi segue i precedenti regolatori: le azioni di enforcement del Cyber Resilience Act colpiranno per prime le aziende statunitensi. Lo ha previsto Hoofnagle, analista del Berkeley Center for Law & Technology, osservando che le misure coercitive, quando arriveranno, «saranno contro aziende americane, in parte perché l’America è dove le cose vengono inventate». Il risultato è che le imprese emergenti di Silicon Valley — quelle che portano sul mercato dispositivi innovativi ma spesso con processi di security maturity ancora in formazione — sono particolarmente esposte.
Non è una questione astratta di geopolitica regolatoria. Il CRA si applica a qualunque prodotto con elementi digitali immesso sul mercato europeo, indipendentemente dalla sede del produttore. E gli obblighi di segnalazione dei produttori — i primi a scattare, ben prima dell’applicazione integrale del regolamento fissata all’11 dicembre 2027 — rappresentano il banco di prova della credibilità enforcement dell’Unione. Per uno studio legale con pratica transatlantica come Taylor Wessing, la partenza anticipata a settembre 2026 non è casuale: serve a testare la capacità di risposta delle filiere globali prima che l’intero impianto sanzionatorio diventi operativo.
L’ironia è palpabile: l’Europa, che ha costruito il CRA anche in risposta alla percezione di una dipendenza tecnologica dall’ecosistema americano, userà proprio i campioni di quell’ecosistema come primi destinatari della sua azione punitiva. E il danno reputazionale, per un’azienda californiana abituata a presentarsi come leader della cybersecurity, potrebbe pesare più della sanzione amministrativa.
Tre mosse per non restare sotto shock
La risposta non è solo legale: è organizzativa. Per costruttori, datori di lavoro che gestiscono parchi di dispositivi connessi e manutentori che operano su apparecchiature di terzi, il margine per prepararsi esiste ancora — ma si misura in settimane. Ecco tre azioni concrete che discendono direttamente dai requisiti del regolamento.
La mappatura dei prodotti con elementi digitali. Ogni organizzazione deve sapere esattamente quali dispositivi, firmware e componenti software ricadono nell’ambito del CRA. Non è un esercizio banale: un sensore di temperatura con modulo Wi-Fi, un quadro elettrico con interfaccia di telecontrollo, un’apparecchiatura medicale che dialoga con un server cloud sono tutti «prodotti con elementi digitali». La mappatura serve a due scopi: identificare chi, all’interno dell’organizzazione o della catena di fornitura, ha la responsabilità di notifica verso ENISA, e predisporre i canali interni di escalation. Senza questa anagrafe, il rischio è che la presa di coscienza avvenga — per riprendere l’esempio iniziale — da un tecnico che legge GitHub la sera, senza sapere a chi inoltrare la segnalazione entro le 24 ore.
Il processo di vulnerability disclosure. Il CRA impone una procedura strutturata: ricezione della segnalazione, verifica dello sfruttamento attivo, compilazione dell’early warning sulla SRP, analisi tecnica per la notifica completa, emissione della relazione finale. Ogni passaggio ha una scadenza. Le aziende che già operano sotto regimi analoghi — per esempio, le quotate statunitensi soggette agli obblighi SEC sulla disclosure degli incidenti — hanno un vantaggio procedurale, ma devono adattare i flussi al formato e alla tempistica CRA, che sono più stringenti. Chi parte da zero deve costruire il processo in fretta: nominare un responsabile, formare il personale tecnico, simulare almeno un’esercitazione di notifica sulla piattaforma SRP non appena sarà disponibile in fase di test.
Il piano di risposta che include la comunicazione al consumatore. L’obbligo di emettere comunicazioni separate rivolte ai consumatori, quando sussiste un potenziale danno, trasforma la risposta tecnica in un atto di responsabilità verso il mercato. Per il costruttore significa predisporre modelli di notifica, canali di distribuzione (portali di supporto, e-mail certificate, avvisi in-app) e criteri decisionali per stabilire quando il danno potenziale è tale da far scattare l’obbligo. Per il datore di lavoro che utilizza dispositivi connessi nei propri processi, significa coordinarsi con il fornitore per non subire passivamente la comunicazione. Per il manutentore, significa integrare nel contratto di servizio clausole che definiscano chi, tra committente e manutentore, ha l’onere di notifica verso ENISA e verso gli utenti finali.
