Torna al Blog

Cyber Resilience Act: dall'11 settembre 2026 scattano gli obblighi di notifica per i produttori di software e dispositivi connessi

·5 min lettura
Cyber Resilience Act - Timeline notifiche Article 14

Dall'11 settembre 2026, i produttori di software installabile, firmware o dispositivi connessi venduti nel mercato UE hanno 24 ore per inviare un early warning a ENISA ogni volta che una vulnerabilità nel loro prodotto viene attivamente sfruttata. La Single Reporting Platform è in costruzione e sarà operativa in tempo: chi non ha ancora un processo interno di notifica ha meno di 100 giorni per costruirlo.

Il Regolamento (UE) 2024/2847 — Cyber Resilience Act — è in vigore dall'11 dicembre 2024, ma il grosso degli obblighi entra in applicazione in tre tranches. La prima riguarda gli articoli 14 e 16: obblighi di notifica delle vulnerabilità e degli incidenti gravi, con scadenze a orologio. L'11 settembre 2026, tra meno di 100 giorni, parte il cronometro.

Non riguarda solo i grandi nomi del software. Il Regolamento colpisce chiunque immetta sul mercato UE un "prodotto con elementi digitali" — definizione volutamente ampia.

Chi è davvero coinvolto

"Prodotti con elementi digitali": software, app, firmware, IoT — anche le PMI

Il CRA si applica ai produttori di prodotti con elementi digitali: qualsiasi hardware o software che include componenti digitali e può connettersi a un dispositivo o a una rete (art. 3(1) Reg. 2024/2847). L'elenco concreto comprende software installabili (desktop, server, mobile), firmware per embedded, sensori e attuatori IoT industriali, router, telecamere connesse.

Una PMI italiana che sviluppa un gestionale on-premise e lo vende a clienti in Germania è in scope. Un fornitore di firmware per sensori industriali è in scope. Un'app mobile aziendale pubblicata su store è in scope.

Il punto più controverso per le PMI software riguarda il SaaS cloud-only: un'applicazione erogata esclusivamente come servizio cloud, senza componenti installabili, tende a essere esclusa. Tuttavia, se il backend cloud costituisce "remote data processing" progettato dal produttore e necessario per le funzioni core (art. 3(2)), la distinzione diventa meno netta. La Commissione Europea ha pubblicato draft guidance il 3 marzo 2026; la versione definitiva è attesa entro il 2026. Chi eroga SaaS con dipendenze da elaborazioni cloud proprietarie dovrebbe verificare la propria posizione prima di settembre.

Le esenzioni principali

Restano fuori dal perimetro: i prodotti già regolati da quadri settoriali con requisiti equivalenti (dispositivi medici, aviazione, automotive), il software open source senza scopo commerciale, le attività di security research in buona fede e le pratiche di coordinated disclosure conformi alle linee guida ENISA.

Cosa scatta l'11 settembre 2026

L'articolo 14 del Regolamento (UE) 2024/2847 istituisce due distinti filoni di notifica obbligatoria, ciascuno con la propria catena di scadenze.

Vulnerabilità attivamente sfruttate — 24h → 72h → 14 giorni

Quando un produttore viene a conoscenza del fatto che una vulnerabilità nel proprio prodotto è attivamente sfruttata (exploited in the wild), scatta la catena (art. 14(1)-(2)):

  • Entro 24 ore: early warning a ENISA via Single Reporting Platform — identificazione del prodotto, natura generale della vulnerabilità, indicazione dello sfruttamento attivo.
  • Entro 72 ore: notifica dettagliata con classificazione, gravità, impatto potenziale, misure di mitigazione disponibili.
  • Entro 14 giorni: rapporto finale con analisi completa, piano di remediation, patch o workaround rilasciati.

Incidenti gravi — 24h → 72h → 1 mese

Per gli incidenti di sicurezza gravi che impattano il prodotto, le prime due fasi sono identiche; il rapporto finale ha una finestra più ampia (art. 14(3)-(5)):

  • Entro 24 ore: early warning.
  • Entro 72 ore: notifica dettagliata.
  • Entro 1 mese: rapporto finale.

Le due timeline si sovrappongono spesso: un incidente grave è quasi sempre associato a una vulnerabilità sfruttata. In quel caso si applicano entrambe le catene in parallelo.

La Single Reporting Platform ENISA

Una sola notifica, due destinatari

L'articolo 16 del CRA istituisce la Single Reporting Platform (SRP), gestita da ENISA. Il principio è "notifica una volta, raggiunge tutti": l'invio tramite SRP trasmette automaticamente l'informazione sia a ENISA sia al CSIRT coordinatore dello Stato membro dove il produttore ha la sede principale nell'UE.

Per le PMI italiane il CSIRT coordinatore è ACN — Agenzia per la Cybersicurezza Nazionale. Non è necessario notificare separatamente ACN se si utilizza la SRP. La piattaforma sarà operativa l'11 settembre 2026; il manuale operativo e il materiale formativo saranno disponibili entro giugno 2026.

I campi richiesti per fase

I campi differiscono tra le tre fasi: l'early warning richiede identificazione del prodotto e conferma dello sfruttamento attivo; la notifica delle 72 ore aggiunge CVE (se disponibile), impatto sugli utenti finali e misure di mitigazione; il rapporto finale include root cause, patch rilasciata con numero di versione e lezioni apprese. Pre-compilare template distinti per ciascuna fase riduce drasticamente gli errori sotto pressione.

Cosa fare adesso

Con 98 giorni al via, il tempo è sufficiente — ma solo se si inizia ora.

  1. Censire i prodotti CRA-scope: inventario di ogni prodotto con elementi digitali distribuito nel mercato UE — software installabile, firmware, app mobile, IoT. Per ogni prodotto: verificare se ricade nelle esenzioni oppure, nel caso SaaS, se il "remote data processing" richiede un'analisi specifica.
  2. Identificare il CSIRT coordinatore: per le PMI italiane è ACN. Chi ha sedi in più Stati membri verifica sul registro ENISA dei CSIRT nazionali il coordinatore competente.
  3. Monitorare la SRP ENISA: il manuale è atteso a giugno 2026. Seguire enisa.europa.eu per i materiali di onboarding.
  4. Definire i trigger interni: cosa costituisce "vulnerabilità attivamente sfruttata" ai fini del CRA? Servono criteri documentati — exploit pubblico confermato, segnalazione da CERT/CSIRT, evidenze in threat intelligence — per distinguerla da un bug ordinario. Questi criteri vanno decisi prima di settembre, non durante un incidente.
  5. Costruire un processo di escalation 24/7: la scadenza delle 24 ore non rispetta weekend né festività. Occorre una reperibilità nominata con autorità di decisione e template pre-approvati per la prima notifica.
  6. Pre-compilare i template per le 3 fasi: early warning (24h), notifica dettagliata (72h), rapporto finale — campi diversi per ciascuna, prepararli ora riduce errori sotto pressione.

Chi gestisce già obblighi di notifica NIS 2 può integrare parzialmente i due processi: la logica a cascata è analoga, anche se i destinatari e i trigger differiscono. Vedi NIS 2 Italia: le scadenze del 31 ottobre 2026 per il confronto operativo.

Le sanzioni

L'articolo 64 del Regolamento (UE) 2024/2847 prevede tre livelli sanzionatori:

  • Tier 1 — violazione degli obblighi essenziali di sicurezza, inclusi gli obblighi di notifica dell'articolo 14: €15 milioni o 2,5% del fatturato mondiale annuo, si applica il maggiore.
  • Tier 2 — altre violazioni del Regolamento: €10 milioni o 2% del fatturato mondiale annuo.
  • Tier 3 — informazioni false o fuorvianti alle autorità di vigilanza: €5 milioni o 1% del fatturato mondiale annuo.

Una precisazione per le micro e piccole imprese: non possono essere sanzionate per il mancato rispetto delle scadenze di notifica — le 24 ore per l'early warning di una vulnerabilità attivamente sfruttata (art. 14(2)(a)) e le 24 ore per l'early warning di un incidente grave (art. 14(4)(a)). L'obbligo di notificare esiste in ogni caso: l'esenzione riguarda le sanzioni per ritardo, non l'esonero dall'obbligo in sé.

Fonti