Denmark Central Population Register
The password was 123456. The access was legitimate. The register is national.
What happened?
Attackers obtained names, addresses and CPR numbers for 8.8 million people by misusing a private Danish company's legitimate access to search the Central Population Register. The register holds about 11 million records, so the breach covers roughly 80% of it. The company has since been named: Pays ApS, a Funen-based IT firm whose managing director confirmed on 9 October that its access had been exploited.
At least three Pays accounts used the password 123456, one of them the company administrator account. The person claiming responsibility told Politiken they held access from 10 September for 21 days and 17 hours. The CPR administration learned on the evening of Friday 2 October that there had been irregular activity during September. It established the extent over the weekend, notified the Danish Data Protection Agency on Sunday 4 October, and the Ministry of Research, Education and Digitalisation disclosed publicly on 5 October. The company's access has been cut off and police are investigating.
What data was actually inside?
Names, addresses and CPR numbers. The set covers people living in Denmark, people who have died, and citizens who have moved abroad. Records belonging to people who registered for name and address protection were not included.
The CPR number is the point. It is the single identifier that follows a Danish resident through healthcare, banking, tax, employment and government services for life. It encodes a date of birth. It is not reissued because it leaked. Denmark built an entire digital state on the assumption that this number identifies a person, which is exactly what makes a bulk copy of it valuable.
Who gets hurt and how?
Most of a country, including people who have died and people who left years ago. None of them had any relationship with the company whose access was misused, and none had a way to decline.
A national identity number paired with a current address is the input for account opening, credit applications and impersonation against any service that treats the number as proof of identity. The usual remedy after an identity leak is to change the identifier. Denmark cannot, not at this scale, so the exposure is permanent and the mitigation has to happen in every system that trusts the number rather than in the register itself.
What did they think they were doing right?
The access was legitimate and the architecture was conventional. Private companies query the CPR for sound reasons, including verifying customers, running payroll and meeting their own regulatory duties. Granting that access under agreement is how a national register is meant to function.
The control that failed was not authentication. It was the absence of a limit on what authorised use looks like. A company verifying its own customers makes a steady, bounded number of lookups. Nothing appears to have distinguished that pattern from a systematic enumeration of the register.
What did they not know about their own data?
How much one approved integration could extract. This is the same failure as the Florida DAVID entry in this series, at national scale: the system knew the account was permitted and did not know that permitted use does not look like this.
Irregular activity ran through September and surfaced on 2 October. The register could say precisely how many records were touched once it looked, which means the logging existed. What did not exist was anything watching those logs against a definition of normal.
A register is a known quantity. Denmark knows exactly what a CPR record contains, how many there are and who is entitled to query them. The unanswered question was never what the data was. It was what the third parties were doing with it, and that question had no owner.
If your business runs on databases, you probably have similar records, customer data, credentials, financial information. Do you know what's actually in yours?
Not sure where to start? How to find sensitive data across your estate
What does attribution look like the morning after?
No group has claimed this and no extortion demand has been reported. The route was a company's own credentials, which means the useful attribution question is how that access was taken rather than who posted a leak site entry.
Police are investigating alongside other authorities, and the Data Protection Agency was notified within two days of discovery. For a public sector breach that is a fast disclosure, and it stands in contrast to several entries in this series where the gap ran to months.
What would have changed the outcome?
A password. Three accounts at the connected company used 123456, including the administrator account, so in this case hardening credentials would have helped and multi-factor authentication would have ended it outright. That is the cheapest finding in this entire series.
Beyond that, rate limiting and behavioural monitoring on third-party access. Twenty-one days of systematic enumeration passed unremarked, which no password policy addresses. Denmark secured the register. The exposure came through an organisation it had authorised, operating inside the permissions it was given, with a credential a child could guess. Any institution that grants bulk query access to outside parties is holding the same unexamined question: what does legitimate use look like, and would anything notice if it stopped looking like that?
Sources
- Help Net Security: Data breach at Denmark's population register exposes 8.8 million people
- The Copenhagen Post: CPR data breach exposes personal details of 8.8 million people in Denmark
- The Irish Times: Major Denmark breach exposes personal data of 8.8 million people
- IT Security Guru: Denmark's CPR breach exposes 8.8 million people as experts warn over trusted third-party access
- Insurance Journal: Denmark Data Breach Exposes 8.8 Million People's Personal Data
- The Copenhagen Post: '123456' password used in massive Danish CPR data breach
- The Register: '123456' password linked to Denmark data breach affecting 8.8M people
- Malwarebytes: How "123456" became the key to almost 9 million personal records
Gyazo found out the hard way.
Your team could spend the next 6 months rebuilding systems, notifying customers, and answering legal questions. Or you could spend 24 hours finding out what's actually at risk.
Want to understand the process first? Read our guide to sensitive data discovery .