Cyber Resilience Act: dall’11 settembre scattano le segnalazioni obbligatorie

Una scadenza già operativa, non un obbligo futuro

Dall’11 settembre 2026 sono applicabili i primi obblighi operativi del Cyber Resilience Act, il regolamento europeo sulla sicurezza dei prodotti con elementi digitali. Le prescrizioni principali del regolamento diventeranno pienamente applicabili l’11 dicembre 2027, ma le segnalazioni di alcune vulnerabilità e di determinati incidenti gravi sono già entrate in vigore.

Questo passaggio riguarda il modo in cui i produttori reagiscono quando scoprono un problema serio in un prodotto digitale. Non basta prevedere una correzione tecnica: servono responsabilità definite, tempi misurabili, informazioni verificabili e un canale di segnalazione pronto prima dell’emergenza.

• Entrata in vigore del regolamento: 10 dicembre 2024.
• Obblighi di segnalazione applicabili: 11 settembre 2026.
• Applicazione generale delle prescrizioni principali: 11 dicembre 2027.
• Piattaforma unica di segnalazione ENISA operativa dall’11 settembre 2026.

Chi deve prepararsi

Il CRA riguarda i prodotti con elementi digitali messi a disposizione sul mercato dell’Unione: software, hardware, dispositivi connessi e componenti venduti separatamente. Per produttore si intende, in sintesi, chi sviluppa o fa sviluppare un prodotto e lo commercializza con il proprio nome o marchio, anche quando il prodotto è offerto gratuitamente nell’ambito di un’attività commerciale.

Non ogni consulente informatico, scuola o impresa che utilizza un software diventa automaticamente il soggetto obbligato alla segnalazione. La domanda decisiva è quale ruolo si ricopre nella catena: produttore, importatore, distributore oppure semplice utilizzatore. Una PMI che sviluppa e distribuisce una propria applicazione o un dispositivo connesso deve quindi verificare con attenzione la propria posizione; una scuola che usa un prodotto di terzi deve soprattutto conoscere i canali del fornitore e le procedure interne di risposta.

• Software distribuito con il proprio marchio.
• Dispositivi IoT e apparati connessi.
• Componenti hardware o software commercializzati separatamente.
• Prodotti già immessi sul mercato che continuano a essere interessati dagli obblighi previsti dal regolamento.

Che cosa va segnalato

La segnalazione riguarda due categorie essenziali: le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza del prodotto. Una vulnerabilità soltanto teorica o un normale errore applicativo non diventano automaticamente un caso da notificare: occorre una valutazione tecnica documentata che distingua gravità, sfruttamento reale, impatto sul prodotto e conseguenze per gli utenti.

Per evitare decisioni improvvisate, il team deve raccogliere evidenze, data e ora della prima conoscenza, versioni coinvolte, indicatori di compromissione, possibili contromisure e stato della correzione. La classificazione non dovrebbe dipendere da una sola persona irreperibile: ruoli e sostituzioni vanno stabiliti in anticipo.

• Vulnerabilità attivamente sfruttata: esistono elementi che indicano uno sfruttamento malevolo reale.
• Incidente grave: l’evento compromette la sicurezza del prodotto con un impatto rilevante.
• Ogni valutazione deve essere tracciata, anche quando si conclude che la segnalazione non è dovuta.
• La correzione tecnica e la comunicazione agli utenti devono procedere insieme alla gestione normativa.

Le finestre temporali: 24 ore, 72 ore e relazione finale

Il tempo decorre da quando il produttore viene a conoscenza dell’evento. Per una vulnerabilità attivamente sfruttata è prevista una prima segnalazione entro 24 ore, seguita da una notifica completa entro 72 ore. La relazione finale deve arrivare entro 14 giorni dalla disponibilità di una misura correttiva o di mitigazione.

Anche per un incidente grave che incide sulla sicurezza del prodotto sono previste una segnalazione iniziale entro 24 ore e una notifica entro 72 ore. La relazione finale va presentata entro un mese dalla notifica delle 72 ore. Le scadenze rendono indispensabile registrare con precisione quando l’organizzazione ha acquisito consapevolezza dell’evento.

• Entro 24 ore: avviso iniziale.
• Entro 72 ore: notifica con le informazioni disponibili e una prima valutazione.
• Vulnerabilità sfruttata: relazione finale entro 14 giorni dalla disponibilità della correzione o mitigazione.
• Incidente grave: relazione finale entro un mese dalla notifica delle 72 ore.

Un solo canale: la piattaforma ENISA

La segnalazione viene presentata una sola volta attraverso la Single Reporting Platform predisposta da ENISA. Il flusso coinvolge il CSIRT competente nello Stato membro in cui il produttore ha il proprio stabilimento principale e l’Agenzia europea per la cybersicurezza.

La piattaforma non sostituisce il lavoro interno di analisi. Prima di usarla bisogna sapere chi è autorizzato a inviare, quali dati può comunicare, chi approva il contenuto e come conservare ricevute e aggiornamenti. La procedura deve inoltre coordinarsi con altri eventuali obblighi applicabili, senza duplicare o contraddire le informazioni.

• Registrare in anticipo i referenti autorizzati.
• Conservare le prove dell’invio e le successive integrazioni.
• Proteggere le informazioni tecniche sensibili durante raccolta e trasmissione.
• Mantenere allineati team tecnico, direzione, legale e comunicazione.

Checklist operativa per PMI e team di sviluppo

La conformità diventa gestibile se viene trasformata in un processo breve e provato. Una procedura di due pagine, con contatti reali e criteri verificabili, è più utile di un documento molto lungo che nessuno consulta durante un incidente.

• Creare l’inventario dei prodotti, delle versioni supportate e dei componenti di terze parti.
• Assegnare un responsabile per la sicurezza del prodotto e almeno un sostituto.
• Attivare un indirizzo per la segnalazione delle vulnerabilità e definirne il monitoraggio.
• Stabilire criteri di triage per sfruttamento attivo, gravità, impatto e utenti coinvolti.
• Preparare una scheda evento con orari, evidenze, decisioni, mitigazioni e versioni interessate.
• Provare il flusso con un’esercitazione: scoperta, valutazione, approvazione e invio entro le finestre previste.
• Collegare la segnalazione al processo di aggiornamento e all’avviso destinato agli utenti.

Che cosa possono chiedere scuole e imprese ai fornitori

Chi acquista tecnologia non è un osservatore passivo. Nella scelta di piattaforme, gestionali, apparati di rete e dispositivi didattici conviene chiedere per quanto tempo saranno forniti aggiornamenti, come vengono comunicate le vulnerabilità, quale canale usare durante un incidente e chi assume le diverse responsabilità.

Queste domande migliorano gli acquisti anche quando il soggetto utilizzatore non è il responsabile diretto della segnalazione CRA. Un prodotto economico ma privo di una politica di aggiornamento, di un contatto di sicurezza o di tempi di risposta dichiarati può generare costi e rischi molto superiori al risparmio iniziale.

• Durata del supporto e politica degli aggiornamenti di sicurezza.
• Canale pubblico per segnalare vulnerabilità.
• Tempi e modalità di comunicazione degli incidenti ai clienti.
• Elenco dei componenti critici e gestione delle dipendenze.
• Responsabilità contrattuali in caso di vulnerabilità o prodotto non più supportato.

Prepararsi adesso significa reagire meglio

Il nuovo obbligo non si risolve compilando un modulo all’ultimo minuto. Richiede visibilità sui prodotti, capacità di distinguere un’anomalia da un evento segnalabile e una catena decisionale che funzioni anche sotto pressione. È un esercizio di sicurezza operativa prima ancora che di conformità.

Se la tua impresa sviluppa software o dispositivi, oppure la tua scuola deve valutare fornitori e procedure di risposta, posso aiutarti a costruire inventario, checklist, responsabilità e simulazioni operative proporzionate alla realtà dell’organizzazione. Contattami per trasformare il regolamento in un processo comprensibile e verificabile.