CRA vs NIS2: differenze per produttori e operatori

Cyber Resilience Act e NIS2 sono due pilastri della nuova strategia europea sulla cybersecurity, ma regolano oggetti diversi: il primo riguarda i prodotti con elementi digitali, il secondo riguarda le organizzazioni che gestiscono servizi e infrastrutture critiche.

Il Cyber Resilience Act (Regolamento UE 2024/2847) introduce requisiti orizzontali di cybersecurity per prodotti software, hardware, componenti e soluzioni remote collegate al prodotto. L’obiettivo dichiarato dalla Commissione Europea è fare in modo che dispositivi e software siano progettati, aggiornati e mantenuti in sicurezza lungo il ciclo di vita.

La NIS2 (Direttiva UE 2022/2555) introduce invece misure di gestione del rischio, obblighi di notifica, supervisione e governance per soggetti essenziali e importanti in settori critici o rilevanti. La Commissione Europea chiarisce che NIS2 amplia il perimetro rispetto alla precedente direttiva e introduce misure di risk management e reporting per entità di più settori. In Italia, la direttiva è stata recepita con il D.Lgs. 4 settembre 2024, n. 138; ACN indica che la normativa copre 18 settori, di cui 11 altamente critici e 7 critici, distinguendo tra soggetti essenziali e soggetti importanti.

La domanda corretta non è quindi “CRA o NIS2?”. In molti casi la risposta dipende dal ruolo nella filiera: chi produce, importa o commercializza un prodotto con elementi digitali deve valutare il CRA; chi gestisce servizi, infrastrutture o reti in settori critici deve valutare la NIS2; chi fa entrambe le cose deve guardare a entrambi i quadri normativi.

ISGroup interviene sul punto comune tra i due regimi: le evidenze tecniche di sicurezza. Non come consulente legale né come ente certificatore, ma come partner tecnico-offensivo per verificare prodotti, ambienti, firmware, software, API, reti OT, accessi remoti e superfici esposte con penetration test, security assessment, reverse engineering e security auditing.

La differenza in sintesi

Norma	Focus	Domanda principale
Cyber Resilience Act	Prodotto con elementi digitali	Il prodotto è progettato, sviluppato, aggiornato e mantenuto in modo sicuro?
NIS2	Organizzazione / entità	L’organizzazione gestisce in modo adeguato il rischio cyber sui sistemi e servizi che utilizza o eroga?

Il CRA chiede al produttore di immettere sul mercato prodotti con meno vulnerabilità e con processi adeguati di gestione della sicurezza lungo il ciclo di vita. Il testo ufficiale del regolamento indica come obiettivo garantire che prodotti hardware e software siano immessi sul mercato con meno vulnerabilità e che i produttori prendano la sicurezza sul serio lungo il ciclo di vita del prodotto.

La NIS2 chiede invece a soggetti essenziali e importanti di adottare misure tecniche, operative e organizzative adeguate e proporzionate per gestire i rischi relativi alla sicurezza dei sistemi informativi e di rete usati per le loro attività o per l’erogazione dei servizi.

Confronto operativo: CRA vs NIS2

Criterio	Cyber Resilience Act	NIS2
Tipo di atto	Regolamento UE	Direttiva UE recepita dagli Stati membri
Oggetto	Prodotti con elementi digitali	Organizzazioni, servizi e sistemi informativi/rete
Focus principale	Sicurezza del prodotto	Gestione del rischio organizzativo
Soggetti principali	Produttori, importatori, distributori, operatori economici	Soggetti essenziali e importanti
Ambito	Software, hardware, componenti, prodotti connessi, remote data processing collegato al prodotto	Settori critici e rilevanti: energia, trasporti, sanità, digitale, manifattura critica, utility e altri
Logica	Secure by design, secure by default, gestione vulnerabilità, sicurezza del ciclo di vita	Governance, misure tecniche/operative/organizzative, incident reporting, sicurezza della supply chain
Tipo di evidenza	Documentazione tecnica, valutazione di conformità, test, gestione vulnerabilità, marcatura CE	Risk assessment, policy, controlli, incident handling, supply chain, verifica efficacia misure
Driver tecnico	Prodotto sicuro prima e dopo l’immissione sul mercato	Organizzazione resiliente e capace di gestire il rischio
Intersezione	Il prodotto sicuro riduce il rischio per chi lo usa	L’organizzazione deve governare anche il rischio introdotto dai prodotti e fornitori
Ruolo ISGroup	Verifica tecnica del prodotto: firmware, software, API, hardware, aggiornamenti, superfici esposte	Verifica tecnica dell’ambiente: OT, accessi remoti, reti, supply chain, segmentazione, sistemi esposti

Quando si applica il CRA

Il CRA si applica ai prodotti con elementi digitali messi a disposizione sul mercato europeo: prodotti software o hardware, incluse soluzioni di elaborazione dati da remoto e componenti software o hardware immessi separatamente sul mercato. Il testo del regolamento definisce il prodotto con elementi digitali come un prodotto software o hardware e le sue soluzioni remote di data processing, incluse componenti software o hardware immesse separatamente sul mercato.

Esempi tipici di prodotti coinvolti:

Dispositivi IoT;
Software commercializzato;
Firmware;
Gateway industriali;
Apparati embedded;
Componenti hardware e software;
Dispositivi smart e sistemi edge;
Prodotti connessi a cloud;
Soluzioni remote necessarie al funzionamento del prodotto;
Componenti destinati all’integrazione in altri sistemi.

Le scadenze operative sono già definite: il CRA è entrato in vigore il 10 dicembre 2024; gli obblighi di reporting per vulnerabilità attivamente sfruttate e incidenti gravi si applicano dall’11 settembre 2026; gli obblighi principali si applicano dall’11 dicembre 2027, come indicato dalla Commissione Europea.

Quando si applica la NIS2

La NIS2 si applica a soggetti essenziali e importanti che operano in settori considerati critici o rilevanti per la società e l’economia. La Commissione Europea sottolinea che NIS2 rafforza il livello comune di cybersecurity nell’UE tramite un perimetro più ampio, regole più chiare, strumenti di supervisione più forti, misure di risk management e obblighi di reporting. In Italia, ACN indica che la normativa NIS copre 18 settori e oltre 80 tipologie di soggetti, distinguendo tra soggetti essenziali e importanti.

Esempi di organizzazioni potenzialmente coinvolte:

Energia;
Trasporti;
Banche e infrastrutture dei mercati finanziari;
Sanità;
Acqua potabile e acque reflue;
Infrastrutture digitali e gestione servizi ICT;
Pubblica amministrazione, secondo perimetro nazionale;
Spazio;
Servizi postali e corrieri;
Gestione rifiuti;
Chimica e alimentare;
Manifattura di prodotti critici;
Fornitori digitali;
Ricerca, secondo condizioni applicabili.

La NIS2 non guarda solo al prodotto acquistato o venduto, ma alla capacità dell’organizzazione di gestire il rischio sui propri sistemi e servizi.

Il punto di contatto: la supply chain

Il punto di intersezione più rilevante tra CRA e NIS2 è la supply chain. Un’organizzazione soggetta a NIS2 può utilizzare prodotti digitali, dispositivi IoT, gateway industriali, software, firmware, sistemi OT, router, HMI, SCADA, cloud, API e componenti forniti da terzi. Se quei prodotti presentano vulnerabilità, l’organizzazione eredita una parte del rischio.

La NIS2 include la sicurezza della supply chain tra le misure di gestione del rischio e richiede di considerare aspetti legati ai rapporti con fornitori e service provider diretti, vulnerabilità specifiche, qualità complessiva dei prodotti e servizi e pratiche di cybersecurity dei fornitori. Il CRA, dall’altro lato, spinge i produttori a progettare, sviluppare e mantenere prodotti più sicuri lungo il ciclo di vita.

Ruolo	Norma più vicina	Rischio concreto
Produttore di gateway industriale	CRA	Il prodotto deve essere sviluppato e mantenuto con requisiti cyber adeguati
Utility che usa quel gateway	NIS2	Il gateway può diventare punto di ingresso verso l’ambiente operativo
System integrator	CRA / NIS2, a seconda del ruolo	Può introdurre componenti vulnerabili o accessi remoti rischiosi
OEM che vende macchine connesse	CRA + Regolamento Macchine	Il prodotto/macchina deve essere verificabile anche sul piano cyber
Operatore industriale	NIS2	Deve governare il rischio introdotto da prodotti, fornitori e connessioni

Quando un’azienda è sia produttore sia operatore

Molte aziende non rientrano in una sola categoria. Un gruppo industriale può produrre macchine connesse, gestire stabilimenti, offrire manutenzione remota ai clienti, vendere dispositivi IoT, usare piattaforme cloud e operare in un settore NIS2. In questi casi, l’azienda può trovarsi a dover rispettare entrambi i quadri normativi.

Scenario	Possibile impatto normativo
Produzione di un dispositivo connesso	Valutare il CRA
Utilizzo di quel dispositivo in un impianto critico	Valutarlo come parte del rischio NIS2
Offerta di manutenzione remota	Verificare accessi, credenziali, logging e segmentazione
Commercializzazione con proprio marchio di un prodotto sviluppato da terzi	Possibile assunzione di obblighi come operatore economico nel CRA
Gestione di ambienti OT	Misurare il rischio reale su reti, asset, segmenti e accessi
Fornitura a un soggetto NIS2	Prodotti e processi possono essere valutati nella supply chain del cliente

CRA e NIS2 non si escludono: guardano lati diversi dello stesso ecosistema. Il CRA chiede se il prodotto è sicuro; la NIS2 chiede se l’organizzazione governa il rischio cyber. Quando un prodotto vulnerabile entra in un’organizzazione critica, i due ambiti si incontrano.

Matrice di autovalutazione: produttore, operatore o entrambi

Situazione	Domanda da porsi	Norma da approfondire	Verifica tecnica utile
Produzione di software o hardware connesso	Il prodotto rientra tra i prodotti con elementi digitali?	CRA	Product security assessment, code review, firmware analysis
Importazione o distribuzione di prodotti digitali	È possibile dimostrare che il prodotto rispetta i requisiti applicabili?	CRA	Technical security review, vulnerability assessment
Gestione di infrastrutture o servizi critici	L’organizzazione rientra tra soggetti essenziali o importanti?	NIS2	Risk assessment tecnico, security assessment, penetration test
Gestione di ambienti OT	L’OT è incluso nella gestione del rischio?	NIS2 + IEC 62443	OT security assessment, segmentation review
Utilizzo di prodotti di terzi in ambienti critici	Il rischio dei fornitori è stato valutato?	NIS2 + CRA come driver supply chain	Supplier security review, product assessment
Produzione di macchine connesse	Il prodotto/macchina introduce rischio digitale?	CRA + Regolamento Macchine	IoT/OT assessment, firmware test, accesso remoto
Offerta di teleassistenza	Gli accessi remoti sono controllati e tracciati?	NIS2 / Regolamento Macchine / IEC 62443	Remote Access Security Review
Ruolo di produttore e operatore contemporaneamente	È necessario governare sia il prodotto sia l’organizzazione?	CRA + NIS2	Assessment integrato prodotto + ambiente

Evidenze tecniche: cosa chiedono CRA e NIS2 in concreto

CRA e NIS2 hanno oggetti diversi, ma convergono su un punto: la cybersecurity deve essere dimostrabile. Il CRA richiede che i produttori considerino la sicurezza nel ciclo di vita dei prodotti con elementi digitali, con requisiti relativi a progettazione, sviluppo, produzione, gestione delle vulnerabilità e documentazione tecnica, come indicato dalla Commissione Europea. La NIS2 richiede misure tecniche, operative e organizzative proporzionate per gestire i rischi, incluse policy e procedure per valutare l’efficacia delle misure adottate.

In entrambi i casi, la domanda concreta diventa: quali evidenze tecniche sono disponibili per dimostrare che il rischio è stato valutato e che i controlli funzionano?

Esempi di evidenze rilevanti:

Penetration test report;
Vulnerability assessment;
Firmware security assessment;
Reverse engineering report;
Source code review;
API security testing;
Mobile app security testing;
Backend security assessment;
OT security assessment;
Segmentation validation;
Remote access review;
Threat model;
Remediation plan e re-test report;
Evidenza di gestione delle vulnerabilità.

Queste evidenze non certificano automaticamente la conformità, ma rendono il percorso molto più solido trasformando una dichiarazione in una verifica documentata.

Esigenza	Nel CRA	Nella NIS2	Verifica ISGroup
Progettazione sicura	Progettazione sicura del prodotto	Misure tecniche proporzionate	Threat modeling, architecture review
Gestione delle vulnerabilità	Gestione vulnerabilità del prodotto	Gestione rischio e vulnerabilità sui sistemi	Vulnerability assessment, remediation tracking
Controllo degli accessi	Protezione accessi al prodotto	Controllo accessi sui sistemi	Penetration test, privilege review
Sicurezza della supply chain	Qualità e sicurezza del prodotto immesso sul mercato	Valutazione fornitori e service provider	Supplier access review, product assessment
Gestione degli incidenti	Reporting vulnerabilità/incidenti sul prodotto	Incident handling e reporting organizzativo	Logging review, detection test, tabletop tecnico
Sicurezza degli aggiornamenti	Aggiornamenti sicuri del prodotto	Patch e manutenzione sicura dei sistemi	Firmware assessment, update mechanism test
Rischio OT e industriale	Prodotti connessi industriali	Ambienti OT e servizi critici	OT Security Assessment
Efficacia dei controlli	Test e review del prodotto	Valutazione efficacia misure	Penetration test, re-test, validation

Conformità NIS2 e prodotti vulnerabili: perché non bastano le policy

Un’organizzazione può avere un buon sistema di governance e usare prodotti non testati. Esempi concreti: gateway industriale con firmware vulnerabile, router LTE con password di default, HMI accessibile da rete non autorizzata, API cloud esposte, aggiornamenti firmware non firmati, app mobile con token salvati in chiaro, dispositivo IoT usato come ponte verso OT, accesso remoto fornitore non tracciato.

In questi casi il problema non riguarda solo il produttore: diventa rischio operativo per chi usa quel prodotto. La NIS2 chiede di gestire il rischio dell’organizzazione, inclusi gli aspetti di supply chain; il CRA spinge i produttori a migliorare la sicurezza dei prodotti digitali. Le due logiche si completano.

Conformità CRA e integrazione in ambienti critici: perché non basta il prodotto sicuro

Vale anche il ragionamento inverso. Un prodotto progettato secondo i requisiti CRA può essere integrato in modo non sicuro: installato in una rete piatta, configurato senza autenticazione a più fattori, con chiavi API condivise tra più utenti, con processi interni di patch non gestiti, con log non raccolti, con accesso remoto lasciato sempre aperto o con segmentazione teorica ma firewall configurato male.

Il CRA lavora sulla sicurezza del prodotto; la NIS2 richiede che l’organizzazione gestisca il rischio nel proprio contesto operativo. Anche un prodotto tecnicamente valido va verificato nel modo in cui viene installato, configurato, usato, aggiornato e integrato.

Il ruolo della IEC 62443 negli ambienti industriali

Per ambienti industriali e OT, la IEC 62443 è il riferimento tecnico che aiuta a tradurre obblighi normativi in controlli pratici e verificabili. Copre zone e conduit, segmentazione IT/OT, security level, controllo degli accessi, integrità dei sistemi, flusso dati ristretto, secure development lifecycle, sicurezza dei componenti, gestione di fornitori e service provider, e controlli compensativi per ambienti legacy.

Tema	CRA	NIS2	IEC 62443
Prodotto industriale	Requisiti di cybersecurity del prodotto	Rischio introdotto nella supply chain	62443-4-1 / 4-2
Ambiente OT	Non è il focus primario	Gestione rischio dell’organizzazione	62443-2-1 / 3-2 / 3-3
Fornitore / integratore	Operatore economico se immette prodotti	Supply chain e service provider	62443-2-4
Validazione	Test e review del prodotto	Valutazione efficacia misure	Assessment e penetration test

La IEC 62443 non sostituisce CRA o NIS2, ma aiuta a rendere tecnici, misurabili e verificabili alcuni controlli richiesti da entrambi.

Casi applicativi

Produttore di gateway industriale

Un’azienda produce un gateway industriale 5G per collegare macchine, cloud e rete OT. Il prodotto include firmware, interfaccia web, API, VPN, connettività radio, account tecnici, aggiornamento remoto e dashboard cloud. Il CRA è centrale: il gateway è un prodotto con elementi digitali e devono essere valutati sicurezza by design, gestione delle vulnerabilità, aggiornamenti, documentazione tecnica e sicurezza del ciclo di vita.

Verifiche tecniche consigliate: firmware security assessment, reverse engineering, API security testing, test del meccanismo di aggiornamento, hardware security testing, vulnerability assessment, penetration test applicativo, review di credenziali e accessi remoti. Se quel gateway viene venduto a un operatore NIS2, la sua sicurezza diventa anche un tema di supply chain per il cliente.

Utility che usa dispositivi IoT di terzi

Una utility soggetta a NIS2 usa sensori IoT, gateway LTE e dashboard cloud di fornitori diversi. Il problema principale non è produrre il dispositivo, ma governare il rischio introdotto da quei dispositivi nell’ambiente operativo. Verifiche consigliate: supplier security review, assessment del gateway, controllo degli accessi remoti, segmentazione IT/OT, API/backend security testing, verifica del logging, penetration test OT mirato, remediation e re-test. Il CRA riguarda i produttori dei dispositivi; la NIS2 riguarda l’utility che li usa nel proprio ambiente.

OEM di macchine connesse

Un OEM produce macchine industriali con accesso remoto, telemetria, firmware aggiornabile e dashboard cloud. I livelli normativi potenzialmente coinvolti sono il CRA per componenti digitali e software, il Regolamento Macchine per safety e modifiche digitali rilevanti, la NIS2 se l’OEM rientra come soggetto essenziale/importante o come fornitore critico, e la IEC 62443 come riferimento tecnico industriale. Verifiche consigliate: IoT/OT Security Assessment, penetration test su macchina connessa, firmware analysis, protocol security testing, Remote Access Security Review, source code review, backend/API security testing, re-test post-remediation.

Errori da evitare nella gestione di CRA e NIS2

Ridurre CRA e NIS2 a checklist documentali. Policy, procedure e documentazione servono, ma non dimostrano da sole che un prodotto o un ambiente siano resistenti a un attacco.

Pensare che una norma escluda l’altra. CRA e NIS2 guardano oggetti diversi. Un prodotto può rientrare nel CRA e diventare parte del rischio NIS2 per chi lo usa.

Aspettare le scadenze finali. Il CRA prevede obblighi di reporting dall’11 settembre 2026 e obblighi principali dall’11 dicembre 2027. Un redesign firmware, un aggiornamento sicuro o una revisione architetturale richiedono tempo.

Confondere certificazione e verifica tecnica. Una certificazione o una dichiarazione non sostituiscono un test tecnico. ISGroup non certifica prodotti o organizzazioni: produce evidenze tecniche.

Trascurare l’OT. In ambienti industriali, il rischio non vive solo su server e laptop, ma anche su PLC, HMI, gateway, accessi remoti, firmware, protocolli e reti industriali.

Il ruolo di ISGroup

ISGroup supporta aziende che sviluppano, integrano, vendono o utilizzano prodotti digitali, dispositivi IoT, gateway industriali, sistemi OT e macchine connesse con attività tecniche ad alto valore. Le attività includono IoT/OT Security Assessment, penetration test OT e su prodotti connessi, firmware security assessment, reverse engineering, hardware security testing, software security testing, source code review, API security testing, mobile app security testing, backend security assessment, protocol security testing, Remote Access Security Review, supplier access review, vulnerability assessment, security auditing, remediation plan e re-test.

ISGroup non vende “conformità CRA” o “adeguamento NIS2 chiavi in mano”. Interviene dove CRA e NIS2 diventano concreti: testare prodotti, ambienti e superfici d’attacco per produrre evidenze tecniche di sicurezza.

Richiedi una valutazione tecnica adatta al tuo scenario: prodotto, ambiente o entrambi. ISGroup verifica dispositivi IoT, macchine connesse, firmware, software, API, backend, accessi remoti e reti OT con metodologie offensive controllate.

Domande frequenti su CRA e NIS2

CRA e NIS2 regolano la stessa cosa?
No. Il Cyber Resilience Act riguarda i prodotti con elementi digitali: software, hardware, componenti e soluzioni remote collegate al prodotto. La NIS2 riguarda organizzazioni, sistemi, servizi e misure di gestione del rischio cyber per soggetti essenziali e importanti. Sono strumenti complementari, non alternativi.
Un’organizzazione conforme alla NIS2 è automaticamente a posto con il CRA?
No. Un programma NIS2 maturo non copre gli obblighi CRA applicabili a chi produce o commercializza prodotti con elementi digitali. I due quadri normativi richiedono valutazioni distinte.
Un prodotto CRA compliant può essere usato senza ulteriori verifiche da un operatore NIS2?
Non necessariamente. Il CRA riguarda la sicurezza del prodotto; la NIS2 riguarda il rischio nel contesto operativo dell’organizzazione. Un prodotto sicuro può essere installato, configurato o integrato in modo non sicuro, e questo rimane responsabilità dell’operatore.
Dove si intersecano concretamente CRA e NIS2?
Soprattutto nella supply chain. La NIS2 richiede di considerare la sicurezza della catena di fornitura e dei fornitori diretti; il CRA spinge i produttori a sviluppare e mantenere prodotti digitali più sicuri. Un prodotto vulnerabile usato da un soggetto NIS2 è il caso tipico in cui i due ambiti si incontrano.
Quali evidenze tecniche servono per CRA e NIS2?
Dipende dal caso. Possono essere necessari penetration test report, firmware analysis, source code review, API security testing, OT security assessment, segmentation validation, remote access review, vulnerability assessment, remediation plan e re-test. Le evidenze non certificano la conformità, ma la rendono dimostrabile e verificabile.