Robot industriali e cobot: prodotti importanti del CRA?
Riepilogo
Questa guida segue una release fittizia di un cobot dalla classificazione al perimetro di prodotto, alla valutazione del rischio, all'SBOM, alla firma di rilascio, alla segnalazione di vulnerabilità e al trasferimento tra operatori economici. La stessa struttura serve per un braccio a 6 assi, una cella collaborativa o un controllore di robot venduto con visione opzionale e servizi di cloud di flotta.
- Il percorso standard è il punto di partenza. I robot industriali e i cobot non figurano oggi negli elenchi CRA dei prodotti importanti o critici. Tratti come una classificazione a parte qualsiasi offerta in cui dominino funzioni di firewall, gestione di rete o controllore resistente alle manomissioni.
- Cominci dal memorandum sui limiti. Nomini la variante esatta: braccio, armadio di controllo, console di programmazione, opzioni di bus di campo, ambiente di esecuzione, connettore di flotta o cloud, uso previsto, elementi digitali forniti, periodo di supporto e motivo del percorso scelto.
- Cibersicurezza e sicurezza delle macchine si incrociano dal 2027. La norma ISO 10218-1:2025 aggiunge requisiti di cibersicurezza quando incidono sulla sicurezza del robot e il Regolamento Macchine si applica dal 20 gennaio 2027. Il fascicolo CRA e il safety case condividono evidenze in quei punti.
- Il supporto richiede una data credibile. Il periodo di supporto è di almeno cinque anni, salvo che il tempo di uso previsto sia inferiore. Molti robot funzionano in fabbrica ben più a lungo, perciò il fascicolo deve nominare una finestra che il fabbricante sia in grado di mantenere e comunicare la data di fine supporto prima dell'acquisto.
- La gestione delle vulnerabilità è un modello operativo. Il fascicolo deve nominare chi riceve gli avvisi, chi approva le finestre di manutenzione, chi può effettuare il rollback di un aggiornamento e come restano visibili gli avvisi residui.
- Anche il trasferimento è evidenza. Il fabbricante conserva il fascicolo del prodotto; l'integratore conserva il fascicolo della cella finita quando esce sotto il suo nome; l'operatore esercisce la cella. Ogni passaggio si documenta, non si scarica informalmente sul cliente.
Come si classifica una release di robot industriale o cobot?
Parta dall'offerta, non dal braccio. Un braccio a 6 assi venduto a un integratore e lo stesso braccio venduto come cella cobot completa a una piccola officina sono prodotti CRA distinti. Il percorso dipende da ciò che il cliente acquista, dal controllore e dalla console di programmazione forniti e dal fatto che il fabbricante fornisca anche il cloud di flotta, la configurazione di sicurezza e la via di aggiornamento OTA.
La figura fissa il percorso. La matrice fissa il memorandum sui limiti: una volta scelta la variante, queste sono le righe di evidenza che il fabbricante deve poter completare per quella variante.
Vendita come componente; l'integratore costruisce la cella.
Braccio, controllore, console di programmazione, ambiente di esecuzione, opzioni di bus di campo, aggiornamenti firmati, processo di gestione delle vulnerabilità e manuale per l'integratore.
Autorizzazione di scrittura della stazione di ingegneria, slot di ripristino, esposizione del bus di campo, monitoraggio degli avvisi dei fornitori e rotazione delle credenziali al ritiro della cella.
Braccio collaborativo a forza limitata, configurazione pronta all'uso, visione opzionale e cloud di flotta.
Braccio, controllore, console di programmazione, configurazione di sicurezza, sensore di visione, ambiente di esecuzione, connettore del cloud di flotta e servizio OTA.
Modo collaborativo, ruolo dell'operatore nello spazio condiviso, autorità del cloud di flotta, account della console e via del firmware di sicurezza firmato.
Rivendita all'interno di una linea di confezionamento o di una macchina di processo sotto la marcatura CE dell'integratore.
Il fabbricante del robot conserva nel proprio fascicolo braccio, controllore, console di programmazione e software fornito. La macchina finita ha il proprio fascicolo sotto la marcatura CE dell'integratore.
Avvisi dei fornitori su RT OS, bus di campo e visione; coerenza delle dichiarazioni di conformità del fornitore; esposizione durante l'integrazione; raccordo del supporto con il fabbricante della macchina.
Cosa rientra nel perimetro del prodotto robot?
Per un robot o un cobot, il perimetro non coincide sempre con la recinzione della cella. Coincide con ciò che il fabbricante fornisce e mantiene: braccio, armadio di controllo, firmware, ambiente di esecuzione, console di programmazione, aggiornamenti firmati, connettore cloud e documentazione per l'utente. Ciò che porta il cliente o l'integratore resta fuori per impostazione predefinita, salvo che il fabbricante lo consegni come parte dell'offerta.
Quale percorso di valutazione della conformità si applica?
I robot industriali e i cobot non figurano oggi negli elenchi CRA dei prodotti importanti o critici, perciò il percorso standard è l'ipotesi di pianificazione. Il fabbricante può scegliere il controllo interno, l'esame UE del tipo seguito dalla conformità al tipo, la garanzia di qualità completa o uno schema europeo di certificazione di cibersicurezza applicabile. La scelta non dipende dall'applicazione di norme armonizzate.
La condizione delle «norme pienamente applicate» appartiene al percorso di riserva per i prodotti importanti, non al percorso predefinito. Se un futuro aggiornamento aggiungesse un sottoprodotto di robot o cobot a quell'elenco e le norme o gli schemi disponibili non coprissero i requisiti essenziali pertinenti, il fabbricante avrebbe bisogno di un percorso di valutazione da terza parte per la parte non coperta. L'elenco non include i robot oggi.
Il Regolamento Macchine 2023/1230 si applica dal 20 gennaio 2027 e include requisiti di sicurezza che si sovrappongono all'evidenza cyber, in particolare la protezione contro la corruzione e l'affidabilità dei sistemi di comando. Tratti il fascicolo CRA e il fascicolo di sicurezza della macchina come due fili della stessa cartella di prodotto.
Quali controlli di architettura appartengono al fascicolo del robot?
Il fascicolo deve spiegare in che modo il fabbricante presidia i punti in cui un comando digitale può cambiare il movimento, la configurazione di sicurezza o lo stato di aggiornamento.
| Punto di architettura | Cosa si verifica | Evidenza minima |
|---|---|---|
| Controllore e CPU di movimento | Chi può scrivere logica, parametri e firmware | Modello di autorità, firma del firmware, registro modifiche |
| Console di programmazione | Quali ruoli possono muovere il robot, caricare programmi o cambiare modo | Matrice dei ruoli, prova di credenziali, audit di sessione |
| Bus di campo | Quale traffico può influire sul ciclo di movimento | Elenco dei protocolli, regole di segmentazione, prova con frame anomali |
| Cloud di flotta | Quale autorità remota esiste su aggiornamenti e telemetria | Mappa dei punti di connessione, certificati, finestra di manutenzione, rollback |
| Servizio locale | Come si presidiano USB, ripristino e tunnel temporanei | Modalità di servizio, registro di intervento, prova di chiusura automatica |
Come si costruisce la valutazione del rischio del robot?
Quale prodotto stiamo valutando?
L'esempio usa una cella cobot completa venduta a una PMI: braccio a forza limitata, controllore, console di programmazione, configurazione di sicurezza preparata, visione opzionale, connettore del cloud di flotta, aggiornamenti firmati e documentazione per l'utente. Non valuta una linea di stabilimento completa né una cella progettata da un integratore, salvo nei punti di trasferimento.
| Decisione di perimetro | Scelta dell'esempio | Perché conta |
|---|---|---|
| Variante | Cella cobot completa | Il fabbricante conserva il fascicolo di prodotto per intero |
| Perimetro digitale | Controllore, console, firmware, visione, cloud, OTA | È ciò che può cambiare movimento, configurazione o disponibilità |
| Cliente | PMI operatrice | Meno squadra interna di sicurezza, più dipendenza dal fabbricante |
| Integratore | Può installare, ma non rietichetta il prodotto | Il trasferimento esiste, ma non sposta automaticamente il fascicolo |
Prima di scrivere la tabella delle minacce, provi i tre percorsi che di solito decidono il rischio del robot: caricamento programma e autorità della console, confine tra sicurezza funzionale e cibersicurezza, e trasferimento all'integratore. La figura trasforma l'esempio in domande di ingegneria, non in un elenco generico di minacce.
Come cambia la superficie d'attacco tra un robot recintato e un cobot?
| Superficie | Robot industriale recintato | Cobot a forza limitata |
|---|---|---|
| Prossimità umana | Esclusa da recinzione, barriera o interblocco | Continua; il monitoraggio di forza, velocità o separazione fa parte del safety case |
| Accesso alla console | Di solito all'interno della cella bloccata | Spazio condiviso, spesso con ruolo attivo dell'operatore |
| Ingresso di visione | Opzionale e localizzato | Frequente, talvolta centrale per sicurezza e operazione |
| Teleoperazione | Meno abituale | Sempre più comune in alcune gamme |
| Attore più probabile | Servizio, ingegneria o integratore | Operatore, stazione remota o uso improprio del ruolo condiviso |
Quali asset si proteggono?
| Asset | Perché conta | Esempio di evidenza |
|---|---|---|
| Autorità di movimento | Cambia traiettoria, velocità o modo | Matrice dei ruoli, prova di sessione, blocco di modo |
| Firmware di sicurezza | Incide su arresto, velocità, separazione e interblocchi | Firma, revisione congiunta sicurezza funzionale e cyber |
| Programmi del robot | Possono introdurre movimenti non sicuri o interruzioni | Validazione del parser, controllo dell'origine, registro di caricamento |
| Credenziali della console | Consentono modifiche locali in produzione | Rotazione iniziale, scadenza, audit dell'operatore |
| Connettore cloud | Può distribuire avvisi, aggiornamenti o tunnel | Certificati, lista dei punti di connessione, prova di rollback |
| Componenti software | RT OS, visione, bus di campo e librerie hanno vulnerabilità | SBOM, monitoraggio degli avvisi, decisione di patch |
Dove si trovano i confini di fiducia principali?
| Confine | Attraversamento | Domanda di rischio |
|---|---|---|
| Fabbricante a integratore | Manuale, pacchetto per l'importatore, configurazione di sicurezza e avvisi | Cosa si consegna e cosa resta fuori? |
| Integratore a operatore | Cella installata, ruoli, finestre di manutenzione | Chi può cambiare il movimento dopo la consegna? |
| Stazione di ingegneria a controllore | Progetto, programma, firmware, parametri | Quale prova impedisce una scrittura fuori sessione? |
| Cloud a flotta | Avvisi, aggiornamenti, certificati, tunnel | Quale autorità remota esiste e come si revoca? |
| Fornitore a fabbricante | Componenti, librerie, firmware di terzi | Come si rileva un avviso che incide sul robot? |
Quali minacce si valutano per prime?
| ID | Minaccia | Asset interessato | Confine |
|---|---|---|---|
| R1 | Un account di fabbrica o dell'integratore resta attivo dopo la consegna | Autorità di movimento | Integratore a operatore |
| R2 | Un pacchetto di firmware vecchio viene accettato durante il ripristino | Integrità del firmware | Servizio locale |
| R3 | Il cloud di flotta apre un tunnel fuori dalla finestra di manutenzione | Autorità remota | Cloud a flotta |
| R4 | Un progetto manomesso cambia la logica di velocità o separazione | Sicurezza collaborativa | Stazione di ingegneria |
| R5 | Un certificato scaduto blocca avvisi o aggiornamenti | Disponibilità | Cloud |
| R6 | L'operatore non riceve in tempo un avviso di vulnerabilità | Gestione delle vulnerabilità | Fabbricante a operatore |
| R7 | Un fornitore pubblica un avviso che incide su RT OS o visione e non viene rilevato | Componenti | Fornitore a fabbricante |
| R8 | Un frame del bus di campo provoca un guasto della CPU di movimento o un sovraccarico del ciclo | Disponibilità del movimento | Bus di campo |
| R9 | Un'immagine USB di ripristino viene applicata senza audit | Integrità del firmware | Supporto di servizio |
| R10 | Un pacchetto di diagnostica espone nomi di programma, certificati o rete | Dati di servizio | Portale di supporto |
| R11 | Una vulnerabilità in RT OS, bus di campo o visione non viene rilevata durante il supporto | Componenti del firmware | Avvisi dei fornitori |
| R12 | Un trasferimento al cliente lascia attiva la stazione di ingegneria precedente | Credenziali | Ritiro dal servizio |
| R13 | Il parser dell'ambiente di esecuzione fallisce o esegue contenuto non sicuro da un progetto malformato | Integrità degli strumenti | Importazione di progetto |
| R14 | L'integratore combina il braccio con un PLC di sicurezza di terzi senza evidenza vigente | Conformità del fornitore | Trasferimento di cella |
Come si stabiliscono le priorità sui rischi iniziali?
Usi una scala di decisione. Non tutti i rischi richiedono la stessa risposta.
| Esito residuo | Perché resta | Evidenza operativa |
|---|---|---|
| Patch di lunga durata | Un componente del fornitore non ha ancora correzione | Avviso del componente, mitigazione temporanea, data di revisione |
| Modifica del cliente | L'operatore vuole integrare una stazione propria | Memorandum sui limiti, nota di perimetro, istruzione di supporto |
| Tempistica della patch | Lo stabilimento richiede finestra e validazione | Avviso con impatto sulla macchina, mitigazione, rollback |
| Accesso fisico al servizio | Armadi, console e stazioni sono accessibili in manutenzione | Restrizioni in modalità di servizio, campione di audit, blocco del debug |
Quali controlli di progettazione cambiano il rischio?
| Controllo | Cosa riduce | Evidenza |
|---|---|---|
| Firmware firmato con rigetto delle versioni precedenti | Pacchetti vecchi o manomessi | Registro di prova dell'aggiornamento, hash, esito di rigetto |
| Credenziali per dispositivo e rotazione iniziale | Account condivisi di fabbrica | Registro di provisioning, prova al primo avvio |
| Ruoli separati per operatore, manutenzione e ingegneria | Modifiche di movimento fuori ruolo | Matrice di autorizzazione e audit |
| Finestre di manutenzione per cloud e tunnel | Autorità remota aperta | Registro della finestra, chiusura automatica, rollback |
| SBOM e monitoraggio dei fornitori | Avvisi che non arrivano al team | SBOM, fonti degli avvisi, decisione di classificazione |
Quale rischio residuo resta dopo i controlli?
Dopo aver applicato i controlli, il fabbricante deve nominare cosa resta vivo e perché. In questo esempio, il rischio di vulnerabilità del fornitore permane perché il robot dipende da RT OS, visione e bus di campo di terzi. Il rischio non si accetta in astratto: si lega a monitoraggio degli avvisi, firma dei pacchetti, finestre di manutenzione, comunicazione con gli integratori e prove correttive. La mitigazione documentata deve dimostrare che il processo esista prima che inizi la produzione.
Come devono circolare gli avvisi del cloud di flotta?
La valutazione precedente vive in un armadio di robot. L'instradamento degli avvisi vive in centinaia di robot. Quando il cloud di flotta del fabbricante serve più integratori e stabilimenti, la domanda non è solo se il cloud è sicuro. La domanda è chi riceve un avviso di vulnerabilità in 24 ore e chi approva la finestra di aggiornamento di ogni sito.
| Topologia di flotta | Chi sta tra fabbricante e utente finale | Cosa cambia nel fascicolo |
|---|---|---|
| Operatore di un solo sito, diretto dal fabbricante | Fabbricante → operatore | L'avviso arriva al team di manutenzione dell'operatore; un canale può bastare |
| Operatore multisito con ingegneria centrale | Fabbricante → ingegneria centrale → stabilimenti | Il fascicolo deve registrare il contatto centrale perché l'avviso non si perda in una casella locale |
| Flotta gestita da OEM | Fabbricante → operazioni OEM → operatori finali | L'OEM inoltra avvisi con impatto sulla macchina, ma il fabbricante necessita di una via verso gli utenti interessati |
| Flotta gestita da integratore | Fabbricante → integratore → PMI utilizzatrici | L'avviso del fabbricante alimenta il processo proprio dell'integratore quando questi vende con il proprio marchio |
| Flotta di flotte | Cloud del fabbricante ↔ cloud OEM ↔ cloud dell'integratore ↔ operatore | Documenti quale catena è contrattuale e quale copre la notifica regolatoria e gli utenti |
Registro di rilascio. Una mappa di instradamento del cloud di flotta deve nominare, per ciascun integratore e operatore della lista, il contatto per gli avvisi di 24 ore, il titolare della finestra di manutenzione, l'autorità di rollback e gli avvisi residui aperti.
Quali porte di validazione si chiudono prima del rilascio?
Eviti una porta generica di «sicurezza rivista». Usi un inventario di porte con modalità di guasto, controllo ed evidenza per ogni decisione che può bloccare la spedizione.
| Porta | Guasto che blocca | Evidenza |
|---|---|---|
| Chiusura della variante | Non è chiaro cosa si vende | Memorandum sui limiti e percorso |
| Autorità di movimento | Un ruolo errato può cambiare traiettoria o modo | Prova negativa e audit |
| Firmware di sicurezza | L'aggiornamento altera la logica di sicurezza senza revisione | Revisione congiunta e prova firmata |
| Bus di campo | Frame anomali incidono sul ciclo o sulla disponibilità | Prova del bus e segmentazione |
| Cloud e OTA | Il cloud conserva un'autorità indefinita | Finestra, certificati, rollback |
| Documentazione | Manca contatto, supporto o istruzioni | Indice del fascicolo e pacchetto per l'importatore |
Chi assume lo sviluppo del robot dal concept al supporto?
Usi una corsia di responsabilità. Ogni fase ha un responsabile principale, un registro mantenuto e una porta di revisione. Il rilascio non si chiude finché ogni fase non lascia traccia.
Quali registri di evidenza entrano nel fascicolo?
L'elenco seguente è una vista revisionabile. Congela l'identità del prodotto, i controlli di sicurezza e gli obblighi post-vendita. Ogni riga deve puntare a un registro mantenuto, non a una cartella di schermate sparse.
| Registro di evidenza | Cosa cattura per un robot industriale o cobot |
|---|---|
| Identità del prodotto | Modello del braccio, carico utile, portata, armadio di controllo, console di programmazione, ramo del firmware, ambiente di esecuzione, sensore di visione, opzioni di bus, servizio hardware |
| Uso previsto | Operazione collaborativa o recintata, carico utile, applicazione, modalità operatore, schema di utilizzo e variante |
| Fascicolo di ciberresilienza | Percorso di classificazione, perimetro, lista delle minacce, controlli di fiducia e decisioni residue |
| Inventario dei componenti | CPU di movimento, sistema operativo real-time, stack del bus di campo, stack slave EtherCAT, firmware di sicurezza, ambiente di esecuzione, librerie, modulo di visione |
| Configurazione sicura per impostazione predefinita | Nessun segreto condiviso, account unici, blocco delle versioni precedenti, OPC UA sicuro per impostazione predefinita, servizio dopo la messa in servizio |
| Meccanismo di aggiornamento | Firmware firmato, rollback, mappa di impatto sulla macchina, contatto del cliente ed evidenza del cloud |
| Gestione delle vulnerabilità | Politica di divulgazione, contatto unico, flusso di classificazione, monitoraggio degli avvisi dei componenti e degli integratori |
| Istruzioni per l'utente | Messa in servizio sicura, gestione dei ruoli, dismissione, finestre di aggiornamento, limiti di servizio |
| Tracciabilità e contatto | Tipo, lotto o seriale, dati del fabbricante, data di fine supporto e contatto per le vulnerabilità |
Cosa entra in un SBOM di robot?
Il CRA richiede un SBOM leggibile da macchina che identifichi i componenti e copra almeno le dipendenze di primo livello, ma non fissa ancora un formato unico. Finché la Commissione non specifica ulteriori dettagli, i fabbricanti scelgono di solito CycloneDX o SPDX. La guida trasversale è nella guida SBOM; questa sezione copre l'albero specifico del robot.
Una release di robot fornisce solitamente più elementi digitali con cicli di aggiornamento separati, non un unico binario. Due schemi soddisfano il minimo: un SBOM di prodotto con sezioni per elemento, oppure un SBOM per elemento digitale fornito che si aggiorna a ogni rilascio. L'uno o l'altro vanno bene se l'SBOM è leggibile da macchina e copre le dipendenze di primo livello.
Registro SBOM: un SBOM leggibile da macchina in CycloneDX o SPDX che copra almeno le dipendenze di primo livello. Per i robot, è di solito un SBOM di prodotto con sezioni per elemento, oppure un SBOM per elemento digitale fornito. Le dipendenze transitive più profonde sono raccomandate quando il sistema di build può produrle.
Cosa verifica la firma di rilascio?
Prima che il robot esca sul mercato dell'UE, la firma deve chiudere gli stessi quattro registri delle domande Q1-Q4. L'inventario non vive nell'evidenza astratta sopra. Questa tabella riguarda solo le quattro decisioni che bloccano il rilascio.
Firma di rilascio: quattro registri che bloccano l'uscita
- Q1 Memorandum di classificazione. Perché il prodotto è classificato così: uso previsto, contesto di vendita, elementi digitali consegnati e percorso standard scelto.
- Q2 Inventario degli elementi consegnati. Cosa si spedisce esattamente: braccio, controllore, console di programmazione, visione, firmware, cloud, librerie, manuali e varianti.
- Q3 Pacchetto di prova della configurazione sicura per impostazione predefinita. Credenziali per dispositivo, profilo OPC UA, rigetto delle versioni precedenti, blocco del debug e modalità di servizio.
- Q4 Processo di gestione delle vulnerabilità. Contatto pubblico, politica di divulgazione, classificazione, monitoraggio dei componenti, integratori e preparazione alle notifiche.
Verifiche preliminari: i quattro registri si devono ritrovare in meno di un minuto; le cartelle devono essere fissate al ramo del firmware e alla baseline dei fornitori; deve esistere un responsabile nominato per gli avvisi di 24 e 72 ore.
Porta di firma: se manca un registro, il rilascio non si firma.
Registro della dichiarazione: usi la guida principale alla dichiarazione UE di conformità per il modello e i campi richiesti. In una release di robot, l'identità del prodotto deve fissare braccio, armadio di controllo, console di programmazione, ramo del firmware, opzioni fornite e riferimento al periodo di supporto. Se la stessa dichiarazione copre anche la legislazione sulle macchine, nomini quel percorso e mantenga allineati il fascicolo tecnico del robot e il fascicolo di sicurezza della macchina.
Come si trasferisce il robot a importatore, distributore, integratore e operatore?
Il fascicolo deve rendere verificabile il trasferimento da fabbricante a importatore, distributore, integratore come fabbricante di macchina e utente finale. Per robot e cobot, il punto debole non è di solito solo la marcatura CE. Spesso è se la spedizione, il manuale, il cloud di flotta, il servizio OTA e il trasferimento all'integratore continuano a coincidere con la release valutata.
Trasferimento tra operatori economici: ruoli, verifiche e regimi vicini
- 01 Fabbricante. Mantiene il pacchetto di rilascio: dichiarazione, CE, indice del fascicolo, finestra di supporto e contatto per le vulnerabilità.
- 02 Importatore. Verifica pacchetto, CE, indice, data di supporto e contatto. Sospende la spedizione se ci sono dubbi su tracciabilità, credenziali, account cloud o canale di aggiornamento.
- 03 Distributore. Esamina CE visibile, documenti forniti, tracciabilità per l'operatore, supporto e affermazioni sugli aggiornamenti. Sospende la vendita se l'annuncio nasconde operatori, esagera il supporto o contraddice la dichiarazione.
- 04 Integratore. Combina il braccio con sicurezza, visione e logica di cella. Se la cella esce sotto il suo nome, l'integratore diventa fabbricante della cella.
- 05 Operatore. Riceve avvisi, applica aggiornamenti nelle finestre di manutenzione e segnala problemi. Non è fabbricante.
Verifica A: rappresentante e notifica fuori UE. Il mandato del rappresentante autorizzato è opzionale. I fabbricanti senza stabilimento principale nell'Unione usano la cascata del punto di notifica per scegliere il CSIRT coordinatore.
Verifica B: nuovi fabbricanti. Un importatore o distributore che vende con il proprio nome, o che modifica sostanzialmente il robot, diventa fabbricante di quell'offerta. Altri terzi attraversano quella linea solo quando la loro modifica è sostanziale.
Regimi vicini: Regolamento Macchine dal 20 gennaio 2027, ISO 10218-1:2025, NIS2 per gli operatori di infrastrutture critiche e Regolamento sull'IA per le applicazioni con IA.
Le righe seguenti sono la versione breve: cosa verificare, quando sospendere e quando il robot richiede una nuova analisi del ruolo. Il dettaglio trasversale dei ruoli è in chi deve rispettare il CRA.
Accettazione dell'importatore
Verifichi dichiarazione, controllo del CE, indice del fascicolo, periodo di supporto, contatto per le vulnerabilità, identità dell'importatore e manuale nella lingua di destinazione. Sospenda se pacchetto, tracciabilità, modello di credenziali della console, account cloud o canale di aggiornamento generano dubbi.
Diligenza del distributore
Verifichi CE visibile, documenti forniti, tracciabilità per l'operatore, supporto e affermazioni sugli aggiornamenti. Sospenda se l'offerta nasconde operatori, esagera il supporto, contraddice la dichiarazione o continua a vendere dopo una vulnerabilità nota.
Integratore come fabbricante di macchina
Un integratore che combina il braccio con sicurezza, visione e logica di cella diventa fabbricante della macchina quando la cella esce sotto il suo nome. Il fabbricante del robot resta fabbricante del componente per braccio, controllore e software fornito.
Importatore o distributore con marchio proprio
Un importatore o distributore che immette il robot sul mercato dell'Unione con il proprio nome o marchio diventa fabbricante di quell'offerta. Lo stesso accade se modifica sostanzialmente un robot già commercializzato: firmware con marchio proprio, nuova identità della console, nuovo cloud di flotta, nuovo canale di aggiornamento, nuova configurazione di sicurezza o nuova finalità prevista.
Altro rivenditore dopo modifica sostanziale
Un terzo che non è fabbricante, importatore né distributore diventa fabbricante solo se modifica sostanzialmente il robot prima di metterlo a disposizione. Il ruolo si applica alla parte interessata, o al prodotto intero se la modifica incide sulla cibersicurezza complessiva.
Rappresentante autorizzato e notifica fuori UE
Il fabbricante può nominare un rappresentante autorizzato tramite mandato scritto: è un'opzione, non un obbligo derivante dall'essere fuori dall'UE. La selezione del punto di notifica scatta per un altro fatto: non avere stabilimento principale nell'Unione. La cascata del CRA inizia dal rappresentante, prosegue con l'importatore, poi il distributore e infine la maggiore base utenti.
Regimi vicini
Mantenga valutazioni separate per Regolamento Macchine, ISO 10218-1:2025, NIS2 e Regolamento sull'IA. Possono condividere evidenze, ma non sostituiscono il fascicolo CRA.
Domande frequenti
I robot industriali e i cobot sono prodotti importanti o critici ai sensi del CRA?
Non per categoria di robot. I robot industriali e i cobot non figurano oggi negli elenchi CRA dei prodotti importanti o critici. L'ipotesi di lavoro è il percorso predefinito. Il percorso cambia solo se una funzione elencata domina, per esempio un robot venduto principalmente come firewall, sistema di gestione di rete o controllore resistente alle manomissioni. Non esiste una categoria di «robot» che forzi automaticamente il percorso critico.
Un braccio robotico a 6 assi richiede un organismo notificato?
Non per il fatto di essere un braccio robotico. Nel percorso predefinito, il fabbricante può usare il controllo interno, l'esame UE del tipo con conformità al tipo, la garanzia di qualità completa o uno schema europeo di certificazione applicabile. L'organismo notificato interviene solo nei percorsi che lo richiedono. La condizione delle norme pienamente applicate appartiene al percorso di riserva per i prodotti importanti di classe I, non al percorso predefinito.
Il Regolamento Macchine copre già la parte cyber?
Copre una parte, non tutto. Il Regolamento Macchine include requisiti di sicurezza relativi alla corruzione dei sistemi di comando e all'affidabilità del controllo. Il CRA aggiunge lo strato di ciberresilienza: postura di sicurezza, processo di gestione delle vulnerabilità, supporto, SBOM e documentazione tecnica. Li tratti come due fascicoli connessi.
Chi è il fabbricante quando un integratore costruisce la cella?
Se l'integratore vende la cella finita con il proprio nome, l'integratore è fabbricante di quella cella. Il fabbricante del robot mantiene il proprio fascicolo per braccio, controllore e software che fornisce. Se l'integratore si limita a installare una cella con il marchio del fabbricante, documenti il trasferimento e i limiti, ma non inventi un cambio di ruolo che non esiste.
Un cobot per officine PMI rientra nella stessa categoria di un robot recintato?
Sì, se nessuna funzione elencata domina l'offerta. La differenza sta nella valutazione del rischio, non nella categoria CRA iniziale. Il cobot ha di solito più esposizione umana, più ruoli condivisi e maggiore dipendenza dal fabbricante per avvisi, supporto e aggiornamenti.
Cosa succede se il robot include visione, IA o teleoperazione remota?
Non cambia automaticamente la categoria CRA. Cambia il perimetro e la lista delle minacce. La visione aggiunge telecamere, SDK e modelli; la teleoperazione aggiunge autorità remota; l'IA può attivare un'analisi ai sensi del Regolamento sull'IA se ne supera le soglie. Ogni elemento deve comparire nel memorandum sui limiti e nell'SBOM.
Il cloud di flotta cambia il perimetro del prodotto?
Sì, quando il cloud è fornito dal fabbricante ed è necessario per avvisi, aggiornamenti, certificati, telemetria o tunnel. In quel caso, il connettore cloud e la sua autorità fanno parte del fascicolo del fabbricante. Se il cloud appartiene al cliente o all'integratore, documenti il trasferimento e i limiti.
Cosa deve includere una valutazione del rischio CRA di un robot?
Deve coprire movimento, firmware di sicurezza, console di programmazione, stazione di ingegneria, bus di campo, cloud, servizio locale, componenti del fornitore, ritiro dal servizio e comunicazione delle vulnerabilità. La domanda non è solo se c'è cifratura. La domanda è chi può cambiare il movimento, la configurazione di sicurezza o la disponibilità.
Quanto dettaglio richiede il modello delle minacce?
Quel che basta a giustificare le decisioni di rilascio. Una frase generica su «accesso non autorizzato» non serve. Una voce utile nomina asset, confine, modalità di guasto, controllo, prova e decisione residua: per esempio, «un pacchetto di firmware vecchio viene accettato durante il ripristino; si mitiga con firma e rigetto delle versioni precedenti; si verifica nella modalità di ripristino».
Quali rischi si valutano per primi?
Cominci da quelli che cambiano il movimento o la sicurezza: credenziali di fabbrica, aggiornamenti del firmware, autorità del cloud, caricamento dei programmi, ruoli della console e bus di campo. Poi copra disponibilità, dati di servizio, avvisi dei fornitori e ritiro dal servizio.
Qual è un buon esempio di voce di rischio?
«Un progetto di robot malformato provoca un guasto del parser o carica una traiettoria non validata dalla stazione di ingegneria. Asset: autorità di movimento. Confine: stazione di ingegneria a controllore. Controllo: validazione del formato, firma del progetto, ruolo di ingegneria e prova negativa. Evidenza: output del parser, registro di rigetto e audit di sessione.»
Quando va aggiornata la valutazione del rischio?
La aggiorni quando cambia lo stato rilasciato: nuovo modello di account della console, nuovo bus di campo, cambio di cloud, firmware di sicurezza, ambiente di esecuzione, modulo di visione, debug o ritiro dal servizio. La data anticipata è rilevante: gli obblighi di notifica iniziano l'11 settembre 2026, prima dell'applicazione piena del CRA l'11 dicembre 2027. La valutazione, la politica di divulgazione e il contatto unico devono funzionare prima di quella data.
Qual è la prima evidenza che un fabbricante di robot deve creare?
Il memorandum sui limiti. Nomini il prodotto esatto, cosa si consegna, cosa resta fuori, cosa integra il cliente, cosa mantiene il fabbricante e quale percorso di conformità si usa. Senza quel registro, l'SBOM, la valutazione del rischio e il trasferimento all'integratore restano fluttuanti.
Cosa succede se si scopre una vulnerabilità dopo il rilascio?
Il fabbricante deve agire immediatamente quando il prodotto o i processi non risultano conformi: correzione, ritiro o richiamo del prodotto quando opportuno. In pratica, il fascicolo deve essere pronto per la sequenza di notifica: avviso di 24 ore per la vulnerabilità attivamente sfruttata, notifica di 72 ore, rapporto finale quando è disponibile la misura correttiva o di mitigazione, e avviso agli utenti. Per i robot, la correzione è di solito un aggiornamento firmato con nota di impatto sulla macchina e proposta di finestra di manutenzione; il richiamo resta per i casi che non si possono aggiornare in sicurezza sul campo.