Il Cyber Resilience Act si applica per intero dall’11 dicembre 2027, ma non tutto aspetta quella data. Dall’11 settembre 2026, cioè fra sei settimane, i fabbricanti di prodotti con elementi digitali dovranno notificare le vulnerabilità attivamente sfruttate e gli incidenti gravi entro 24 ore dal momento in cui ne vengono a conoscenza, attraverso una piattaforma unica gestita dall’ENISA. Il 27 luglio la Commissione europea ha pubblicato gli orientamenti su come applicare il regolamento e, lo stesso giorno, l’ENISA ha aggiornato le proprie risposte sulla piattaforma. L’obbligo ha una data fissa; gli strumenti per adempierlo stanno arrivando adesso.
Che cosa si applica l’11 settembre, e che cosa no
L’articolo 71 del regolamento (UE) 2024/2847 fissa tre date, non una. Il regolamento si applica dall’11 dicembre 2027; il capo IV, cioè gli articoli da 35 a 51 sulla 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. L’11 settembre, quindi, non diventano esigibili i requisiti essenziali di cibersicurezza dell’allegato I, né la valutazione della conformità, né la marcatura CE: diventa esigibile soltanto l’obbligo di segnalare.
La sequenza ha una conseguenza che conviene mettere a verbale. L’articolo 64 fissa il massimale per la violazione dell’articolo 14, cioè sanzioni amministrative pecuniarie fino a 15 milioni di euro o, se l’autore è un’impresa, fino al 2,5 per cento del fatturato mondiale totale annuo dell’esercizio precedente se superiore. Quell’articolo, però, si applica insieme al resto del regolamento dall’11 dicembre 2027. L’obbligo di segnalare precede di quindici mesi il regime sanzionatorio che lo assiste e precede anche la vigilanza del mercato, ma resta un obbligo giuridico pieno, con un termine di 24 ore.
Le due cose da segnalare, e i tre tempi
L’articolo 14 individua due fatti generatori. Il primo è la vulnerabilità attivamente sfruttata contenuta nel prodotto, di cui il fabbricante venga a conoscenza. Il secondo è l’incidente grave che abbia un impatto sulla sicurezza del prodotto. In entrambi i casi la notifica va trasmessa simultaneamente al CSIRT designato come coordinatore e all’ENISA, attraverso la piattaforma unica istituita dall’articolo 16.
Per le vulnerabilità i tempi sono tre. Una notifica di preallarme senza indebito ritardo e comunque entro 24 ore dalla conoscenza, che indichi, se del caso, gli Stati membri nel cui territorio il prodotto è stato messo a disposizione. Una notifica delle vulnerabilità entro 72 ore, con le informazioni generali sul prodotto interessato, sulla natura dello sfruttamento e della vulnerabilità, sulle misure correttive o di attenuazione adottate e su quelle che gli utilizzatori possono adottare, oltre al grado di sensibilità che il fabbricante attribuisce alle informazioni notificate. Una relazione finale entro 14 giorni dalla messa a disposizione di una misura correttiva o di attenuazione, con la descrizione della vulnerabilità, la sua gravità e il suo impatto, le informazioni disponibili sul soggetto malintenzionato e i dettagli dell’aggiornamento di sicurezza. Per gli incidenti gravi lo schema è lo stesso, con due differenze: il preallarme entro 24 ore deve precisare come minimo se si sospetta che l’incidente derivi da atti illeciti o dolosi, e la relazione finale è dovuta entro un mese dalla notifica delle 72 ore.
Che cosa sia un incidente grave lo dice il paragrafo 5, e la definizione è larga: lo è l’incidente che incide negativamente, o è in grado di incidere negativamente, sulla capacità del prodotto di proteggere la disponibilità, l’autenticità, l’integrità o la riservatezza di dati o funzioni sensibili o importanti, oppure che ha portato o è in grado di portare all’introduzione o all’esecuzione di un codice maligno nel prodotto o nei sistemi informativi e di rete di un utilizzatore. Il paragrafo 8 aggiunge un secondo destinatario: dal momento in cui viene a conoscenza del fatto, il fabbricante informa anche gli utilizzatori interessati e, se del caso, tutti gli utilizzatori, se necessario in un formato strutturato e leggibile da un dispositivo automatico. Se non lo fa tempestivamente, possono farlo i CSIRT che hanno ricevuto la notifica.
L’obbligo copre anche ciò che è già sul mercato
Il punto meno visibile sta nelle disposizioni transitorie. L’articolo 69, paragrafo 2, stabilisce che i prodotti immessi sul mercato prima dell’11 dicembre 2027 sono soggetti ai requisiti del regolamento solo se, a decorrere da quella data, subiscono una modifica sostanziale. Il paragrafo 3 introduce però una deroga espressa: gli obblighi dell’articolo 14 si applicano a tutti i prodotti con elementi digitali che rientrano nell’ambito di applicazione del regolamento e che sono stati immessi sul mercato prima dell’11 dicembre 2027. Il perimetro della segnalazione non è quindi il catalogo futuro, ma il parco installato, compreso ciò che è stato venduto anni fa e che il fabbricante continua a supportare.
Alla stessa logica risponde l’estensione soggettiva: l’ENISA ricorda che agli obblighi di segnalazione sono soggetti anche i gestori di software libero e open source, nella misura in cui siano coinvolti nei prodotti. Per chi ha un catalogo lungo e una storia lunga, il primo adempimento non è tecnico ma inventariale, cioè sapere quali prodotti ancora supportati ricadono nell’ambito di applicazione e chi risponde per ciascuno.
Il canale è uno solo, e non ha ancora un indirizzo
L’articolo 16 affida all’ENISA l’istituzione della piattaforma unica di segnalazione e la gestione delle sue operazioni quotidiane, con un’architettura che consente agli Stati membri e all’Agenzia di predisporre i propri terminali per la notifica elettronica. L’articolo 14, paragrafo 7, precisa che la notifica si trasmette dal terminale del CSIRT designato come coordinatore dello Stato membro in cui il fabbricante ha lo stabilimento principale nell’Unione, contemporaneamente all’ENISA. Non sono previsti canali alternativi: la piattaforma è il modo in cui l’obbligo si adempie.
Nelle risposte aggiornate il 27 luglio l’ENISA scrive che la piattaforma è programmata per essere operativa entro l’11 settembre 2026 e che è previsto un periodo di prova prima di quella data. L’indirizzo pubblico non è ancora noto e sarà comunicato sulla stessa pagina prima dell’avvio. L’accesso richiederà un account EU Login, che può essere creato fin da ora; la verifica che una persona possa segnalare per conto di un determinato fabbricante sarà svolta dal CSIRT coordinatore dopo il primo accesso, in parallelo alla segnalazione e senza impedirla. Per non congestionare i CSIRT, l’ENISA suggerisce di registrarsi e avviare la verifica solo quando si deve effettivamente trasmettere una notifica.
Manca invece l’atto di esecuzione che l’articolo 14, paragrafo 10, consente alla Commissione di adottare per specificare formato e procedure di trasmissione: al 31 luglio 2026 non risulta adottato. L’unico atto di secondo livello pubblicato è il regolamento delegato (UE) 2026/881, in vigore dal 10 maggio 2026, che fissa termini e condizioni dei motivi connessi alla cibersicurezza per i quali un CSIRT può ritardare la diffusione di una notifica agli altri CSIRT.
Gli orientamenti della Commissione, e il loro peso
Gli orientamenti pubblicati il 27 luglio sono la comunicazione C(2026) 5252 e il suo allegato. Chiariscono quando certi prodotti rientrano nell’ambito di applicazione, comprese le soluzioni di elaborazione dati da remoto e il software libero e open source; che cosa costituisce una modifica sostanziale; come vanno intesi e applicati i periodi di assistenza; come si adempie agli obblighi di segnalazione e ai requisiti di valutazione del rischio. Sono esattamente i quattro aspetti che l’articolo 26 impone alla Commissione di affrontare quando pubblica orientamenti, con particolare attenzione alle microimprese e alle piccole e medie imprese. Il documento contiene 67 esempi pratici, casi d’uso e diagrammi di flusso, e l’ENISA segnala che il punto 9.1 spiega in dettaglio gli obblighi di segnalazione dei fabbricanti e dei gestori di software libero e open source.
La Commissione qualifica espressamente gli orientamenti come non vincolanti e annuncia che, in linea con l’articolo 26, valuterà di adottarne altri. È una precisazione che pesa: gli orientamenti riducono l’incertezza interpretativa, non spostano una data e non sostituiscono il testo. Vale la pena leggerli accanto al modello di autovalutazione che l’ENISA ha pubblicato il 13 luglio per le piccole e medie imprese, perché il destinatario dichiarato è lo stesso.
Sei settimane, e che cosa si può fare adesso
Le date non si muovono e gli orientamenti non le muovono. Quello che un fabbricante può fare da qui all’11 settembre non dipende dall’apertura della piattaforma: individuare quale CSIRT coordinatore è competente in base allo stabilimento principale nell’Unione, predisporre le credenziali EU Login, censire i prodotti ancora supportati che ricadono nell’ambito di applicazione, compresi quelli immessi sul mercato anni fa. Soprattutto, stabilire chi, dentro l’organizzazione, ha il potere di qualificare un fatto come vulnerabilità attivamente sfruttata o come incidente grave e di far partire la notifica. Le 24 ore decorrono dalla conoscenza, non dalla correzione, e prima di essere un problema tecnico questa è una questione di catena decisionale, dello stesso tipo di quella che il quadro europeo sta spostando verso i vertici aziendali. Il calendario del Cyber Resilience Act, del resto, è l’immagine speculare di quello dell’AI Act, dove lo strumento tecnico è arrivato prima della scadenza: qui è l’obbligo ad arrivare per primo.
