Denmark says unauthorized parties used a private company's legitimate access to the Central Person Register (CPR) to collect names, addresses and CPR numbers for about 8.8 million people. The lookups took place in September and were not discovered until October 2.
What happened
On October 5, 2026, Denmark's Ministry of Research, Education and Digitalization announced that unauthorized parties had misused a Danish company's lawful access to CPR data. According to the ministry, the exposed data covers about 8.8 million registered people, including living people, people who have moved abroad and deceased people, out of roughly 11 million in the register. People registered with name and address protection were not affected. The ministry says the activity took place during September and was discovered on October 2.
The CPR administration has cut off the company's access, reported the case to the Danish Data Protection Authority (Datatilsynet), and the police are investigating. Minister Christina Egelund informed Parliament's Business and Digitalization Committee and ordered a full security review of the CPR system. The ministry says measures to prevent a repeat are already in place but has not described them. The company has not been named.
Datatilsynet confirmed it was notified on October 4. It said the case involves a very large number of automated lookups against the CPR system to find valid CPR numbers, and that it has opened its own investigation into what happened and who is responsible.
The Hacker News, citing an interview with news agency Ritzau, reports that the lookups ran for about 10 days. It says Egelund agreed that the safeguards around this kind of access had not been strong enough and that alarms should have gone off. The Next Web reports about 14 million lookup attempts. It also reports that the activity was noticed when the CPR administration invoiced the company and saw a very large bill. Neither the ministry nor Datatilsynet has said how the company's access was compromised.
Why it matters
This is a third-party access failure at national scale. The attackers used a partner account that was allowed to query it, and the lookups looked like normal use until the volume showed up on an invoice. As reported, the gap was not authentication at the register. It was the lack of limits and monitoring on what an approved account could do.
Most organizations have the same pattern on a smaller scale. Partners, data brokers, payroll providers and integration accounts get API access to customer or employee records, and that access is reviewed once at onboarding. Volume limits, alerts on unusual query patterns and checks on how the partner protects its credentials are often missing.
The data is also the kind used to verify identity. The ministry warns people not to share passwords or confidential information even when a caller already knows their name, address or CPR number. According to The Hacker News, the register's own guidance is that a CPR number alone is not proof of identity. If your help desk or customer support accepts a national ID number plus address as verification, this incident is a reason to change that.
What to check in your environment
- Inventory partner and integration accounts with lookup or bulk-read access to customer, employee or citizen records. Record the owner, what the account can query, and how it authenticates.
- Set volume limits on those accounts. Define a normal daily query volume for each one and enforce rate limits or quotas where the platform supports them.
- Alert on unusual query patterns, not just failed logins. Sequential or enumeration-style lookups and sudden spikes in volume should page someone within hours. A billing cycle is too late.
- Review how partners protect the credentials you issued. Ask partners how API keys or certificates are stored, who can use them, and whether access is limited to known source networks.
- Confirm you can revoke partner access quickly. Know who can disable a partner's credentials and how long it takes.
- Stop using static identifiers as proof of identity. Check help desk, account recovery and customer support processes that accept a national ID number, birth date or address as verification. Replace them with stronger checks.
- Warn Danish staff and customers about targeted phishing. Point them to the ministry's advice: don't share passwords or codes, even with callers who know personal details.