In sintesi
- Sei riferimenti armonizzati sono stati pubblicati nella Gazzetta ufficiale dell’Unione europea il 15 luglio 2026; altri due standard tecnici sono stati pubblicati a settembre.
- Coprono sei aree: protocolli di scambio, identificativi univoci, data carrier, conservazione, API e interoperabilità.
- La conformità alle parti applicabili può sostenere la presunzione di conformità ai requisiti ESPR coperti dalle norme.
- Gli standard non definiscono da soli i dati obbligatori per ogni prodotto: tali dati dipendono dalla legislazione specifica di categoria.
- Per le imprese diventano criteri pratici per valutare piattaforme, integrazioni, QR/NFC e continuità del servizio.
Il Digital Product Passport è un sistema distribuito: collega il prodotto fisico, un identificativo stabile, un data carrier, dati provenienti da più organizzazioni e livelli di accesso differenti. Senza regole comuni, ogni progetto rischierebbe di diventare un portale isolato. Gli standard armonizzati definiscono il linguaggio tecnico di base con cui queste componenti devono comunicare.
Stato verificato al 30 ottobre 2026
L’elenco della Commissione consultato riporta la Decisione (UE) 2026/1736 con sei riferimenti. UNI conferma la pubblicazione tecnica di EN 18239 ed EN 18246 il 16 settembre. La timeline UE indica novembre 2026 per la decisione sui due riferimenti rimanenti: è una previsione, da distinguere dalla pubblicazione dell’atto nella GUUE.
Consulta la timeline DPP della Commissione · Leggi gli ambiti di EN 18239 ed EN 18246
Cosa ha pubblicato la Commissione europea
La Decisione di esecuzione (UE) 2026/1736 del 14 luglio 2026 pubblica i riferimenti di sei standard elaborati da CEN, CENELEC ed ETSI a supporto degli articoli 10 e 11 dell’ESPR. La Decisione è entrata in vigore con la pubblicazione nella Gazzetta ufficiale il 15 luglio 2026.
Il principio importante è la presunzione di conformità: quando un DPP è conforme alle norme armonizzate o alle parti applicabili, può essere considerato conforme ai requisiti ESPR coperti da quelle norme. L’analisi deve comunque essere svolta rispetto al prodotto, alle funzioni implementate e all’atto applicabile.
Le sei aree tecniche
| Riferimento | Ambito | Domanda aziendale |
|---|---|---|
| EN 18216:2026 | Protocolli di scambio dei dati | Come vengono trasferite le informazioni tra sistemi e organizzazioni? |
| EN 18219:2026 | Identificativi univoci | Come si collegano senza ambiguità prodotto, operatore, struttura e passaporto? |
| EN 18220:2026 | Data carrier | Come deve funzionare il collegamento fisico o digitale, per esempio tramite QR o NFC? |
| EN 18221:2026 | Conservazione, archiviazione e persistenza | Come si mantiene il DPP disponibile e verificabile nel tempo? |
| EN 18222:2026 | API per lifecycle e ricercabilità | Come si crea, aggiorna, interroga e gestisce il passaporto tramite interfacce documentate? |
| EN 18223:2026 | Interoperabilità dei sistemi | Come si evita che dati e processi restino bloccati in una singola piattaforma? |
EN 18239 ed EN 18246: accessi e integrità dei dati
Le due norme completano gli ambiti tecnici del programma DPP. UNI ne segnala la pubblicazione da parte di CEN e CENELEC il 16 settembre 2026.
| Riferimento | Ambito | Verifica nel progetto |
|---|---|---|
| EN 18239:2026 | Gestione dei diritti di accesso, sicurezza dei sistemi e riservatezza aziendale | Definire chi può leggere, modificare e condividere le informazioni. |
| EN 18246:2026 | Autenticazione, affidabilità e integrità dei dati | Documentare provenienza, controlli e rilevazione delle modifiche. |
Quando una norma sostiene la presunzione di conformità?
La disponibilità di una norma tecnica e la citazione del suo riferimento nella GUUE sono passaggi distinti. La presunzione riguarda i requisiti coperti dai riferimenti armonizzati applicabili; il progetto deve verificare versione, parti pertinenti e legislazione di prodotto.
Fonte UNI: pubblicazione delle due nuove norme DPP.
Cosa non definiscono gli standard
Gli standard orizzontali disciplinano il funzionamento dell’infrastruttura DPP. Non sostituiscono gli atti che stabiliscono, per una specifica categoria, quali informazioni devono essere presenti, la granularità richiesta, i soggetti autorizzati ad accedere e la data di applicazione.
Standard tecnico e obbligo di prodotto sono due livelli diversi
Una piattaforma può essere progettata secondo gli standard europei, ma l’obbligo concreto e il dataset del passaporto devono essere verificati sulla legislazione applicabile alla categoria. Anche l’operatività del Registro europeo non rende il DPP automaticamente obbligatorio per tutti i prodotti.
Come usarli per valutare un software DPP
- Identità esportabili: il fornitore deve spiegare come vengono creati, risolti e mantenuti gli identificativi.
- Data carrier sostituibile: il QR o l’NFC non deve incorporare logiche che impediscono la migrazione o l’aggiornamento controllato.
- API documentate: creazione, lettura, ricerca, aggiornamento e revoca devono poter essere governati a volume.
- Versioni e audit: deve essere possibile ricostruire quale dato era pubblicato, da chi e in quale momento.
- Continuità: vanno definite disponibilità, backup, esportazione, archiviazione e piano di uscita dal servizio.
- Accessi separati: pubblico, partner, autorità e soggetti autorizzati devono vedere soltanto i dati previsti.
Dal requisito alla prova: come valutare un software DPP
Porta al confronto un prodotto campione, un documento del fornitore e i ruoli coinvolti. Usa queste tre prove per definire il perimetro del software DPP NexusDpp e i risultati da accettare nel pilota.
1. Identificativo e QR code
Scansiona il supporto e confronta identificativo, modello e versione approvata. Conserva l’esito e verifica cosa accade se un dato viene aggiornato.
2. Accessi e storico
Confronta la vista pubblica con quella di un utente autorizzato. Prova la revoca di un permesso e controlla la registrazione di autore, data e modifica.
3. Esportazione e continuità
Richiedi un esempio di esportazione documentata e una prova di recupero dei dati. Definisci responsabilità, tempi e condizioni di migrazione nel perimetro concordato.
Per le batterie, collega queste prove alla mappa dei dati del Battery Passport e alla gestione dei diritti di accesso. Le prove proposte aiutano a preparare il progetto; non costituiscono una certificazione delle norme.
Impatto sull’architettura aziendale
Gli standard favoriscono un’architettura a componenti: ERP, PLM, MES, WMS, portali fornitori e repository documentali restano fonti, mentre il servizio DPP governa identità, validazioni, versioni, pubblicazione e accesso. L’obiettivo non è duplicare ogni dato, ma sapere da dove proviene, chi lo approva e come viene reso disponibile.
Per questo un progetto pilota deve provare non solo la pagina pubblica, ma anche esportazione, aggiornamento, errori, indisponibilità di una fonte, sostituzione di un documento e gestione di una variante o di un lotto.
Come NexusDpp applica questi criteri
NexusDpp collega identificativi, workflow, documenti, versioni, data carrier e integrazioni in un unico modello governato. La configurazione viene adattata alla granularità richiesta e ai sistemi esistenti; l’adozione delle componenti standard viene verificata in base alla legislazione e al perimetro effettivo del progetto.
Fonti ufficiali
- Commissione europea — elenco dei riferimenti DPPElenco verificato il 30 ottobre 2026.
- UNI — EN 18239 ed EN 18246Annuncio del 24 settembre 2026.
- Decisione di esecuzione (UE) 2026/1736Riferimenti delle sei norme armonizzate per i Digital Product Passport.
- Regolamento (UE) 2024/1781 — ESPRRequisiti del sistema DPP, interoperabilità e presunzione di conformità.
- Commissione europea — DPP Registry now liveCollegamento tra Registro, API e standard armonizzati.
Nota editoriale: contenuto aggiornato al 30 ottobre 2026. L’applicazione di una norma tecnica e la valutazione di conformità richiedono l’esame della versione ufficiale, del perimetro coperto e della legislazione di prodotto.