CPR-fallet i Danmark: Vad produktteam bör kontrollera innan åtkomst ges

Publicerad och granskad: 14 oktober 2026. Författare: SundAI. Utredningen kan ändra uppgifterna.

Bekräftade uppgifter och medierapporter

Ministeriet uppgav den 5 oktober 2026 att obehöriga hade missbrukat ett privat företags tillåtna CPR-åtkomst till information om cirka 8,8 miljoner registrerade personer, även avlidna och utvandrade. Åtkomsten hade stoppats och händelsen utreddes. Det fastställer inte att alla uppgifter offentliggjordes.

Ritzau-rapportering den 10 oktober identifierade Pays i Odense och beskrev minst tre konton, inklusive ett administratörskonto, med “123456”. Det är en rapporterad uppgift, inte en bevisad förklaring till intrånget. Datatilsynets meddelande är inget slutligt rättsligt avgörande.

Svaga lösenord är bara en del av åtkomstkedjan

Password spraying prövar några vanliga lösenord mot många konton. Credential stuffing återanvänder tidigare stulna konton och lösenord. Mekanismerna skiljer sig; ingen presenteras här som bekräftad metod i fallet.

Granska blockering av svaga lösenord, riskanpassad MFA, begränsade inloggningsförsök, unika identiteter och snabb återkallelse. Testa sedan vad ett autentiserat konto kan hämta. Inloggning ersätter inte kundseparering eller minsta behörighet.

Vad lagen kräver

GDPR artikel 32 kräver lämpliga tekniska och organisatoriska åtgärder i förhållande till risken, inklusive konfidentialitet, motståndskraft och regelbundna tester. Den anger ingen universell lösenordslängd. Artikel 33 kräver normalt anmälan utan onödigt dröjsmål och om möjligt inom 72 timmar efter kännedom, om det inte är osannolikt att incidenten innebär risk för personers rättigheter. Personuppgiftsbiträden underrättar ansvarig utan onödigt dröjsmål.

NIS2 beror på om organisation och verksamhet omfattas av dansk implementering. Anta inte att varje liten leverantör omfattas. ISO/IEC 27001 är en riskbaserad ledningsstandard, ingen garanti mot komprometterade konton. NIST och OWASP ger teknisk vägledning, inte europeisk juridisk analys.

Var kod och integrationer kan öka exponeringen

Saknade behörighetskontroller på servern, breda servicekonton, hemligheter i kod, osäkra datafrågor och bristande loggning kan öka skadan från en komprometterad identitet. Detta är granskningshypoteser för er produkt, inte påståenden om Pays-kod. AI-genererad kod behöver samma säkerhetsgranskning och tester.

Använd godkända testkonton och syntetiska uppgifter: testa kundseparering, att läsroller inte skriver, att massfrågor larmar och att leverantörsåtkomst kan återkallas. Testa aldrig andras system utan tillåtelse.

Tre kontroller denna vecka

Utse ägare för varje integration och ange exakt vad den kan läsa eller ändra. Ta bort delade identiteter och oanvänd åtkomst.

Kör ett negativt åtkomsttest och ett återkallelsetest. Spara resultat, ägare och datum. Använd den kostnadsfria checklistan eller begär AI Decision Review om ett beslut har fastnat.

Källor och vidare läsning

Artikeln förklarar kontroller och frågor; den är inget juridiskt utlåtande eller avgörande om Pays.

Hämta den kostnadsfria guiden Hitta nästa säkerhetssteg