CPR-sagen i Danmark: Hvad produktteams bør kontrollere før adgang gives

Udgivet og gennemgået: 14. oktober 2026. Forfatter: SundAI. Efterforskningen kan ændre oplysningerne.

Bekræftede oplysninger og presseomtale

Ministeriet oplyste 5. oktober 2026, at uvedkommende havde misbrugt en privat virksomheds lovlige CPR-adgang til oplysninger om cirka 8,8 millioner registrerede personer, også afdøde og udrejste. Adgangen var stoppet, og sagen blev undersøgt. Det fastslår ikke, at alle oplysninger blev offentliggjort.

Ritzau-omtale fra 10. oktober identificerede Pays i Odense og beskrev mindst tre konti, herunder en administratorkonto, med “123456”. Det er en presseoplysning, ikke en bevist forklaring på indtrængningen. Datatilsynets meddelelse er ikke en endelig juridisk afgørelse.

Svage kodeord er kun én del af adgangskæden

Password spraying afprøver få almindelige kodeord mod mange konti. Credential stuffing genbruger tidligere stjålne loginpar. Mekanismerne er forskellige; ingen af dem beskrives her som den bekræftede metode i sagen.

Kontrollér blokering af svage kodeord, risikotilpasset MFA, begrænsning af loginforsøg, personlige identiteter og hurtig tilbagekaldelse. Test derefter, hvilke oplysninger en godkendt konto kan hente. Login erstatter ikke kundeadskillelse eller mindst mulige rettigheder.

Hvad loven kræver

GDPR artikel 32 kræver passende tekniske og organisatoriske foranstaltninger i forhold til risikoen, herunder fortrolighed, robusthed og regelmæssig test. Der er ikke én universel kodeordslængde. Artikel 33 kræver som udgangspunkt anmeldelse uden unødig forsinkelse og om muligt inden 72 timer efter kendskab, medmindre bruddet næppe indebærer risiko for personers rettigheder. Databehandlere underretter den dataansvarlige uden unødig forsinkelse.

NIS2 afhænger af virksomhedens og aktivitetens placering inden for dansk gennemførelse. Antag ikke, at alle små leverandører er omfattet. ISO/IEC 27001 er en risikobaseret ledelsesstandard, ikke garanti mod kompromitterede konti. NIST og OWASP giver teknisk vejledning, ikke en europæisk juridisk vurdering.

Hvor kode og integrationer kan udvide eksponeringen

Manglende serverkontrol af rettigheder, brede servicekonti, hemmeligheder i kode, usikre dataforespørgsler og mangelfuld logning kan udvide skaden fra én identitet. Det er hypoteser til gennemgang af jeres produkt, ikke påstande om Pays-kode. AI-genereret kode skal gennem samme sikkerhedstest.

Brug tilladte testkonti og syntetiske data: test kundeadskillelse, at læseroller ikke skriver, at masseforespørgsler giver alarmer, og at leverandøradgang kan tilbagekaldes. Test aldrig andres systemer uden tilladelse.

Tre tjek denne uge

Udpeg ejeren af hver integration, og skriv præcist, hvad den kan læse eller ændre. Fjern delte identiteter og ubrugt adgang.

Kør én negativ adgangstest og én tilbagekaldelsestest. Gem resultat, ejer og dato. Brug den gratis tjekliste for leverandøradgang eller anmod om AI Decision Review, hvis en beslutning er gået i stå.

Kilder og videre læsning

Artiklen forklarer kontroller og spørgsmål; den er ikke en juridisk vurdering eller afgørelse om Pays.

Hent den gratis guide Find det næste sikkerhedsskridt