EN 18216: protokoll och dataformat för digitala produktpass

EN 18216 är den europeiska standarden för hur data i ett digitalt produktpass skickas mellan system: vilka protokoll som används, vilka dataformat som ska stödjas och hur samma pass kan läsas både av en människa och av ett program. Den berör alla som bygger eller driver passsystem, alltså tillverkare, varumärken och deras leverantörer av passtjänster, och alla som vill läsa pass automatiskt, till exempel återvinnare, marknadsplatser och myndigheter.

Standarden är en av sex harmoniserade standarder för produktpass som CEN godkände den 3 maj 2026; SIS fastställde den svenska utgåvan den 27 maj 2026. Kommissionen publicerade referenserna i Europeiska unionens officiella tidning den 15 juli 2026. Den som följer standarden presumeras därmed uppfylla motsvarande krav i ekodesignförordningen (ESPR). Den här artikeln förklarar vad standarden omfattar, vad den betyder i praktiken och hur den hänger ihop med de andra standarderna i serien. En samlad bild finns i översikten över DPP-standarderna.

Vad standarden omfattar

Den fullständiga beteckningen är EN 18216:2026 Digital product passport – Data exchange protocols. Den har tagits fram av den gemensamma tekniska kommittén CEN-CLC/JTC 24 på uppdrag av kommissionens standardiseringsbegäran M/604 (genomförandebeslut C(2024) 5423 av den 31 juli 2024, i ändrad lydelse M/604 Amd 1). Den svenska utgåvan SS-EN 18216:2026 är på 19 sidor.

Enligt standardens egen omfattningsbeskrivning, som SIS publicerar, definierar den protokoll och dataformat för säkert och effektivt datautbyte. Protokollen är de regler och procedurer som system följer när de kommunicerar. Dataformaten bestämmer hur informationen är uppbyggd så att mottagaren kan förstå och bearbeta den. Tillsammans ska de göra att data är läsbara för både människor och maskiner, strukturerade, sökbara och överförbara genom ett öppet, interoperabelt nätverk utan inlåsning till en leverantör. Det är nästan ordagrant samma krav som ESPR ställer i artikel 10.1 d.

Omfattningsbeskrivningen räknar upp fem områden:

• Säker kommunikation: protokoll som skyddar data mot obehörig åtkomst och ser till att bara behöriga parter når skyddad information.
• Interoperabilitet: protokoll och format som går att koppla till befintliga system och fungerar mellan sektorer.
• Enkel användning: lösningar som är lätta att införa, särskilt på mobila enheter.
• Dataintegritet: informationen ska hålla genom hela värdekedjan, ända till produktens livsslut.
• Dokumentation och upptäckbarhet: protokollen och formaten ska vara tillgängliga även för den som saknar specialkunskap.

Standarden bygger medvetet på protokoll och format som redan används i annan EU-lagstiftning, för att hålla nere kostnaderna för företagen. På CEN och CENELEC:s webbinarium den 25 juni 2026 beskrevs EN 18216 som spridda och säkra protokoll, ändpunkter och format, som tillåter frivilliga tillägg och är oberoende av system och leverantör.

Vad den kräver i praktiken

Standardtexten är upphovsrättsskyddad och säljs via de nationella standardiseringsorganen, i Sverige SIS. Detaljerna nedan kommer från den licensierade SS-EN-utgåvan så som vi läste den när vi byggde DPP Agents validator. Jämför alltid med ert eget exemplar innan ni bygger efter dem.

Transport

Klausul 4 handlar om transportlagret. Passdata ska skickas över HTTPS. Lägsta tillåtna version är TLS 1.2, och TLS 1.3 eller senare rekommenderas starkt. TLS 1.0, TLS 1.1 och alla SSL-versioner är förbjudna. På HTTP-nivå är HTTP/2 lägsta nivå, äldre versioner får inte användas, och HTTP/3 rekommenderas. API:er bör följa REST-stil, men det är en rekommendation och inget krav.

För de flesta är detta en fråga om driftmiljön snarare än om koden. Moderna molnplattformar och CDN:er erbjuder TLS 1.3 och HTTP/2 som standard. Den som driver egna servrar behöver kontrollera konfigurationen och stänga av gamla protokollversioner.

Dataformat

Klausul 5 gör JSON enligt ISO/IEC 21778 till den gemensamma grunden som alltid ska stödjas. XML och JSON-LD får erbjudas utöver det, och passet ska dessutom kunna återges som HTML. Båda väljs med innehållsförhandling. Valet av JSON som minsta gemensamma nämnare betyder att ett program som kan läsa JSON alltid kan läsa ett pass, oavsett vem som har publicerat det.

Innehållsförhandling

Vilket format som skickas avgörs med HTTP-innehållsförhandling enligt RFC 9110, alltså med Accept-huvudet i anropet. Samma adress kan då svara på två sätt. En mobiltelefon som läser QR-koden får en webbsida. Ett program som skickar Accept: application/json till samma adress får passets data som JSON.

En mobil läser QR-koden

En passadresssamma som i QR-koden

WebbsidaHTML, tillgänglig enligt EN 301 549

Ett program skickar Accept: application/json

Passets data som JSONska alltid stödjas (avsnitt 5)

Det här är det krav som många tidiga pass missar. Ett pass som bara går att läsa som webbsida kan se fullständigt ut för en konsument, men en återvinnare eller en myndighet som vill läsa tusentals pass automatiskt får ingenting att arbeta med.

Tillgänglig HTML

När passet skickas som HTML ska sidan följa W3C:s standarder och den europeiska tillgänglighetsstandarden EN 301 549. Ett pass är alltså också en tillgänglighetsfråga: rubrikstruktur, kontraster, alternativtexter och språkangivelse spelar roll.

En kontrollista

1. Svarar passadressen över HTTPS med TLS 1.2 eller senare, och är äldre versioner avstängda?
2. Stöder servern HTTP/2?
3. Ger samma adress JSON när anropet skickar Accept: application/json?
4. Talar svaret om att innehållet beror på Accept (huvudet Vary: Accept), så att cachar inte blandar ihop HTML och JSON?
5. Är HTML-versionen granskad mot EN 301 549?

Punkt 4 är god HTTP-praxis enligt RFC 9110 snarare än något vi har läst som ett krav i EN 18216, men utan den kan en cache skicka webbsidan till ett program som bad om JSON.

Hur EN 18216 hänger ihop med de andra standarderna och lagen

ESPR säger i artikel 10.1 d att all data i passet ska bygga på öppna standarder, ha ett interoperabelt format och, där det är lämpligt, vara maskinläsbar, strukturerad, sökbar och överförbar genom ett öppet interoperabelt nätverk för datautbyte utan leverantörsinlåsning. Artikel 11 a kräver att passet är fullt interoperabelt med andra produktpass i fråga om tekniska, semantiska och organisatoriska aspekter av kommunikation och dataöverföring.

Genomförandebeslut (EU) 2026/1736 av den 14 juli 2026 konstaterar att de sex standarderna uppfyller kraven i artiklarna 10 och 11, och beslutet trädde i kraft när det publicerades den 15 juli 2026. Enligt ESPR artikel 41.2 presumeras ett pass som följer en sådan standard uppfylla kraven i artiklarna 10 och 11, i den utsträckning standarden täcker dem. För EN 18216 anger bilaga ZA vilka krav det gäller: artikel 10.1 d, artikel 11 a (bara protokoll och dataformat) och artikel 11 h.

Inom serien är EN 18216 grunden som de andra står på. CEN och CENELEC beskrev den på webbinariet som en förutsättning för datautbyte och processer över internet. Arbetsfördelningen ser ut så här:

• EN 18219 bestämmer identifieraren, alltså den adress som anropet går till.
• EN 18220 bestämmer databäraren, till exempel QR-koden som bär adressen.
• EN 18222 bestämmer vilka API-anrop som finns. De går över de protokoll som EN 18216 anger.
• EN 18223 bestämmer vad datan betyder: datamodell, semantik och serialisering.
• EN 18221 bestämmer hur passet lagras, arkiveras och överlever via en backup.

Säkerheten kring datautbytet har fått två egna standarder, EN 18239 om åtkomsträttigheter och EN 18246 om dataautentisering. CEN godkände dem den 17 augusti 2026 och SIS fastställde dem den 16 september 2026, men de är inte citerade i EUT och ger därför ingen presumtion om överensstämmelse.

För batterier ställer batteriförordningen (EU) 2023/1542 snarlika krav. Artikel 77.5 säger att informationen i batteripasset ska bygga på öppna standarder, ha ett interoperabelt format och vara överförbar utan leverantörsinlåsning, maskinläsbar, strukturerad och sökbar. Artikel 78 a kräver att batteripasset är fullt interoperabelt med de produktpass som krävs enligt ekodesignlagstiftningen. Standardiseringsbegäran omfattade även batterier, men beslut 2026/1736 publicerar referenserna till stöd för ESPR. Det ger alltså ingen presumtion enligt batteriförordningen.

Vanliga missförstånd

"En snygg webbsida räcker"

Nej. JSON är den gemensamma grunden som alltid ska stödjas. Webbsidan krävs också, men den ersätter inte JSON.

"JSON-LD är obligatoriskt"

Inte enligt EN 18216 som vi läser den. JSON-LD är ett av de format som får erbjudas utöver JSON. Det kan vara klokt att erbjuda, eftersom länkade data gör betydelsen tydligare, men kravet är JSON.

"En nedladdningslänk till en JSON-fil är samma sak"

Standarden anvisar innehållsförhandling på anropet som mekanism. En separat fil under en annan adress gör att ett program först måste veta var filen finns, vilket är just det problem som innehållsförhandlingen löser.

"Harmoniserad betyder obligatorisk"

Harmoniserade standarder är frivilliga att använda, vilket CEN och CENELEC också skriver. Fördelen med att följa dem är presumtionen om överensstämmelse. Den som väljer en annan lösning måste själv visa att kraven i ESPR är uppfyllda.

"EN 18216 bestämmer vad som ska stå i passet"

Nej. Standarderna är enligt CEN och CENELEC tvärgående och produktneutrala. Vilken data ett pass ska innehålla bestäms i de delegerade akterna för varje produktgrupp, enligt ESPR artikel 9.2 a och bilaga III.

Så ser det ut i praktiken

I DPP Agent, som Blippa utvecklar, svarar varje passadress både som webbsida och som JSON eller JSON-LD beroende på Accept-huvudet, och svaren märks med Vary: Accept. Samma adress som står i QR-koden används alltså av konsumenten och av maskinen. Validatorn på dppagent.com gör samma kontroll mot vilket pass som helst: den ber om JSON med Accept: application/json och redovisar resultatet mot EN 18216 klausul 5.