Se vendiamo un plugin per WordPress o WooCommerce, un’applicazione, un programma o un dispositivo connesso, una vulnerabilità di sicurezza non è più soltanto un problema tecnico da correggere il prima possibile. Dall’11 settembre 2026 entra infatti in applicazione l’articolo 14 del Cyber Resilience Act, Regolamento UE 2024/2847, che introduce obblighi precisi di segnalazione per i fabbricanti di prodotti con elementi digitali. Addirittura In determinati casi avremo appena 24 ore dal momento in cui veniamo a conoscenza del problema per effettuare una prima segnalazione.
Questo non significa che ogni errore trovato in un programma debba essere comunicato alle autorità entro un giorno. L’obbligo riguarda situazioni più precise: le vulnerabilità attivamente sfruttate e gli incidenti gravi che hanno un impatto sulla sicurezza del prodotto.
Il problema, soprattutto per le piccole imprese, è un altro: capire di rientrare nella normativa soltanto quando qualcosa è già successo. Ed è esattamente ciò che conviene evitare.
Il rischio concreto: scoprire troppo tardi di essere considerati fabbricanti
Quando sentiamo parlare di “fabbricanti di prodotti con elementi digitali”, è facile pensare immediatamente a grandi aziende che producono dispositivi elettronici, router, sistemi industriali o apparecchi per la casa connessa. Nella realtà del Cyber Resilience Act ha però una definizione molto più ampia. Per il regolamento, un prodotto con elementi digitali può essere hardware oppure software. Anche un componente software venduto separatamente può quindi rientrare nel suo campo di applicazione.
Ancora più importante è la definizione di fabbricante. Non è fabbricante soltanto chi scrive materialmente il codice o costruisce fisicamente il prodotto. Il regolamento comprende anche chi fa progettare, sviluppare o fabbricare un prodotto e successivamente lo commercializza con il proprio nome o marchio. Quindi, tradotto in una situazione molto più vicina alle piccole aziende italiane: possiamo commissionare a uno sviluppatore esterno la realizzazione completa di un plugin, di un’applicazione o del software integrato in un dispositivo e continuare comunque ad avere gli obblighi del fabbricante se quel prodotto viene immesso sul mercato con il nostro marchio.
Aver affidato lo sviluppo a un fornitore esterno non trasferisce automaticamente la responsabilità normativa su quel fornitore. Ed è qui che una questione apparentemente destinata alle multinazionali comincia a interessare anche imprese decisamente più piccole.
Plugin, temi, applicazioni e dispositivi connessi possono rientrare nel Cyber Resilience Act
Il CRA si applica ai prodotti con elementi digitali messi a disposizione sul mercato europeo quando il loro utilizzo prevede una connessione logica o fisica, diretta o indiretta, con un dispositivo o una rete. La definizione comprende espressamente sia prodotti hardware sia prodotti software e relativi componenti.
Un’estensione commerciale per WordPress o WooCommerce può quindi essere interessata dalla normativa. Lo stesso vale, a seconda delle caratteristiche concrete, per applicazioni, programmi installabili, componenti software e dispositivi connessi.
Non serve essere una grande azienda. Non serve nemmeno aver sviluppato internamente tutto il prodotto. La domanda corretta da porci è piuttosto: stiamo mettendo sul mercato europeo, sotto la nostra responsabilità o il nostro marchio, un prodotto software o hardware con elementi digitali? Se la risposta è sì, il CRA merita una verifica seria e non è il caso di procrastinarla a lungo.
Attenzione al SaaS: non tutti i servizi nel cloud rientrano automaticamente nel CRA
Qui è necessaria una distinzione importante. Un servizio SaaS, cioè un software utilizzato interamente tramite internet, non rientra automaticamente nel Cyber Resilience Act soltanto perché è software. Il regolamento distingue infatti i prodotti software dalle normali attività di elaborazione dati a distanza. Per far comprendere questa distinzione facciamo due esempi di casi opposti col classico “prodotto” SaaS, il Cloud.
Un servizio nel cloud può rientrare nel CRA quando costituisce una componente remota necessaria al funzionamento di un prodotto con elementi digitali e viene progettato o sviluppato dal fabbricante, o sotto la sua responsabilità. Un esempio indicato dallo stesso regolamento è quello di un dispositivo per la casa connessa che dipende da funzionalità nel cloud per essere controllato a distanza.
Un normale servizio nel cloud indipendente da un prodotto di questo tipo può invece ricadere fuori dal CRA ed essere eventualmente interessato da altre normative, come la NIS2 nei casi previsti. Per questo motivo, quando analizziamo un servizio SaaS dobbiamo verificare concretamente come funziona, come viene distribuito e quale rapporto esiste tra il servizio remoto e il prodotto software o hardware.
Cosa cambia esattamente dall’11 settembre 2026
Il Cyber Resilience Act sarà pienamente applicabile dall’11 dicembre 2027. Gli obblighi di segnalazione previsti dall’articolo 14 partono però molto prima: 11 settembre 2026.
Da quella data il fabbricante deve comunicare due categorie di eventi: una vulnerabilità attivamente sfruttata, cioè una vulnerabilità per la quale esistono prove affidabili che un soggetto malevolo l’abbia effettivamente sfruttata senza autorizzazione; oppure un incidente grave che abbia un impatto sulla sicurezza del prodotto, per esempio compromettendone o potendo comprometterne disponibilità, autenticità, integrità o riservatezza dei dati e delle funzioni.
Per capire la differenza in pratica: immaginiamo Gino Shop, un piccolo e-commerce che vende scarpe artigianali e distribuisce con il proprio marchio un plugin di configurazione taglie per WooCommerce, usato anche da altri negozi. Un ricercatore di sicurezza segnala una falla nel plugin e fornisce prove che qualcuno la sta già sfruttando per inserire codice malevolo nei siti che lo usano: questa è una vulnerabilità attivamente sfruttata, perché il difetto tecnico è individuato e c’è evidenza di uno sfruttamento malevolo già in corso.
L’Hotel Derry Town House, invece, ha fatto sviluppare con il proprio marchio un’app per il check-in automatico degli ospiti. Una notte l’app smette di funzionare per tutti gli utenti e, dalle prime verifiche, emerge che i dati di prenotazione di centinaia di clienti sono stati esposti: qui non c’è necessariamente una falla precisa già identificata e sfruttata in modo mirato, ma un evento con un impatto grave e concreto sulla disponibilità e sulla riservatezza dei dati del prodotto. Questo è un incidente grave, e l’obbligo di segnalazione scatta anche se non si è ancora capito con precisione come sia successo.
Questa distinzione è fondamentale. Trovare semplicemente un errore di sicurezza non significa automaticamente dover attivare la procedura obbligatoria delle 24 ore. Se un ricercatore ci comunica che esiste una vulnerabilità teoricamente sfruttabile, dobbiamo certamente valutarla e gestirla. L’obbligo specifico dell’articolo 14 relativo alla vulnerabilità attivamente sfruttata scatta però quando veniamo a conoscenza di elementi affidabili che dimostrano che quella vulnerabilità è già stata effettivamente utilizzata da un soggetto malevolo.
Le scadenze delle 24 e 72 ore
Quando veniamo a conoscenza di una vulnerabilità attivamente sfruttata, il tempo comincia a decorrere. Entro 24 ore deve essere inviata una prima segnalazione. Entro 72 ore deve seguire una notifica più completa, contenente le informazioni disponibili sul prodotto interessato, sulla vulnerabilità, sullo sfruttamento rilevato e sulle eventuali misure correttive o di mitigazione già adottate. Successivamente deve essere presentata una relazione finale.
Per una vulnerabilità attivamente sfruttata, la relazione finale deve essere trasmessa entro 14 giorni da quando è disponibile una misura correttiva o di mitigazione. Per un incidente grave il meccanismo iniziale è simile, con preallarme entro 24 ore e notifica entro 72 ore. La relazione finale deve però essere trasmessa entro un mese dalla notifica delle 72 ore.
La differenza non è un dettaglio da nota a piè di pagina. Serve a organizzare correttamente la procedura interna.
Dove si effettua la segnalazione
Le notifiche previste dal CRA devono passare attraverso la piattaforma unica di segnalazione gestita da ENISA, l’Agenzia dell’Unione europea per la cibersicurezza. La piattaforma diventa operativa dall’11 settembre 2026 insieme all’obbligo previsto dall’articolo 14. La comunicazione viene indirizzata al CSIRT coordinatore competente e resa contemporaneamente disponibile a ENISA.
ENISA ha inoltre chiarito che chi effettua materialmente le segnalazioni per conto del fabbricante deve utilizzare un account EU Login con autenticazione a più fattori (e ci mancherebbe).
Non è necessario correre a registrare preventivamente ogni azienda sulla piattaforma. ENISA consiglia di avviare la registrazione quando diventa necessario presentare una segnalazione. Possiamo però prepararci creando per tempo l’account EU Login e individuando già chi dovrà gestire un eventuale incidente.
Sono dettagli organizzativi apparentemente banali, fino al momento in cui abbiamo 24 ore a disposizione e nessuno sa chi possiede le credenziali.
Un esempio concreto: una vulnerabilità in un plugin WooCommerce
Immaginiamo una piccola società italiana che vende con il proprio marchio un plugin WooCommerce per collegare il negozio online a un sistema gestionale. Lo sviluppo del plugin è stato affidato a un programmatore esterno. Il prodotto, però, viene commercializzato dalla società con il proprio nome.
Alle 9:00 di lunedì mattina arriva una segnalazione da un ricercatore di sicurezza, che non segnala soltanto una possibile vulnerabilità: fornisce anche elementi attendibili che mostrano che la falla è stata sfruttata contro alcuni siti sui quali il plugin era installato. In una situazione del genere non possiamo limitarci a inoltrare l’email allo sviluppatore e aspettare che abbia tempo di controllarla. Il primo passaggio consiste nel verificare rapidamente l’attendibilità delle informazioni e stabilire se esistono prove affidabili di sfruttamento attivo.
Se confermiamo la situazione, da quel momento parte il conteggio. Entro le 9:00 di martedì deve essere effettuato il preallarme delle 24 ore tramite la piattaforma di ENISA. Entro le 9:00 di giovedì deve essere inviata la notifica delle 72 ore con le informazioni disponibili: prodotto e versioni interessate, natura della vulnerabilità, informazioni sullo sfruttamento, misure già adottate e indicazioni che gli utenti possono seguire per ridurre il rischio.
Nel frattempo lavoriamo con lo sviluppatore per produrre una versione corretta del plugin. Se l’aggiornamento di sicurezza viene reso disponibile mercoledì pomeriggio, da quel momento decorre il termine massimo di 14 giorni per la relazione finale sulla vulnerabilità.
Il regolamento prevede inoltre che il fabbricante informi gli utenti interessati e, quando opportuno, tutti gli utenti del prodotto, indicando le misure che possono adottare per ridurre il rischio.
L’esempio mostra bene perché il CRA non possa essere gestito soltanto quando arriva l’incidente. Se prima non abbiamo deciso chi riceve le segnalazioni, chi verifica la vulnerabilità, chi contatta lo sviluppatore, chi comunica con i clienti e chi effettua la notifica, 24 ore diventano pochissime.
Quanto si rischia con le sanzioni del Cyber Resilience Act
Le cifre previste dal regolamento sono elevate. La violazione degli obblighi degli articoli 13 e 14, oltre che dei requisiti essenziali di cibersicurezza, può comportare sanzioni amministrative pecuniarie fino a 15 milioni di euro oppure, nel caso di un’impresa, fino al 2,5% del fatturato mondiale totale annuo dell’esercizio precedente, se tale valore è superiore.
Ovviamente, questo non significa che una microimpresa che commette un errore riceverà automaticamente una multa da 15 milioni di euro. Siamo realisti. Il CRA stabilisce espressamente che nella determinazione della sanzione devono essere considerate le circostanze concrete, comprese natura, gravità e durata della violazione, conseguenze, eventuali precedenti e dimensioni dell’operatore, con particolare attenzione a microimprese, piccole e medie imprese e nuove imprese.
Esiste inoltre una tutela specifica per le imprese più piccole: per microimprese e piccole imprese le sanzioni amministrative pecuniarie non si applicano al solo mancato rispetto del termine iniziale delle 24 ore previsto per il preallarme di vulnerabilità o incidente.
È però importante non interpretare questa previsione come un’esenzione generale dal CRA. Le altre scadenze e gli altri obblighi rimangono.
Cosa dobbiamo preparare concretamente prima che si verifichi un problema
La priorità non dovrebbe essere produrre decine di pagine di documentazione che nessuno consulterà mai. Per una piccola realtà serve soprattutto una procedura semplice che funzioni davvero.
- Identifichiamo i prodotti che possono rientrare nel CRA. Verifichiamo plugin, applicazioni, componenti software, programmi e dispositivi commercializzati con il nostro marchio. Se lo sviluppo è stato affidato a terzi, controlliamo comunque quale soggetto assume il ruolo di fabbricante.
- Creiamo un punto di contatto per le vulnerabilità. Deve essere chiaro come un cliente, un ricercatore di sicurezza o un fornitore può comunicarci un problema. Una segnalazione importante non dovrebbe finire in una casella email controllata una volta alla settimana.
- Decidiamo chi valuta la segnalazione. Chi riceve il messaggio deve sapere immediatamente a chi inoltrarlo per verificare se si tratta di una normale vulnerabilità, di una vulnerabilità attivamente sfruttata o di un incidente grave.
- Registriamo con precisione quando siamo venuti a conoscenza dell’evento. Le scadenze delle 24 e 72 ore dipendono proprio da questo momento. Data, ora, fonte della segnalazione ed elementi disponibili devono essere documentati.
- Prepariamo l’accesso alla piattaforma di ENISA. Individuiamo chi sarà autorizzato a effettuare la segnalazione e predisponiamo un account EU Login protetto con autenticazione a più fattori.
- Definiamo già la comunicazione agli utenti. Dobbiamo sapere come contattare rapidamente chi utilizza il prodotto e come distribuire indicazioni di mitigazione o aggiornamenti di sicurezza.
- Rivediamo i rapporti con gli sviluppatori esterni. Se un plugin o un’applicazione viene sviluppato per noi da un fornitore, dobbiamo essere certi che una vulnerabilità critica venga comunicata immediatamente e non al termine del normale ciclo di assistenza.
La sicurezza del prodotto non può dipendere dalla speranza che qualcuno controlli casualmente una casella di posta al momento giusto. Sarebbe un grosso rischio.
L’11 settembre 2026 è solo il primo passaggio
Gli obblighi di segnalazione dell’articolo 14 rappresentano una delle prime parti del Cyber Resilience Act a diventare applicabili. Il regolamento entrerà pienamente in applicazione l’11 dicembre 2027. Da quel momento entreranno pienamente in gioco anche i requisiti essenziali di sicurezza del prodotto, la gestione delle vulnerabilità durante il periodo di supporto, la documentazione tecnica, le procedure di conformità e gli altri obblighi previsti per i fabbricanti.
Preparare oggi una procedura per ricevere, classificare e gestire le vulnerabilità serve quindi a risolvere un problema immediato, ma costituisce anche il primo pezzo di un percorso più ampio verso il 2027. Per una piccola impresa il vantaggio è proprio questo: possiamo iniziare dalle procedure indispensabili, verificare quali prodotti rientrano realmente nel regolamento e costruire gradualmente il resto, invece di arrivare alla fine del 2027 con un prodotto sul mercato e nessuna documentazione sulla sua sicurezza. Non arrivare sotto data potrebbe rivelarsi una mossa importantissima.
Il software libero e open source ha regole diverse
Il Cyber Resilience Act introduce un regime specifico per il software libero e open source. Il semplice contributore che partecipa a un progetto open source non diventa automaticamente un fabbricante soggetto a tutti gli obblighi del CRA.
Il regolamento introduce inoltre la figura del gestore di software open source, cioè una persona giuridica che sostiene in modo sistematico e continuativo lo sviluppo di determinati prodotti open source destinati ad attività commerciali. Questi soggetti hanno obblighi specifici e alleggeriti rispetto ai normali fabbricanti: devono, tra le altre cose, adottare una politica di cybersecurity, collaborare con le autorità e, nei casi previsti, effettuare le segnalazioni sulle vulnerabilità e sugli incidenti.
Il CRA stabilisce però che ai gestori di software open source non si applicano le sanzioni amministrative pecuniarie previste dal regolamento. Diverso è il caso in cui un’azienda commercializzi direttamente un prodotto open source come fabbricante: la semplice pubblicazione del codice con una licenza aperta non basta, da sola, a ottenere il regime alleggerito.
Dal problema alla procedura: cosa conviene fare adesso
Il Cyber Resilience Act non impone a ogni piccolo sviluppatore di trasformarsi in una grande struttura di sicurezza informatica. Impone però di sapere cosa stiamo vendendo, quale responsabilità abbiamo sul prodotto e cosa dobbiamo fare quando emerge un problema serio.
Dal settembre 2026 il tempo per improvvisare si riduce drasticamente. Se commercializziamo software, plugin, applicazioni o dispositivi connessi, conviene quindi effettuare almeno una prima verifica del catalogo, individuare i prodotti potenzialmente soggetti al CRA e definire una procedura interna per la gestione delle vulnerabilità.
Quando analizziamo questi progetti, partiamo proprio da qui: identifichiamo il prodotto, verifichiamo il ruolo dell’impresa, controlliamo il processo di sviluppo e definiamo chi deve intervenire in caso di vulnerabilità o incidente.
Non serve creare burocrazia inutile. Serve fare in modo che, quando arriva una segnalazione seria, nessuno debba iniziare chiedendo: “E adesso chi se ne occupa?”. Basta creare anche un file Excel con la lista dei plugin del nostro ecommerce, i fornitori e i contatti dei fornitori.
Domande frequenti
Il Cyber Resilience Act riguarda anche le piccole imprese?
Sì. Il CRA non prevede un’esclusione generale per le piccole imprese. Una piccola società che mette sul mercato un prodotto con elementi digitali può quindi rientrare nel regolamento. Sono però previste misure di proporzionalità e alcune agevolazioni specifiche, tra cui l’esclusione delle sanzioni amministrative pecuniarie per micro e piccole imprese nel caso del solo mancato rispetto del termine iniziale delle 24 ore.
Se facciamo sviluppare il nostro plugin da un programmatore esterno, il CRA riguarda lui o noi?
Dipende da come viene commercializzato il prodotto. Se commissioniamo lo sviluppo e successivamente vendiamo il prodotto con il nostro nome o marchio, possiamo essere considerati fabbricanti ai sensi del CRA anche se non abbiamo scritto materialmente il codice. Il contratto con lo sviluppatore dovrebbe quindi prevedere procedure rapide per la comunicazione e gestione delle vulnerabilità.
Dobbiamo segnalare qualsiasi vulnerabilità entro 24 ore?
No. L’obbligo previsto dall’articolo 14 riguarda, in particolare, le vulnerabilità attivamente sfruttate, cioè quelle per cui esistono prove affidabili di sfruttamento effettivo da parte di un soggetto malevolo. Una vulnerabilità semplicemente scoperta o teoricamente sfruttabile non coincide automaticamente con questa definizione.
Un SaaS è sempre soggetto al Cyber Resilience Act?
No. I normali servizi nel cloud non rientrano automaticamente nel CRA. Un servizio remoto può però rientrare quando costituisce una soluzione di elaborazione necessaria al funzionamento di un prodotto con elementi digitali ed è sviluppato dal fabbricante o sotto la sua responsabilità. L’inquadramento va quindi verificato sulla struttura concreta del servizio.
Cosa succede dall’11 dicembre 2027?
Da quella data il Cyber Resilience Act diventa pienamente applicabile. Oltre agli obblighi di segnalazione già operativi dal settembre 2026, acquistano piena efficacia i requisiti essenziali di cibersicurezza, gli obblighi relativi allo sviluppo sicuro, alla gestione delle vulnerabilità, alla documentazione e alla conformità dei prodotti.
Come posso preparare un account EU Login?
L’account EU Login (in precedenza ECAS) è il sistema di autenticazione standard della Commissione Europea, usato anche per accedere alla piattaforma di segnalazione ENISA. Si può creare gratuitamente e in anticipo, senza aspettare che serva davvero, all’indirizzo ecas.ec.europa.eu: bastano un indirizzo email e la configurazione dell’autenticazione a più fattori (l’app EU Login Mobile Authenticator è l’opzione più semplice, ma sono supportate anche altre modalità). Conviene individuare già ora chi in azienda dovrà occuparsene, così l’account è pronto prima che serva davvero, non nel mezzo di un’emergenza con 24 ore sul groppone.
Attenzione a non confondere i due passaggi: l’account EU Login si può e conviene crearlo subito; la registrazione sulla piattaforma di segnalazione vera e propria, invece, secondo le indicazioni di ENISA conviene farla solo quando c’è davvero una segnalazione da presentare, non prima.
Fonti esterne citate (link verificati il 8/9/2026):
- Gazzetta Ufficiale dell’Unione Europea / EUR-Lex — Regolamento (UE) 2024/2847
- Commissione Europea, Direzione Generale CONNECT — CRA Reporting obligations
- ENISA — Agenzia dell’Unione Europea per la cibersicurezza: CRA Single Reporting Platform Factsheet
- Agenzia per la Cybersicurezza Nazionale (ACN) — supporto alle PMI in vista del Cyber Resilience Act
