Cyber Resilience Act, l’11 settembre scattano gli obblighi di segnalazione: cosa cambia per le aziende

Il primo vero appuntamento operativo con il Cyber Resilience Act è ormai alle porte: dall’11 settembre 2026 scattano gli obblighi di segnalazione previsti dall’articolo 14: i fabbricanti di prodotti con elementi digitali dovranno notificare le vulnerabilità attivamente sfruttate e gli incidenti gravi secondo tempistiche stringenti, a partire dal preallarme entro 24 ore.

È una scadenza che cambia la prospettiva sull’adeguamento al CRA. Guardare soltanto alla piena applicazione del Regolamento nel dicembre 2027 non basta più: incident response, vulnerability management e procedure di segnalazione devono essere pronti adesso.

Le nuove linee guida UE diventano così uno strumento per tradurre gli obblighi normativi in una roadmap operativa di conformità.

Che cos’è il CRA

Il Cyber Resilience Act è il primo regolamento europeo di natura orizzontale che definisce requisiti essenziali di sicurezza per l’immissione sul mercato dei prodotti con elementi digitali (Products with Digital Elements – PDE).

Per “prodotto con elementi digitali” la norma intende qualsiasi software o hardware e le relative soluzioni di elaborazione dati da remoto (inclusi i componenti sviluppati separatamente) la cui connessione logica o fisica a un dispositivo o alla rete sia diretta o indiretta.

Il perimetro della normativa è estremamente esteso e impatta direttamente produttori, importatori e distributori.

L’impianto normativo del CRA si erge su due pilastri concettuali indispensabili:

• security by design e security by default;
• gestione dell’intero ciclo di vita del prodotto.

Security by design e security by default

La sicurezza informatica non può essere aggiunta al termine della fase di sviluppo, ma deve essere integrata fin dalle prime fasi di progettazione (by design).

I fabbricanti sono tenuti a effettuare una valutazione dei rischi di ciber sicurezza già in fase di concept, garantendo che i prodotti vengano forniti con la configurazione di massima sicurezza predefinita (by default), per esempio privi di credenziali di default universalmente note, con interfacce non necessarie disattivate e con meccanismi di cifratura attivi.

Gestione dell’intero ciclo di vita del prodotto

L’impegno del produttore non si esaurisce con la vendita o il rilascio del software.

Il CRA impone la responsabilità continuativa sul ciclo di vita del prodotto (Lifecycle Management). I fabbricanti devono monitorare e gestire le vulnerabilità per tutto il periodo di utilizzo previsto del prodotto, rilasciando aggiornamenti di sicurezza gratuiti e tempestivi e predisponendo piani di risposta agli incidenti in caso di compromissione.

Roadmap del Cyber Resilience Act (CRA): gli obblighi dall’11 settembre 2026 e prossime scadenze

L’entrata in vigore del Regolamento stabilisce un preciso percorso cronologico di adeguamento per consentire al mercato di strutturarsi.

È fondamentale identificare le scadenze chiave per evitare di trovarsi impreparati a ridosso dei termini perentori.

11 Settembre 2026: obblighi, sanzioni e impatto reputazionale

All’interno della roadmap di attuazione del Cyber Resilience Act, la data dell’11 settembre 2026 rappresenta il vero primo spartiacque operativo per i produttori e gli sviluppatori di prodotti con elementi digitali.

A differenza della piena applicazione del regolamento (prevista per fine 2027), l’Articolo 14 del CRA entra infatti in vigore con oltre un anno di anticipo, imponendo con immediata vincolatività stringenti obblighi di notifica delle falle di sicurezza.

Cosa prevede l’obbligo di segnalazione e cosa fare in concreto

A partire dall’11 settembre 2026, i fabbricanti non potranno più gestire la scoperta o lo sfruttamento di vulnerabilità nei propri software/hardware in modalità confidenziale o differita.

Saranno tenuti ad attivare flussi comunicativi rapidissimi verso l’ENISA (l’Agenzia Europea per la Cibersicurezza) e verso i CSIRT nazionali competenti (in Italia, l’Agenzia per la Cybersicurezza Nazionale – ACN):

• Pre-allarme entro 24 ore: entro un solo giorno dal momento in cui l’azienda viene a conoscenza di una vulnerabilità attivamente sfruttata sul mercato o di un incidente di ciber sicurezza grave, deve inviare una prima notifica sintetica.
• Notifica di incidente ed esito entro 72 ore: entro tre giorni deve seguire una relazione completa contenente un’analisi preliminare dell’impatto, la gravità del problema e le eventuali contromisure o patch d’emergenza già approntate.
• Rapporto finale. Per una vulnerabilità, entro e non oltre 14 giorni dalla disponibilità di una misura correttiva o di mitigazione. Per un incidente grave, entro un mese dalla notifica a 72 ore. Espone la descrizione completa, la gravità, l’impatto e la correzione applicata.

Sanzioni pecuniarie: multe fino a 15 milioni di euro

Per le aziende che ritardano, omettono o insabbiano la comunicazione delle vulnerabilità note, il quadro sanzionatorio del CRA è estremamente severo. La mancata osservanza degli obblighi di notifica ex Articolo 14 comporta sanzioni amministrative pecuniarie pari a:

• fino a 15 milioni di euro;
• oppure fino al 2,5% del fatturato globale annuo dell’esercizio precedente (se tale importo risulta superiore alla quota fissa);
• la non conformità agli obblighi relativi a rappresentanti autorizzati, importatori, distributori, dichiarazione di conformità, marcatura CE, documentazione tecnica e valutazione di conformità è soggetta a sanzioni fino a 10.000.000 euro o, se l’autore del reato è un’impresa, fino al 2% del fatturato mondiale totale annuo. Un terzo livello, fino a 5.000.000 euro o l’1% del fatturato, si applica per informazioni inesatte o fuorvianti fornite alle autorità.

Riflessioni e impatti: la violazione non è solo un costo economico

La previsione di sanzioni così pesanti – analoga per portata al GDPR o alla Direttiva NIS2 – dimostra come il legislatore europeo intenda eradicare la prassi del “silenzio aziendale” sulle falle di sicurezza.

Tuttavia, fermarsi alla sola analisi dell’impatto economico diretto sarebbe
riduttivo.

Le conseguenze reali per un’azienda che non rispetta la scadenza dell’11 settembre 2026 si sviluppano su più livelli critici:

• Effetto domino e paralisi della supply chain: in un mercato B2B e B2G integrato, la trasparenza è una condizione di continuità operativa. Se un fornitore nasconde una falla di sicurezza e questa provoca una compromissione a catena nei sistemi dei clienti, il danno materiale non si limiterà alla multa dell’autorità, ma genererà richieste di risarcimento danni da parte delle terze parti colpite.
• Danno reputazionale e perdita di fiducia: la pubblicazione delle sanzioni o la gestione maldestra di una vulnerabilità resa nota da ricercatori esterni (Coordinated Vulnerability Disclosure) mina irrimediabilmente la credibilità del brand aziendale, portando all’uscita dal mercato e all’esclusione dai bandi di gara pubblici.
• Responsabilità diretta del management: la gestione dei rischi di sicurezza non è più confinata nei reparti IT, ma diventa responsabilità diretta del board di gestione aziendale, esponendo gli amministratori a contestazioni per mancata diligenza e governance inadeguata.

Anticipare la scadenza dell’11 settembre 2026 non significa solo evitare la multa di 15 milioni: significa dotare l’organizzazione di procedure interne di Incident Response, canali di segnalazione sicuri e monitoraggio continuo della Software Bill of Materials (SBOM), trasformando un obbligo normativo in un fattore distintivo di affidabilità e competitività.

Punti salienti delle linee guida UE

La Commissione Europea ha predisposto linee guida interpretative volte a tradurre il rigoroso linguaggio legale in criteri pratici. Vediamo nel dettaglio i quattro ambiti di maggior rilievo:

• Support Period (Periodo di supporto di sicurezza).
• Software Open source: distinzione tra uso no-profit e commerciale.
• SBOM (Software Bill of Materials): la distinta base del software.
• Classificazione del rischio e criterio di funzionalità principale.

Periodo di supporto di sicurezza

Un punto ampiamente dibattuto riguarda la durata durante la quale il produttore è obbligato a rilasciare aggiornamenti di sicurezza:

• Cosa dice la linea guida: la norma menziona un periodo di supporto di riferimento di almeno 5 anni, ma le linee guida chiariscono che il limite dei 5 anni non è un “tetto massimo” fisso.
• In termini semplici: il periodo di supporto deve riflettere l’aspettativa di vita reale del prodotto. Se un’azienda produce un macchinario industriale, un dispositivo medico o un sistema hardware progettato per restare in funzione per 10 o 15 anni, il periodo di supporto di sicurezza e il rilascio delle patch devono coprire l’intera vita utile attesa dell’apparecchiatura, anche se superiore a 5 anni.

Software open source: distinzione tra uso no-profit e commerciale

L’ecosistema moderno del software si fonda sulla condivisione di componenti e librerie Open source. Applicare obblighi stringenti a sviluppatori indipendenti avrebbe rischiato di soffocare l’innovazione globale:

• Cosa dice la linea guida: le linee guida operano una netta distinzione tra lo sviluppo di codice open source condotto senza scopo di lucro e le attività di natura commerciale.
• In termini semplici: se uno sviluppatore indipendente crea un software open source e lo condivide gratuitamente senza monetizzarlo, non rientra nel campo di applicazione del CRA. Se invece un’azienda prende quel codice, lo integra in un proprio prodotto commerciale o lo distribuisce fornendo servizi di assistenza a pagamento, la responsabilità della conformità e della sicurezza del codice passa interamente in capo all’azienda che commercializza la soluzione.

SBOM (Software Bill of Materials): la distinta base del software

Il concetto di Software Bill of Materials costituisce la spina dorsale della trasparenza nella catena di fornitura digitale:

• Cosa dice la linea guida: la SBOM è una lista strutturata, leggibile da strumenti automatici, di tutti i componenti software, le librerie terze, le dipendenze e i moduli impiegati nell’architettura di un prodotto.
• In termini semplici: è l’equivalente dell’elenco degli ingredienti presente sulle etichette degli alimenti. Se emerge una vulnerabilità critica su una specifica libreria (come avvenne storicamente per casi noti come Log4j), la presenza di una SBOM aggiornata consente al produttore e ai clienti di verificare istantaneamente se il proprio sistema è a rischio, accelerando i tempi di mitigazione.

Classificazione del rischio e criterio di funzionalità principale

Non tutti i prodotti digitali presentano il medesimo livello di criticità. Il CRA suddivide i prodotti in tre macro-categorie: Standard, Importanti (Classe I e Classe II) e Critici:

• Cosa dice la linea guida: il livello di rischio viene determinato valutando la funzionalità principale del prodotto in relazione alla sicurezza informatica e al suo contesto d’uso.
• In termini semplici: un software di fotoritocco o un gioco rientrano nella categoria Standard (per i quali è sufficiente un’autovalutazione di conformità condotta dal produttore). Diversamente, un sistema operativo, un firewall, un password manager o un gestionale d’identità svolgono funzioni primarie di sicurezza e rientrano tra i prodotti Importanti o Critici, richiedendo l’intervento di un Ente Notificato terzo per ottenere la certificazione necessaria.

Perché le linee guida “non vincolanti” sono fondamentali

Dal punto di vista della gerarchia delle fonti del diritto, le linee guida emanate dalla Commissione Europea non costituiscono legge in senso stretto e mantengono un carattere formalmente “non vincolante”.

Ci si potrebbe quindi chiedere quale sia il loro valore pratico.

Le linee guida svolgono una funzione cruciale di orientamento e certezza del diritto per diversi motivi:

• Uniformità di applicazione nell’UE: senza indicazioni chiare, gli organi di vigilanza dei 27 Stati membri rischierebbero di interpretare la norma in modo frammentato, creando ostacoli alla libera circolazione dei prodotti nel mercato unico.
• Proporzionalità per PMI e startup: chiariscono come applicare i requisiti in modo scalabile, evitando che i costi di conformità diventino una barriera insormontabile per le piccole e medie imprese.
• Punto di riferimento durante le verifiche e gli audit: in sede di controllo da parte delle Autorità di vigilanza del mercato o degli audit di certificazione, l’allineamento alle linee guida ufficiali costituisce per l’azienda la dimostrazione di aver agito secondo la “regola dell’arte” e la massima diligenza professionale.

Suggerimenti operativi per la conformità

La conformità al Cyber Resilience Act non rappresenta una semplice pratica burocratica da sbrigare a ridosso del termine del 2027.

Richiede una revisione profonda dei processi interni di ingegnerizzazione, gestione della qualità, analisi dei rischi e supporto post-vendita.

Un approccio tardivo rischia di comportare conseguenze pesanti, tra cui il blocco della commercializzazione dei prodotti e sanzioni pecuniarie elevate.

Il piano di azione consigliato per organizzazioni e produttori:

• Mappatura e censimento dei prodotti (gap analysis): censire tutto l’hardware, il firmware e il software attualmente a catalogo o in fase di sviluppo. Determinare la classe di rischio di ciascun prodotto (Standard, Importante Classe I/II, Critico) sulla base della funzionalità primaria.
• Implementazione della SBOM (tracciabilità dei componenti): integrare all’interno della pipeline di sviluppo strumenti automatizzati in grado di generare e mantenere aggiornata la Software Bill of Materials. Verificare la presenza di licenze o componenti terzi affetti da vulnerabilità note.
• Integrazione del Secure SDLC e standard ISO: strutturare un ciclo di vita dello sviluppo software sicuro (Secure Software Development Life Cycle), inserendo attività di vulnerability assessment e penetration test periodiche. Integrare il sistema di gestione aziendale orientandosi agli standard internazionali di riferimento come la ISO/IEC 27001 (Sicurezza delle informazioni) e la ISO/IEC 62443 (Sicurezza per i sistemi di automazione e controllo).
• Gestione incidenti e cordinated vulnerability disclosure (CVD): definire e formalizzare la procedura interna per la gestione e la segnalazione delle vulnerabilità e degli incidenti gravi in conformità con i tempi prescritti dal CRA (24h/72h). Attivare un canale pubblico dedicato alle segnalazioni di vulnerabilità da parte di ricercatori esterni (Coordinated Vulnerability Disclosure).