Denmark’s Central Population Register breach exposes personal data of 8.8 million people: full technical analysis

Attackers used a private company’s lawful API access to the CPR in September, exposing names, addresses and national ID numbers

Denmark has confirmed that unauthorized actors accessed the personal records of about 8.8 million people through the Central Population Register (Det Centrale Personregister, or CPR). Authorities disclosed the breach on October 5, 2026. The exposed data is full names, residential addresses and CPR numbers, the 10-digit national ID that Danish institutions use as a universal identifier. The access happened during September 2026 and ran through a private company’s legally sanctioned connection to the register.

Most breaches start with an unpatched flaw or a brute-forced login. By the authorities’ account, this one started with the misuse of an approved corporate connection. That puts third-party access oversight and API governance at the center of the story, along with a harder question: how well does a national identity system hold up when the threat arrives through a trusted door?

Research, Education and Digitalization Minister Christina Egelund called the breach “deeply serious” and asked for a full security review of the CPR architecture. The incident has been reported to Denmark’s Data Protection Authority (Datatilsynet), and police are investigating with other agencies. No threat actor or APT group has been publicly named.

What the CPR is and why it matters

The CPR was established in 1968. Everyone registered in Denmark gets a unique 10-digit CPR number (format DDMMYY-XXXX), and that number works as the identifier in nearly every government and commercial interaction. It is the credential for the tax system (SKAT), the healthcare platform (Sundhedsplatformen), banking, Borger.dk, electoral registration, employment records, social benefits and even library memberships.

The register holds about 11 million records, more than Denmark’s roughly 5.9 million living residents, because it keeps entries for people who emigrated and for the deceased. The Ministry of the Interior and Housing (Indenrigs- og Boligministeriet) runs it under the Civil Registration Act. It connects to more than 2,000 public and private systems through bulk data feeds, real-time query interfaces and role-based API endpoints.

That centrality is why the register is so useful and why a compromise hurts so much. A CPR number paired with a name and address is what security people call a full identity triple. It is enough to open bank accounts, apply for credit, file false tax returns and pass as the victim in dealings with government, and it makes social engineering far more convincing.

The attack vector: misuse of lawful third-party access

Danish authorities say the unauthorized access came through a private Danish company’s existing, lawful connection to the CPR. That access falls under Section 38 of the Civil Registration Act, which lets private entities with a legitimate interest query predefined subsets of CPR data. Four conditions apply. The company names in advance the group of people whose data it needs, so the authorization never covers the full database. It shows a concrete, legally recognized business need. It complies with GDPR (Regulation 2016/679) and Denmark’s Databeskyttelsesloven. And it uses the data only for the purpose the access was granted for.

During September 2026, the unauthorized parties used that connection to extract records on about 8.8 million people, far more than any Section 38 authorization would allow. How the company’s access was hijacked, redirected or abused is still under investigation.

The Ministry has not said whether the compromise involved stolen API credentials, a malicious insider, a supply-chain compromise of the company’s infrastructure, session hijacking or an access token with too broad a scope. The answer decides whether this was a targeted attack by a state or criminal actor, an insider threat or a systemic failure of access governance. Authorities have also not named the company, likely to protect the investigation.

Timeline of discovery and response

The breach was not caught in real time. According to the official disclosure, CPR administrators first noticed anomalous system behavior on the evening of Friday, October 2, 2026. What the anomaly was has not been disclosed: unusual query volumes, irregular access patterns, off-hours activity from the company’s endpoint or exfiltration signatures are all possible. Over the weekend of October 3 and 4, forensic analysis confirmed that unauthorized parties had accessed records on about 8.8 million people. The response went as follows:

1. The private company’s connection to the CPR was terminated.
2. External cybersecurity specialists were brought in to map the scope of the incident, identify the data fields accessed and determine how the data left the system.
3. The breach was reported to Datatilsynet, as GDPR Article 33 requires.
4. Danish police (Rigspolitiet) opened a criminal investigation with other authorities.
5. Minister Egelund briefed the Parliamentary Business and Digitalization Committee (Erhvervs- og Digitaliseringsudvalget) and commissioned the security review.
6. Officials said protective measures had started but withheld the technical details.
7. The Cyberhotline (+45 33 37 00 37) extended its hours to 8:00 AM through midnight to handle public inquiries.

The disclosure does not say when in September the access began, so the gap before detection on October 2 could be anywhere from days to several weeks. If it does run to weeks, that says a lot about how third-party access to the CPR is monitored. In a mature setup, a bulk extraction usually trips an alert within minutes or hours.

What data was exposed

Authorities have confirmed that full legal names, residential addresses and 10-digit CPR numbers were accessed.

People registered under name and address protection (navne- og adressebeskyttelse) got a partial answer. The security review found that their names and addresses were not part of the unauthorized access. Officials cautioned that this does not confirm every data field for protected individuals stayed untouched. Whether their CPR numbers or other metadata were accessed has not been confirmed.

Financial records, medical histories, tax filings, employment data and authentication credentials are not on the confirmed exposure list, and the CPR does not store them. The CPR number is the lookup key for all of those systems, though, so having a valid one makes it much easier to target a person in downstream services.

The phishing and social engineering risk

For the 8.8 million affected people, the most immediate danger is targeted social engineering. With a victim’s full name, exact address and national ID number, an attacker can write phishing emails, SMS messages and voice calls that are hard to tell from the real thing.

A caller claiming to be from SKAT or the benefits agency Udbetaling Danmark can quote the victim’s CPR number and address to build trust, then ask for bank credentials or MitID codes. Fraudsters can contact banks with a stolen identity triple to attempt account takeovers, loan applications or credit line increases. Phishing emails that cite the victim’s CPR number can send people to fake Borger.dk or bank login pages built to capture MitID credentials. Combined with data from other breaches, the exposed records can also feed synthetic identities used for money mule accounts, fraudulent business registrations or benefits fraud.

Danish authorities say residents must not share passwords, authentication codes or confidential information in response to unsolicited calls, emails or texts, even when the sender knows their name, address or CPR number. Reciting personal data does not prove a caller is legitimate. Guidance is available at Sikkerdigital.dk and through the Cyberhotline at +45 33 37 00 37.

GDPR obligations and enforcement

The breach triggers several obligations under GDPR, which Denmark implements through Databeskyttelsesloven.

Under Article 33, the data controller, here the CPR administration under the Ministry of the Interior and Housing, must notify the supervisory authority, Datatilsynet, within 72 hours of becoming aware of the breach. Detection on October 2 and the weekend investigation suggest that window was met, but the exact timing has not been confirmed publicly.

Article 34 requires notifying affected individuals when a breach is likely to create a high risk to their rights and freedoms. CPR numbers cannot be changed or reissued like a credit card number, so that threshold is clearly met. Individual notifications are expected, but reaching 8.8 million people, including those living abroad and the estates of the deceased, is a large operational job.

The private company also faces possible liability. GDPR’s Articles 28 to 32 require processors to apply appropriate technical and organizational measures. If the investigation shows the company failed to secure its credentials, skipped anomaly detection or let its use of access drift beyond its Section 38 authorization, fines of up to €20 million or 4% of annual global turnover could apply.

Why identity registries share this problem

Estonia’s X-Road, Sweden’s BankID, Finland’s Suomi.fi and Norway’s ID-porten all carry the same tension. Third-party access to centralized identity data is operationally necessary, and any single compromised access point can expose the whole population.

The CPR is especially exposed because of its age and design. It was conceived in 1968 as a centralized registry with batch-oriented access and has been adapted step by step for real-time APIs, third-party integrations and digital services. Each layer adds attack surface. Section 38 was written for a time when access meant a printed extract from a municipal office, and it now governs programmatic access that can return millions of records in an automated query.

The legal frameworks that grant access are detailed and well documented. The monitoring that checks how that access is used tends to be underfunded and reactive. Whether that holds for the CPR is something the security review should answer.

What remains unknown

• Attribution. No state, criminal group or other actor has been named, and authorities have not said whether they suspect espionage, organized cybercrime, hacktivism or something else.
• The company. It has not been named, and it is undetermined whether it was itself a victim of credential theft or an infrastructure compromise, or whether an insider helped.
• The entry method. Stolen API tokens, compromised service accounts, an authentication flaw and session replay are all unconfirmed.
• Exfiltration. Access is confirmed, but authorities have not said whether the data was copied to external infrastructure, saved locally or only viewed. The difference matters legally and practically.
• Duration. The breach is confirmed for September 2026, with no start or end dates. It could have been one bulk extraction or sustained access over days or weeks.
• Affected fields. Names, addresses and CPR numbers are confirmed. Investigators have not ruled out other metadata such as municipality codes or registration timestamps, and the birth date is encoded in the CPR number itself.

Technical analysis: authorized access abuse

Misuse of legitimate credentials is one of the hardest threat categories to detect, because at the protocol level the access looks legitimate. An SQL injection or a zero-day leaves traces that look wrong. Abused credentials generate log entries that look structurally identical to normal queries, so detection depends on behavioral analytics: query volume baselines, time-of-day patterns, sequential versus randomized access and anomaly scoring against history.

The scale points to automated extraction. A person working through a legitimate interface could not realistically pull millions of records in one session without hitting volume-based rate limits, assuming such limits exist. The lack of an alert until October 2 suggests one of three things: volume monitoring was absent, its thresholds were too high to catch this, or the access was throttled to stay under detection limits over a longer period. That is my inference. Authorities have not said which.

For anyone running a similar registry, five practices follow from this incident:

1. Apply zero trust to all third-party access. Every query gets authenticated, scoped, logged and checked against behavior in real time, whatever the caller’s authorization status.
2. Enforce least privilege at the API layer. Section 38-style access should be constrained technically, at the database and gateway, to return only the records and fields authorized, and not merely governed by contracts and law.
3. Write audit logs to tamper-evident storage with enough granularity to reconstruct the full scope of unauthorized activity.
4. Run automated anomaly detection, such as user and entity behavior analytics (UEBA), on third-party access, with alerts on deviations from baseline within minutes.
5. Re-certify third-party access rights on a schedule, and revoke automatically for entities that have not used their access within a set window.

What affected people should do

Danish residents, former residents and the estates of deceased people registered in Denmark should take these steps:

• Treat any unsolicited call, email, SMS or letter that cites your CPR number, name or address and asks for more information, credentials or financial details with suspicion.
• Do not click links in unexpected messages, even ones that appear to come from SKAT, your bank or Borger.dk. Type the official URL yourself.
• Watch your financial accounts for unauthorized transactions, new credit inquiries and account openings you did not make. You can request a credit report from RKI (Ribers Kredit Information) or Experian Denmark.
• Turn on multi-factor authentication for every service tied to your CPR number, especially MitID, banking apps and Borger.dk.
• Report suspicious activity right away to your bank, Datatilsynet or the Cyberhotline at +45 33 37 00 37.
• Register for name and address protection through your municipality (kommune) if you have not already, particularly if you are in a vulnerable situation.
• Follow official channels: Sikkerdigital.dk, the Ministry of the Interior and Housing’s website and verified government social media accounts. Unofficial sources may amplify misinformation or exploit public anxiety for more phishing.

The political and institutional response

Minister Egelund briefed the Business and Digitalization Committee and commissioned a full review, so the government is treating the incident as a top-level matter. The review is expected to cover the technical controls around CPR access and whether the Section 38 framework still fits an era of programmatic data access.

Datatilsynet’s involvement opens the door to formal enforcement: administrative fines, binding orders to fix specific security deficiencies or, in the most severe case, temporary limits on certain categories of CPR data processing until security improves.

Opposition parties have called for a public inquiry and for the government to name the private company, arguing that transparency is needed to keep public trust. The government has declined so far, citing the integrity of the police investigation.

What happens next

The investigation is at an early stage. Danish police, working with the Danish Security and Intelligence Service (PET) and possibly Europol, will try to attribute the attack, identify those responsible and find out whether the data has been distributed, sold on darknet marketplaces or used in downstream fraud.

The CPR security review will likely recommend changes to the technical architecture (API gateway hardening, rate limiting, behavioral monitoring), to governance (third-party access lifecycle management, incident response playbooks) and possibly to the law (tighter Section 38 requirements, mandatory breach disclosure timelines for private-sector data processors).

For the 8.8 million people affected, their CPR numbers, names and addresses should now be treated as permanently compromised. A CPR number is assigned at birth or on registration and cannot be rotated like a password, so the baseline social engineering risk for each of them stays higher for the rest of their lives.

This is a developing story. Updates will be published as Danish authorities release more findings.