Dall'11 settembre 2026 il Cyber Resilience Act ha una conseguenza operativa già applicabile: i fabbricanti devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza dei prodotti con elementi digitali. PLC, pannelli HMI, gateway, sistemi SCADA e software industriali possono rientrare nel regolamento quando soddisfano la definizione di prodotto con elementi digitali; non vi rientrano, però, soltanto perché sono installati in un bene 4.0.
Per la PMI acquirente il punto non è presentare la segnalazione a ENISA al posto del fabbricante. È assicurarsi che l'informazione partita a monte arrivi in tempo a chi gestisce la linea, identifichi esattamente le versioni interessate e sia accompagnata da una mitigazione utilizzabile in produzione. Questa continuità non nasce automaticamente dal regolamento: va costruita nel contratto di fornitura e manutenzione.
Che cosa è cambiato l'11 settembre 2026
Il Regolamento (UE) 2024/2847 è stato pubblicato il 20 novembre 2024 ed è entrato in vigore il 10 dicembre successivo. Le sue date di applicazione sono però scaglionate:
- dall'11 giugno 2026 si applica il capo IV, dedicato alla notifica delle autorità e degli organismi di valutazione della conformità;
- dall'11 settembre 2026 si applica l'articolo 14, relativo alle segnalazioni;
- dall'11 dicembre 2027 si applicherà in via generale il regolamento, compresi i requisiti di prodotto, la gestione delle vulnerabilità, la documentazione tecnica e le procedure di conformità.
L'articolo 14 impone al fabbricante che viene a conoscenza di una vulnerabilità attivamente sfruttata di trasmettere, attraverso la piattaforma unica di segnalazione, un preallarme entro 24 ore e una seconda notifica entro 72 ore. La relazione finale deve seguire entro 14 giorni dalla disponibilità di una misura correttiva o di attenuazione. Per un incidente grave che incide sulla sicurezza del prodotto valgono il preallarme entro 24 ore e la notifica entro 72 ore, mentre la relazione finale deve essere presentata entro un mese da quest'ultima.
La Single Reporting Platform di ENISA è operativa dall'11 settembre 2026. La segnalazione è indirizzata al CSIRT designato come coordinatore ed è resa disponibile a ENISA secondo il meccanismo previsto dal regolamento.
L'obbligo riguarda anche i prodotti immessi sul mercato prima dell'11 dicembre 2027. Gli orientamenti della Commissione del 27 luglio 2026, che non sono vincolanti ma illustrano l'interpretazione della Commissione, precisano inoltre che il reporting continua anche dopo la fine del periodo di assistenza. Ciò non significa che il fabbricante debba necessariamente continuare a correggere un prodotto fuori supporto: significa che, se viene a conoscenza degli eventi descritti dall'articolo 14, resta tenuto a segnalarli.
Lo stesso articolo impone al fabbricante di informare gli utilizzatori interessati e, quando opportuno, tutti gli utilizzatori, indicando anche le misure correttive o di attenuazione che possono adottare. La norma, però, non risolve da sola i passaggi tra OEM, costruttore della macchina, integratore, rivenditore, manutentore e stabilimento utilizzatore. È proprio in questi passaggi che serve il contratto.
Prima delle clausole: identificare prodotto, versione e ruoli
Un contratto efficace parte dal perimetro tecnico. Il CRA riguarda hardware o software la cui finalità prevista o il cui uso ragionevolmente prevedibile comportano una connessione logica o fisica, diretta o indiretta, con un dispositivo o una rete. Anche il software necessario per configurare, controllare o usare l'hardware può far parte dello stesso prodotto, pur essendo distribuito separatamente.
Non basta quindi scrivere «PLC» o «software MES». L'allegato contrattuale dovrebbe identificare almeno:
- fabbricante, modello, numero di serie e revisione hardware;
- versione di firmware, sistema operativo, applicativi e moduli opzionali;
- componenti e servizi remoti necessari alle funzioni del prodotto;
- interfacce di rete, protocolli e dipendenze operative;
- ruolo di ciascun soggetto della filiera: fabbricante, importatore, distributore, integratore e manutentore;
- soggetto responsabile del contatto con l'utilizzatore in caso di vulnerabilità o incidente.
Questa ricognizione evita anche un errore frequente: nel testo definitivo del CRA PLC, SCADA e sistemi di automazione industriale non sono automaticamente prodotti importanti di Classe II in ragione del loro impiego presso un soggetto essenziale NIS2. Il Regolamento di esecuzione (UE) 2025/2392 conferma che conta la funzionalità principale del prodotto nel suo complesso. L'integrazione di un componente appartenente a una categoria dell'allegato III non trasferisce automaticamente la stessa classificazione all'intera macchina.
Nel contratto è quindi preferibile chiedere al fornitore di dichiarare la classificazione CRA attribuita al prodotto e di motivarla in base alla sua funzionalità principale, invece di imporre una classe ricavata dal solo contesto d'uso.
Le clausole da inserire nel contratto
1. Catena delle responsabilità e obblighi verso i subfornitori
Il venditore contrattuale può non coincidere con il fabbricante su cui grava l'articolo 14. Il contratto deve obbligare il venditore a ottenere dall'OEM e dagli altri soggetti a monte le informazioni necessarie e a trasferirle all'acquirente senza ritardi. Lo stesso obbligo deve essere riprodotto nei contratti con subfornitori, sviluppatori e manutentori dai quali dipendono patch, firmware o servizi remoti.
La clausola dovrebbe individuare un responsabile unico verso l'acquirente. Un generico rinvio al produttore del singolo componente lascia invece alla PMI il compito di ricostruire la filiera durante l'incidente.
2. Canale di allerta e identificazione dei prodotti interessati
Occorre stabilire un recapito di sicurezza presidiato, distinto dall'assistenza commerciale ordinaria, e un recapito alternativo per le emergenze. Il fornitore dovrebbe impegnarsi a comunicare entro 24 ore da quando ne viene a conoscenza almeno:
- identificativo della vulnerabilità o dell'incidente, se disponibile;
- prodotti, numeri di serie e versioni interessati;
- condizioni necessarie perché il problema sia sfruttabile;
- gravità, impatto possibile e indicatori utili al rilevamento;
- mitigazioni temporanee, aggiornamento disponibile e istruzioni di ripristino;
- eventuali effetti della correzione su sicurezza funzionale, disponibilità e prestazioni.
Questo termine è uno SLA contrattuale verso l'acquirente: non sostituisce né modifica il termine legale, che decorre dalla conoscenza del fabbricante e riguarda la segnalazione alle autorità.
La clausola funziona soltanto se entrambe le parti mantengono un inventario aggiornato delle installazioni. Il contratto deve quindi disciplinare chi registra sostituzioni, aggiornamenti e cambi di configurazione e con quale frequenza l'elenco viene riconciliato.
3. SBOM consegnata e aggiornata
Dal dicembre 2027 il CRA richiederà al fabbricante di identificare e documentare componenti e vulnerabilità, anche mediante una Software Bill of Materials in formato comunemente utilizzato e leggibile automaticamente, comprendente almeno le dipendenze di primo livello.
Il regolamento non riconosce però all'acquirente un diritto generale a ricevere la SBOM. L'allegato II disciplina espressamente il caso in cui il fabbricante decida di metterla a disposizione dell'utilizzatore. Se l'azienda vuole consultarla, deve quindi prevederlo nel contratto.
La clausola dovrebbe richiedere:
- consegna in un formato strutturato e leggibile automaticamente;
- associazione univoca tra SBOM e versione del prodotto;
- aggiornamento a ogni rilascio di firmware o software;
- indicazione almeno di componenti, versioni e dipendenze necessarie a verificare l'esposizione;
- una procedura per interrogare il fornitore quando una vulnerabilità riguarda un componente elencato;
- regole di riservatezza che consentano comunque l'uso della SBOM per la gestione del rischio.
Per sistemi industriali ad alta criticità può essere ragionevole chiedere anche le dipendenze transitive rilevanti, andando oltre il minimo regolamentare delle dipendenze di primo livello.
4. Periodo di assistenza coerente con la vita della macchina
Il futuro obbligo dell'articolo 13 non si riduce a una garanzia fissa di cinque anni. Il periodo di assistenza deve riflettere il tempo durante il quale si prevede che il prodotto resti in uso ed essere almeno quinquennale, salvo che la durata d'uso prevista sia più breve. Il considerando 60 osserva espressamente che i sistemi di controllo industriale rimangono spesso in esercizio molto più a lungo.
Nel contratto devono quindi comparire il mese e l'anno di fine supporto per ogni componente essenziale e l'impegno a non abbreviare unilateralmente quel periodo. Per una linea destinata a funzionare dieci o quindici anni, accettare cinque anni senza un piano di continuità trasferisce sull'acquirente il rischio di obsolescenza molto prima della fine economica dell'investimento.
L'articolo 13, paragrafo 9, prevede inoltre che ogni aggiornamento di sicurezza reso disponibile durante il periodo di assistenza rimanga reperibile per almeno dieci anni dal rilascio o per il periodo di assistenza residuo, se più lungo. Il contratto dovrebbe indicare anche il canale dal quale recuperare versioni storiche, firme, checksum e istruzioni.
5. Patch, mitigazioni e compatibilità con la produzione
L'allegato I del CRA richiederà che le vulnerabilità siano corrette senza ritardo e che gli aggiornamenti di sicurezza siano distribuiti tempestivamente. Salvo un diverso accordo relativo a un prodotto su misura tra fabbricante e utilizzatore commerciale, gli aggiornamenti di sicurezza dovranno essere gratuiti.
Per una rete OT, tuttavia, «patch disponibile» non equivale a «patch installabile». Il contratto deve disciplinare:
- modalità online e offline di distribuzione;
- firma e verifica dell'integrità dei pacchetti;
- compatibilità con configurazioni, moduli e software già validati;
- prova in ambiente separato o procedura di accettazione prima del rilascio in produzione;
- possibilità di rollback e conservazione della versione precedente;
- mitigazione alternativa quando il fermo necessario all'aggiornamento non è immediatamente sostenibile;
- responsabilità per intervento, ripristino e malfunzionamenti causati dalla correzione.
Un unico tempo di patching basato soltanto sul punteggio CVSS è poco adatto a un impianto. La priorità deve considerare anche sfruttamento effettivo, raggiungibilità del componente, misure compensative, conseguenze sulla continuità produttiva e rischi per le persone.
6. Divulgazione coordinata delle vulnerabilità
Il fornitore dovrebbe mantenere una politica di Coordinated Vulnerability Disclosure, un recapito per le segnalazioni e una procedura documentata per ricezione, analisi e correzione. Dal dicembre 2027 questi elementi faranno parte del sistema di gestione delle vulnerabilità previsto dal CRA; inserirli prima nel contratto consente di renderli verificabili nella relazione con l'acquirente.
La clausola deve precisare come vengono gestite le segnalazioni provenienti da ricercatori, clienti e manutentori, chi informa i produttori dei componenti interessati e quando l'acquirente riceve gli aggiornamenti sull'indagine. La comunicazione pubblica non dovrebbe precedere la disponibilità di una mitigazione quando ciò aumenterebbe il rischio per gli impianti ancora esposti.
7. Modifiche, prove e rimedi contrattuali
Aggiornamenti, nuovi moduli, servizi cloud, porte di rete e dipendenze esterne possono cambiare il profilo di rischio. Il contratto dovrebbe richiedere una valutazione preventiva delle modifiche rilevanti, l'aggiornamento della documentazione tecnica e la comunicazione degli effetti su supporto, interoperabilità e conformità.
Il diritto di audit può essere esercitato anche attraverso evidenze documentali: rapporti di prova, politica di disclosure, registro degli aggiornamenti, motivazione della classificazione, dichiarazione UE di conformità quando dovuta e prova della gestione delle vulnerabilità. È preferibile chiedere questi elementi rispetto a un generico «certificato CRA», che il regolamento non prevede come documento universale per tutti i prodotti.
Devono essere stabiliti anche i rimedi: correzione, sostituzione, assistenza per la mitigazione, recupero dei costi direttamente causati dall'inadempimento e diritto di recesso quando la cessazione anticipata del supporto rende il prodotto non più gestibile in sicurezza. Senza rimedi, SLA e obblighi informativi restano dichiarazioni difficili da far rispettare.
Le clausole non trasferiscono la qualifica di fabbricante
Una clausola può ripartire costi, compiti e responsabilità tra le parti, ma non cambia il ruolo attribuito dal regolamento in base ai fatti.
L'articolo 21 considera fabbricante l'importatore o il distributore che immette il prodotto sul mercato con il proprio nome o marchio oppure vi apporta una modifica sostanziale. L'articolo 22 riguarda invece un'altra persona che modifica sostanzialmente un prodotto e lo mette a disposizione sul mercato. La modifica è sostanziale quando, dopo l'immissione sul mercato, incide sulla conformità ai requisiti essenziali oppure cambia la finalità prevista per la quale il prodotto è stato valutato.
Ne deriva una distinzione importante. La PMI che modifica un prodotto soltanto per usarlo internamente non diventa fabbricante per il solo fatto della modifica, perché l'articolo 22 richiede anche la successiva messa a disposizione sul mercato. Diverso è il caso dell'integratore che assembla componenti in un nuovo prodotto con elementi digitali e lo immette sul mercato sotto la propria responsabilità: gli orientamenti della Commissione lo considerano fabbricante del nuovo prodotto nel suo complesso.
Il contratto deve quindi prevedere un controllo delle modifiche e chiarire chi potrà commercializzare, cedere o incorporare il sistema risultante. Non può però stabilire che un soggetto non sia fabbricante quando le attività effettivamente svolte soddisfano i criteri del CRA.
Beni 4.0 e CRA: due verifiche distinte
La qualificazione di un investimento secondo gli allegati fiscali dei beni 4.0 non determina l'ambito del Cyber Resilience Act, e vale anche il contrario. Il regime fiscale guarda alle caratteristiche e alle condizioni previste dalla disciplina agevolativa; il CRA guarda al prodotto con elementi digitali, alla connessione, al ruolo dell'operatore economico e alla sua immissione o messa a disposizione sul mercato.
Per gli acquisti 2026 conviene quindi affiancare al capitolato funzionale un allegato di cibersicurezza autonomo. Non serve a creare una nuova condizione fiscale: serve a conservare nel tempo il valore operativo di un investimento che dipende da firmware, software e componenti connessi.
L'11 settembre 2026 non ha trasformato ogni utilizzatore di una macchina connessa in un fabbricante. Ha però reso obbligatoria una catena di informazioni che parte dal fabbricante. La qualità del contratto decide se quella catena termina in una piattaforma europea o arriva fino alla persona che, nello stabilimento, deve proteggere la produzione.