Cyber Resilience Act: cosa cambia per i produttori di dispositivi OT e IoT

Cosa è il CRA e a chi si applica

Il Regolamento UE sulla Resilienza Informatica (Cyber Resilience Act, CRA) è entrato in vigore nel 2024 e diventa pienamente applicabile nel 2027. È il primo atto legislativo europeo che impone requisiti di cybersecurity direttamente ai produttori di prodotti con elementi digitali: dall'hardware al software, dai dispositivi connessi alle componenti.

La logica del CRA è diversa da quella di NIS2 o DORA: non si rivolge agli operatori che usano i prodotti, ma a chi li progetta e li vende. L'obiettivo è spostare la responsabilità della sicurezza verso l'origine della filiera, integrando la sicurezza nella progettazione del prodotto invece di lasciarla come problema dell'utilizzatore finale.

L'ambito di applicazione è ampio: tutti i prodotti con elementi digitali che vengono messi in commercio nel mercato europeo, salvo alcune eccezioni per prodotti già coperti da altra normativa settoriale. Per il mondo OT e IoT industriale, questo significa PLC, sensori connessi, gateway industriali, HMI, router industriali, sistemi embedded di controllo, software di supervisione.

Obblighi per i produttori: security by design, aggiornamenti, disclosure

Il CRA definisce tre categorie principali di obblighi.

Requisiti di sicurezza essenziali: il prodotto deve essere progettato e sviluppato con la sicurezza come requisito intrinseco, non aggiunta a posteriori. Questo include: superficie di attacco minimizzata, autenticazione robusta, nessuna credenziale di default, dati protetti a riposo e in transito, capacità di aggiornamento sicuro. Questi requisiti devono essere soddisfatti al momento dell'immissione sul mercato e dimostrabili attraverso documentazione tecnica.

Gestione delle vulnerabilità: i produttori devono implementare processi per identificare e risolvere le vulnerabilità nei loro prodotti durante l'intero ciclo di vita supportato. Questo significa un programma di vulnerability disclosure coordinata (VDP), la capacità di distribuire aggiornamenti di sicurezza in modo sicuro, e l'obbligo di notificare all'ENISA le vulnerabilità attivamente sfruttate entro 24 ore dalla scoperta.

Obblighi di trasparenza: documentazione tecnica completa, dichiarazione di conformità UE, marcatura CE, informazioni per l'utente finale su come mantenere il prodotto sicuro nel tempo.

Prodotti "importanti" e "critici": le categorie a rischio OT/IoT

Il CRA distingue tre categorie con requisiti di conformità diversi:

Prodotti standard: la maggior parte dei prodotti. Possono autocertificarsi seguendo le norme armonizzate CEN/CENELEC quando disponibili.

Prodotti importanti (Classe I e II): prodotti con profilo di rischio elevato. La Classe I può ancora autocertificarsi se applica standard armonizzati; la Classe II richiede il coinvolgimento di un organismo di valutazione di conformità terzo.

Prodotti critici: livello massimo. Richiedono schema europeo di certificazione della cybersecurity.

Per il mondo OT/IoT industriale, molti prodotti rientrano nelle categorie Classe I e II: sistemi operativi per uso industriale, hypervisor, router e switch industriali, microcontrollori con connettività, gateway IoT industriali. Alcuni sistemi di controllo per infrastrutture critiche potrebbero rientrare nella categoria critica.

Scadenze e periodo di transizione

Il Regolamento è in vigore da dicembre 2024. Le scadenze principali:

• Settembre 2026: obblighi di notifica delle vulnerabilità all'ENISA diventano applicabili.
• Dicembre 2027: tutti i requisiti del CRA diventano pienamente applicabili per i prodotti nuovi immessi sul mercato.

I prodotti già sul mercato prima di dicembre 2027 non devono essere ritirati, ma devono conformarsi nel caso di aggiornamenti sostanziali. I produttori con cicli di sviluppo lunghi, come spesso accade nell'OT industriale, devono iniziare ora per essere pronti.

Come prepararsi: dalla documentazione al processo

La conformità al CRA non è un esercizio di documentazione: è una trasformazione del processo di sviluppo del prodotto.

Audit del portafoglio prodotti: identificare quali prodotti rientrano nell'ambito CRA, a quale categoria appartengono, e qual è il gap tra lo stato attuale e i requisiti.

Secure development lifecycle (SDL): integrare i requisiti di sicurezza in ogni fase dello sviluppo: threat modeling in fase di design, code review sicura, penetration testing prima del rilascio, processo formale di gestione delle vulnerabilità post-rilascio.

Vulnerability disclosure program: stabilire un canale formale per la ricezione di segnalazioni di vulnerabilità da ricercatori e utenti, con processi definiti per la valutazione, la risoluzione e la comunicazione pubblica.

Documentazione tecnica: il CRA richiede una documentazione tecnica dettagliata del prodotto che dimostri la conformità ai requisiti essenziali. Non è un documento di marketing: deve includere analisi del rischio, descrizione delle misure di sicurezza implementate, test di verifica.

Per i produttori di dispositivi OT e IoT abituati a cicli di sviluppo lunghi e clienti con requisiti di stabilità, il CRA rappresenta un cambiamento culturale significativo. La sicurezza non può più essere un'aggiunta dell'ultimo momento o delegata all'utilizzatore finale: deve essere parte integrante del prodotto dalla prima riga di codice.

L'angolo MON5

Il CRA riguarda i produttori, ma i suoi effetti ricadono su chi i dispositivi li usa: più vulnerabilità verranno divulgate formalmente, più aggiornamenti di sicurezza andranno gestiti in impianto. Sapere quali prodotti e quali versioni firmware sono presenti in rete diventa la condizione per beneficiare dei nuovi obblighi dei vendor.

La fase ANALYZE di MON5 mantiene l'inventario continuo degli asset, correla le CVE pubblicate con i dispositivi realmente installati e supporta i percorsi di compliance CRA e NIS2. Per costruire questa visibilità prima delle scadenze del 2026 e 2027, inizia da un assessment OT.