Orientamenti CRA di luglio 2026: i casi limite svolti

Il suo distributore automatico ha una SIM card all’interno. Quel modem cellulare rientra in una categoria di prodotto che il CRA sottopone a una valutazione di conformità più severa. La macchina che lo contiene resta nella categoria di default.

Quella differenza decide se può ricorrere al controllo interno o deve pagare un organismo notificato per la valutazione. La dichiarazione la firma in ogni caso. Dipende da una singola frase che quasi nessun fabbricante ha mai letto.

La Commissione europea ha pubblicato gli orientamenti sull'applicazione del CRA il 27 luglio 2026. Il documento conta 84 pagine con 67 esempi pratici. Questo articolo ne analizza cinque che cambiano la risposta nella pratica, con un caso svolto per ciascuno.

Un componente regolamentato non riclassifica la macchina

Il suo percorso di valutazione di conformità dipende da una sola cosa: la funzionalità principale del prodotto. Se la sbaglia, o paga un organismo notificato senza bisogno, o spedisce senza una valutazione che la legge le impone.

Il CRA non definisce mai la funzionalità principale. Gli orientamenti sì.

Un distributore automatico, un modem cellulare e 25.000 €

Questo scenario è ipotetico.

Lei produce distributori automatici. Il suo fa tre cose:

• Accetta pagamenti con carta
• Monitora le scorte con sensori di peso
• Porta un modem cellulare, così la sede centrale può scaricare i dati di vendita durante la notte e aggiornare i prezzi

Il modem è ciò che crea la domanda. I router e i modem destinati alla connessione a internet figurano tra i prodotti importanti di Classe I del CRA. La sua macchina ne contiene uno.

Sulle cifre illustrative sopra, e ammesso che la via del controllo interno non le fosse stata aperta, quella singola riga vale per lei circa 25.000 €. I costi di valutazione effettivi variano in base al prodotto e all’organismo. I prodotti di Classe I possono comunque ricorrere al controllo interno dove si applica integralmente una norma armonizzata pertinente, anche se gli orientamenti aggiungono a questo una seconda condizione, trattata più avanti.

Cosa deve ancora garantire per quel modem

Il modem esce dalla questione della classificazione. Non esce dai suoi obblighi.

• Valutazione del rischio: il modem è un componente integrato e appartiene alla valutazione del rischio del suo prodotto, comprese le interfacce che espone e i flussi di dati che porta.
• Dovuta diligenza: deve adottare misure adeguate per confermare che il componente non comprometta la conformità del suo prodotto. La documentazione tecnica e di sicurezza del fornitore può servire da prova.
• La rete non è sua: la rete cellulare a cui si collega il suo modem è un canale di comunicazione, non parte del suo prodotto. Non deve alcuna dovuta diligenza verso l’operatore mobile.

Ecco la ripartizione completa, perché i team spesso azzeccano una metà e sbagliano l’altra.

L’ultima riga è dove cadono in errore gli integratori. Comprare un modulo certificato e saldarlo dentro è una questione di catena di fornitura. Scrivere il firmware che ci gira sopra può renderla fabbricante di ciò che immette sul mercato, e se questo si estende al modem stesso dipende da come viene fornito e da cosa ha modificato.

Per il funzionamento dettagliato delle categorie, veda la nostra guida alla classificazione dei prodotti. Per i modem come prodotti a sé stanti, veda router e modem.

Due lacune che si porta dietro senza saperlo

• La funzionalità principale è definita solo negli orientamenti: il regolamento stesso non definisce mai il termine che decide il suo percorso di conformità. La definizione da cui parte è la lettura della Commissione, e non vincola nessuno.
• Il criterio per ricorrere al controllo interno ha guadagnato in silenzio una seconda condizione: la legge rende necessaria una valutazione di terza parte per un prodotto importante di Classe I quando il fabbricante non ha applicato pienamente le norme armonizzate pertinenti. Questo è un solo test. Gli orientamenti ne aggiungono un altro: l’ambito della norma deve coprire anche ogni rischio di cibersicurezza legato alla sua funzionalità principale. Il secondo test non è scritto in questi termini nella legge. La Commissione lo deriva da come i requisiti applicabili e la presunzione di conformità si combinano, e così restringe per via interpretativa, non testuale, chi può ricorrere al controllo interno.

Vendere un modulo a parte lo riclassifica

Dove offre in vendita, licenza o abbonamento separato i moduli di una suite, ciascuno diventa un prodotto a sé stante. Ognuno viene poi classificato in base alla propria funzionalità principale, non a quella della suite.

La Commissione lo illustra con una suite di sicurezza divisa in parti, e le parti finiscono in regimi diversi.

Una riga sul listino sposta un modulo in un regime più severo

Questo scenario è ipotetico.

Lei vende software proprietario a operatori industriali. Fa quattro cose:

• Raccoglie dati dalle linee di produzione
• Mostra dashboard
• Genera allarmi
• Include un modulo di rilevamento delle intrusioni per la rete OT

Venduto come piattaforma unica, la funzionalità principale è il monitoraggio della produzione. È un prodotto di categoria di default. Ricorre al controllo interno, firma la dichiarazione, spedisce.

Poi le vendite chiedono di rendere disponibile il modulo di rilevamento delle intrusioni da solo, perché tre potenziali clienti lo vogliono senza il resto. Lei aggiunge una riga al listino.

Quel modulo è ora un prodotto separato. La sua funzionalità principale è il rilevamento delle intrusioni. I sistemi di rilevamento e prevenzione delle intrusioni sono una categoria importante di Classe II.

La Classe II richiede una valutazione di conformità di terza parte. Questo non è facoltativo né condizionato alle norme. I prodotti che si qualificano come software libero e open source seguono un percorso proprio.

Nel codice non è cambiato nulla. Una decisione commerciale ha spostato un modulo in un regime più severo, e sulle cifre tipiche questo significa un costo di valutazione molto più alto e un percorso di rilascio più lungo.

Nessuno ha definito cosa significhi ‘disponibile separatamente’

Gli orientamenti nominano l’acquisto separato, la licenza e l’abbonamento, ed escludono i moduli forniti solo come parte di un prodotto integrato. Resta aperto un solo caso. Quattro situazioni, tre con risposta:

• Uno SKU separato sul listino. Risolto. L’acquisto separato è nominato esplicitamente, quindi rientra.
• Un feature flag che il suo team commerciale può concedere in licenza autonomamente. Risolto. Licenza e abbonamento sono nominati insieme all’acquisto, quindi non serve uno SKU separato.
• Un componente aggiuntivo venduto solo ai clienti già titolari della piattaforma. Aperto. Non può comprarlo da solo, ma può comprarlo separatamente dal resto della suite. Gli orientamenti non coprono questo caso.
• Un modulo tecnicamente separabile ma mai offerto da solo. Risolto. I moduli forniti solo come parte di un prodotto integrato sono esclusi, e la classificazione resta a livello dell’intero prodotto.

Il test segue quindi la realtà commerciale più delle etichette di confezionamento, e un feature flag concedibile in licenza conta anche senza uno SKU. Quello che resta aperto è il componente riservato ai clienti esistenti, e la risposta lì cambia quanto paga.

Conta più di quanto sembri. I product manager cambiano il confezionamento ogni trimestre e non lo considerano mai un evento regolatorio. Inserisca un controllo in quella decisione adesso, perché l’alternativa è scoprirlo dopo che un cliente ha già ricevuto un preventivo.

Veda i percorsi di valutazione di conformità per cosa comporta e cosa costa ciascun modulo.

L’aggiornamento non azzera il periodo di supporto

Una modifica sostanziale la obbliga a rivalutare il periodo di supporto. Non lo azzera in automatico. Non lo allunga in automatico nemmeno.

La domanda è più ristretta di quanto pensi la maggior parte dei team. La modifica ha cambiato i fattori che avevano stabilito la durata di utilizzo prevista in origine?

La Commissione fornisce due casi: una modifica software che lascia in piedi la data di fine originale, e una modifica hardware che impone un nuovo calcolo.

Lo stesso controllore, due modifiche, due risposte diverse

Questo scenario è ipotetico.

Lei immette sul mercato un controllore logico programmabile nel 2028. La durata di utilizzo prevista è dodici anni, basata sulla durabilità dell’hardware e su cosa i clienti industriali si aspettano ragionevolmente da quella classe di apparecchiature. Dichiara un periodo di supporto che termina nel 2040.

2031. Rilascia un firmware che aggiunge la diagnostica remota. Ammesso che le nuove interfacce e i nuovi flussi di dati cambino il modo in cui il prodotto soddisfa i requisiti essenziali, su questi elementi conta come modifica sostanziale. Questo attiva una nuova valutazione di conformità e un fascicolo tecnico aggiornato. Le nuove interfacce da sole non basterebbero a deciderlo.

Non sposta la data di supporto. La durabilità dell’hardware non è cambiata. Le aspettative dei clienti non sono cambiate. Il supporto termina ancora nel 2040, e il fatto che restino meno di cinque anni a un certo punto successivo non lo allunga.

2033. Sostituisce il modulo di calcolo con una generazione più recente progettata per una vita operativa più lunga, e commercializza la macchina su questa base. Ora i fattori sono cambiati. I clienti possono ragionevolmente aspettarsi più anni di servizio. Ricalcola il periodo di supporto al rialzo.

Accorciare un periodo di supporto resta senza risposta

I casi svolti mostrano il periodo restare uguale e il periodo allungarsi. La regola in sé dice di ricalcolare rispetto ai criteri quando cambiano i fattori determinanti, senza dire che il risultato possa solo salire.

Se una modifica restringe la vita di servizio realistica di un prodotto, per esempio interrompendo il supporto della piattaforma hardware su cui gira, nessun caso svolto dice se il periodo dichiarato possa seguirlo verso il basso. Non accorceremmo un periodo già comunicato ai clienti, ma gli orientamenti non lo risolvono.

Per approfondire come impostare il periodo fin dall’inizio: i fondamenti del periodo di supporto.

Un ricambio può smettere di essere un ricambio quando la sicurezza cambia

I ricambi che sostituiscono componenti identici restano fuori dal CRA. La parola che fa il lavoro è ‘identici’, e gli orientamenti la definiscono in modo più stretto di quanto assuma la maggior parte dei processi di gestione dell’obsolescenza.

L’identità si giudica sul ruolo funzionale del componente insieme alle sue caratteristiche rilevanti per la cibersicurezza, e gli orientamenti dicono che serve sempre una valutazione caso per caso. L’elenco della Commissione delle caratteristiche rilevanti include algoritmi, protocolli, meccanismi crittografici e funzioni di controllo degli accessi, e non è un elenco chiuso.

La Commissione mette a confronto due sostituzioni di fine vita. Una cambia l’implementazione crittografica e il meccanismo di secure boot, e perde l’esenzione. Una cambia il chipset ma mantiene gli stessi protocolli e gli stessi meccanismi di sicurezza, e la mantiene.

Due moduli di ricambio, uno dei due è un nuovo prodotto

Questo scenario è ipotetico.

Ha installato pannelli di controllo accessi in tutta la sede aziendale nel 2029. Nel 2033 il modulo wireless al loro interno raggiunge fine vita e il suo fornitore propone due ricambi.

Ricambio A. Chipset diverso, fabbricante diverso, stessi protocolli radio, stessa memorizzazione delle chiavi, stessa catena di secure boot. Su questi elementi dovrebbe ancora qualificarsi come ricambio, fuori dal CRA, spedito tramite il suo canale di assistenza.

Ricambio B. Stessa radio, ma un elemento sicuro più recente con una gerarchia delle chiavi diversa e una sequenza di verifica del boot diversa. Queste differenze riguardano le caratteristiche di cibersicurezza, quindi su questi elementi non è identico. Diventa un prodotto con elementi digitali a sé stante, che richiede una propria valutazione di conformità, una propria documentazione tecnica e la marcatura CE.

Stesso codice articolo nella sua distinta base. Stesso ingombro fisico. Due esiti di conformità completamente diversi.

La conseguenza per cui nessuno si è preparato

Il suo processo di gestione dell’obsolescenza quasi certamente confronta le schede tecniche. Compatibilità dei pin, tensione, ingombro, intervallo di temperatura, prestazioni RF.

Niente di tutto questo risponde alla domanda che pone il CRA. Serve un confronto delle caratteristiche di sicurezza accanto a quello elettrico. Questi sono i campi che deve contenere.

Conviene verificare secure boot e memorizzazione delle chiavi fin da subito, perché un cambiamento in uno dei due è facile da perdere in un confronto tra schede tecniche. Gli orientamenti non stabiliscono un ordine di importanza tra le caratteristiche, quindi nessuna può essere saltata.

La maggior parte dei team non ha questo documento. Costruirlo è un lavoro modesto adesso, contro una spedizione bloccata e una valutazione di conformità d’urgenza più avanti.

Un’altra condizione che coglie di sorpresa: essere tecnicamente intercambiabile non basta da solo. Lo scopo di riparazione deve risultare evidente da come il componente viene fornito, tramite l’identificazione del prodotto nell’ordine o nell’offerta commerciale, oppure tramite la fornitura attraverso i canali post-vendita. Un componente venduto come prodotto standalone generico non ottiene l’esenzione solo perché si adatta.

Lo stesso principio vale per i lettori di controllo accessi e i terminali biometrici.

L’elenco delle caratteristiche di sicurezza resta aperto

L’elenco delle caratteristiche rilevanti per la sicurezza è aperto. Se un aggiornamento della versione firmware all’interno di un modulo altrimenti identico conti come modifica non è affrontato da nessuna parte.

Una modifica non trascina tutto il prodotto

Il CRA si applica pienamente dall’11 dicembre 2027. Dall’11 settembre 2026 l’obbligo di segnalazione coprirà anche i prodotti immessi sul mercato prima di allora, ma quei prodotti acquisiscono il resto del regime solo se vengono modificati sostanzialmente in seguito.

Il timore che questo genera è ragionevole: toccare una volta una macchina di quindici anni e l’intero prodotto deve arrivare a uno standard che non esisteva quando lo aveva progettato.

Non è quello che succede. Dove è il fabbricante originale a effettuare la modifica, gli obblighi si attaccano alla parte modificata. L’intero prodotto segue solo dove la modifica danneggia la sicurezza del prodotto nel suo complesso.

Cosa è dovuto per una macchina del 2026 modificata nel 2029

Questo scenario è ipotetico.

Ha spedito una linea di imballaggio industriale nel 2026 con una vita di servizio di vent’anni. Nel 2029 rilascia una modifica firmware al sottosistema di etichettatura che aggiunge un’interfaccia di rete per la gestione dei lavori di stampa. Questa è una modifica sostanziale.

Cosa deve garantire: la conformità del sottosistema di etichettatura, una valutazione del rischio aggiornata che lo copra, e una documentazione tecnica aggiornata per ciò che è cambiato.

Cosa non deve garantire: l’adeguamento dei controllori di movimento, degli interblocchi di sicurezza, o del terminale operatore. E non deve ricostruire i registri di progettazione e di test del 2025 che non sono mai esistiti in questa forma. Gli orientamenti sono diretti su questo punto. I prodotti progettati prima dell’applicazione del CRA non necessitano di una riprogettazione dove una valutazione del rischio attuale dimostra che le misure esistenti affrontano i rischi, e ricostruire la documentazione storica non renderebbe il prodotto più sicuro.

L’asimmetria di cui nessuno parla

L’ambito ristretto si applica al fabbricante originale e a un terzo estraneo che effettua la modifica e immette sul mercato il prodotto modificato. Non si applica a importatori e distributori, gestiti da una regola separata senza questo limite.

Rilegga quelle righe. Un’impresa di ingegneria a contratto che modifica una macchina e la immette sul mercato ottiene l’ambito ristretto, a condizione che la modifica lasci intatta la cibersicurezza del prodotto nel suo complesso. Un importatore che effettua la stessa identica modifica ottiene quello ampio. L’azione è la stessa. L’esposizione no.

Il regolamento tratta i due casi in modo diverso sulla sua stessa formulazione. L’effetto pratico è che gli importatori che modificano portano più peso dei terzi che modificano.

Per la cronologia completa e cosa si applica quando, veda la nostra cronologia di implementazione del CRA.

La frase che decide tutto non è definita da nessuna parte

L’agevolazione dipende dal fatto che la modifica «comprometta negativamente la cibersicurezza del prodotto nel suo complesso». Quella frase decide se aggiorna un sottosistema o tutti quanti, e non è definita da nessuna parte.

Si aspetti che quella frase sia quella su cui discuterà con un organismo notificato.

Come si lega alla bozza di marzo

La Commissione ha condotto una consultazione pubblica su una bozza di questi orientamenti tra il 3 marzo e il 13 aprile 2026. Ne avevamo parlato quando era uscita, in cosa significa la bozza di marzo 2026.

Il documento di luglio è il risultato di quella consultazione. Non copre il CRA per intero, e la Commissione lo dice direttamente.

Il paragrafo 9 indica che la Commissione può valutare la pubblicazione di ulteriori orientamenti ai sensi dell’articolo 26. Cita come esempi l’interazione del CRA con l’AI Act e con DORA. È una possibilità, non un impegno a pubblicare un altro documento.

Questo articolo ha scopo puramente informativo e non costituisce consulenza legale. Per indicazioni di conformità specifiche, si rivolga a un consulente legale qualificato.