Modifica sostanziale nel CRA: rischi e obblighi per chi cambia un prodotto

Nel CRA la modifica sostanziale non si misura in righe di codice o giornate di lavoro. Conta l’effetto del cambiamento: se incide sui requisiti essenziali di cybersicurezza oppure altera la destinazione d’uso rispetto alla quale il prodotto era stato valutato, chi lo modifica e lo rende nuovamente disponibile può assumere gli obblighi del fabbricante. Una funzione piccola, come il salvataggio locale di un token, può quindi pesare più di un refactoring esteso.

Per gli integratori il problema nasce anche prima, quando componenti conformi vengono combinati in una soluzione nuova. Nel white label basta invece il marchio: chi presenta il prodotto come proprio risponde della conformità, delle vulnerabilità, delle notifiche e del supporto, pur avendo affidato all’OEM ogni attività tecnica. Il contratto distribuisce il lavoro e i costi; di fronte al mercato e alle autorità, il ruolo segue il prodotto.

Una dashboard, un nuovo comando e un fabbricante inatteso

Immaginiamo una scena comune. Un’impresa ha installato presso il cliente una piattaforma che raccoglie i dati di una macchina e li mostra su una dashboard. Qualche mese dopo il cliente chiede di poter cambiare i parametri e riavviare l’impianto dalla stessa schermata. L’integratore aggiunge due pulsanti, aggiorna il backend e riconsegna la soluzione. Per il team di progetto è una change request ben riuscita. Per il Cyber Resilience Act potrebbe essere accaduto qualcosa di più impegnativo: il manutentore potrebbe aver immesso sul mercato un prodotto sostanzialmente modificato ed essere diventato, per quella versione, fabbricante.

Il passaggio è facile da perdere perché il CRA usa una soglia giuridica, mentre le imprese ragionano per dimensione del progetto. L’art. 3, n. 30, del Regolamento (UE) 2024/2847 guarda agli effetti di un cambiamento intervenuto dopo l’immissione sul mercato. La modifica è sostanziale quando incide sulla conformità ai requisiti essenziali dell’allegato I, parte I, oppure cambia la destinazione d’uso rispetto alla quale il prodotto era stato valutato. Il numero dei file toccati, il valore economico dell’intervento e il nome scelto nel ticket non compaiono nella definizione.

Anche la destinazione d’uso merita attenzione. Non vive soltanto nella scheda tecnica. Il CRA la ricava dalle istruzioni, dalla documentazione, dal materiale promozionale e dalle dichiarazioni rese durante la vendita. Se una piattaforma nata per monitorare viene proposta come strumento di governo di un processo industriale, il prodotto cambia agli occhi del diritto prima ancora che nell’architettura. Lo stesso può accadere durante un rebranding: una promessa commerciale troppo ambiziosa allarga il perimetro che dovrà essere difeso e documentato.

La guida pubblicata dalla Commissione il 27 luglio 2026, allegata alla Comunicazione C(2026) 5252, prova a tradurre questa formula in domande utilizzabili da chi deve autorizzare un rilascio. Il cambiamento apre nuovi vettori di minaccia? Rende possibili scenari d’attacco che prima non esistevano? Aumenta la probabilità di quelli già considerati; oppure ne aggrava le conseguenze? Le domande sono quattro e vanno documentate. La guida resta un atto interpretativo, privo di forza vincolante, ma offre oggi la traccia più concreta disponibile per leggere il CRA.

Il ruolo dipende da ciò che si fa e da come il prodotto torna sul mercato

Nel linguaggio corrente manutentore, integratore e rivenditore descrivono un mestiere. Nel CRA descrivono, al massimo, il punto di partenza. Il regolamento osserva chi controlla il prodotto che arriva all’utente: chi ne decide la funzione, chi lo presenta come proprio, chi approva gli aggiornamenti e chi possiede le informazioni necessarie per seguirne le vulnerabilità. Da questa prospettiva emergono situazioni diverse, spesso sovrapposte nei contratti.

L’art. 22 riguarda chi interviene su un prodotto già immesso sul mercato. Se un soggetto diverso dal fabbricante originario esegue una modifica sostanziale e poi rende disponibile il prodotto modificato, viene considerato fabbricante ai fini del CRA. L’art. 21 segue un’altra strada: l’importatore o il distributore che colloca sul prodotto il proprio nome o marchio assume quel ruolo anche senza alterare hardware o software. L’integratore che assembla componenti in una soluzione nuova, infine, è fabbricante dell’insieme sin dalla prima immissione sul mercato. Non serve attendere una modifica successiva.

Sono differenze concrete. Chi modifica un prodotto esistente deve delimitare la parte coinvolta e verificare se il nuovo rischio si propaga all’intero sistema. Chi costruisce un insieme nuovo deve valutare le interazioni tra i componenti, anche quando ciascuno dispone già della propria dichiarazione di conformità. Il titolare di un marchio white label, invece, prende in carico il prodotto completo. Potrà farsi assistere dall’OEM, ma dovrà essere in grado di firmare la dichiarazione UE e difenderla.

La formula contrattuale scelta dalle parti non risolve la questione. Scrivere che il fornitore resta l’unico responsabile CRA serve a regolare rivalse, costi e rimedi; non impedisce all’autorità di qualificare come fabbricante il soggetto che ha messo il proprio marchio sul prodotto. Lo stesso vale per il manutentore che, dietro un ordine di servizio, decide e rilascia una versione con un nuovo profilo di rischio. Il diritto dei prodotti segue i fatti.

Occorre poi che il prodotto modificato venga messo a disposizione. Un intervento confinato all’uso interno richiede un’analisi specifica; l’art. 22 collega infatti il cambio di ruolo alla successiva fornitura del prodotto. Nei servizi resi a un cliente, tuttavia, la riconsegna della macchina o la distribuzione dell’aggiornamento può già integrare una messa a disposizione nell’ambito di un’attività commerciale. È opportuno che il contratto indichi chi autorizza quel momento e con quali evidenze.

Manutenzione: quando si resta manutentori

Il CRA non trasforma ogni tecnico che apre un dispositivo in un fabbricante. Riparare significa, di regola, riportare il prodotto entro il perimetro già valutato. La Commissione usa un esempio molto semplice: sostituire la RAM guasta di un server con un componente più performante migliora le prestazioni, ma non cambia la funzione del server né il suo profilo di cybersicurezza. Il tecnico ha riparato il prodotto. Può chiudere il ticket come manutentore.

La cautela cresce quando il ricambio incorpora software o funzioni di sicurezza. L’art. 2, par. 6, esclude dal regolamento i pezzi destinati a sostituire componenti identici, fabbricati secondo le stesse specifiche. In ambito digitale, l’identità non coincide sempre con il codice del catalogo. Un chipset diverso può essere equivalente; un firmware che cambia il secure boot, la cifratura o i protocolli di autenticazione probabilmente richiede un esame più serio. Il ricambio potrebbe essere un prodotto CRA autonomo. Questo, da solo, non rende sostanziale la modifica della macchina riparata: va ancora verificato l’effetto sul prodotto nel suo complesso.

Il tema diventa delicato sui sistemi legacy. I prodotti immessi sul mercato prima dell’11 dicembre 2027 entrano nel regime ordinario del CRA, da quella data, se subiscono una modifica sostanziale. Un retrofit industriale non comporta però, per definizione, la rivalutazione di ogni vite e di ogni riga del software storico. La guida adotta un criterio proporzionato: se il nuovo modulo resta isolato e le assunzioni di sicurezza dell’insieme tengono, l’analisi può concentrarsi sulla parte coinvolta. Quando l’intervento cambia fiducia, privilegi o flussi dell’intero sistema, il perimetro si allarga.

Qui la documentazione tecnica decide più dell’etichetta apposta al progetto. Chi vuole sostenere che un intervento è una riparazione deve mostrare la baseline precedente, la specifica del ricambio, i test eseguiti e la ragione per cui restano validi gli scenari d’attacco originari. Bastano poche pagine, se sono scritte al momento giusto. Ricostruirle dopo un incidente è assai più difficile.

Le patch piccole che cambiano il rischio

Il software rende ingannevole qualsiasi criterio basato sulla quantità. Una release può riscrivere migliaia di righe per eliminare debito tecnico e lasciare identiche le superfici di attacco. Un’altra aggiunge un solo flag e sposta il modello di fiducia del prodotto. Per questo la guida della Commissione insiste sul confronto con il risk assessment originario, non sulla dimensione della patch.

Prendiamo la funzione «ricordami». Se il nuovo rilascio salva in locale un token di autenticazione, entrano in scena il furto del token, il session hijacking e l’accesso da un dispositivo compromesso. Sono rischi molto concreti. Se il fascicolo originario non li aveva considerati, la funzione può integrare una modifica sostanziale anche se il diff occupa poche righe. Lo stesso vale per un export diagnostico che raccoglie log sensibili e li lascia in chiaro sul dispositivo.

La dashboard dell’esempio iniziale mostra l’altro lato del problema. Leggere la temperatura di una macchina e comandarne il riavvio sono azioni diverse. Cambiano i privilegi necessari; cambia anche l’impatto di un account compromesso. La nuova funzione può alterare la destinazione d’uso, oltre alla valutazione del rischio. Il fatto che lo stesso codice fosse già presente ma disattivo non chiude l’analisi: bisogna verificare se la sua attivazione era stata progettata, valutata e coperta da misure effettive.

Esistono infatti aggiornamenti funzionali già compresi nella conformità iniziale. Una piattaforma può essere progettata per introdurre il controllo automatico in una release successiva; il fascicolo descrive la funzione, include i relativi scenari e prevede le misure da attivare. Quando la roadmap è così concreta, il rilascio può restare nel perimetro valutato. Una frase generica sulle «future evoluzioni del prodotto» non ha lo stesso valore.

Anche gli aggiornamenti di sicurezza vanno guardati per ciò che fanno. Correggere un controllo di input, chiudere una porta inutile o rendere obbligatoria una MFA già prevista riduce il rischio e normalmente non costituisce modifica sostanziale. Diverso è spostare la cifratura da un modulo locale a un servizio remoto di key management. L’obiettivo resta la sicurezza, ma sono cambiati i confini del prodotto, le dipendenze e i flussi di dati. Serve una nuova verifica.

Da qui discende un’esigenza organizzativa molto pratica: il change management deve contenere un passaggio CRA prima del go-live. Qualcuno deve confrontare la release con architettura, destinazione d’uso e threat model; deve poi lasciare una traccia della decisione. È un controllo breve per le patch ordinarie. Diventa un vero fascicolo quando cambiano interfacce, privilegi o dipendenze critiche.

Personalizzare un prodotto altrui, costruirne uno nuovo

Le personalizzazioni richieste dai clienti occupano una zona in cui le parole usate nei progetti confondono più di quanto aiutino. Configurare un prodotto attraverso i parametri previsti dal fabbricante, seguendo le istruzioni e restando nella destinazione d’uso valutata, appartiene all’installazione. Toccare codice, firmware, interfacce o dipendenze impone invece il test sulla modifica sostanziale. Se il lavoro produce una soluzione nuova destinata al mercato, l’integratore è fabbricante dell’insieme.

Pensiamo a un system integrator che acquista un PLC, un gateway e un modulo di accesso remoto; sviluppa poi la logica di orchestrazione e collega il tutto a un backend. Le marcature dei singoli componenti sono utili, ma non raccontano cosa accade quando il gateway espone il PLC, l’accesso remoto attraversa il firewall e il backend invia comandi. Il prodotto finale nasce da quelle interazioni. Spetta all’integratore descriverne la destinazione d’uso e valutarne gli scenari di attacco.

Il CRA tiene conto di questa catena. L’allegato II impone al fabbricante di un componente destinato all’integrazione di fornire le informazioni necessarie perché chi costruisce il prodotto finale possa adempiere ai propri obblighi. È un passaggio importante: la conformità del componente diventa un’evidenza da usare, non un lasciapassare per l’insieme. L’integratore deve conoscere versioni, configurazioni sicure, dipendenze e condizioni di supporto.

Neppure la commessa unica offre un’esenzione generale. La messa a disposizione comprende la fornitura per distribuzione o uso nell’ambito di un’attività commerciale, anche gratuita. Un prodotto tailor-made venduto a un solo cliente resta dunque un prodotto immesso sul mercato. In alcuni rapporti B2B il CRA consente di modulare aspetti operativi, soprattutto per software su misura; la qualifica di chi ha progettato e fornito la soluzione, però, rimane.

White label: il marchio fa salire a bordo tutti gli obblighi

Nel white label il cambio di ruolo può avvenire in tipografia. Nessuno modifica il firmware, il prodotto esce dalla stessa linea e l’OEM continua a sviluppare ogni aggiornamento. Sulla scatola, però, compare un altro marchio. L’art. 3, n. 13, considera fabbricante anche chi fa progettare o fabbricare un prodotto e lo commercializza con il proprio nome; l’art. 21 applica la stessa regola a importatori e distributori.

La Blue Guide del 2022 chiarisce il principio per tutta la legislazione europea di prodotto. Chi presenta un bene come proprio assume la responsabilità della sua conformità, pur avendo affidato a terzi progettazione e produzione. Può riutilizzare test, certificati e documentazione preparati dall’OEM, a condizione che riguardino esattamente il prodotto commercializzato e siano sufficienti a sostenerne la conformità. Deve anche poterli comprendere. La firma sulla dichiarazione UE non è un gesto amministrativo.

Nella pratica, il rischio nasce quando il marchio dispone soltanto di un dossier commerciale. L’OEM conserva il threat model, la distinta delle dipendenze e i risultati dei test; il reseller riceve un PDF con la marcatura CE. Finché nulla accade, il modello sembra efficiente. Alla prima vulnerabilità attivamente sfruttata, il soggetto che dovrebbe notificare non sa quali versioni sono esposte e quello che conosce il prodotto non appare sul mercato come fabbricante.

Il co-branding richiede una lettura meno automatica. Un rivenditore può aggiungere la propria identificazione commerciale lasciando chiaro chi ha fabbricato il prodotto. Può quindi restare distributore. Se packaging, interfaccia, sito e documentazione inducono l’acquirente a considerare quel prodotto come appartenente al rivenditore, la conclusione cambia. Conviene osservare l’esperienza completa: chi firma la dichiarazione, chi promette il supporto, chi riceve le segnalazioni e chi decide il rilascio delle patch?

Un buon contratto OEM deve costruire il ponte che manca. Il titolare del marchio deve accedere al risk assessment, alla SBOM, ai test e alla cronologia delle versioni; deve essere avvertito quando cambiano componenti, fornitori o servizi remoti. Servono tempi stretti per condividere le notizie sulle vulnerabilità e un processo concordato per firmare e distribuire gli aggiornamenti. Vanno previsti anche la cessazione dell’OEM e il passaggio a un nuovo fornitore. Sono obblighi contrattuali molto concreti, perché rendono praticabile una responsabilità che il marchio ha già assunto per legge.

Quanto va rifatto della valutazione di conformità

Quando la modifica è sostanziale e il prodotto modificato viene reso disponibile, la guida lo tratta come un nuovo prodotto ai fini del CRA. Occorre aggiornare il risk assessment e la documentazione tecnica, applicare la procedura di valutazione pertinente, predisporre una nuova dichiarazione UE e apporre correttamente la marcatura CE. Se era intervenuto un organismo notificato, il cambiamento va gestito secondo il modulo applicabile e, quando incide sul tipo approvato o sul processo di vulnerability handling, portato alla sua attenzione.

Questo non obbliga a ripetere prove rimaste valide. La Commissione consente di riusare la documentazione e i risultati relativi alle parti che il cambiamento non ha toccato. Occorre però spiegare perché sono ancora affidabili. Se un nuovo modulo è isolato, le interfacce restano le stesse e il rischio dell’insieme non cresce, la nuova valutazione può concentrarsi sul perimetro modificato. Se il modulo riceve privilegi amministrativi o cambia i flussi di fiducia, il prodotto completo torna in discussione.

A mio avviso, questo è uno dei passaggi più utili della guida: evita una ricertificazione cieca e premia chi conosce davvero la propria architettura. La proporzionalità ha però un prezzo. Chi esclude una parte dalla nuova valutazione deve mostrare dove termina la modifica, quali dipendenze restano invariate e quali test sorreggono quella conclusione. Una mappa aggiornata vale più di una dichiarazione generica di assenza di impatti.

Va verificata anche la classificazione. L’art. 32 prevede per i prodotti ordinari, tra le opzioni, il controllo interno del modulo A. Per i prodotti importanti di classe I quella strada resta disponibile soltanto alle condizioni fissate dal regolamento, compresa l’applicazione completa degli strumenti che conferiscono presunzione di conformità; altrimenti serve un percorso con esame UE del tipo o garanzia qualità totale. La classe II richiede l’intervento di una terza parte o, dove prevista e applicabile, una certificazione europea adeguata. Il Regolamento di esecuzione (UE) 2025/2392 descrive in modo più preciso le categorie importanti e critiche.

Una nuova funzione può spostare il prodotto da una categoria all’altra. Se diventa la sua core functionality, cambia anche il percorso di conformità disponibile. Il fascicolo della modifica deve quindi contenere due risposte: il prodotto soddisfa ancora i requisiti essenziali? E continua ad appartenere alla stessa categoria? Sono domande collegate, ma non equivalenti.

Dopo la consegna: vulnerabilità, notifiche, reperibilità

Il fabbricante CRA non esaurisce il proprio lavoro con la marcatura CE. L’art. 13 e l’allegato I, parte II, gli chiedono di conoscere i componenti del prodotto, seguire le vulnerabilità, testare regolarmente la sicurezza e correggere senza ritardo ciò che emerge. Deve pubblicare una policy di coordinated vulnerability disclosure, offrire un canale per le segnalazioni e distribuire le security update in modo sicuro. La SBOM, almeno per le dipendenze di primo livello, alimenta questo processo; non lo sostituisce.

Dall’11 settembre 2026 entra poi in applicazione l’art. 14. Le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza del prodotto dovranno essere notificati tramite la piattaforma unica. Il primo avviso parte entro ventiquattro ore dalla conoscenza. Entro settantadue ore segue una notifica più completa; per la vulnerabilità attivamente sfruttata, il rapporto finale arriva entro quattordici giorni dalla disponibilità di una misura correttiva o mitigativa. Sono tempi incompatibili con una filiera che si parla soltanto durante le riunioni mensili.

La guida precisa due aspetti che meritano di essere tenuti distinti. Gli obblighi dell’art. 14 si applicano anche ai prodotti già immessi sul mercato prima della piena operatività del CRA. Le notifiche continuano inoltre a essere dovute quando il fabbricante viene a conoscenza dell’evento dopo la fine del periodo di supporto, mentre l’attività ordinaria di vulnerability handling si esaurisce con quel periodo. È una lettura della Commissione, non una modifica del testo normativo; le imprese farebbero comunque bene a progettare fin d’ora i flussi sulla base di essa.

Torniamo al white label. Alle 17:40 di venerdì l’OEM riceve la prova che una vulnerabilità viene sfruttata. Chi controlla quella casella? Chi stabilisce che l’evidenza è sufficiente? Chi comunica al titolare del marchio le versioni interessate e la mitigazione disponibile? Ventiquattro ore passano in fretta, soprattutto se OEM e reseller lavorano in fusi orari diversi. Servono una reperibilità reale e una matrice di responsabilità che assegni valutazione, decisione e invio.

La modifica eseguita da un terzo può inoltre creare ruoli paralleli. Il nuovo fabbricante risponde della parte sostanzialmente modificata; la responsabilità si estende all’intero prodotto quando l’effetto investe la sua cybersicurezza complessiva. Il fabbricante originario continua a seguire le versioni e le parti già immesse sul mercato. Senza una mappa condivisa, la stessa vulnerabilità può generare due notifiche incoerenti oppure nessuna. Il confine disegnato per la conformità serve quindi anche durante l’incidente.

Il periodo di supporto segue la vita reale del prodotto

I cinque anni del CRA vengono spesso letti come una durata standard. L’art. 13, par. 8, dice qualcosa di più esigente. Il supporto deve accompagnare il tempo durante il quale il prodotto è ragionevolmente destinato a essere utilizzato, tenendo conto delle aspettative degli utenti, della natura del bene, della sua destinazione d’uso e della disponibilità dell’ambiente operativo e dei componenti essenziali. Cinque anni sono il limite minimo di salvaguardia; un prodotto con vita attesa più breve può avere un periodo inferiore, se la scelta è giustificata.

Per un oggetto di consumo il calcolo può essere relativamente semplice. Per una macchina industriale destinata a lavorare quindici anni, fermarsi al quinto significa ignorare l’uso che il fabbricante stesso ha promesso. Il periodo deve seguire quella vita, salvo ragioni documentate. Qui marketing, procurement e product security devono parlarsi: la disponibilità di un componente critico o il contratto con l’OEM può diventare il vincolo che rende impossibile la promessa fatta al cliente.

Ogni versione software sostanzialmente modificata deve avere un periodo dichiarato secondo gli stessi criteri. Il contatore non riparte automaticamente. Se una release aggiunge nuove modalità a un robot aspirapolvere senza allungare la vita dell’hardware, il supporto della versione può coincidere con il tempo residuo del prodotto. Un retrofit che rinnova la piattaforma di calcolo di un PLC e ne prolunga sensibilmente l’impiego porta invece a riesaminare la durata. È il prodotto reale a dare la risposta.

Per il software evolutivo, l’art. 13, par. 10, consente di correggere le vulnerabilità soltanto nell’ultima versione sostanzialmente modificata se gli utenti delle versioni precedenti possono passarvi gratuitamente e senza costi aggiuntivi per adeguare hardware o ambiente software. La Commissione tratta come ordinari il tempo del personale, i test e le regolazioni di configurazione. L’acquisto obbligatorio di nuovo hardware o una sostituzione radicale dell’infrastruttura superano la soglia.

Il fabbricante deve indicare con chiarezza almeno mese e anno di fine supporto e, dove tecnicamente possibile, far sì che il prodotto avvisi l’utente. Gli aggiornamenti di sicurezza pubblicati durante il periodo devono restare disponibili per almeno dieci anni dalla pubblicazione, oppure più a lungo se il supporto residuo lo richiede. Nel white label queste promesse vanno costruite insieme all’OEM. Un marchio che annuncia dieci anni di vita contando su un contratto tecnico di cinque ha già creato il proprio problema di conformità.

La decisione che serve prima del rilascio

Una procedura sulla modifica sostanziale non deve diventare un altro questionario da archiviare. Deve costringere l’impresa a fissare una baseline leggibile: versione, architettura, destinazione d’uso, core functionality, componenti, scenari d’attacco, misure applicate e periodo di supporto. Ogni change request viene confrontata con quella fotografia. Dove appaiono una nuova interfaccia, un privilegio ulteriore o una dipendenza esterna, si apre l’analisi.

La decisione richiede competenze diverse. Engineering conosce il codice; product security legge gli scenari; quality e compliance verificano la procedura. Legal entra quando cambia il ruolo o il contratto, marketing quando si allarga la destinazione d’uso, procurement quando la modifica dipende da un fornitore. Non occorre convocare ogni funzione per ogni patch. Occorre sapere chi deve essere coinvolto quando una risposta al test della Commissione diventa positiva.

Il verbale finale può essere breve. Deve indicare la parte interessata, l’effetto sul rischio dell’insieme, il soggetto che rende disponibile il prodotto, la procedura di conformità scelta e l’impatto sul supporto. Se la conclusione è che la patch resta ordinaria, lo si scrive e si collega la decisione ai test. Anche le risposte negative hanno valore, purché possano essere rilette da un team diverso due anni dopo.

Per la filiera servono clausole coerenti con questa procedura: notifica preventiva dei change, accesso alle evidenze, tracciabilità delle versioni e tempi compatibili con l’art. 14. Una matrice può distribuire le attività. Non può spostare con una cella il ruolo che il CRA attribuisce al soggetto presente sul mercato.

Il punto decisivo arriva prima del rilascio e prima del rebranding. È allora che un’impresa può ancora scegliere il perimetro del prodotto, chiedere all’OEM le informazioni mancanti, coinvolgere un organismo notificato o rivedere la promessa di supporto. Dopo un incidente, quelle scelte diventano spiegazioni da fornire all’autorità. Le sanzioni per la violazione dei requisiti essenziali e degli artt. 13 e 14 possono raggiungere 15 milioni di euro o il 2,5 per cento del fatturato mondiale annuo. Scoprire troppo tardi di essere il fabbricante è un modo costoso di leggere il CRA.

Riferimenti normativi e istituzionali essenziali

Regolamento (UE) 2024/2847 (Cyber Resilience Act), in particolare artt. 3, 13, 14, 21, 22, 28-32, 64, 69 e 71; allegati I, II, VII e VIII.

Commissione europea, C(2026) 5252, Guida sull’applicazione del Cyber Resilience Act, 27 luglio 2026, sezioni 4 e 5 e relativi esempi applicativi.

Commissione europea, Blue Guide on the implementation of EU product rules 2022, Comunicazione 2022/C 247/01, in particolare sezioni 2.1 e 3.1.

Regolamento di esecuzione (UE) 2025/2392, descrizioni tecniche delle categorie di prodotti con elementi digitali importanti e critici.