Cyber Resilience Act con Odoo: conformità dei prodotti connessi entro il 2027 (guida PMI manifattura)

Settantaduesima guida operativa Odoo 19 per PMI italiane. Il Cyber Resilience Act (CRA, Regolamento UE 2024/2847 sulla resilienza informatica) è in vigore da dicembre 2024 e si applicherà pienamente dall’11 dicembre 2027: impone requisiti di sicurezza informatica a tutti i “prodotti con elementi digitali” immessi sul mercato UE. I prodotti intelligenti realizzati dalle PMI italiane (macchinari connessi, dispositivi IoT, software integrato nei prodotti) rientrano nell’ambito. Senza conformità niente marcatura CE, e senza marcatura CE niente vendita nell’UE. Le sanzioni arrivano fino a 15 milioni di € o al 2,5% del fatturato mondiale. Chi produce prodotti connessi deve iniziare a prepararsi adesso: in questa guida vediamo come affrontare il CRA con Odoo 19.

Vediamo: l’ambito del CRA, le categorie di prodotto, i requisiti di sicurezza fin dalla progettazione, la gestione delle vulnerabilità, gli obblighi dopo la vendita, la distinta base del software (SBOM) ed esempi illustrativi per PMI manifatturiere.

L’ambito del CRA

Cos’è un “prodotto con elementi digitali”

• Prodotti software
• Hardware con software
• Dispositivi connessi
• Prodotti IoT (Internet delle cose)
• Componenti hardware o software immessi sul mercato separatamente

Esclusioni

• Software libero sviluppato o fornito al di fuori di un’attività commerciale
• Dispositivi medici e diagnostici in vitro (regolamenti MDR e IVDR)
• Veicoli a motore (normativa specifica)
• Aviazione civile ed equipaggiamento marittimo (normativa specifica)
• Prodotti sviluppati esclusivamente per sicurezza nazionale o difesa
• Servizi in cloud (SaaS) in quanto tali, coperti dalla direttiva NIS2, salvo le soluzioni di elaborazione remota dei dati necessarie al prodotto

Esempi nella manifattura italiana

• Macchinario industriale con pannello operatore (HMI) e connettività
• Elettrodomestici intelligenti
• Dispositivi IoT industriali
• Sensori industriali connessi
• Software integrato in prodotti hardware (firmware)
• Robot industriali con software e connettività

Le categorie di prodotto del CRA

Categoria predefinita

• Autovalutazione della conformità (controllo interno)
• La maggior parte dei prodotti di consumo e industriali
• Marcatura CE e dichiarazione UE di conformità

Prodotti importanti di classe I

• Autovalutazione solo se si applicano integralmente norme armonizzate o certificazioni riconosciute, altrimenti organismo terzo
• Esempi: sistemi di gestione delle identità, browser, gestori di password, antivirus, VPN, sistemi operativi, router, prodotti per la casa intelligente con funzioni di sicurezza (serrature, videocamere)

Prodotti importanti di classe II

• Valutazione della conformità da parte di un organismo terzo obbligatoria
• Esempi: hypervisor e ambienti di esecuzione dei container, firewall, sistemi di rilevamento e prevenzione delle intrusioni, microprocessori e microcontrollori a prova di manomissione

Prodotti critici

• Certificazione europea di sicurezza informatica, quando richiesta dagli atti delegati
• Moduli di sicurezza hardware (HSM), gateway per contatori intelligenti, smart card ed elementi sicuri

Scadenze di applicazione

11 dicembre 2027

• Applicazione completa dei requisiti
• Marcatura CE con requisiti CRA obbligatoria per i prodotti nell’ambito

11 settembre 2026

• Obbligo di segnalazione delle vulnerabilità attivamente sfruttate
• Obbligo di segnalazione degli incidenti gravi
• Vale anche per i prodotti già sul mercato

Periodo transitorio

• Tempo per prepararsi (dall’11 giugno 2026 si applicano le norme sugli organismi notificati)
• Norme tecniche armonizzate in fase di stesura
• Pubblicazione progressiva di linee guida

Sicurezza fin dalla progettazione

Ogni prodotto connesso deve dimostrare “sicurezza fin dalla progettazione e per impostazione predefinita” (security by design e by default). La scheda prodotto in Odoo, insieme alla gestione delle modifiche tecniche di PLM (in Enterprise), può documentare scelte progettuali, analisi delle minacce, funzioni di sicurezza e certificazioni applicabili:

• Specifiche dei requisiti di sicurezza
• Documentazione dell’analisi delle minacce (threat model)
• Funzioni di sicurezza implementate
• Crittografia utilizzata e gestione delle chiavi
• Meccanismi di autenticazione
• Configurazione predefinita sicura
• Meccanismo di aggiornamento sicuro

Produzione con controlli di sicurezza integrati

L’ordine di produzione (MO) dei prodotti connessi deve includere controlli di sicurezza e un caricamento sicuro di chiavi e credenziali (provisioning). La filiera della sicurezza (chip, firmware, certificati) richiede tracciabilità completa: in Odoo si usano numeri di serie, lotti e i controlli dell’app Quality (in Enterprise):

• Fasi di provisioning sicuro
• Gestione delle chiavi crittografiche
• Credenziali uniche per dispositivo, nessuna password predefinita comune
• Controllo della versione del firmware per numero di serie
• Controllo qualità delle funzioni di sicurezza
• Registro delle operazioni di provisioning

SBOM (Software Bill of Materials)

Il CRA richiede al fabbricante di redigere una SBOM, cioè la distinta base del software, in un formato leggibile da una macchina e comprendente almeno le dipendenze di primo livello; fa parte della documentazione tecnica e non deve essere necessariamente pubblicata. La distinta base di Odoo, estesa con i componenti software, può fare da punto di raccordo con gli strumenti che generano la SBOM:

• Componenti software individuati
• Versione specifica di ogni componente
• Licenza e limitazioni (utile, anche se non richiesta dal CRA)
• Monitoraggio delle vulnerabilità per componente
• Formati standard (SPDX, CycloneDX)
• Processo di aggiornamento documentato
• Date di fine supporto

Requisiti di sicurezza per i fornitori

I fornitori di componenti devono fornire informazioni sulla sicurezza e la relativa SBOM. Gli ordini di acquisto e i contratti quadro possono richiamare questi requisiti: prevenire gli attacchi che passano dalla filiera è centrale per la conformità al CRA:

• Requisiti di sicurezza nel contratto
• Obbligo di consegna della SBOM
• Collaborazione nella divulgazione delle vulnerabilità
• Impegno a fornire aggiornamenti di sicurezza
• Notifica della fine del supporto
• Diritto di audit sulla sicurezza informatica

Obblighi di supporto dopo la vendita

Il CRA obbliga a garantire il supporto di sicurezza per il periodo d’uso previsto del prodotto, di norma almeno 5 anni. Collegare in Odoo ordini di vendita, numeri di serie e clienti permette di sapere chi avvisare e quale versione aggiornare:

• Prodotti venduti collegati al cliente
• Canale di distribuzione degli aggiornamenti
• Canale per gli avvisi di sicurezza
• Comunicazione della fine del supporto
• Tempi di correzione delle vulnerabilità
• Assistenza ai clienti documentata (ad esempio con l’app Helpdesk, in Enterprise)

Obblighi di gestione delle vulnerabilità

Politica di divulgazione delle vulnerabilità

• Punto di contatto pubblico obbligatorio
• Processo di divulgazione coordinata delle vulnerabilità (CVD, Coordinated Vulnerability Disclosure)
• Riconoscimento dei ricercatori che segnalano
• Comunicazione chiara

Segnalazione delle vulnerabilità attivamente sfruttate

• 24 ore: preallarme
• 72 ore: notifica della vulnerabilità
• 14 giorni dalla disponibilità della correzione: relazione finale
• Invio tramite la piattaforma unica di segnalazione gestita dall’ENISA, al CSIRT nazionale (in Italia CSIRT Italia dell’ACN)

Segnalazione degli incidenti gravi

• Incidente grave: impatto significativo su disponibilità, autenticità, integrità o riservatezza
• Preallarme entro 24 ore, notifica entro 72 ore, relazione finale entro un mese
• Informazione agli utilizzatori interessati
• Analisi delle cause

Requisiti essenziali di sicurezza informatica

Progettazione e sviluppo

• Nessuna vulnerabilità sfruttabile nota al momento dell’immissione sul mercato
• Configurazione predefinita sicura
• Protezione di riservatezza e integrità
• Controllo degli accessi adeguato
• Resilienza agli attacchi

Gestione delle vulnerabilità

• Processo pubblico di divulgazione delle vulnerabilità
• Aggiornamenti di sicurezza disponibili per tutto il periodo di supporto
• Documentazione delle funzioni di sicurezza
• Trasparenza sugli incidenti

Periodo di supporto

• Almeno 5 anni, salvo che il prodotto abbia un periodo d’uso previsto più breve
• Aggiornamenti di sicurezza gratuiti
• Aggiornamenti di sicurezza separati da quelli funzionali, ove tecnicamente possibile
• Comunicazione chiara della fine del supporto

Opzioni di valutazione della conformità

Autovalutazione (categoria predefinita e, a certe condizioni, classe I)

• Valutazione interna rispetto ai requisiti
• Documentazione tecnica
• Dichiarazione UE di conformità
• Marcatura CE
• Costi legati soprattutto al lavoro interno e ai test

Valutazione da parte di terzi (classe II e, se necessario, classe I)

• Coinvolgimento di un organismo notificato
• Esame della documentazione tecnica
• Possibile verifica in stabilimento
• Rilascio del certificato
• Costi da preventivare con l’organismo notificato

Certificazione europea di sicurezza informatica

• Solo per i prodotti critici, quando richiesta
• Schemi di certificazione europei (sviluppati con l’ENISA)
• Percorso più lungo e oneroso

Voci di costo per la conformità al CRA

Avvio sul primo prodotto

• Analisi delle minacce e progettazione della sicurezza
• Test di sicurezza
• Documentazione tecnica
• Strumenti e procedure per la SBOM
• Processo di gestione delle vulnerabilità
• Valutazione della conformità (molto variabile secondo la categoria)
• L’importo dipende dalla categoria del prodotto e dalla maturità del team di sviluppo: va stimato caso per caso.

Prodotti successivi (economie di scala)

• Costo di avvio sensibilmente inferiore rispetto al primo prodotto
• Riutilizzo di modelli di progettazione e strumenti
• Resta la valutazione della conformità specifica del prodotto

Costi ricorrenti annuali

• Monitoraggio delle vulnerabilità
• Rilascio degli aggiornamenti di sicurezza
• Segnalazioni e comunicazione
• Formazione e sensibilizzazione
• Da mettere a budget per tutta la durata del periodo di supporto.

Errori comuni nella preparazione

“I nostri prodotti non sono digitali”

Problema: qualsiasi hardware con software o connettività rientra potenzialmente nell’ambito.
Soluzione: valutazione dell’ambito con un parere legale.

“La sicurezza si guarda alla fine”

Problema: test di sicurezza solo a fine progetto, problemi strutturali scoperti tardi.
Soluzione: sicurezza fin dalla progettazione, inserita nella pianificazione del prodotto.

“SBOM ignorata”

Problema: componenti software non tracciati, risposta lenta alle vulnerabilità.
Soluzione: SBOM generata automaticamente fin dall’inizio, monitoraggio continuo.

“Periodo di supporto non pianificato”

Problema: anni di supporto di sicurezza non previsti a budget.
Soluzione: il calcolo dei costi sul ciclo di vita include il supporto di sicurezza di lungo periodo.

“Requisiti vaghi per i fornitori”

Problema: i subfornitori consegnano componenti insicuri e il prodotto finale diventa difficile da rendere conforme.
Soluzione: requisiti specifici nel contratto e audit periodici.

Esempi illustrativi per PMI manifatturiere italiane

Esempio 1 — Macchinario industriale: controlli intelligenti

• Macchinario con PLC, pannello operatore e connettività
• Classificazione: categoria predefinita
• Autovalutazione e documentazione tecnica
• Impegno maggiore sul primo prodotto
• Costi inferiori sui prodotti successivi grazie al riutilizzo

Esempio 2 — Elettrodomestico intelligente: prodotto di consumo

• Elettrodomestico con Wi-Fi
• Autovalutazione
• Meccanismo di aggiornamento a distanza (OTA, over-the-air)
• Impegno di supporto di almeno 5 anni
• Costi di supporto inseriti nel prezzo

Esempio 3 — IoT industriale: componente critico

• Gateway per contatori intelligenti = prodotto critico
• Certificazione o valutazione da parte di terzi
• Percorso lungo da avviare con largo anticipo
• Requisito per continuare a servire i clienti più strutturati

Esempio 4 — Sensore IoT: ambito scoperto tardi

• Sensore “semplice” ma dotato di connettività
• Si scopre tardi che rientra nel CRA
• Costi imprevisti e ritardi nel lancio
• Lezione: valutare l’ambito il prima possibile

Domande frequenti

I miei prodotti rientrano nel CRA?

Verifica di base: il prodotto contiene software o si collega ad altri dispositivi o reti? Se sì, quasi certamente rientra. Controllate poi le esclusioni (dispositivi medici, veicoli e così via). Per avere certezza serve un parere legale.

Quanto tempo serve per essere conformi?

Per un prodotto della categoria predefinita servono in genere diversi mesi sul primo prodotto; per le classi I e II e per i prodotti critici i tempi si allungano, anche per la disponibilità degli organismi notificati. I prodotti successivi sono più rapidi.

Posso usare software libero senza problemi?

Sì, ma dovete indicarlo nella SBOM, monitorarne le vulnerabilità e fornire gli aggiornamenti di sicurezza. Il software libero integrato in un vostro prodotto diventa una vostra responsabilità ai fini del CRA.

Cosa fare se si scopre una vulnerabilità dopo il lancio?

Il percorso: (1) verifica; (2) se è attivamente sfruttata, preallarme entro 24 ore tramite la piattaforma unica di segnalazione; (3) sviluppo della correzione; (4) distribuzione dell’aggiornamento ai clienti; (5) divulgazione pubblica coordinata.

Che differenza c’è tra CRA e NIS2?

La NIS2 (in Italia D.Lgs. 138/2024) riguarda la sicurezza informatica dei soggetti che erogano servizi essenziali o importanti. Il CRA riguarda la sicurezza informatica dei prodotti venduti. Una PMI può essere soggetta a entrambi: conviene un approccio integrato.

Prossimi passi

Nelle prossime guide vedremo come prepararsi al Regolamento UE sul lavoro forzato, come applicare il Data Act agli obblighi di condivisione dei dati e come valutare l’impatto di DSA e DMA (regolamenti europei sui servizi e sui mercati digitali) per le PMI che gestiscono piattaforme di vendita online.

Vuoi organizzare in Odoo la conformità al CRA nella tua PMI manifatturiera?
I consulenti certificati Odoo di BrentaSoft aiutano le PMI manifatturiere a strutturare in Odoo la documentazione di prodotto, la tracciabilità di componenti e firmware, i requisiti verso i fornitori e la gestione del supporto dopo la vendita.
Prenota una call conoscitiva oppure prova la nostra demo Odoo 19 online. Oppure prova Odoo direttamente su odoo.com (link referral BrentaSoft).