Den nya praktiska flaskhalsen: Vem får registrera ett pass?
EU-DPP-registret är operativt sedan den 20 juli 2026. För många team stod den tekniska frågan först i centrum: Går det att registrera en produktidentifierare, och leder databäraren till rätt plats? Det är nödvändigt, men inte tillräckligt. Genom genomförandeförordning (EU) 2026/1778 av den 16 juli 2026 får den föregående identiteten en egen regulatorisk betydelse: Registreringar ska göras av verifierade ekonomiska aktörer, och åtkomst till registerfunktioner är inte samma sak som allmän åtkomst till produktinformation.
Detta är ingen anledning att göra QR-koder mer komplicerade. Det är en anledning att tydligt modellera ansvar, underlag och behörigheter före den första produktiva registreringsprocessen. Följande vägledning skiljer dessa nivåer åt och visar vad tillverkare praktiskt kan förbereda nu.
Tre identiteter som inte får blandas ihop
I ett DPP-projekt förekommer minst tre olika identiteter.
För det första finns den ekonomiska aktören: företaget eller den enskilda näringsidkaren som släpper ut en produkt på marknaden eller agerar i registret. Artikel 4 i förordning 2026/1778 kopplar klassificeringen som ”verifierad ekonomisk aktör” till ett identitetsunderlag. För enskilda näringsidkare med säte i EU nämner rättsakten exempelvis en kvalificerad elektronisk signatur eller ett elektroniskt identifieringsmedel som uppfyller kraven i eIDAS och har hög tillitsnivå. Juridiska personer måste också verifieras genom definierade underlag.
För det andra finns den mänskliga användaren. Inköp, underhåll av grunddata, regelefterlevnad, externa tjänsteleverantörer och en DPP-tjänsteleverantör agerar inte automatiskt med samma befogenhet. Ett användarkonto ersätter därför inte den verifierade företagskontexten. Det behövs en spårbar koppling: Vem agerar för vilken ekonomisk aktör, i vilken roll och fram till när?
För det tredje finns produktidentiteten. En GTIN, ett serienummer eller en annan identifierare beskriver produkten respektive den föreskrivna granulariteten; den visar inte att personen framför skärmen har rätt att registrera. ESPR skiljer uttryckligen dessa områden åt: Databäraren kopplar produkten till passet, medan registret innehåller de entydiga identifierarna och registreringsuppgifterna. Kommissionens översikt över DPP beskriver förloppet på motsvarande sätt: Produktinformation skapas och registreras, varefter registret skapar ett unikt registrerings-ID.
Den som samlar dessa tre identiteter i en tabell, en API-token eller en gemensam e-postbrevlåda skapar senare en revisions- och driftsrisk. Den rätta frågan är inte ”Vem känner till länken?”, utan ”Vem får utlösa en registeråtgärd för denna ekonomiska aktörs räkning?”.
Allmän QR-åtkomst är inte registerbehörighet
En QR-kod på produkten förblir en åtkomst till passet. Den är ingen inloggningsmekanism för registret och bör inte heller bli det. Konsumenter, reparationsföretag, återvinnare och myndigheter behöver olika typer av information. Den aktuella kommissionsvägledningen om DPP beskriver uttryckligen att information är åtkomlig utifrån användarroller.
I praktiken rekommenderas därför en tydlig skiktindelning:
- Den offentliga skanningen visar en stabil och kostnadsfritt åtkomlig passvy med den information som föreskrivs för den aktuella produktgruppen.
- Ett rollbegränsat gränssnitt hanterar underlag, leverantörsdata, ändringshistorik och interna godkännanden.
- Registeranslutningen får endast överföra nödvändiga registreringsuppgifter och koppla ett registersvar till en specifik produktpost.
Detta förhindrar två vanliga missuppfattningar. För det första ersätter en ”hemlig” QR-länk ingen åtkomstkontroll; den kan vidarebefordras och är inget tillförlitligt behörighetsunderlag. För det andra är registret inte lagringsplats för alla produktdokument. Kommissionen förklarar att den fullständiga produktinformationen kan finnas hos den ekonomiska aktören eller hos en DPP-tjänsteleverantör; det som registreras är nödvändiga metadata och identifierare.
Vad förordningen antyder tekniskt
Förordning 2026/1778 beskriver inte registret som en enkel uppslagsdatabas. Den nämner bland annat ett API för registrering och datamottagning, en plattform för att bekräfta existens och fullständighet, ett schema för unika registrerings-ID:n, ett register över verifierade DPP-tjänsteleverantörer, ett loggsystem samt identifierings- och auktoriseringsscheman. Datamodeller måste dessutom versionshanteras.
Dessa krav leder inte till en färdig produktarkitektur. Men de ger robusta riktlinjer:
Företagsprofil före produktimport
Skapa en kontrollerad företagspost före en massimport. Den bör innehålla den juridiska enheten, dess status som ekonomisk aktör, valt identitetsunderlag, tidpunkten för kontrollen och ansvarig funktion. Själva underlaget bör ett DPP-system endast lagra i den utsträckning det är nödvändigt och tillåtet; ofta räcker en kontrollstatus med referens och logik för utgång eller omprövning.
Delegering är en egen datapost
När en tjänsteleverantör eller byrå agerar behöver delegeringen ha en definierad omfattning. Minst följande bör anges: ekonomisk aktör, tillåtna åtgärder, produktgrupper eller varumärken, start, slut och återkallelse. En generell API-nyckel utan mandatbegränsning är för grov för en registreringsrelevant åtgärd.
Registrering som spårbar process
Per registrering bör teamen åtminstone spara den lokala produktversionen, den överförda identifieraren, svaret inklusive registrerings-ID, tidsstämpel, agerande roll och felklass. Då går det senare att skilja mellan ett sakligt ofullständigt pass, en kolliderande identifierare och en saknad behörighet. Loggningen ska inte bli en insamling av onödiga personuppgifter; den ska skapa en ansvarsfull och granskningsbar handlingskedja.
Testa behörigheter som verksamhetsregler
Testfallen bör inte sluta vid ”API:t svarar 200”. Kontrollera åtminstone följande: En obehörig användare kan inte utlösa en registrering; en delegerad tjänsteleverantör kan endast hantera det avtalade mandatet; en utgången delegering avvisas; den offentliga passvyn avslöjar inga interna register- eller underlagsuppgifter; och en återinsänd process hanteras spårbart som en upprepning.
En enkel startplan för de kommande veckorna
Börja inte med en fullständig migrering. Välj en liten, representativ produktmängd och en verklig ansvarskedja.
- Koppla tillverkare, den som släpper ut produkten på marknaden, dataansvariga och eventuella tjänsteleverantörer till varje pilotprodukt.
- Dokumentera med vilken metod den ekonomiska aktören verifieras och vem som godkänner kontrollen.
- Definiera roller för utkast, sakgranskning, registrering och enbart läsbehörighet.
- Registrera en testpost med versionshanterade produktuppgifter och logga registrering, svar och korrigeringsväg.
- Testa den offentliga QR-åtkomsten separat från interna roller och registeranslutningen.
- Öva på återkallelse och byte: Vad händer vid byte av tjänsteleverantör, ändrad företagsbeteckning eller en felaktig identifierare?
Detta förlopp stämmer också med den redan publicerade rekommendationen att testa register, resolver och datakälla separat. Det nya är tyngdpunkten: Före en robust API-integration måste det vara tydligt vilken verifierad organisation och vilken roll som ansvarar för åtgärden.
Vad man ännu inte bör hävda
Registerförordningen skapar den tekniska och organisatoriska ramen. Den gör inte varje produktgrupp omedelbart DPP-pliktig och ersätter inte sektorsspecifika delegerade rättsakter. Kommissionen beskriver fortfarande införandet produktgrupp för produktgrupp; enligt ESPR-delegerade rättsakter föreskrivs i princip en övergångsperiod på minst 18 månader. En verifierad företagsstatus är inte heller ett frikort för ofullständiga eller felaktiga produktuppgifter.
Konsekvensen för teamen är ändå konkret: Identitet, mandat, roller och loggning hör hemma i DPP-backloggen innan registreringar skalas upp. Då förblir QR-koden den enkla offentliga ingången — och registeråtgärden blir det den är ur regulatoriskt perspektiv: en ansvarsfull och spårbar åtgärd av en verifierad ekonomisk aktör.
