CRA vs NIS2: differenze, chi rientra e notifiche

Il Cyber Resilience Act (regolamento UE 2024/2847) regola i prodotti con elementi digitali che un'azienda mette sul mercato europeo; la NIS2 (direttiva UE 2022/2555, in Italia D.Lgs. 138/2024) regola la sicurezza dei sistemi e dei servizi dei soggetti essenziali e importanti. Il CRA guarda al prodotto, la NIS2 all'organizzazione: un produttore di elettronica o di macchinari di media dimensione può doverle rispettare entrambe.

Il legislatore europeo lo dice nel considerando 3 del CRA: il diritto UE in materia di cibersicurezza, NIS2 compresa, "non contempla direttamente requisiti obbligatori per la sicurezza dei prodotti con elementi digitali". Il CRA nasce per coprire quel vuoto, non per sostituire la NIS2. Qui sotto il confronto punto per punto e i casi in cui si applicano tutte e due.

CRA e NIS2 in otto punti

• Oggetto. CRA: la cibersicurezza dei prodotti hardware e software con una connessione dati a un dispositivo o a una rete. NIS2: la gestione dei rischi per i sistemi informativi e di rete con cui un soggetto svolge le sue attività e fornisce i suoi servizi.
• Tipo di atto. CRA: regolamento, si applica direttamente in tutti gli Stati membri. NIS2: direttiva, in Italia recepita con il D.Lgs. 138/2024.
• Chi è obbligato. CRA: gli operatori economici della filiera del prodotto, soprattutto il fabbricante, ma anche importatori e distributori. NIS2: i soggetti dei settori degli allegati I e II, di norma dalla media impresa in su, più alcune categorie a prescindere dalle dimensioni.
• Obblighi principali. CRA: requisiti essenziali dell'Allegato I sul prodotto e sulla gestione delle vulnerabilità, valutazione della conformità, marcatura CE. NIS2: misure di gestione dei rischi (articolo 21), responsabilità degli organi di gestione (articolo 20), notifica degli incidenti significativi (articolo 23).
• Cosa si segnala. CRA: vulnerabilità attivamente sfruttate e incidenti gravi che hanno un impatto sulla sicurezza del prodotto. NIS2: incidenti con impatto significativo sui servizi del soggetto.
• A chi. CRA: al CSIRT designato come coordinatore e all'ENISA, tramite una piattaforma unica di segnalazione. NIS2: al CSIRT nazionale, in Italia il CSIRT Italia.
• Sanzioni. CRA: fino a 15 milioni di euro o al 2,5% del fatturato mondiale annuo per i requisiti essenziali e gli obblighi degli articoli 13 e 14. NIS2 in Italia: fino a 10 milioni o 2% per i soggetti essenziali, fino a 7 milioni o 1,4% per gli importanti.
• Date. CRA: obblighi di segnalazione dall'11 settembre 2026, applicazione generale dall'11 dicembre 2027. NIS2: la direttiva chiedeva agli Stati membri di applicare le norme nazionali dal 18 ottobre 2024 (articolo 41).

Due logiche diverse: il prodotto e l'organizzazione

Il CRA è una norma di mercato, costruita sul modello della marcatura CE. L'articolo 2 lo applica ai prodotti con elementi digitali la cui finalità prevista o il cui utilizzo ragionevolmente prevedibile include una connessione dati, diretta o indiretta, a un dispositivo o a una rete. Gli obblighi seguono il prodotto per tutto il periodo di assistenza, che l'articolo 13 fissa di regola in almeno cinque anni.

La NIS2 è una norma sull'organizzazione. L'articolo 21 della direttiva chiede ai soggetti essenziali e importanti misure tecniche, operative e organizzative adeguate e proporzionate per gestire i rischi sui sistemi che usano nelle loro attività.

Nel CRA il soggetto obbligato si individua dal ruolo nella filiera del prodotto, a qualunque dimensione: anche una piccola software house che vende un'app per comandare un apparato è fabbricante. Nella NIS2 conta il settore e, di regola, la dimensione: l'articolo 3 del D.Lgs. 138/2024 riguarda i soggetti degli allegati I e II che superano i massimali per le piccole imprese della raccomandazione 2003/361/CE.

Chi rientra in cosa

Solo nel CRA

Chi immette sul mercato prodotti con elementi digitali senza appartenere a un settore NIS2, oppure senza superarne le soglie. Esempi tipici: una piccola impresa che produce sensori connessi, un'azienda che rivende con il proprio marchio telecamere IP prodotte da altri (l'articolo 21 del CRA la considera fabbricante), uno sviluppatore di software installato presso il cliente. Per capire se il proprio prodotto è dentro, e in quale classe, il riferimento è la nostra guida al Cyber Resilience Act.

Solo nella NIS2

Chi rientra in un settore degli allegati, ha le dimensioni previste e non mette sul mercato prodotti con elementi digitali: un ospedale, un'azienda di trasporti, un'impresa alimentare, un fornitore di servizi gestiti. Il dettaglio di settori e soglie è in a chi si applica la NIS2.

In tutte e due

Il caso più frequente nel mid-market industriale. L'allegato II della NIS2, alla voce fabbricazione, comprende tra gli altri la fabbricazione di computer e prodotti di elettronica e ottica, di apparecchiature elettriche e di macchinari (divisioni 26, 27 e 28 della NACE Rev. 2). Un'azienda di media dimensione in queste divisioni, che vende macchine o apparati con software e connettività, è soggetto NIS2 per i propri sistemi e fabbricante CRA per i prodotti che vende.

Il caso del software in abbonamento

Il considerando 12 del CRA traccia il confine. Le funzionalità cloud fornite dal fabbricante per far funzionare il prodotto, come il controllo a distanza di un dispositivo per la casa intelligente, rientrano nel CRA come soluzioni di elaborazione dati da remoto. I servizi cloud la cui progettazione e il cui sviluppo esulano dalla responsabilità del fabbricante restano fuori, e ai modelli SaaS, PaaS e IaaS si applica la NIS2, che copre i fornitori di servizi di cloud computing dalla media impresa in su.

Le segnalazioni: tempi simili, eventi diversi

Le scansioni temporali sono quasi identiche, ma l'evento che fa partire l'orologio non è lo stesso.

CRA, articolo 14

Il fabbricante notifica ogni vulnerabilità attivamente sfruttata contenuta nel suo prodotto e ogni incidente grave che ha un impatto sulla sicurezza del prodotto. La sequenza:

1. preallarme entro 24 ore da quando ne è venuto a conoscenza;
2. notifica entro 72 ore;
3. relazione finale entro 14 giorni dalla messa a disposizione di una misura correttiva o di attenuazione, per la vulnerabilità, o entro un mese dalla notifica, per l'incidente grave.

La notifica va contemporaneamente al CSIRT designato come coordinatore e all'ENISA, attraverso la piattaforma unica di segnalazione dell'articolo 16. Il CRA definisce quel CSIRT con un rinvio all'articolo 12 della NIS2, e in Italia l'articolo 16 del D.Lgs. 138/2024 designa come coordinatore il CSIRT Italia: per un fabbricante con stabilimento principale in Italia il terminale di riferimento è quindi quello del CSIRT Italia. Gli obblighi dell'articolo 14 si applicano dall'11 settembre 2026 e, per l'articolo 69, anche ai prodotti già sul mercato. Le date intermedie sono in scadenze CRA 2026 e 2027.

NIS2, articolo 23 (in Italia articolo 25 del D.Lgs. 138/2024)

Il soggetto essenziale o importante notifica al CSIRT Italia ogni incidente che ha un impatto significativo sulla fornitura dei suoi servizi: pre-notifica entro 24 ore, notifica entro 72 ore, relazione finale entro un mese dalla notifica. La procedura è descritta in notifica degli incidenti NIS2.

Quando scattano tutte e due

Nella nostra lettura, un'azienda che è insieme soggetto NIS2 e fabbricante CRA può trovarsi a notificare lo stesso episodio due volte, con contenuti diversi. Un esempio: l'azienda vende ai clienti un software di supervisione per le sue macchine e lo usa anche nei propri stabilimenti; una vulnerabilità di quel software viene sfruttata e ferma la produzione interna. Il fermo è un possibile incidente significativo NIS2; lo sfruttamento della vulnerabilità nel prodotto venduto è una notifica CRA, che riguarda anche i clienti che lo hanno installato. Se ci sono di mezzo dati personali, si aggiunge il Garante, come spiegato in NIS2 vs GDPR. Una notifica non sostituisce l'altra.

Dove si incontrano: la catena di fornitura

L'articolo 21 della NIS2 chiede ai soggetti obbligati di occuparsi della sicurezza della catena di approvvigionamento e della sicurezza nell'acquisizione, nello sviluppo e nella manutenzione dei sistemi, compresa la gestione delle vulnerabilità. Il paragrafo 3 aggiunge che, nel valutare le misure, vanno considerate le vulnerabilità specifiche di ogni fornitore diretto e la qualità complessiva dei prodotti e delle pratiche di cibersicurezza dei fornitori, comprese le procedure di sviluppo sicuro.

Il CRA risponde dall'altro lato. Il considerando 24 spiega che il regolamento mira anche a facilitare il rispetto dei requisiti NIS2 sulla catena di approvvigionamento da parte dei fornitori di infrastrutture digitali, garantendo che i prodotti che usano per i loro servizi siano sviluppati in modo sicuro e abbiano accesso ad aggiornamenti di sicurezza tempestivi. L'articolo 5 chiede agli Stati membri di tenere conto, negli appalti pubblici, della conformità ai requisiti essenziali e della capacità del fabbricante di gestire le vulnerabilità.

Per un fornitore, nella nostra lettura, questo significa che le domande sul CRA arriveranno prima dai clienti NIS2 che dalle autorità: distinta base del software, politica di divulgazione delle vulnerabilità, periodo di assistenza, tempi di rilascio delle patch. Come impostare il presidio dei fornitori dal lato cliente è spiegato in NIS2 e fornitori.

Sanzioni e autorità

Le autorità sono diverse e lo restano anche per la stessa azienda.

• CRA. L'applicazione spetta alle autorità di vigilanza del mercato designate da ciascuno Stato membro (articolo 52). L'articolo 64 fissa i massimali: 15 milioni di euro o 2,5% del fatturato mondiale annuo per i requisiti essenziali e gli obblighi degli articoli 13 e 14; 10 milioni o 2% per altri obblighi, tra cui quelli di importatori e distributori; 5 milioni o 1% per informazioni inesatte, incomplete o fuorvianti. Il paragrafo 10, nel testo rettificato il 2 luglio 2025, esclude in deroga ai paragrafi da 2 a 9 le sanzioni pecuniarie per micro e piccole imprese fabbricanti che mancano il termine di 24 ore, e per i gestori di software open source.
• NIS2. In Italia l'autorità è ACN. L'articolo 38 del D.Lgs. 138/2024 prevede fino a 10 milioni di euro o 2% del fatturato annuo mondiale per i soggetti essenziali e fino a 7 milioni o 1,4% per gli importanti, sulle violazioni degli obblighi di governance, misure e notifica.

Nei due testi non c'è una clausola di coordinamento delle sanzioni come quella che la NIS2 prevede verso il GDPR all'articolo 35. Nella nostra lettura il motivo è che puniscono violazioni diverse: un prodotto non conforme da una parte, un'organizzazione senza misure adeguate dall'altra.

Come impostare il lavoro se rientri in entrambe

Due norme e due autorità, ma molte attività in comune. Cinque passi.

1. Separa i due inventari, poi incrociali. Da una parte i sistemi e i servizi che contano per la NIS2, dall'altra i prodotti con elementi digitali che vendi con il tuo marchio. Segna dove si toccano: ambienti di sviluppo, server di aggiornamento, piattaforme di assistenza remota.
2. Un solo processo di gestione delle vulnerabilità, con due uscite: le correzioni sui sistemi interni per la NIS2, gli aggiornamenti di sicurezza sui prodotti per il CRA, con la distinta base del software dell'Allegato I.
3. Una procedura incidenti con un passaggio di classificazione in più. Al primo triage si decide se l'evento è significativo per la NIS2, se è una vulnerabilità attivamente sfruttata o un incidente grave di prodotto per il CRA, se tocca dati personali. Le notifiche partono in parallelo, ciascuna con i suoi contenuti.
4. Monitoraggio continuo. Il preallarme a 24 ore, in tutte e due le norme, presuppone di accorgersi dell'evento in tempo. Serve un rilevamento attivo anche di notte e nel fine settimana.
5. Una sola regia di governance. L'articolo 20 della NIS2 chiede agli organi di gestione di approvare le misure e sovrintendere alla loro attuazione; conviene che lo stesso comitato segua anche il piano CRA.

Se stai valutando come organizzare rilevamento, gestione delle vulnerabilità e risposta agli incidenti per reggere sia la NIS2 sia gli obblighi di segnalazione del CRA, trovi il nostro approccio nella pagina cybersecurity.