L’11 settembre 2026 non è la data in cui tutto il Cyber Resilience Act diventa applicabile. È però il giorno in cui entra in funzione una parte molto concreta del regolamento: l’obbligo di segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza dei prodotti con elementi digitali.
La distinzione conta. Gli obblighi principali del CRA si applicheranno dall’11 dicembre 2027, ma il reporting previsto dall’articolo 14 parte quindici mesi prima. La Commissione europea lo ha ribadito nelle indicazioni pubblicate il 27 luglio 2026, mentre ENISA ha messo online le informazioni operative sulla Single Reporting Platform. Per produttori software, imprese che incorporano componenti digitali nei propri prodotti e responsabili della sicurezza, la scadenza non richiede una nuova casella e-mail: richiede un processo capace di decidere in poche ore.
Prima domanda: l’impresa è davvero un produttore?
Il CRA riguarda i prodotti con elementi digitali messi a disposizione sul mercato dell’Unione: hardware, software e relative soluzioni di elaborazione remota quando rientrano nel perimetro del prodotto. Tuttavia, non ogni azienda che usa un software assume automaticamente il ruolo di produttore.
La verifica deve partire dal ruolo economico. Un’impresa che sviluppa e commercializza un’applicazione con il proprio nome o marchio è in una posizione diversa da chi acquista un gestionale standard per uso interno. Anche importatori, distributori e soggetti che modificano sostanzialmente un prodotto devono valutare le responsabilità previste dal regolamento. Per l’open source, il CRA disciplina inoltre gli open-source software steward, con obblighi specifici e proporzionati al loro coinvolgimento.
Questa mappa dei ruoli non è un esercizio legale separato dall’IT. Determina chi deve conoscere la vulnerabilità, chi può valutarne l’impatto, chi autorizza la comunicazione e quale CSIRT deve riceverla. Se il ruolo viene chiarito soltanto durante un incidente, le prime 24 ore rischiano di essere spese a cercare il proprietario del processo.
Cosa va segnalato, e cosa no
Il regolamento non chiede di trasmettere ogni bug o indisponibilità. Le due categorie obbligatorie sono più precise.
La prima comprende le vulnerabilità attivamente sfruttate: deve esserci una vulnerabilità nel prodotto e un’evidenza affidabile che un soggetto malevolo l’abbia sfruttata. La seconda riguarda gli incidenti gravi con impatto sulla sicurezza del prodotto, valutati rispetto a elementi come disponibilità, autenticità, integrità o riservatezza.
La pagina ufficiale della Commissione dedicata al reporting CRA sintetizza le tempistiche: un early warning entro 24 ore dalla conoscenza dell’evento e una notifica più completa entro 72 ore. Per una vulnerabilità attivamente sfruttata, il rapporto finale va presentato entro 14 giorni dalla disponibilità di una misura correttiva o di mitigazione; per un incidente grave, entro un mese dalla notifica delle 72 ore.
Il momento iniziale è quindi la “conoscenza”, non la conclusione di un’indagine forense perfetta. Nelle prime 24 ore l’organizzazione può non avere tutte le risposte, ma deve saper distinguere un segnale credibile da una segnalazione generica e raccogliere le informazioni minime disponibili senza ritardare ingiustificatamente.
Un solo ingresso, non un solo problema
La Single Reporting Platform gestita da ENISA diventa il punto elettronico unico per le notifiche CRA. Secondo le FAQ ENISA aggiornate il 3 agosto 2026, la piattaforma consente di inviare una sola segnalazione, indirizzata al CSIRT coordinatore competente e resa disponibile agli altri destinatari previsti dal regolamento.
Il vantaggio tecnico non elimina però il coordinamento aziendale. Un evento può toccare contemporaneamente sviluppo, assistenza clienti, sicurezza, legale, privacy, comunicazione e fornitori. Può inoltre attivare obblighi distinti previsti da NIS2, GDPR, DORA o da contratti con clienti e partner. “Una sola piattaforma” non significa che una sola persona possa gestire l’intero caso senza una matrice di responsabilità.
Serve quindi un percorso che separi almeno quattro decisioni: classificare l’evento, determinare il ruolo dell’impresa, rispettare il tempo CRA e verificare gli altri canali di notifica. Le informazioni possono sovrapporsi, ma destinatari, soglie e termini non sono intercambiabili.
La prova generale da fare prima dell’11 settembre
Un test da tavolo di novanta minuti può essere più utile di una procedura di trenta pagine mai utilizzata. Il caso simulato può partire da una segnalazione ricevuta dal supporto: un ricercatore comunica che una libreria inclusa nel prodotto è sfruttata attivamente e fornisce una prova tecnica iniziale.
Il gruppo di lavoro dovrebbe riuscire a rispondere a queste domande:
- quale prodotto, versione e componente sono interessati;
- chi certifica che l’impresa agisce come produttore o steward nel caso concreto;
- quali elementi rendono attendibile l’evidenza di sfruttamento;
- chi avvia il conteggio delle 24 e delle 72 ore e dove viene registrato;
- quali misure possono adottare subito gli utilizzatori;
- chi approva la notifica e chi mantiene i rapporti successivi;
- quali informazioni sono sensibili e come vengono condivise in modo controllato.
Il test deve includere almeno un’assenza: il responsabile prodotto non è disponibile, il fornitore non risponde o il registro delle versioni non è aggiornato. È proprio in queste discontinuità che emerge la differenza tra un processo e una lista di nomi.
L’inventario diventa uno strumento di risposta
Per rispettare i tempi non basta sapere che una vulnerabilità esiste. Occorre capire in quali prodotti è presente, quali versioni sono sul mercato, dove sono distribuite e quali clienti o canali devono ricevere una misura di mitigazione.
Un inventario dei componenti, eventualmente supportato da una software bill of materials, è utile solo se collegato alla configurazione realmente rilasciata. Devono essere tracciati proprietario, versione, dipendenze critiche, periodo di supporto e percorso di aggiornamento. Anche il registro delle decisioni è essenziale: perché l’evento è stato classificato come notificabile, quali dati erano disponibili e quali verifiche restavano aperte.
Questo non trasforma il CRA in un progetto documentale. Al contrario, porta la conformità dentro il ciclo di sviluppo, la gestione delle vulnerabilità e il servizio post-vendita. La qualità dell’evidenza riduce sia il rischio di sottovalutare un evento sia quello di produrre comunicazioni incoerenti sotto pressione.
Una checklist essenziale per le prossime settimane
Prima dell’avvio del reporting obbligatorio, produttori e steward dovrebbero completare almeno cinque attività:
- confermare ruoli e prodotti nel perimetro, senza estendere automaticamente l’obbligo a ogni utilizzatore di tecnologia;
- registrare gli utenti autorizzati e provare l’accesso alla piattaforma ENISA;
- definire un canale interno unico per vulnerabilità e incidenti di prodotto;
- collegare inventario, versioni rilasciate, contatti dei fornitori e procedure di aggiornamento;
- simulare early warning, notifica delle 72 ore e rapporto finale, conservando le evidenze del test.
Il testo ufficiale dell’articolo 14 del Regolamento (UE) 2024/2847 resta il riferimento giuridico; le indicazioni della Commissione e le FAQ ENISA aiutano a tradurlo in operatività. Le linee guida della Commissione sono di supporto e non sostituiscono il regolamento né una valutazione del caso concreto.
L’11 settembre non anticipa ogni requisito del Cyber Resilience Act. Anticipa però qualcosa di decisivo: la capacità di accorgersi, qualificare e comunicare un problema mentre è ancora in corso. Chi aspetta il 2027 per organizzare questo processo scoprirà troppo tardi che il primo adempimento era già una prova di maturità operativa.
Nota di trasparenza: questo articolo e le immagini collegate sono stati realizzati in parte con l’utilizzo dell’intelligenza artificiale, con supervisione e responsabilità editoriale umana.