Denmark’s Population Registry Was Drained With a Stolen Vendor Key: What 8.8 Million Leaked Identities Mean for African Digital ID

Denmark’s national registry leaked 8.8 million identities, and no malware was involved

Someone walked out of one of Europe’s most complete citizen databases with names, addresses, dates of birth, marital status, and CPR identification numbers for roughly 8.8 million people. The Central Population Register confirmed the breach on Friday October 2, then spent the weekend working out how far it went. The method was the disturbing part. No zero-day, no ransomware, no exotic exploit chain. Threat actors misused a private Danish company’s legitimate access to the registry system, brute-forced their way through valid CPR numbers, and pulled the data attached to each one.

How it happened

Denmark’s Data Protection Agency says the attack involved brute-forcing to enumerate valid CPR numbers, then extracting the record behind each hit. That description is worth sitting with. The attacker needed only a credential the system already trusted. Once they had it, probably stolen from the private company that held the access, the registry did what registries are built to do: answer queries. Query, answer, query, answer, nearly nine million times.

The CPR system holds records for about 11 million people, including residents, emigrants, and the deceased, so the breach reached roughly 80 percent of the register. The incident happened during September. The company whose access was abused has been cut off from the system, and Danish police have an investigation running.

Research Minister Christina Egelund told Parliament’s Business and Digitalization Committee that the incident is extremely serious, which is the correct read. She urged citizens to watch for unsolicited contact, and the registry’s own warning is worth quoting in full: never disclose passwords or confidential information in response to calls or emails, even if the person on the other end appears to know your name, address, and CPR number.

Why this scales so badly

Civil registries are designed to be queryable. Banks, hospitals, employers, tax authorities, and welfare services all need to verify who a person is, so the system exposes lookup paths to vetted third parties. That architecture has a consequence nobody likes to write down: every legitimate query path is also a data extraction path, and the only thing separating the two is whether the caller holds a valid credential and stays inside the expected rhythm.

Brute-force enumeration worked here because the identifier itself is guessable and the registry answers differently for valid and invalid numbers. The attacker gets free signal from the system’s own responses. A national ID format that follows a checksum rule narrows the search space further, and Denmark’s CPR number encodes date of birth plus a sequence digit, so an attacker who knows a target’s birthday is already most of the way to a valid number.

The African read

South Africa, Nigeria, Kenya, and Ghana are all building or expanding digital identity systems that work the way the CPR does: one master record per citizen, query access open to banks, telcos, government agencies, and contractors. South Africa’s SASSA grant system already depends on ID verification through third-party integrations. Nigeria’s NIN-to-SIM linkage created the same query surface at a scale Denmark has never had to defend.

The lessons from this breach transfer directly. The soft target is not the registry, it is the smallest company with legitimate access to it. Vendors, contractors, and integrators hold credentials that front the master database, and their security posture is usually far weaker than the state system behind them. Enumeration against a national identifier turns a stolen vendor credential into a mass extraction tool, because the system is built to answer. And the breach window matters more than the detection alert. Denmark’s registry learned on October 2 about an incident from September, then spent days sizing the damage. Most African institutions would run the same timeline.

What defenders should actually do

Rate-limiting alone will not stop this, since nine million queries can be spread over months. What would have hurt the attacker:

  • Anomaly detection per credential, not per source IP. A vendor integration that normally verifies 200 identities a day and suddenly requests 400,000 has been abused, no matter whose laptop the traffic comes from.
  • Uniform responses for valid and invalid identifiers. If the registry answers every query with the same shape and timing, enumeration loses its signal.
  • Scoped, expiring access for third parties. A contractor that needs verification for one payroll run should not hold a standing key to the whole register.
  • Independent audit of the vendor chain. Assume at least one integration partner will eventually be breached, and design the query layer so a partner breach degrades into a limited extract instead of a national dump.

Where eHawu sits

eHawu builds network-layer identity verification for African fintech and enterprise, and the Denmark incident is a case study in why the layer matters. Perimeter tools assume the credential in use is honest. Ours does not. Every request that touches a regulated data path gets inspected for behavior, not just authorization: the spike in query volume, the enumeration shape, the credential that suddenly acts like a scraper. When a Danish-style breach reaches an African registry or the vendors wired into it, the fight happens in the gap between abuse and extraction. That gap is measured in the first thousand queries.

Source: BleepingComputer, reporting on the Danish CPR announcement and the Danish Data Protection Agency statement, published October 5, 2026.

Get the next one in your inbox. The eHawu Thursday brief collects the week's analyses in one email.
Weekly Intel Brief

The Thursday security digest

One email a week. The week's threat analyses, CVE breakdowns and infrastructure notes from the eHawu SOC. No noise, no daily spam.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *