Componenti di terzi e CRA: integrare o importare?

Compra un modulo Bluetooth. Oppure un SDK per il firmware. Oppure un termostato connesso già finito, con il logo del fornitore sulla scatola.

Non sono lo stesso problema ai fini del CRA. Se integra il componente nel suo prodotto, la documentazione del prodotto finito è sua. Se importa un prodotto finito a marchio extra-UE, verifica la documentazione del fabbricante. Questa distinzione va fatta prima dell'ordine di acquisto, non dopo l'arrivo della merce.

La domanda reale degli acquirenti europei

La domanda è raramente formulata come una questione di ruolo giuridico. Suona come approvvigionamento:

• «Compriamo il modulo wireless da un fornitore.»
• «L'SDK cloud arriva da un vendor.»
• «L'ODM ci invia la scheda e noi ci carichiamo il nostro firmware.»
• «Il dispositivo finito arriva da un fabbricante extra-UE.»

Ogni frase indica uno schema documentale diverso. L'errore è trattarle tutte come «dovuta diligenza sul fornitore».

Il nostro punto di vista: la decisione sul ruolo appartiene alla fase di acquisto. Se l'ufficio acquisti aspetta che il prodotto sia in magazzino, il team di conformità eredita una situazione difficile da cambiare. L'ordine di acquisto dovrebbe già dire se la sua azienda redigerà la documentazione del prodotto finito o verificherà quella del fornitore.

Per la mappa completa dei ruoli, usi l'albero decisionale dei ruoli CRA. Per il bivio dell'acquisto, tenga il focus sui registri che derivano dall'atto di acquisto.

Il bivio: integrare componenti o importare prodotti finiti

Il primo bivio è pratico:

Atto di acquisto	Test in parole semplici	Esito documentale
Integrare un modulo, chip, SDK, libreria o scheda nel suo prodotto	Il prodotto finito arriva sul mercato UE con l'identità del suo prodotto	Redige la documentazione del prodotto finito
Importare un prodotto finito a marchio extra-UE	Il prodotto del fornitore è già completo e mantiene l'identità del fornitore	Verifica la documentazione del fabbricante
Apporre il suo nome o marchio sul prodotto	Il mercato vede la sua azienda come origine	Entra nel lavoro di livello fabbricante
Rivendere invariato dopo che un altro operatore lo ha immesso sul mercato	Non incide sulle proprietà del prodotto	Esegue i controlli di dovuta diligenza del distributore

In pratica: non si chieda se il fornitore sia «conforme al CRA» in astratto. Si chieda che cosa sta facendo con il componente o il prodotto.

Quando integra un modulo, chip, SDK o libreria

Se integra un componente di terzi nel suo prodotto, non sta comprando una posizione di conformità già completa. Sta comprando un input.

L'articolo 3 definisce il prodotto con elementi digitali come comprensivo dei componenti software o hardware immessi sul mercato separatamente. Lo stesso articolo definisce il componente come software o hardware destinato all'integrazione in un sistema di informazione elettronico. Per questo un modulo wireless, un SDK per il firmware o una libreria embedded venduti separatamente possono avere una propria traccia documentale.

Quella traccia comunque non diventa il fascicolo del suo prodotto finito.

Quando immette il prodotto finito sul mercato UE, il lavoro del fabbricante spetta all'entità che immette quel prodotto con il proprio nome o marchio. Per un fabbricante UE di termostati, il fornitore del modulo wireless può fornire la dichiarazione di modulo, un inventario dei componenti, le note sulle versioni del firmware e i recapiti per la segnalazione di vulnerabilità. Il fabbricante del termostato scrive comunque la valutazione del rischio di cibersicurezza del termostato, la documentazione tecnica, la dichiarazione UE di conformità e la base della marcatura CE.

Entrambi gli obblighi si trovano nell'articolo 13: la dovuta diligenza sui componenti che integra e la documentazione tecnica, la valutazione della conformità, la dichiarazione UE di conformità e la marcatura CE del prodotto finito.

La regola pratica è semplice: i registri del fornitore alimentano il suo fascicolo. Non lo sostituiscono.

Tra gli input utili del fornitore rientrano:

• Identità del componente: modello esatto, versione, ramo del firmware, lotto o revisione hardware.
• Percorso degli aggiornamenti di sicurezza: chi rilascia le correzioni del componente, come le riceve e come arrivano al suo prodotto.
• Distinta base del software o inventario dei componenti: dettaglio sufficiente per monitorare le vulnerabilità del componente durante il periodo di assistenza.
• Contatto per le vulnerabilità: un canale reale per le vulnerabilità del componente, non solo un indirizzo commerciale.
• Date del ciclo di vita: date di fine vendita e fine assistenza del modulo, SDK o scheda.

Per l'esame approfondito del fornitore, usi il questionario di dovuta diligenza sui fornitori CRA. Questa pagina non ripete quel questionario. Spiega soltanto dove si collocano i registri del fornitore nel fascicolo del prodotto finito.

L'open source conta come componente di terzi

La maggior parte dei firmware include più codice open source che codice acquistato. Il CRA tratta l'open source come qualsiasi altro componente: l'obbligo di dovuta diligenza copre il software libero e open source che integra, anche quando nessuno gliel'ha venduto e non esiste un contratto.

Il registro cambia forma, non l'obbligo:

• L'identità conta comunque: registri il progetto, la versione esatta e la fonte da cui lo scarica, allo stesso modo in cui registra un modulo a pagamento.
• Il monitoraggio conta comunque: la libreria entra nell'inventario dei componenti, così può sorvegliare le vulnerabilità durante il periodo di assistenza.
• Le correzioni viaggiano in entrambe le direzioni: quando trova una vulnerabilità in un componente integrato, la segnala al progetto che lo mantiene e corregge comunque il suo prodotto. Quando corregge lei stesso il componente, condivide la correzione con il manutentore.

Non c'è un fornitore da interrogare, quindi la verifica si svolge sul progetto stesso: quanto è attivo, come pubblica le correzioni di sicurezza e se la versione che ha bloccato riceve ancora questi aggiornamenti.

Quando importa un prodotto finito a marchio extra-UE

Importare un prodotto finito è diverso. Il prodotto esiste già come prodotto con elementi digitali. Il fabbricante extra-UE vi mantiene il proprio nome o marchio. La sua azienda UE è il primo operatore UE che lo immette sul mercato dell'Unione.

È uno schema da importatore.

Il compito dell'importatore non è ricreare la documentazione tecnica del fabbricante. L'importatore controlla che il fabbricante abbia svolto la valutazione della conformità e redatto la documentazione tecnica, e che la marcatura CE e la dichiarazione UE di conformità siano presenti. Verifica anche che le informazioni per l'utente richieste accompagnino il prodotto e che siano presenti l'identificazione del prodotto, i dati di contatto del fabbricante e la data di fine del periodo di assistenza.

Questo schema di verifica è fissato dall'articolo 19. L'importatore deve conservare una copia della dichiarazione UE di conformità per almeno 10 anni dall'immissione del prodotto sul mercato o per il periodo di assistenza, se più lungo, e assicurarsi che la documentazione tecnica possa essere messa a disposizione delle autorità di vigilanza del mercato su richiesta.

Un'etichetta spetta a lei: l'importatore appone il proprio nome, l'indirizzo postale e il contatto digitale sul prodotto, sull'imballaggio o su un documento di accompagnamento.

È un fascicolo di verifica, non un fascicolo del fabbricante.

Usi la guida per l'importatore CRA per il controllo completo in ricezione. La distinzione utile qui è più stretta: se il prodotto resta il prodotto finito del fabbricante extra-UE, verifica. Se lo trasforma nel suo prodotto, lo redige.

La catena documentale: redigere, verificare o conservare copia

Questa tabella è il registro di lavoro. La usi per linea di prodotti, non per fornitore. Uno stesso fornitore può comparire in due colonne se compra un modulo per un prodotto e importa un prodotto finito dalla stessa azienda.

In pratica: lo stesso documento del fornitore può svolgere 2 ruoli. Per chi integra, diventa evidenza in input per il fascicolo del prodotto finito. Per chi importa, sostiene un registro di verifica pre-mercato.

Esempio pratico: lo stesso modulo Bluetooth/Wi-Fi in due percorsi CRA

Prenda un modulo wireless. Stesso modello. Stesso firmware. Stesso fornitore.

Il lavoro CRA cambia quando cambia lo schema di acquisto.

Scenario A: un fabbricante UE di termostati integra il modulo.
Costruisce un termostato connesso con il suo marchio. Compra il modulo Bluetooth/Wi-Fi e lo integra nella sua scheda. Il fornitore del modulo le fornisce la scheda tecnica, la versione del firmware, il contatto di sicurezza e la dichiarazione sul ciclo di vita.

Redige comunque il fascicolo del termostato. Il suo fascicolo spiega come il modulo incide su accoppiamento, esposizione sulla rete locale, distribuzione degli aggiornamenti, monitoraggio delle vulnerabilità e pianificazione del periodo di assistenza. I registri del fornitore del modulo stanno dentro il suo insieme di evidenze come input.

Scenario B: un importatore UE acquista il termostato finito.
Acquista un termostato finito a marchio extra-UE. Il modulo wireless è già dentro il dispositivo. Il fabbricante extra-UE mantiene il proprio marchio su scatola, firmware, app e dichiarazione.

Verifica la documentazione del fabbricante. Non scrive un nuovo fascicolo tecnico del termostato. Conserva il registro di verifica dell'importazione, la copia della dichiarazione e gli impegni del fornitore necessari per rispondere a una richiesta della vigilanza del mercato.

Lo stesso modulo genera un lavoro diverso perché il prodotto immesso sul mercato è diverso.

Come leggere i documenti del fornitore senza fidarsi troppo

I documenti del fornitore sono utili quando rispondono a una domanda sul prodotto. Sono deboli quando dicono solo «conforme» senza traccia di prodotto, versione o assistenza.

Parta da 5 controlli:

Documento del fornitore	Che cosa deve dimostrare	Come lo usa
Dichiarazione o certificato di modulo	Prodotto, modello e ambito del firmware esatti	Lo colleghi alla versione del componente nel registro del suo prodotto
Distinta base del software o elenco componenti	Elementi software e firmware che può monitorare	Alimenti l'inventario del suo prodotto e il monitoraggio delle vulnerabilità
Contatto per le vulnerabilità	Un canale per le vulnerabilità del componente	Lo salvi nel flusso di gestione delle vulnerabilità del prodotto
Dichiarazione di assistenza o ciclo di vita	Per quanto tempo il componente riceve correzioni	La confronti con il periodo di assistenza del suo prodotto
Processo di notifica delle modifiche	Come viene a sapere di nuove versioni di firmware, chip o SDK	Avvii un riesame del fascicolo di prodotto prima del rilascio o dell'importazione

In pratica: il documento è utile solo quando si aggancia a un prodotto, una versione e una decisione con un nome. Un PDF generico del fornitore senza SKU, data o canale di contatto non dovrebbe reggere una decisione di rilascio.

Per chi integra, il pacchetto del fornitore deve rispondere a una domanda: questo componente può stare dentro il prodotto senza indebolirne la cibersicurezza durante il periodo di assistenza?

Per chi importa, il pacchetto del fornitore deve rispondere a una domanda diversa: il fabbricante extra-UE ha svolto il lavoro sul prodotto finito e può dimostrare di averlo verificato prima dell'immissione nell'UE?

L'opinione non è «raccolga più documenti». L'opinione è «decida che cosa dimostra ogni documento prima di comprare».

Il filtro dell'ordine di acquisto

Metta la decisione sul ruolo dentro il processo di acquisto. I principali obblighi del CRA si applicano dall'11 dicembre 2027 e tutto ciò che immette sul mercato da quella data richiede questi registri già pronti. Un riesame di conformità dopo l'arrivo della merce è tardivo, costoso e spesso politico.

Prima di firmare l'ordine di acquisto, si ponga queste domande:

1. Che cosa stiamo comprando? Un componente, una scheda, un SDK, una dipendenza cloud o un prodotto finito.
2. Il nome di chi arriva sul mercato? Il suo marchio, quello del fornitore o entrambi.
3. Cambieremo firmware, instradamento cloud, percorsi di aggiornamento o impostazioni di sicurezza predefinite? Ogni risposta affermativa richiede un riesame del ruolo.
4. Quali registri arrivano con il componente? Dichiarazione, indice della documentazione tecnica, distinta base del software, data di assistenza, contatto per le vulnerabilità e informazioni per l'utente.
5. Quali registri redigiamo? Contrassegni come suoi la documentazione del prodotto finito, la dichiarazione e i registri del periodo di assistenza solo quando l'identità del suo prodotto arriva sul mercato.
6. Quali registri verifichiamo? Contrassegni i registri del fornitore o del fabbricante come evidenza di verifica solo quando il prodotto finito resta sotto l'identità del fornitore.
7. Quale evento riapre la decisione? Modifica del firmware, fine vita del fornitore, rebranding, nuova revisione del modulo, cambio di endpoint cloud o avviso di vulnerabilità.

Chi acquista dovrebbe poter rispondere a queste domande in una pagina. Se serve una serie di riunioni, l'acquisto non è pronto per la pianificazione del rilascio.

Errori comuni in fase di acquisto

Questi errori compaiono prima che l'ingegneria veda una vulnerabilità. Nascono negli acquisti, nel marchio privato e nella ricezione.

• «Il modulo ha la marcatura CE, quindi il nostro fascicolo di prodotto è completo»: il marchio del modulo non copre l'architettura del prodotto finito, il percorso di aggiornamento, il periodo di assistenza o la valutazione del rischio. Lo tratti come documentazione in input.
• «Il fornitore dichiara la conformità al CRA, quindi possiamo importare»: una dichiarazione commerciale non è un registro di verifica. Chieda la dichiarazione, l'indice della documentazione tecnica, la dichiarazione sul periodo di assistenza, il contatto per le vulnerabilità e le informazioni per l'utente.
• «Ci mettiamo il nostro marchio ma ci chiamiamo ancora importatori»: il marchio proprio indica un lavoro di livello fabbricante. Usi la guida white-label e OEM prima di pubblicare l'annuncio.
• «Abbiamo cambiato il firmware ma tenuto la dichiarazione del fornitore»: cambiare il firmware, l'endpoint cloud o il percorso di aggiornamento può cambiare il prodotto valutato. Faccia il controllo del ruolo prima di spedire.
• «Ci limitiamo a distribuire, quindi nessuno deve controllare nulla»: i distributori eseguono comunque controlli di dovuta diligenza prima di mettere a disposizione i prodotti. Usi la checklist del distributore per il banco di ricezione.

La regola sicura più breve: se il prodotto cambia o il suo nome diventa l'origine, si fermi e rifaccia l'analisi del ruolo.

Casi particolari trattati in altre pagine

Usi queste pagine quando la situazione esce dal bivio dei componenti:

Caso particolare	Dove andare	Perché
Vende un prodotto OEM con il suo nome	Guida white-label e OEM	Il marchio proprio sposta il lavoro nel territorio del fabbricante
Le serve un questionario per il fornitore	Questionario di dovuta diligenza sui fornitori	Quella pagina copre segnali d'allarme, playbook e clausole
Rivende solo prodotti invariati	Checklist del distributore	Il controllo in ricezione è incentrato su marchi visibili e documenti
Le serve l'albero completo dei ruoli	Chi deve conformarsi al CRA	Questa pagina non sostituisce la classificazione dei ruoli
Una persona giuridica ha più ruoli	Guida CRA multi-ruolo	L'accumulo di ruoli è un problema di portfolio aziendale

In pratica: rimandi ad altre pagine quando la domanda cambia. Non trasformi una pagina sull'acquisto di componenti in una guida generale ai ruoli CRA.

Quali evidenze conservare prima dell'immissione sul mercato UE

Parta da una linea di prodotti. Poi agganci i registri a quella linea, non a una cartella generica del fornitore.

Segua questo ordine:

1. Classifichi l'atto di acquisto. Scriva componente integrato, importazione di prodotto finito, prodotto a marchio proprio o rivendita invariata accanto allo SKU.
2. Indichi il titolare del documento. Contrassegni la documentazione tecnica come nostra, del fabbricante o non detenuta.
3. Agganci gli input del fornitore. Salvi schede tecniche, distinte base del software, date di assistenza, versioni del firmware, contatti per le vulnerabilità e dichiarazioni nel registro del prodotto.
4. Registri la decisione. Conservi la data, il revisore e il motivo per cui tratta il registro come evidenza di redazione, verifica o dovuta diligenza.
5. Imposti l'evento di riesame. Riapra il registro in caso di modifica del firmware del fornitore, fine vita del modulo, avviso di vulnerabilità, rebranding, cambio di endpoint cloud o modifica del periodo di assistenza.