Denmark CPR Data Breach: How Lawful Access Was Abused

SecurityWeek reported that about 8.8 million people were affected by the misuse of access to Denmark's Central Person Register, out of roughly 11 million records including deceased people. The data retrieved included names, addresses, and CPR numbers. People with name and address protection were not affected, according to the reporting. Danish authorities said they could not name the actor responsible.

The CPR offers lookup access to approved organisations. According to Danish reporting, attackers used the account of a small company in Odense, later named by Danish media as Pays ApS, to run automated lookups at scale. Secondary reports put the number of lookups above 14 million over roughly ten days in September. The company's administrator confirmed to Danish media that its access had been misused.

Politiken reported, as relayed by Se og Hør on October 9, that at least three profiles at the company used the password 123456, including the administrator account. A person claiming responsibility told Politiken they used a leaked password from a former employee of a Danish firm and two programs to extract data. That account is the claimant's own and has not been independently verified.

According to the reporting, CPR staff noticed the problem because the company's monthly bill was abnormally large, reflecting the volume of lookups. Danish authorities were notified, the company's access was cut, and the data protection authority, Datatilsynet, was informed. Police and Denmark's national special crime unit are investigating; no charges had been reported.

Reporting places the start of the abuse around September 10, 2026. Detection is reported as the evening of October 2, with notification to Datatilsynet on October 4 and a public announcement on October 5. Sources differ on the exact access window: DR reported roughly September 10 to 20, drawing on the register's own report to the authority, while TV2, citing a freedom of information request, reported access lasting 21 days and 17 hours, which runs to early October. These discrepancies have not been resolved publicly.

The register's own systems were not compromised in the conventional sense. A downstream organisation with legitimate access had weak credentials, and that access had no effective limits on volume or pattern. Any system that exposes sensitive data to many approved customers through an API or portal carries the same risk.

Legitimate users of a person register look up specific individuals for specific transactions. Millions of sequential lookups in days do not match that pattern. Per-customer rate limits, alerts on volume spikes relative to historical baselines, and checks for sequential or enumerating queries would have flagged the abuse within hours rather than at billing time.

Data providers can require customers to use multi-factor authentication, enforce password policies, and rotate credentials when staff leave. If the reported 123456 password is accurate, basic password policy enforcement at the provider would have blocked it.

Here, cost anomalies were the detection mechanism. Usage-based billing data is often richer and more timely than security logs for API products. Feeding usage metrics into security monitoring, and alerting on sudden increases, is cheap and effective.

The claimant's account points to a former employee's leaked password. Whether or not that detail holds, removing access promptly when people leave, and auditing for dormant accounts, is a basic control that third-party customers frequently neglect.

The identity of the actor, what was done with the data, the precise access window, and which firm's former employee's password was used, if that claim is accurate, have not been publicly established.

Names, addresses, and CPR numbers enable targeted phishing and impersonation. Residents should be cautious of unexpected contacts referencing their personal details and follow guidance from Danish authorities.

Providers that expose sensitive records to approved customers should enforce MFA for customer accounts, set per-customer query limits, alert on deviations from each customer's normal volume, detect enumeration patterns, review dormant and high-volume accounts monthly, and require customers to remove leavers promptly. Each of these would have shortened or prevented this incident.

A single identifier that links to a person's name and address across government and commercial services is valuable for fraud and social engineering, so aggregated access to it deserves the strictest controls.