Alle otte DPP-standarder er offentliggjort. Kun seks er citeret.
I maj 2026 offentliggjorde CEN/CENELEC JTC 24 seks af de otte harmoniserede standarder for digitale produktpas. Vi skrev om dem dengang og bemærkede, at to stadig manglede.
De mangler ikke længere. EN 18239 og EN 18246 blev godkendt af CEN den 17. august 2026 og vedtaget som SS-EN den 16. september. Sættet er komplet.
Det er den del, alle vil skrive om. Den del, der betyder mere, er, at et komplet sæt ikke har gjort alle otte ligeværdige, og forskellen er ikke en formalitet.
Seks er citeret, to er ikke
Kommissionens gennemførelsesafgørelse (EU) 2026/1736 offentliggør henvisninger til seks standarder i EU-Tidende — de er citeret:
| Standard | Dækker |
|---|---|
| EN 18216 | Protokoller for dataudveksling |
| EN 18219 | Entydige identifikatorer |
| EN 18220 | Databærere |
| EN 18221 | Datalagring, arkivering og datavarighed |
| EN 18222 | API’er til styring af passets livscyklus og søgbarhed |
| EN 18223 | Interoperabilitet mellem systemer |
EN 18239 (forvaltning af adgangsrettigheder, informationssystemsikkerhed og forretningsmæssig fortrolighed) og EN 18246 (dataægthed, pålidelighed og integritet) er ikke på den liste.
Det er citeringen i EU-Tidende, der giver en harmoniseret standard retsvirkning. En citeret harmoniseret standard giver formodning om overensstemmelse (ESPR artikel 41): Følger du den, formodes du at opfylde det tilsvarende lovkrav, medmindre nogen beviser det modsatte. En standard, der ikke er citeret, giver ingen sådan formodning, uanset hvor nyligt den er offentliggjort, og uanset hvor god den er.
De to nyeste standarder står derfor i en særlig position. De er virkelige, de kan købes, og de udtrykker den gennemtænkte holdning i det udvalg, der skrev de andre seks — men at følge dem er et valg og ikke et forsvar. Du kan ikke pege på EN 18246 og sige, at du formodes at overholde reglerne. Det kan ingen andre heller, og det er værd at vide, når en konkurrent hævder harmoniseret overensstemmelse med »alle otte«.
Begge vil højst sandsynligt blive citeret i en senere ændring af gennemførelsesafgørelsen. Indtil da er den ærlige formulering »vi følger den«, ikke »vi er i overensstemmelse med den«.
Nu vi alligevel retter: Der findes ingen EN 18217
Serien skrives som EN 18216–18223 næsten overalt, også af folk, der burde vide bedre. Det er ikke et sammenhængende interval.
Der findes ingen EN 18217 og ingen EN 18218. De otte er 18216, 18219, 18220, 18221, 18222, 18223, 18239 og 18246. Skriver man intervallet som 18216–18223, opfinder man både to standarder, der ikke findes, og udelader de to, der blev offentliggjort senest.
Hvis du henviser til dem i en specifikation, et tilbud på et udbud eller et leverandørspørgeskema, så angiv dem med nummer og afsnit. Et interval er forkert i begge retninger.
Hvad der faktisk kan tjekkes udefra
Vores validator følger det offentliggjorte sæt. Den kører ti tjek fordelt på syv af de otte standarder mod en hvilken som helst pas-URL, uden medvirken fra udgiveren og uden konto.
| Standard | Afsnit | Hvad der tjekkes |
|---|---|---|
| EN 18216 | §5 | Maskinlæsbar JSON returneres via HTTP content negotiation |
| EN 18219 | §5.1 | Identifikatoren følger en af de fem tilladte ID-ordninger for produkter |
| EN 18219 | §5.2 | ?linkType=all returnerer et GS1-linkset, så linkene kan findes |
| EN 18220 | §5.2 | Databærerens mål fører til et pas, ikke til en fejl |
| EN 18221 | §4.5 | En backupvært er angivet |
| EN 18222 | §4.1 | De tre obligatoriske metoder i Life Cycle API’et svarer |
| EN 18223 | §4.1.2.1 | Passets header-attributter — detaljeringsniveau, skemaversion, seneste opdatering, ID for den erhvervsdrivende |
| EN 18246 | §4.3 | Offentlige pasdata leveres uden autentificering |
| EN 18246 | §5.4.2 | Kan læses på enhver forbrugerenhed uden ekstra software |
| EN 18246 | §5.1.2 / §5.1.5 | Ingen tredjepartssporing af dem, der læser offentlige data |
Syv, ikke otte. EN 18239 handler om adgangskontrol, sikkerhed og fortrolighed, og næsten intet i den kan besvares af en fremmed, der sender én forespørgsel. Vi implementerer den — adgang på rækkeniveau pr. tenant, kortlivede tokens i stedet for delte nøgler, hastighedsbegrænsning i resolveren skrevet efter §5.2 punkt 11 — men at implementere en standard og at teste den udefra er to forskellige ting, og et tjek, der ikke kan fejle, er ikke et tjek.
Den samme tilbageholdenhed gælder inden for EN 18246. Dens tungeste krav handler om at bevise, at et pas og dets databærer er ægte, og det kræver kryptografisk signering. Intet signerer noget endnu — hverken vores eller nogen andens — og et tjek, som intet pas på jorden kan bestå, lærer læseren ingenting. Tre af dens afsnit kan besvares udefra. Det er de tre, vi kører.
Det tjek, de fleste pas vil dumpe
Af de tre vil ét overraske folk.
EN 18246 §5.1.2 forbyder indsamling af personoplysninger fra fysiske personer, der læser offentlige pasdata. §5.1.5 kræver, at profilering forhindres. Læst sammen beskriver de præcis, hvad et analysetag gør: sætter en identifikator på en læser, følger vedkommende på tværs af sider og sender den til en tredjepart.
Et digitalt produktpas, der indlæser Google Analytics, Meta Pixel, Hotjar, Clarity eller Segment, indsamler personoplysninger fra en person, hvis eneste handling var at scanne en QR-kode på en sweater. Validatoren leder efter trackerens vært i den side, en forbruger faktisk modtager, ikke efter et scriptfilnavn, fordi hver af dem leveres under en halv snes forskellige navne.
Dette tjek er ubehageligt at lancere, så det er værd at være ligefrem om vores egen position: Vores resolver indsætter et GA4-tag, når en tenant angiver et measurement ID. Funktionen findes, og enhver tenant, der angiver et, vil dumpe dette tjek i vores egen validator, på vores egne sider. Det er den eneste slags tjek, der er værd at skrive. Et, der fritager forfatteren, er markedsføring.
Hvis du kører analyse på dine passider, er spørgsmålet til din juridiske afdeling ikke, om sporingen er samtykket — det er, om §5.1.2 overhovedet tillader den på den offentlige halvdel af et pas.
Begrænsningen i EN 18239, der gør det svært
EN 18239 §5.2 punkt 11 kræver, at adgangen til DPP-tjenester »skal begrænses på en sådan måde, at angreb eller uautoriseret massescraping af data forhindres«.
De oplagte implementeringer er alle udelukket af andre afsnit i det samme par standarder:
- En API-nøgle eller et login? EN 18246 §4.3 siger, at offentlige data skal leveres uden autentificering. EN 18239 §5.2(2) siger det samme og nævner, at forskelsbehandling på grundlag af geografisk placering skal undgås, som begrundelsen.
- Blokere efter land? EN 18239 §5.2(3) siger, at adgang ikke må nægtes alene på grundlag af aktørens placering eller jurisdiktion.
- En CAPTCHA-mur? Samme problem, og den dumper §5.4.2 om læsbarhed på enhver forbrugerenhed.
- Logge IP-adresser for at finde misbrugere? En IP-adresse er en personoplysning, og §5.1.2 forbyder indsamling af personoplysninger fra dem, der læser offentlige data.
- Blokere bots? EN 18246 §5.1.8 siger, at robuste mekanismer mod scraping bør implementeres, og i samme åndedrag, at systemet kan tillade nyttige søgemaskiner at indeksere DPP-data. En begrænser, der blokerer Googlebot, er ikke mere sikker, den er forkert.
Det, der er tilbage, er snævert: begræns ud fra en saltet hash af adressen, som holdes i hukommelsen i ét vindues længde og aldrig skrives nogen steder. Det, der overlever minuttet, er et antal, og et antal handler ikke om en person.
Det er en reel teknisk begrænsning, og den er af den slags, der først bliver synlig, når standarderne læses sammen i stedet for én ad gangen.
Hvad du skal gøre med det
- Hold op med at skrive intervallet. EN 18216–18223 opfinder to standarder og udelader to. Henvis med nummer og afsnit.
- Skeln mellem »offentliggjort« og »citeret« i dine egne påstande. Seks giver formodning om overensstemmelse. To gør ikke, endnu. Den, der hævder harmoniseret overensstemmelse med alle otte, hævder noget, der ikke findes i dag.
- Se på, hvad dine passider indlæser. Hvis der er et analysetag på den offentlige halvdel, er EN 18246 §5.1.2 en samtale, du skal tage, før en anden starter den.
- Køb standarderne. De fås hos SIS og en-standard.eu. Seks af dem afgør, om din implementering formodes at overholde kravene, og ingen af de resuméer, der er i omløb — heller ikke dette — kan erstatte teksten.
Du kan køre tjekkene ovenfor mod en hvilken som helst pas-URL på dppagent.com/validate, også pas, der ikke er vores. Den rapporterer pr. standard og pr. afsnit og angiver, hvilke fund der er delvise, og hvorfor.
Kilder
Primære kilder brugt i denne artikel:
- Kommissionens gennemførelsesafgørelse (EU) 2026/1736 — offentliggørelse af henvisninger til harmoniserede standarder for digitale produktpas i EU-Tidende
- EN 18216 (protokoller for dataudveksling), EN 18219 (entydige identifikatorer), EN 18220 (databærere), EN 18221 (datalagring, arkivering og datavarighed), EN 18222 (API’er til styring af passets livscyklus og søgbarhed), EN 18223 (interoperabilitet mellem systemer) — CEN/CENELEC JTC 24, offentliggjort i maj 2026
- EN 18239 (forvaltning af adgangsrettigheder, informationssystemsikkerhed og forretningsmæssig fortrolighed) og EN 18246 (dataægthed, pålidelighed og integritet) — godkendt af CEN den 17. august 2026, vedtaget som SS-EN den 16. september 2026
- Forordning (EU) 2024/1781 (ESPR), artikel 4, 9 og 10 — EUR-Lex
Henvisningerne til afsnit i denne artikel gælder de licenserede SS-EN 2026-udgaver. Standarder er ophavsretligt beskyttede dokumenter og kan ikke gengives her; afsnitsnumrene er angivet, så teksten kan holdes op mod originalerne.