Cyber Resilience Act: dall’11 settembre cambiano le segnalazioni. Cosa devono preparare le PMI.

Perché l’11 settembre 2026 è una data concreta

Il Cyber Resilience Act è il Regolamento (UE) 2024/2847 e introduce requisiti orizzontali di cybersicurezza per i prodotti con elementi digitali commercializzati nell’Unione europea. La maggior parte degli obblighi si applicherà dall’11 dicembre 2027, ma il calendario prevede un passaggio anticipato: dall’11 settembre 2026 diventano operative le segnalazioni previste dall’articolo 14.

Non è quindi corretto rimandare ogni attività al 2027. Se un prodotto già presente sul mercato rientra nel perimetro e il fabbricante viene a conoscenza di una vulnerabilità attivamente sfruttata o di un incidente grave, il tempo utile per la prima comunicazione sarà misurato in ore, non in settimane.

La Commissione europea ha pubblicato a luglio 2026 una guida pratica sull’applicazione del regolamento. Nello stesso periodo ENISA ha reso disponibile un modello di maturità e uno strumento di autovalutazione pensati in particolare per micro, piccole e medie imprese. La combinazione tra scadenza, indicazioni operative e strumenti ufficiali rende questa una priorità concreta, non un tema da osservare a distanza.

Prima domanda: la tua impresa è davvero nel perimetro?

Il CRA riguarda prodotti con elementi digitali messi a disposizione sul mercato europeo. La definizione comprende prodotti software o hardware e le soluzioni di elaborazione dati da remoto senza le quali il prodotto non potrebbe svolgere una delle sue funzioni. Il collegamento ai dati può essere diretto o indiretto, logico o fisico.

Per una PMI il punto non è chiedersi genericamente se utilizza computer. È capire se sviluppa, fa sviluppare e commercializza con il proprio nome o marchio un prodotto digitale; se importa o distribuisce prodotti interessati; oppure se modifica un prodotto in modo tale da assumere responsabilità diverse. Un software venduto o concesso in licenza come prodotto, una piattaforma collegata a un dispositivo e un apparato connesso sono casi da esaminare. Un normale sito vetrina realizzato come servizio non entra automaticamente nello stesso perimetro.

Ruolo contrattuale, modalità di commercializzazione, licenza, marchio e dipendenze tecniche cambiano la valutazione. Per questo una checklist tecnica non sostituisce l’analisi legale. L’impresa dovrebbe prima descrivere prodotto e filiera con precisione, poi far verificare l’inquadramento quando esistono dubbi.

• Elencare software, dispositivi e servizi digitali offerti ai clienti.
• Indicare per ciascuno chi lo progetta, chi lo commercializza e con quale marchio.
• Distinguere prodotto, componente, servizio accessorio e sviluppo su commessa.
• Mappare importatori, distributori, fornitori critici e componenti open source.
• Documentare i casi dubbi e sottoporli a una valutazione professionale.

Che cosa deve essere segnalato, e che cosa no

Il regolamento non trasforma ogni difetto software in una segnalazione urgente. La prima categoria riguarda una vulnerabilità attivamente sfruttata: in sintesi, una debolezza per la quale esistono prove affidabili che un soggetto l’abbia utilizzata in un sistema senza il consenso del proprietario. La seconda riguarda incidenti gravi che incidono sulla sicurezza del prodotto con elementi digitali.

La distinzione richiede un processo di triage. Una vulnerabilità scoperta durante un test interno, senza indizi di sfruttamento, deve comunque essere gestita e corretta, ma non coincide automaticamente con il caso di segnalazione anticipata. Allo stesso modo un’interruzione operativa non è, da sola, un incidente di sicurezza grave. Contano causa, impatto, compromissione e criteri del regolamento.

La decisione non può dipendere dalla persona che casualmente legge una mail tecnica. Servono un canale riconoscibile per ricevere segnalazioni, criteri di escalation, una persona responsabile e accesso rapido alle informazioni sul prodotto. Se l’impresa non sa chi decide, le prime ore vengono consumate a ricostruire il contesto.

24 ore, 72 ore e relazione finale: il tempo parte dalla consapevolezza

La procedura europea prevede una segnalazione unica attraverso la piattaforma predisposta per il CRA, destinata al CSIRT competente e a ENISA. Per una vulnerabilità attivamente sfruttata, il fabbricante deve trasmettere un allarme iniziale senza indebito ritardo e comunque entro 24 ore dal momento in cui ne viene a conoscenza. Entro 72 ore segue una notifica più completa, salvo che le informazioni rilevanti siano già state fornite.

La relazione finale sulla vulnerabilità va presentata entro 14 giorni da quando una misura correttiva o di mitigazione è disponibile. Per un incidente grave, dopo l’allarme iniziale e la notifica, la relazione finale è prevista entro un mese dalla notifica dell’incidente. I dettagli e le eventuali eccezioni devono essere letti nella documentazione ufficiale e nel caso concreto.

Il passaggio più importante è organizzativo: il conteggio non aspetta la riunione del lunedì. L’impresa deve sapere quando una segnalazione ricevuta diventa conoscenza rilevante, chi avvia l’orologio, chi raccoglie le prove e chi autorizza la comunicazione. Registrare orari, fonti e decisioni protegge la qualità del processo e rende ricostruibili le azioni compiute.

Un piano realistico nei trenta giorni prima della scadenza

Una PMI non deve costruire in un mese un centro operativo di sicurezza. Deve eliminare le ambiguità che rallentano una risposta. Il primo passo è assegnare un responsabile e un sostituto, quindi collegare prodotti, versioni, clienti interessati, fornitori e contatti tecnici in un inventario utilizzabile.

Nella seconda settimana si definisce il canale di ingresso: casella dedicata, modulo o procedura per supporto e fornitori. Ogni segnalazione deve ricevere un identificativo, un orario, una prima classificazione e un proprietario. Nella terza settimana si prepara un modello di valutazione con le informazioni minime richieste e si prova il flusso su un caso simulato.

L’ultima settimana serve a chiudere ciò che la simulazione ha reso visibile: contatti mancanti, accessi non disponibili, dipendenze sconosciute, criteri contraddittori o approvazioni troppo lente. L’obiettivo non è produrre un documento elegante, ma riuscire a prendere una decisione motivata anche fuori dall’orario ideale.

• Giorni 1–7: ruoli, prodotti, versioni, clienti e filiera.
• Giorni 8–14: canale di ricezione, registro e criteri di escalation.
• Giorni 15–21: simulazione di vulnerabilità attivamente sfruttata.
• Giorni 22–30: correzione dei vuoti e approvazione della procedura.
• Dopo la scadenza: riesame periodico e aggiornamento dell’inventario.

Senza inventario e fornitori coinvolti, la risposta resta incompleta

Il prodotto digitale raramente è un blocco isolato. Librerie open source, servizi cloud, firmware, API, moduli commerciali e componenti hardware possono contribuire alla vulnerabilità. Sapere che cosa è incluso in ogni versione permette di capire più velocemente quali prodotti e clienti sono interessati.

Un inventario utile collega componente, versione, prodotto, responsabile e fornitore. Dove appropriato, una distinta base software può rendere più rapida l’analisi, ma non sostituisce la conoscenza delle dipendenze operative. Anche le condizioni contrattuali dovrebbero indicare come i partner comunicano vulnerabilità, aggiornamenti e incidenti.

Le PMI che lavorano come integratori o fornitori di servizi, pur non essendo sempre il fabbricante responsabile, possono diventare una fonte essenziale di informazioni. Concordare prima destinatari, urgenze e dati minimi evita che una segnalazione critica rimanga in una casella commerciale o venga trattata come un ticket ordinario.

Come usare il nuovo strumento ENISA senza confonderlo con una certificazione

Il modello di maturità pubblicato da ENISA nel luglio 2026 offre a micro, piccole e medie imprese un percorso strutturato per valutare la propria resilienza in relazione al CRA. È accompagnato da uno strumento Excel di autovalutazione e considera organizzazione, gestione del rischio, ciclo di vita del prodotto e capacità di risposta.

È utile come punto di partenza e come linguaggio comune tra direzione, tecnici e fornitori. Può evidenziare aree non presidiate e aiutare a dare priorità agli interventi. ENISA chiarisce però che un livello di maturità elevato non costituisce prova di conformità al regolamento.

Il modo corretto di usarlo è conservare le risposte, collegarle a evidenze reali e trasformare i risultati in responsabilità e scadenze. Compilare il foglio senza verificare backup, accessi, procedure e versioni produce una fotografia rassicurante ma poco utile durante un incidente.

La scadenza è il primo test di una gestione continua

Il CRA porta la sicurezza dentro il ciclo di vita del prodotto. Questo significa progettazione, aggiornamenti, gestione delle vulnerabilità, documentazione e comunicazione dopo la vendita. La segnalazione di settembre è solo la prima parte applicabile di un cambiamento più ampio.

Per una PMI la strada sostenibile è integrare queste attività nel lavoro esistente: revisione delle dipendenze nelle release, contatti di sicurezza nei contratti, inventario aggiornato, monitoraggio delle segnalazioni e simulazioni brevi. Ogni controllo deve avere un proprietario e una frequenza, altrimenti torna a essere un’intenzione.

La visual editoriale di questo articolo è stata realizzata con il supporto di strumenti di intelligenza artificiale generativa, senza loghi o materiali di terzi, e rifinita nella palette Scenicom. Anche questo processo segue lo stesso principio: automazione utile, direzione umana e responsabilità riconoscibile sul risultato.