In sintesi
- Le norme armonizzate sono state pubblicate nella Gazzetta ufficiale dell’Unione europea il 15 luglio 2026.
- 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.
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? |
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.
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
- 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 24 luglio 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.