La risposta breve
L’11 settembre 2026 entra in vigore il primo obbligo operativo del Cyber Resilience Act (Regolamento UE 2024/2847): i produttori di prodotti con elementi digitali devono notificare le vulnerabilità attivamente sfruttate a ENISA e al CSIRT nazionale entro 24 ore dalla scoperta. Una notifica completa deve seguire entro 72 ore; il rapporto finale entro 14 giorni per le vulnerabilità sfruttate e un mese per gli incidenti gravi. Il pieno regime del CRA — con tutti i requisiti di sicurezza sul prodotto e la marcatura CE — scatterà solo l’11 dicembre 2027, ma chi produce software commerciale o dispositivi connessi non può aspettare: costruire un processo di vulnerability management affidabile richiede mesi, non giorni.
Il CRA è distinto dalla NIS2 (che riguarda la sicurezza operativa delle organizzazioni) e dall’AI Act (che regola i sistemi di intelligenza artificiale): si concentra sulla sicurezza intrinseca del prodotto digitale, dall’architettura iniziale fino alla fine vita. Per le imprese italiane con prodotti software o hardware connessi, settembre è la prima scadenza concreta — e l’opportunità di partire con il piede giusto prima che arrivino le verifiche.
Cosa cambia dall’11 settembre 2026
Il Cyber Resilience Act ha seguito un calendario di applicazione progressivo dalla sua pubblicazione nella Gazzetta Ufficiale dell’UE nel novembre 2024. La maggior parte degli articoli sarà applicabile dall’11 dicembre 2027, ma il Regolamento ha estratto gli obblighi di segnalazione delle vulnerabilità (Articolo 14) e li ha anticipati di 15 mesi, al fine di dare alle autorità un flusso di informazioni sulle minacce attive prima ancora che i produttori abbiano completato la piena messa a norma.
Dall’11 settembre 2026, ogni produttore che viene a conoscenza del fatto che un proprio prodotto con elementi digitali è affetto da una vulnerabilità attivamente sfruttata da attori malevoli deve avviare la notifica. La segnalazione va trasmessa attraverso la Single Reporting Platform (SRP) di ENISA, che smista automaticamente le informazioni al CSIRT del Paese dove il produttore ha la sede principale — in Italia, il CSIRT Italia dell’ACN.
Questo è il primo vincolo normativo di notifica pan-europeo che si applica direttamente ai produttori di software e hardware, e non solo agli operatori di servizi o di infrastrutture critiche. Per molte software house italiane è un cambio di paradigma: fino ad ora la comunicazione delle vulnerabilità era una buona pratica, non un obbligo con sanzioni.
Un buon processo di vulnerability assessment e penetration testing regolare è il prerequisito per rilevare le vulnerabilità prima che lo facciano gli attaccanti e per rispettare i tempi di notifica imposti dal CRA.
Chi rientra nel perimetro CRA
Il CRA si applica ai prodotti con elementi digitali (PDE): qualsiasi prodotto hardware o software con una connessione logica o fisica a una rete o a un altro dispositivo, immesso sul mercato UE in forma commerciale. Il perimetro è volutamente ampio:
- Hardware connesso: router, switch, dispositivi IoT, telecamere IP, sensori industriali, dispositivi medicali connessi, wearable.
- Software autonomo: applicazioni desktop, app mobili, software gestionale, videogiochi commerciali, sistemi operativi, firmware.
- Componenti e librerie: SDK, librerie distribuite come prodotti standalone a sviluppatori terzi.
- Software incorporato in un prodotto: firmware di un dispositivo, OS embedded in un macchinario industriale.
Restano fuori dal perimetro: il software open source rilasciato senza scopo commerciale dai suoi maintainer, il software sviluppato esclusivamente a uso interno di un’organizzazione (non distribuito a terzi), il software prodotto per un singolo committente in modo personalizzato e non distribuito ulteriormente.
I PDE sono suddivisi in tre categorie di rischio:
- Default (la maggioranza): obblighi di base, autovalutazione della conformità.
- Classe I (rischio aumentato): software di gestione delle identità, browser, password manager, antivirus, VPN, sistemi SCADA. Richiede valutazione di terze parti o standard armonizzato.
- Classe II (rischio critico): sistemi operativi, hypervisor, hardware con funzioni di sicurezza. Obbligatoria la valutazione da un organismo notificato (come per la marcatura CE in altri settori).
Le imprese italiane nel manifatturiero avanzato, nella logistica e nel fintech che integrano componenti IoT o software nei propri prodotti sono quasi certamente produttori CRA e devono verificare in quale categoria rientrano i propri prodotti prima dell’11 settembre.
La catena di notifica: 24 ore, 72 ore, 14 giorni
Il cuore dell’obbligo di settembre è una catena di notifica a tre stadi, modellata sulla struttura già nota della NIS2 ma applicata ai produttori anziçhé agli operatori di servizi:
Stadio 1 — Early warning (entro 24 ore)
Non appena il produttore viene a conoscenza di una vulnerabilità attivamente sfruttata nel proprio prodotto, deve inviare un preavviso a ENISA tramite la SRP. Il preavviso non richiede ancora l’analisi completa: basta indicare il prodotto coinvolto, la natura della vulnerabilità e, ove disponibile, il vettore di attacco. L’obiettivo è allertare le autorità il prima possibile.
Stadio 2 — Notifica completa (entro 72 ore)
Entro tre giorni dalla scoperta, il produttore deve trasmettere la notifica completa: identificativo CVE (se assegnato), versioni interessate, impatto stimato, misure di mitigazione disponibili o in corso di sviluppo. Questa notifica viene resa disponibile anche al CSIRT Italia in parallelo, senza necessità di un’ulteriore comunicazione separata.
Stadio 3 — Rapporto finale
Entro 14 giorni dal momento in cui è disponibile una misura correttiva o di mitigazione, per vulnerabilità attivamente sfruttate. Entro un mese dalla notifica delle 72 ore, per gli incidenti gravi. Il rapporto finale deve includere la descrizione completa della vulnerabilità, le azioni intraprese, le patch rilasciate e la valutazione delle cause all’origine del problema.
Open source e software su misura: le regole specifiche
Due categorie di software hanno spesso creato confusione nell’applicazione del CRA: il software open source e il software sviluppato su misura per un singolo cliente.
Software open source
Il CRA introduce la figura del software steward: il soggetto che mantiene su base continuativa un progetto open source usato da altri produttori nei propri PDE. I software steward hanno obblighi alleggeriti rispetto ai produttori commerciali: non devono eseguire la valutazione della conformità, ma devono implementare e documentare una politica di sicurezza (vulnerability disclosure policy), cooperare con le autorità di vigilanza e notificare le vulnerabilità gravi. I singoli contributori occasionali a un progetto open source non sono steward e non hanno obblighi.
Il punto critico per le imprese italiane che usano librerie open source nei propri prodotti: se una libreria di terze parti ha una vulnerabilità nota che rende sfruttabile il vostro prodotto, siete voi i responsabili della notifica agli utenti e all’autorità, indipendentemente dall’origine del difetto. Il CRA spinge verso un monitoraggio attivo delle dipendenze — SBOM (Software Bill of Materials) e strumenti di Software Composition Analysis diventano non più opzionali.
Software sviluppato su misura (custom software)
Il software commissionato da un’organizzazione per uso esclusivamente interno, non distribuito a terzi, non è un PDE ai sensi del CRA. Tuttavia, la situazione si complica quando:
- Il software viene successivamente venduto o ceduto in licenza ad altre organizzazioni (anche solo a una filiale).
- Il contratto prevede che il fornitore mantenga o aggiorni il software per conto del cliente: in questo caso il fornitore potrebbe qualificarsi come produttore.
- Il software include componenti di terze parti (framework, librerie) che sono essi stessi PDE.
Per le imprese che commissionano sviluppo software su misura, la buona prassi è inserire già nei contratti clausole esplicite sulla responsabilità CRA: chi notifica le vulnerabilità, chi mantiene l’SBOM, come vengono gestite le patch lungo il ciclo di vita. Definire queste responsabilità oggi previene dispute legali domani.
Cosa fare adesso per essere pronti
Con 31 giorni alla scadenza, le azioni prioritarie si concentrano sulla capacità di rilevare e segnalare le vulnerabilità nel tempo richiesto:
1. Inventario dei prodotti e classificazione CRA
Stilare l’elenco di tutti i prodotti software e hardware con elementi digitali immessi sul mercato UE. Per ciascuno, verificare: rientra nella definizione di PDE? In quale classe di rischio (default, I o II)? Chi è il produttore legalmente responsabile?
2. Monitoraggio attivo delle vulnerabilità
Sottoscrivere i feed CVE (NVD, MITRE) e configurare alert automatici per tutti i componenti usati nei prodotti. Adottare strumenti di Software Composition Analysis (SCA) che correlino automaticamente le dipendenze nel codice con le CVE pubbliche. Senza questo layer, sapere entro 24 ore che una propria dipendenza è sfruttata attivamente è praticamente impossibile.
3. Vulnerability Disclosure Policy (VDP)
Pubblicare una VDP chiara, che indichi come i ricercatori di sicurezza e gli utenti possono segnalare vulnerabilità, e assegnare internamente un referente responsabile di classificarle e gestirle. La VDP è un prerequisito formale del CRA e serve anche come canale d’ingresso prima che una vulnerabilità diventi “attivamente sfruttata”.
4. Playbook di notifica
Documentare la procedura interna da seguire quando si scopre una vulnerabilità sfruttata: chi prende la decisione di notificare, chi prepara il testo dell’early warning, come si accede alla SRP ENISA, chi è il punto di contatto con il CSIRT Italia. Testare il playbook con una simulazione prima dell’11 settembre.
5. Revisione delle dipendenze open source (SBOM)
Generare un Software Bill of Materials per ciascun prodotto in scope: strumenti come Syft, CycloneDX o SPDX semplificano il processo anche su codebase complesse. L’SBOM è anche il documento che le autorità di vigilanza potranno richiedere in caso di ispezione.
Domande frequenti
Quando scatta il primo obbligo del Cyber Resilience Act?
L’11 settembre 2026. Da quella data i produttori di prodotti con elementi digitali (PDE) devono notificare le vulnerabilità attivamente sfruttate a ENISA e al CSIRT nazionale entro 24 ore. L’entrata a pieno regime del CRA con tutti gli obblighi di sicurezza del prodotto è prevista per l’11 dicembre 2027.
Il CRA si applica al software sviluppato su misura?
Il CRA si applica ai prodotti con elementi digitali immessi sul mercato UE, cioè messi a disposizione di terzi. Il software su misura per un singolo committente non distribuito a terzi non rientra nel perimetro diretto. Tuttavia, se il fornitore include componenti terze parti con vulnerabilità note o se il software viene successivamente redistribuito, la responsabilità CRA sorge. I committenti devono verificare le clausole contrattuali con il proprio fornitore di software.
Cosa si intende per ‘prodotto con elementi digitali’ nel CRA?
Qualsiasi prodotto hardware o software con una connessione logica o fisica a una rete o a un altro dispositivo. Rientrano: laptop, smartphone, sensori IoT, router, firmware, app desktop e mobili, software SaaS incorporato in un prodotto, videogiochi commerciali, SDK e librerie distribuite come prodotto standalone. Esclusi: software open source non commerciale, software solo per test o ricerca, servizi SaaS puri.
Quali sono le sanzioni per il mancato rispetto del CRA?
Per i requisiti essenziali di sicurezza e gli obblighi sulle vulnerabilità: fino a 15 milioni di euro o al 2,5% del fatturato mondiale annuo. Per obblighi di notifica e adempimenti secondari: fino a 10 milioni di euro o al 2% del fatturato. Per informazioni false alle autorità: fino a 5 milioni di euro o all’1% del fatturato.
Fonti
Commissione Europea — CRA Reporting obligations (Articolo 14)
01net.it — Cyber Resilience Act, primi obblighi dall’11 settembre 2026: tutele per chi acquista, responsabilità per chi produce e vende
SNI Unioncamere — Cyber Resilience Act: cosa devono fare le imprese nel 2026
Agenda Digitale — CRA e open source: fabbricanti responsabili, gestori sotto pressione
ICT Security Magazine — Cyber Resilience Act obblighi 2026: tutti gli adempimenti in vigore