Cyber Resilience Act: cosa devono fare oggi i produttori di software e dispositivi connessi

Dall'11 settembre 2026 i fabbricanti di software e di prodotti con elementi digitali venduti nell'Unione europea devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi che riguardano i loro prodotti. Lo prevede l'articolo 14 del Cyber Resilience Act, il Regolamento (UE) 2024/2847, e lo stesso giorno l'ENISA ha reso operativa la piattaforma unica di segnalazione. Il resto del regolamento si applica dall'11 dicembre 2027.

Nel frattempo la Commissione europea ha pubblicato, il 27 luglio 2026, le prime linee guida sull'applicazione del regolamento. In Italia il Consiglio dei ministri ha approvato il 2 ottobre 2026, in esame preliminare, lo schema di decreto legislativo che designa l'Agenzia per la cybersicurezza nazionale (ACN) come autorità di vigilanza del mercato. In questa guida trovi cosa prevede oggi la norma, chi è coinvolto e una checklist per arrivare preparato al 2027. Non è una consulenza legale: se hai dubbi sul tuo caso, verificalo con un legale o con un consulente esperto.

Cosa è cambiato l'11 settembre 2026 con il Cyber Resilience Act?

È diventato applicabile l'obbligo di segnalazione dei fabbricanti. L'articolo 71 del regolamento fissa la piena applicazione all'11 dicembre 2027, ma anticipa l'articolo 14 all'11 settembre 2026. Da quella data, se un fabbricante viene a conoscenza di una vulnerabilità attivamente sfruttata o di un incidente grave che ha un impatto sulla sicurezza del suo prodotto, deve notificarlo con tempi precisi.

Vulnerabilità attivamente sfruttata e incidente grave: cosa significano

Il regolamento non chiede di segnalare ogni difetto. Una vulnerabilità attivamente sfruttata è una vulnerabilità per la quale esistono prove attendibili che un soggetto malintenzionato l'ha sfruttata in un sistema senza l'autorizzazione del proprietario (art. 3, punto 42). Una vulnerabilità scoperta in un test interno e mai sfruttata non rientra in questo obbligo, anche se va comunque gestita.

Un incidente che ha un impatto sulla sicurezza del prodotto è considerato grave se incide, o può incidere, sulla capacità del prodotto di proteggere disponibilità, autenticità, integrità o riservatezza di dati o funzioni sensibili o importanti. È grave anche se ha portato, o può portare, all'esecuzione di codice malevolo nel prodotto o nei sistemi di un utilizzatore (art. 14, paragrafo 5).

L'obbligo vale anche per i prodotti già venduti

È il punto che sorprende di più. Di norma i prodotti immessi sul mercato prima dell'11 dicembre 2027 sono soggetti al regolamento solo se subiscono una modifica sostanziale. L'articolo 69, paragrafo 3, fa però un'eccezione: gli obblighi di segnalazione dell'articolo 14 si applicano a tutti i prodotti che rientrano nell'ambito del regolamento, compresi quelli già in commercio. Se vendi un prodotto connesso da anni, l'obbligo riguarda anche lui.

Come funziona la segnalazione: tempi, destinatari e piattaforma unica

Le notifiche vanno inviate in modo simultaneo al CSIRT designato come coordinatore e all'ENISA, l'Agenzia dell'Unione europea per la cibersicurezza. Non si inviano per email: passano dalla piattaforma unica di segnalazione prevista dall'articolo 16, gestita dall'ENISA.

Le scadenze previste dall'articolo 14

Il regolamento prevede tre passaggi successivi, con tempi diversi per vulnerabilità e incidenti. I termini decorrono dal momento in cui il fabbricante ne è venuto a conoscenza.

Nel preallarme il fabbricante indica, se del caso, gli Stati membri in cui sa che il prodotto è stato messo a disposizione. Il CSIRT che riceve per primo la notifica può chiedere anche una relazione intermedia. Il regolamento prevede inoltre la segnalazione volontaria (art. 15) di vulnerabilità non sfruttate, minacce e quasi incidenti.

A quale CSIRT va la notifica

La notifica parte dal terminale del CSIRT designato come coordinatore dello Stato in cui il fabbricante ha lo stabilimento principale nell'Unione, cioè dove si prendono prevalentemente le decisioni sulla cibersicurezza dei prodotti (art. 14, paragrafo 7). Per un fabbricante con sede decisionale in Italia, l'elenco pubblicato dall'ENISA dei CSIRT designati come coordinatori ai sensi del regolamento rimanda al CSIRT Italia dell'ACN.

L'ENISA ha lanciato la piattaforma l'11 settembre 2026 e ha pubblicato FAQ, manuali d'uso e guide alla registrazione. Secondo la pagina dell'Agenzia, il 4 novembre 2026 la piattaforma è stata aggiornata alla versione 1.3: conviene registrarsi prima di averne bisogno e controllare periodicamente la documentazione aggiornata.

Informare gli utilizzatori

La segnalazione alle autorità non basta. Quando viene a conoscenza di una vulnerabilità attivamente sfruttata o di un incidente grave, il fabbricante informa gli utilizzatori interessati e, se serve, indica le misure che possono adottare per attenuarne l'impatto (art. 14, paragrafo 8). Se il fabbricante non lo fa tempestivamente, il CSIRT può informare direttamente gli utilizzatori.

Chi è coinvolto dal Cyber Resilience Act?

Il regolamento si applica ai prodotti con elementi digitali messi a disposizione sul mercato la cui finalità prevista o il cui uso ragionevolmente prevedibile include una connessione dati, diretta o indiretta, a un dispositivo o a una rete (art. 2). La definizione comprende prodotti software e hardware, i loro componenti immessi sul mercato separatamente e le soluzioni di elaborazione dati da remoto.

Fabbricanti

È fabbricante chi sviluppa o fabbrica un prodotto con elementi digitali, o lo fa progettare e fabbricare, e lo commercializza con il proprio nome o marchio, a titolo oneroso, di monetizzazione o gratuito (art. 3, punto 13). Gli obblighi di segnalazione dell'articolo 14 riguardano i fabbricanti.

Attenzione anche agli articoli 21 e 22: un importatore o un distributore che immette sul mercato un prodotto con il proprio marchio, o chiunque apporti una modifica sostanziale a un prodotto già sul mercato e lo metta a disposizione, è considerato fabbricante e assume gli stessi obblighi.

Importatori e distributori

Gli importatori immettono sul mercato solo prodotti conformi: prima di farlo verificano la valutazione della conformità, la documentazione tecnica, la marcatura CE e le istruzioni (art. 19). I distributori verificano la marcatura CE e la documentazione ricevuta (art. 20). Entrambi, quando vengono a conoscenza di una vulnerabilità, ne informano il fabbricante senza indebito ritardo.

Gestori di software open source

Il regolamento introduce la figura del gestore di software open source (in inglese open-source software steward): una persona giuridica, diversa dal fabbricante, che sostiene in modo sistematico e duraturo lo sviluppo di software libero e open source destinato ad attività commerciali (art. 3, punto 14). Ha obblighi più leggeri: una politica di cibersicurezza documentata e la cooperazione con le autorità (art. 24). Secondo l'ENISA, gli obblighi di segnalazione per i gestori si applicano dall'11 dicembre 2027.

Prodotti importanti e critici

Il regolamento elenca nell'Allegato III i prodotti importanti, divisi in due classi. In classe I ci sono, per esempio, sistemi operativi, browser, sistemi di gestione delle password, VPN, router, sistemi SIEM e prodotti per la casa intelligente con funzioni di sicurezza. In classe II ci sono, per esempio, firewall, sistemi di rilevamento e prevenzione delle intrusioni e ipervisori. L'Allegato IV elenca i prodotti critici, come smart card ed elementi sicuri. La Commissione ha adottato nel novembre 2025 un atto di esecuzione con le descrizioni tecniche di queste categorie.

La classificazione conta per la valutazione della conformità: per i prodotti che non sono né importanti né critici il fabbricante può scegliere anche la procedura di controllo interno, mentre per i prodotti importanti e critici il regolamento prevede procedure più rigorose (artt. 7, 8 e 32). Alcuni prodotti sono esclusi perché regolati da altre norme, come i dispositivi medici.

Cosa cambia dall'11 dicembre 2027?

Da quella data si applica tutto il regolamento. Un prodotto con elementi digitali può essere messo a disposizione sul mercato solo se rispetta i requisiti essenziali di cibersicurezza dell'Allegato I e se i processi del fabbricante rispettano i requisiti di gestione delle vulnerabilità (art. 6).

Gli obblighi principali del fabbricante

L'articolo 13 chiede al fabbricante di fare una valutazione dei rischi di cibersicurezza, documentarla e tenerne conto in tutte le fasi, dalla progettazione alla manutenzione. Deve anche esercitare la dovuta diligenza sui componenti di terzi, compresi quelli open source.

Il fabbricante deve poi stabilire un periodo di assistenza, durante il quale gestisce le vulnerabilità del prodotto. Il periodo riflette la durata di utilizzo prevista ed è di almeno cinque anni, salvo che il prodotto sia destinato a essere usato per meno tempo: in quel caso coincide con la durata di utilizzo prevista. Ogni aggiornamento di sicurezza resta disponibile per almeno dieci anni dal rilascio o per il restante periodo di assistenza, se più lungo. La data di fine del periodo di assistenza va indicata in modo chiaro al momento dell'acquisto.

Gestione delle vulnerabilità e distinta base del software

L'Allegato I, parte II, elenca i requisiti di gestione delle vulnerabilità. Il fabbricante identifica e documenta le vulnerabilità e i componenti del prodotto, anche redigendo una distinta base del software (SBOM) in un formato di uso comune e leggibile da una macchina, che includa almeno le dipendenze di primo livello. Deve inoltre correggere tempestivamente le vulnerabilità, testare periodicamente la sicurezza, adottare una politica di divulgazione coordinata delle vulnerabilità, fornire un indirizzo di contatto per le segnalazioni e distribuire gli aggiornamenti in modo sicuro e gratuito.

Documentazione tecnica e marcatura CE

Prima dell'immissione sul mercato il fabbricante redige la documentazione tecnica (art. 31 e Allegato VII): descrizione del prodotto, architettura, processi di gestione delle vulnerabilità, valutazione dei rischi, informazioni usate per fissare il periodo di assistenza, norme applicate e relazioni delle prove. Poi segue la procedura di valutazione della conformità, redige la dichiarazione di conformità UE e appone la marcatura CE. Documentazione e dichiarazione restano disponibili per almeno dieci anni o per il periodo di assistenza, se più lungo.

Cosa dicono le linee guida della Commissione di luglio 2026?

Il 27 luglio 2026 la Commissione ha pubblicato le prime linee guida sull'applicazione del Cyber Resilience Act (documento C(2026) 5252). La Commissione le definisce non vincolanti, ma utili per prepararsi fin da ora.

Secondo la pagina ufficiale, il documento chiarisce l'ambito di applicazione, con attenzione alle soluzioni di elaborazione dati da remoto e al software libero e open source. Tratta poi il concetto di modifica sostanziale, i periodi di assistenza, gli obblighi di segnalazione e la valutazione dei rischi. Per le microimprese e le PMI include 67 esempi, casi d'uso, diagrammi di flusso e grafici. La Commissione aggiorna anche un documento di domande frequenti sull'attuazione.

Se il tuo prodotto è al confine dell'ambito di applicazione, per esempio un software con una componente cloud o un dispositivo che riceve aggiornamenti, le linee guida sono il primo documento da leggere dopo il testo del regolamento.

A che punto è il decreto italiano sul Cyber Resilience Act?

Il regolamento è direttamente applicabile, ma ogni Stato membro deve designare le autorità di vigilanza del mercato (art. 52) e fissare le norme sulle sanzioni. In Italia il Consiglio dei ministri n. 191 del 2 ottobre 2026 ha approvato, in esame preliminare, il decreto legislativo di adeguamento della normativa nazionale al regolamento.

Secondo il comunicato del Governo, lo schema di decreto designa l'ACN come autorità di notifica degli organismi di valutazione della conformità e di vigilanza del mercato, con il possibile supporto della Guardia di finanza. Prevede inoltre un canale di consulenza dedicato a microimprese e PMI, comprese le start-up, tariffe proporzionate per la valutazione della conformità, uno spazio di sperimentazione normativa (Sandbox-CRA) sotto la supervisione dell'ACN e sanzioni amministrative graduate in base alla gravità della violazione.

Al 12 novembre 2026 sul sito del Governo non risulta un'approvazione definitiva e il decreto non è pubblicato in Gazzetta Ufficiale: è uno schema in esame, che può cambiare durante l'iter. Gli obblighi di segnalazione, invece, discendono dal regolamento europeo e sono già applicabili.

Checklist: cosa devono fare oggi i produttori di software e dispositivi connessi

Ecco i passi concreti da avviare subito, in ordine di priorità. Non sostituiscono la lettura del regolamento e delle linee guida, ma ti aiutano a capire dove sei scoperto.

1. Fai l'inventario dei prodotti

Elenca tutti i prodotti software e hardware che metti a disposizione nell'Unione, anche quelli gratuiti, quelli venduti da anni e quelli con componenti cloud. Per ciascuno indica versioni supportate, Paesi di vendita, componenti di terzi e open source, canali di aggiornamento. Ti serve per sapere quali prodotti sono già coperti dall'obbligo di segnalazione.

2. Classifica ruolo e categoria

Per ogni prodotto chiarisci il tuo ruolo: fabbricante, importatore, distributore o gestore di software open source. Verifica se il prodotto rientra in una categoria dell'Allegato III o IV, se è escluso perché regolato da altre norme e se una tua modifica può essere sostanziale. Le linee guida della Commissione aiutano nei casi dubbi.

3. Prepara la procedura di segnalazione

Scrivi una procedura che dica chi decide, chi valuta se una vulnerabilità è attivamente sfruttata o se un incidente è grave, chi invia preallarme, notifica e relazione finale e chi informa gli utilizzatori. Registra l'azienda sulla piattaforma unica dell'ENISA, individua il CSIRT competente e simula una notifica con il team. Le 24 ore partono dalla conoscenza del fatto, anche di notte o nel fine settimana.

4. Struttura la gestione delle vulnerabilità e la divulgazione coordinata

Pubblica un punto di contatto per le segnalazioni di vulnerabilità e una politica di divulgazione coordinata. Definisci come ricevi, valuti, correggi e comunichi le vulnerabilità, compresi i componenti di terzi. Pianifica test di sicurezza periodici: per capire la differenza tra gli strumenti leggi la guida su penetration test e vulnerability assessment e quella sul WAPT per le applicazioni web.

5. Prepara la distinta base del software

Inizia a generare una SBOM leggibile da una macchina per ogni versione rilasciata, con almeno le dipendenze di primo livello. Ti serve già oggi per capire in poche ore se una vulnerabilità sfruttata in un componente riguarda i tuoi prodotti, e dal 2027 è un requisito del regolamento.

6. Avvia la documentazione tecnica

Imposta un modello di documentazione tecnica per prodotto sulla base dell'Allegato VII: valutazione dei rischi, architettura, processi di gestione delle vulnerabilità, periodo di assistenza, relazioni delle prove. Tienila aggiornata a ogni rilascio.

7. Pianifica il percorso verso il 2027

Fissa un piano con responsabili e scadenze fino all'11 dicembre 2027: progettazione sicura, periodo di assistenza, aggiornamenti gratuiti, valutazione della conformità, dichiarazione UE e marcatura CE. Per una visione d'insieme delle date leggi la guida sulle scadenze di compliance 2026-2027.

Come si collega il Cyber Resilience Act a ISO 27001 e NIS2?

Sono norme diverse, ma lavorano bene insieme. Il Cyber Resilience Act riguarda la sicurezza dei prodotti che metti sul mercato; la direttiva NIS2 riguarda la sicurezza di reti e sistemi di alcune organizzazioni; la ISO 27001 è uno standard volontario per il sistema di gestione della sicurezza delle informazioni.

Un sistema di gestione ISO 27001 ti dà già una base solida: valutazione dei rischi, gestione degli incidenti, gestione dei fornitori, controllo delle modifiche, documentazione e miglioramento continuo. Non sostituisce i requisiti di prodotto del regolamento, ma rende più semplice applicarli con metodo. Per approfondire leggi la guida completa alla ISO 27001 e quella su ISO 27001 e NIS2.

Se la tua azienda rientra anche nella NIS2, gli obblighi si sommano: le notifiche del Cyber Resilience Act riguardano i prodotti, quelle NIS2 gli incidenti che colpiscono i tuoi servizi. Per le misure di base da cui partire, anche se non sei soggetto NIS2, leggi la guida sulle misure minime di cybersecurity per le PMI.

Come Complaion ti aiuta con sicurezza delle informazioni e conformità

Complaion affianca le aziende nella sicurezza delle informazioni e nella conformità normativa: certificazione ISO 27001, adeguamento alla NIS2, percorsi legati al Cyber Resilience Act e test di sicurezza con il servizio WAPT.

Un Lead Auditor dedicato segue la tua azienda, analizza la situazione di partenza e ti propone il percorso più adatto. La piattaforma raccoglie le evidenze, gestisce documenti e procedure, tiene lo scadenziario e ti prepara all'audit. Il Lead Auditor conduce anche l'audit interno, così sai se i processi funzionano davvero prima delle verifiche esterne.

Oltre 1.000 clienti hanno già scelto Complaion. Se vuoi capire da dove partire, contattaci.

Domande frequenti sul Cyber Resilience Act

Da quando devo segnalare le vulnerabilità attivamente sfruttate?

Dall'11 settembre 2026, se sei un fabbricante di prodotti con elementi digitali. L'obbligo vale anche per i prodotti già sul mercato prima dell'11 dicembre 2027 (art. 69, paragrafo 3). Il preallarme va inviato entro 24 ore da quando ne sei venuto a conoscenza, tramite la piattaforma unica di segnalazione dell'ENISA.

Devo segnalare ogni vulnerabilità che trovo?

No. L'obbligo riguarda le vulnerabilità attivamente sfruttate, cioè quelle per cui esistono prove attendibili di uno sfruttamento malevolo, e gli incidenti gravi. Le altre vulnerabilità vanno comunque gestite e corrette secondo la tua politica, e possono essere segnalate su base volontaria.

In Italia a chi va la notifica?

La notifica si invia tramite la piattaforma unica dell'ENISA, scegliendo il CSIRT designato come coordinatore dello Stato in cui hai lo stabilimento principale. Per l'Italia l'elenco dell'ENISA rimanda al CSIRT Italia dell'ACN. La notifica è accessibile contemporaneamente all'ENISA.

Il Cyber Resilience Act riguarda anche chi sviluppa software gratuito?

La definizione di fabbricante comprende anche chi commercializza prodotti a titolo gratuito o di monetizzazione. Per il software libero e open source la situazione dipende dal contesto commerciale: le linee guida della Commissione dedicano una parte proprio a questo tema. Se il tuo caso non è chiaro, verificalo con un consulente.

Il periodo di assistenza deve durare per forza cinque anni?

Il regolamento chiede che rifletta la durata di utilizzo prevista del prodotto e fissa almeno cinque anni, salvo che il prodotto sia destinato a essere usato per meno tempo: in quel caso coincide con la durata prevista. Questo obbligo si applica dall'11 dicembre 2027.

Il decreto italiano sul Cyber Resilience Act è già in vigore?

No. Il 2 ottobre 2026 il Consiglio dei ministri lo ha approvato in esame preliminare e al 12 novembre 2026 non risulta pubblicato in Gazzetta Ufficiale. Lo schema designa l'ACN come autorità di vigilanza del mercato e definisce le sanzioni nazionali. Gli obblighi di segnalazione dell'articolo 14, invece, derivano direttamente dal regolamento europeo e si applicano già.