Alle åtte DPP-standardene er publisert. Bare seks er sitert.

I mai 2026 publiserte CEN/CENELEC JTC 24 seks av de åtte harmoniserte standardene for digitale produktpass. Vi skrev om dem da, og påpekte at to fortsatt manglet.

De mangler ikke lenger. EN 18239 og EN 18246 ble godkjent av CEN 17. august 2026 og vedtatt som SS-EN 16. september. Settet er komplett.

Det er den delen alle kommer til å skrive om. Det som betyr mer, er at et komplett sett ikke har gjort alle åtte likeverdige, og forskjellen er ikke en formalitet.

Seks er sitert, to er ikke

Kommisjonens gjennomføringsbeslutning (EU) 2026/1736 siterer seks standarder i EU-tidende:

Standard Dekker
EN 18216 Protokoller for datautveksling
EN 18219 Unike identifikatorer
EN 18220 Databærere
EN 18221 Datalagring, arkivering og varighet for data
EN 18222 API-er for forvaltning av passets livssyklus og søkbarhet
EN 18223 Systeminteroperabilitet

EN 18239 (forvaltning av tilgangsrettigheter, informasjonssystemsikkerhet og forretningsmessig konfidensialitet) og EN 18246 (autentisitet, pålitelighet og integritet for data) står ikke på den listen.

Det er siteringen i EU-tidende som gir en harmonisert standard rettsvirkning. En sitert harmonisert standard gir formodning om samsvar (ESPR artikkel 41): følger du den, formodes du å oppfylle det tilsvarende rettslige kravet, med mindre noen beviser noe annet. En standard som ikke er sitert, gir ingen slik formodning, uansett hvor nylig den ble publisert og hvor god den er.

De to nyeste standardene har altså en underlig stilling. De er ekte, de kan kjøpes, de gir uttrykk for det gjennomtenkte synet til komiteen som skrev de andre seks — og å følge dem er et valg, ikke et forsvar. Du kan ikke peke på EN 18246 og si at du formodes å oppfylle kravene. Det kan heller ingen andre, noe som er verdt å vite når en konkurrent hevder harmonisert samsvar med «alle åtte».

Begge vil mest sannsynlig bli sitert i en senere endring av gjennomføringsbeslutningen. Inntil da er den ærlige formuleringen «vi følger den», ikke «vi er i samsvar med den».

Mens vi likevel retter opp: det finnes ingen EN 18217

Serien skrives som EN 18216–18223 nesten overalt, også av folk som burde vite bedre. Det er ikke et sammenhengende nummerområde.

Det finnes ingen EN 18217 og ingen EN 18218. De åtte er 18216, 18219, 18220, 18221, 18222, 18223, 18239 og 18246. Å skrive området som 18216–18223 både dikter opp to standarder som ikke finnes, og utelater de to som ble publisert sist.

Hvis du viser til disse i en spesifikasjon, et anbudssvar eller et leverandørspørreskjema, så vis til dem med nummer og punkt. Et nummerområde er feil i begge retninger.

Hva som faktisk kan kontrolleres utenfra

Validatoren vår følger det publiserte settet. Den kjører ti kontroller fordelt på sju av de åtte standardene, mot en hvilken som helst pass-URL, uten medvirkning fra utgiveren og uten konto.

Standard Punkt Hva som kontrolleres
EN 18216 §5 Maskinlesbar JSON returneres via HTTP-innholdsforhandling
EN 18219 §5.1 Identifikatoren følger en av de fem tillatte ID-ordningene for produkter
EN 18219 §5.2 ?linkType=all returnerer et GS1-linkset for oppdagelse av lenker
EN 18220 §5.2 Bærerens mål fører til et pass, ikke en feil
EN 18221 §4.5 En vert for sikkerhetskopi er oppgitt
EN 18222 §4.1 De tre obligatoriske metodene i Life Cycle API svarer
EN 18223 §4.1.2.1 Attributter i passheaderen — detaljnivå, skjemaversjon, sist oppdatert, markedsdeltakerens ID
EN 18246 §4.3 Offentlige passdata leveres uten autentisering
EN 18246 §5.4.2 Lesbart på alle forbrukerenheter, uten ekstra programvare
EN 18246 §5.1.2 / §5.1.5 Ingen sporing fra tredjeparter av dem som leser offentlige data

Sju, ikke åtte. EN 18239 handler om tilgangskontroll, sikkerhet og konfidensialitet, og nesten ingenting i den kan besvares av en utenforstående som sender én forespørsel. Vi implementerer den — tilgang på radnivå per leietaker, kortlivede tokener i stedet for delte nøkler, hastighetsbegrensning i resolveren skrevet etter §5.2 nr. 11 — men å implementere en standard og å teste den utenfra er to forskjellige ting, og en kontroll som ikke kan feile, er ikke en kontroll.

Den samme tilbakeholdenheten gjelder innenfor EN 18246. De tyngste kravene i den handler om å bevise at et pass og bæreren er ekte, noe som krever kryptografisk signering. Ingenting signerer noe ennå — ikke vårt, ikke noen andres — og en kontroll som ikke et eneste pass på jorden kan bestå, lærer leseren ingenting. Tre av punktene i den kan besvares utenfra. Det er de tre vi kjører.

Kontrollen de fleste pass kommer til å stryke på

Av de tre kommer én til å overraske folk.

EN 18246 §5.1.2 forbyr innsamling av personopplysninger fra fysiske personer som leser offentlige passdata. §5.1.5 krever at profilering forhindres. Lest sammen beskriver de nøyaktig hva en analysetagg gjør: setter en identifikator på en leser, følger vedkommende på tvers av sider og sender det til en tredjepart.

Et digitalt produktpass som laster inn Google Analytics, Meta Pixel, Hotjar, Clarity eller Segment, samler inn personopplysninger fra noen som ikke har gjort noe annet enn å skanne en QR-kode på en genser. Validatoren ser etter sporerens vert i siden en forbruker faktisk mottar, ikke etter et skriptfilnavn, fordi hver av disse leveres under et halvt dusin navn.

Denne er ubehagelig å lansere, så det er verdt å være tydelig om vår egen posisjon: resolveren vår setter inn en GA4-tagg når en leietaker angir en målings-ID. Funksjonen finnes, og enhver leietaker som angir en, vil stryke på denne kontrollen i vår egen validator, på våre egne sider. Det er den eneste typen kontroll som er verdt å skrive. En som unntar forfatteren, er markedsføring.

Hvis du kjører analyseverktøy på passidene dine, er spørsmålet du bør ta med til juristene dine ikke om det er gitt samtykke til sporingen — det er om §5.1.2 i det hele tatt tillater den på den offentlige delen av et pass.

Begrensningen i EN 18239 som gjør det vanskelig

EN 18239 §5.2 nr. 11 krever at tilgang til DPP-tjenester «skal begrenses på en slik måte at angrep eller uautorisert masseinnhenting av data forhindres».

De åpenbare implementeringene er alle stengt av andre punkter i det samme standardparet:

  • En API-nøkkel eller innlogging? EN 18246 §4.3 sier at offentlige data skal leveres uten autentisering. EN 18239 §5.2(2) sier det samme og nevner det å unngå forskjellsbehandling basert på geografisk plassering som begrunnelsen.
  • Blokkere etter land? EN 18239 §5.2(3) sier at tilgang ikke skal nektes utelukkende på grunnlag av aktørens plassering eller jurisdiksjon.
  • En CAPTCHA-vegg? Samme problem, og den stryker på §5.4.2 om lesbarhet på alle forbrukerenheter.
  • Logge IP-adresser for å avsløre misbrukere? En IP-adresse er en personopplysning, og §5.1.2 forbyr innsamling av personopplysninger fra dem som leser offentlige data.
  • Blokkere roboter? EN 18246 §5.1.8 sier at robuste mekanismer mot skraping bør implementeres, og i samme åndedrag at systemet kan tillate nyttige søkemotorer å indeksere DPP-data. En begrenser som blokkerer Googlebot, er ikke sikrere, den er feil.

Det som gjenstår, er smalt: struping basert på en saltet hash av adressen, holdt i minnet så lenge ett tidsvindu varer, og aldri skrevet ned noe sted. Det som overlever minuttet, er et antall, og et antall handler ikke om en person.

Det er en reell teknisk begrensning, og den typen ting som bare blir synlig når standardene leses sammen i stedet for én om gangen.

Hva du bør gjøre med dette

  1. Slutt å skrive nummerområdet. EN 18216–18223 dikter opp to standarder og utelater to. Vis til dem med nummer og punkt.
  2. Skill mellom «publisert» og «sitert» i dine egne påstander. Seks gir formodning om samsvar. To gjør det ikke ennå. Den som hevder harmonisert samsvar med alle åtte, hevder noe som i dag ikke finnes.
  3. Se på hva passidene dine laster inn. Hvis det finnes en analysetagg på den offentlige delen, er EN 18246 §5.1.2 en samtale du må ta før noen andre starter den.
  4. Kjøp standardene. De er tilgjengelige fra SIS og en-standard.eu. Seks av dem avgjør om implementeringen din formodes å være i samsvar med kravene, og ingen av sammendragene som er i omløp — heller ikke dette — kan erstatte teksten.

Du kan kjøre kontrollene ovenfor mot en hvilken som helst pass-URL på dppagent.com/validate, også pass som ikke er våre. Den rapporterer per standard og per punkt, og sier hvilke funn som er delvise, og hvorfor.


Kilder

Primærkilder brukt i denne artikkelen:

  • Kommisjonens gjennomføringsbeslutning (EU) 2026/1736 — sitering av harmoniserte standarder for digitale produktpass i EU-tidende
  • EN 18216 (protokoller for datautveksling), EN 18219 (unike identifikatorer), EN 18220 (databærere), EN 18221 (datalagring, arkivering og varighet for data), EN 18222 (API-er for forvaltning av passets livssyklus og søkbarhet), EN 18223 (systeminteroperabilitet) — CEN/CENELEC JTC 24, publisert mai 2026
  • EN 18239 (forvaltning av tilgangsrettigheter, informasjonssystemsikkerhet og forretningsmessig konfidensialitet) og EN 18246 (autentisitet, pålitelighet og integritet for data) — godkjent av CEN 17. august 2026, vedtatt som SS-EN 16. september 2026
  • Forordning (EU) 2024/1781 (ESPR), artikkel 4, 9 og 10 — EUR-Lex

Henvisningene til punkter i denne artikkelen gjelder de lisensierte SS-EN 2026-utgavene. Standarder er opphavsrettslig beskyttede dokumenter og kan ikke gjengis her; punktnumrene er oppgitt slik at teksten kan kontrolleres mot originalene.