Denmark's Population Registry Breach Exposed Names, Addresses and CPR Numbers of 8.8 Million People — Attackers Abused a Company's Legitimate Registry Access
Denmark's Population Registry Breach Exposed Names, Addresses and CPR Numbers of 8.8 Million People — Attackers Abused a Company's Legitimate Registry Access
Denmark's Central Person Register (CPR), the national civil registry that underpins banking, healthcare and taxation, has disclosed a data breach affecting approximately 8.8 million registered individuals — living residents, people who moved abroad, and the deceased. The CPR system holds about 11 million records, meaning roughly 80% of everyone ever registered in the country had their data pulled. The exposure includes names, addresses, dates of birth, marital status and the unique CPR number, the Danish equivalent of a Social Security number. Individuals protected by name-and-address confidentiality settings were not included in the exposed dataset, authorities noted.
The attack did not breach the registry's public-facing infrastructure. According to the CPR announcement, threat actors misused a private Danish company's legitimate access to the registry system to obtain the records. Denmark's Data Protection Agency said the intrusion involved brute-forcing to enumerate valid CPR numbers and then extracting the related data from each entry — in other words, a trusted credential walking out the front door with bulk queries. The unauthorized searches took place in September 2026; the CPR administration became aware of the activity on October 2 and determined the scale over the weekend before going public on Monday. The company's access has since been blocked, police are investigating, and the technical route into the company's authorized connection has not been disclosed.
Minister for Research, Education and Digitalization Christina Egelund called it "an extremely serious incident," informed Parliament's Business and Digitalization Committee, and ordered a comprehensive security review of the CPR system alongside additional protective measures. A dedicated cyber hotline has been opened, with guidance available at sikkerdigital.dk. Authorities are blunt about the downstream risk: with real names, addresses and CPR numbers in attackers' hands, phishing and vishing attempts will sound exactly like the government, and the registry itself warned citizens never to disclose passwords or confidential information in response to calls or emails — "even if the recipient appears to know your name, address, and CPR number." The breach is the second government-scale personal-data exposure in barely a week, following the Pentagon DMDC breach that exposed nearly 3 million people we reported on September 28.
What Should You Do?
- If your organization holds privileged access to a registry or directory API, treat that access as a primary attack surface: scope it to the minimum records needed, and log every query with enough context to spot abuse.
- Make enumeration loud. Sequential or brute-forced key lookups — the pattern that pulled 8.8 million CPR entries — are detectable as abnormal query volume and distribution; alert on per-credential request spikes and off-hours bursts.
- Rehearse revocation. One blocked credential path stopped further loss here; know in advance exactly which third-party sessions you can kill, how fast, and who has authority to do it.
- Danish readers and orgs with Danish users: assume attackers have real CPR data; brief staff and customers that a caller knowing a CPR number proves nothing, and route verification through official channels.
The WAF Angle
The uncomfortable part of this incident for perimeter-focused teams is that no attack signature ever fired: a legitimate session, authenticated with a real partner's credentials, issued valid queries and the registry answered correctly. This is the same blind class as API key abuse and insider risk — the request is well-formed, the traffic is trusted, and the only tell is behavioral. For any API that serves a registry, directory or similarly concentrated data store, the defenses that matter are rate limits per partner credential, query-volume baselines with alerting on shape changes, and canary records that scream if someone reads them. A WAF still earns its place in front of such services — for the credential-stuffing and injection that precede or accompany abuse — but the lesson of Copenhagen is that "who can ask, how much, how fast" is a security control, and it belongs in your threat model for every third-party integration you grant.
