Denmark’s CPR case: what product teams should check before granting access

Published and reviewed: 14 October 2026. Author: SundAI. Investigation status may change.

What is confirmed, and what is reported

The Danish ministry stated on 5 October 2026 that unauthorised parties had misused a private company’s lawful CPR access, affecting information on approximately 8.8 million registered people, including deceased and emigrated people. It said the company’s access had been stopped and the incident was under investigation. This does not establish that all records were publicly leaked.

Ritzau reporting published on 10 October identified Pays in Odense and reported that at least three accounts, including an administrator account, used “123456”. That is a reported fact, not a proven explanation of how the intrusion occurred. The regulator’s notice is an investigation notice, not a final legal finding.

Weak credentials are only one part of the access chain

Password spraying tries a small set of common passwords across many accounts. Credential stuffing reuses previously stolen account/password pairs. These are different mechanisms; neither is presented here as the confirmed entry method in this case.

For your own product, review weak-password blocking, MFA appropriate to the risk, login throttling, unique identities and prompt revocation. Then check what an authenticated account can retrieve. A login control does not replace tenant isolation or least privilege.

What the law asks for

GDPR Article 32 requires appropriate technical and organisational measures in relation to risk, including confidentiality, resilience and regular testing. It does not prescribe one universal password length. Article 33 generally requires a controller to notify the competent authority without undue delay and, where feasible, within 72 hours after awareness, unless the breach is unlikely to risk people’s rights and freedoms. Processors notify their controller without undue delay.

NIS2 duties depend on whether the entity and activity fall within the applicable Danish implementation. Do not infer that every small supplier is covered. ISO/IEC 27001 is a risk-based management standard; certification is not a guarantee that an individual account cannot be compromised. NIST and OWASP guidance offer technical controls, not a substitute for European legal analysis.

Where code and integrations can expand the exposure

Missing server-side authorisation checks, overly broad service accounts, embedded secrets, unsafe data queries and inadequate logging can turn one compromised identity into wider access. These are review hypotheses for your product, not allegations about Pays code. AI-generated code still needs the same security review and tests.

A safe test plan uses authorised test accounts and synthetic records: verify that one tenant cannot read another, a read-only role cannot write, bulk queries trigger alerts, and revoking a supplier identity stops access. Never test a third-party system without permission.

Three checks to do this week

Name the owner of each external integration and record exactly what it can read or change. Remove shared identities and unused access.

Run one negative access test and one revocation test. Keep the result, owner and date as evidence. If a decision is stalled, use the free supplier-access checklist or request a focused AI Decision Review.

Sources and further reading

This article explains controls and questions; it is not a legal opinion or a determination about Pays.

Get the free guide Find your next security step