> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# Denmark's ID register spills more people's details than the country has residents
- URL: https://f4n6.co.uk/security-feed/denmarks-id-register-spills-more-peoples-details-than-the-country-has-residents/
- Published: 2026-10-06T12:38:33.000Z
- Updated: 2026-10-06T12:38:33.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

An unauthorized party used a private Danish company's lawful access to the Central Population Register (CPR) to read out names, addresses and personal identification numbers for approximately 8.8 million people, living and dead. The CPR administration detected irregular activity on 2 October 2026, established the scale over the following weekend, blocked the company's access, notified the Danish Data Protection Agency and handed the matter to police. The affected total exceeds Denmark's roughly 6 million residents because the register holds about 11 million records, including deceased persons and citizens who have moved abroad, plus more than 55,000 people in Greenland who hold CPR numbers. No CVSS score, CVE, CISA KEV entry or MITRE-attributed actor is associated with this item in the verified reference data, so this is a data-access and identity-assurance exposure rather than a software vulnerability. For EMEA financial services the exposure is indirect but concrete: CPR numbers are accepted as identity evidence in Danish onboarding, tax and banking processes, and any client relying on a CPR number as a sole identity factor now holds a credential that 8.8 million people's worth of it has been copied.

## 2\. Regulatory framing

| Article                                                                 | Trigger (the fact in this item)                                                                                                                                                                   | Practical impact                                                                                                                                                                     |
| ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| DORA Art. 28: ICT third-party risk — general principles                 | The breach occurred through a private company's legitimate access rights to a national register, not through a compromise of the register operator's own perimeter.                               | Firms that consume CPR data, directly or through a vendor, must treat register-access intermediaries as in-scope ICT third parties and confirm what access their own suppliers hold. |
| DORA Art. 30: key contractual provisions with ICT third-party providers | Access to CPR data is granted to eligible recipients under section 38(1) of the Danish Civil Registration System Act and the ministry's access terms, which is a contractual access relationship. | Where a Danish entity or supplier holds CPR lookup rights, the contract needs audit, revocation and incident-notification terms that match the access actually granted.              |
| NIS2 Art. 21(2)(d): supply chain security measures                      | The initial access vector was a supplier's legitimate credential set, which is a supply chain exposure rather than a perimeter one.                                                               | Entities in scope under NIS2 should verify which of their suppliers can query national identity registers and under what authorisation.                                              |

No DORA incident-reporting article is engaged for a firm that is not the register operator or the breached company. If a client is the unnamed Danish company, or processes CPR data downstream, DORA Art. 17, 18 and 19 and NIS2 Art. 23 apply to that client's own incident process, not to this advisory.

## 3\. Technical analysis & attack chain

The source material describes an access-abuse incident, not a malware intrusion. No exploited component, CVE, payload, persistence mechanism, command-and-control channel or lateral movement is reported. The confirmed sequence is short.

1. A private Danish company held legitimate, lawful access to the Central Population Register under section 38(1) of the Danish Civil Registration System Act, subject to the ministry's access terms.
2. An unauthorized party abused that access to query the register.
3. The queries returned names, addresses and personal identification numbers for approximately 8.8 million people.
4. The CPR administration became aware on the evening of Friday 2 October 2026 of irregular activity that had occurred during September.
5. Over the weekend of 3 to 4 October the administration established the scale of the exposure.
6. The administration blocked the unnamed company's access and began working with specialists and relevant authorities to establish what happened.
7. The Danish Data Protection Agency was notified and police opened an investigation.

The register holds approximately 11 million records, which is why the affected count exceeds Denmark's population of around 6 million. The ministry stated that names and addresses of persons who had registered for name and address protection were not exposed. The database also covers over 55,000 people living in Greenland who use CPR numbers for healthcare, tax services and banking.

The ministry described the company whose access was abused as "small." That is the only characterisation of the access holder in the source material, and it is a single-sourced statement from a government minister. The company is unnamed in every source reviewed. No source states how the unauthorized party obtained or used the company's access, whether the access was a credential theft, an insider action, an API or integration abuse, or a compromise of the company's own systems. That gap is the most important unknown in this item and it is not filled by any source provided.

Two public statements frame the identity-assurance problem. Danish cybersecurity specialist Jan Kaastrup told TV 2 that treating CPR numbers as secrets is a "broken" approach and argued a number alone should not be accepted as proof of identity. Digitization minister Christina Egelund said in a TV interview that it was too soon to say whether Denmark would issue all-new CPR numbers, one of the solutions proposed after the breach. Neither statement is a technical finding, and neither source establishes that CPR numbers have been used fraudulently.

Confidence caveats. The 8.8 million figure, the September activity window and the 2 October detection date come from the CPR administration's statement as reported. The 11 million record count, the 55,000 Greenland residents figure and the name-and-address-protection exclusion come from the ministry. The "small company" characterisation is the minister's. No source in this set is an independent forensic account, and no source describes the access mechanism. Treat the access path as unknown until the Danish authorities publish findings.

## 4\. Mitigation & containment

P1 within 24 hours

- If your firm holds CPR lookup rights, directly or through a Danish subsidiary or supplier, suspend non-essential queries and pull the access log for September and October 2026\. Look for query volumes, query patterns or source addresses that do not match the authorised use case.
- If you accept CPR numbers as identity evidence in onboarding, KYC refresh or payment authorisation, stop treating a CPR number as a sole identity factor. Pair it with a second factor that was not in the register, such as a document check, a liveness check or a channel the customer already controls.
- Escalate to your DORA incident process if you are the breached company or a direct processor of the exposed data. If you are downstream only, log the exposure and the control change rather than opening a major-incident report on the basis of this advisory alone.

P2 within 72 hours

- Inventory every supplier, integration and internal team that can query the CPR register, and confirm the legal basis and the access terms each one operates under. The breach turned on a lawful access grant, so the control that matters is who holds one.
- Review contracts with any supplier holding register access against DORA Art. 30 expectations: audit rights, revocation on demand, and a notification obligation with a defined clock.
- For Danish retail and commercial onboarding, add a retrospective review of accounts opened or verified in September and October 2026 where a CPR number was the primary identity evidence.

P3 within 7 days

- If your firm relies on CPR numbers as a customer identifier in downstream systems, assess what a copied identifier enables: account enumeration, social engineering pretexts, and impersonation at counterparties that still accept the number alone.
- Track the Danish authorities' findings on whether CPR numbers will be reissued. A reissue would force a data migration across any system that stores the number as a key, and that migration should be scoped before it is announced, not after.
- Confirm whether any of your Greenland-resident customers are affected. The register covers over 55,000 people in Greenland, and their CPR numbers are used for healthcare, tax and banking.

No vendor fix, patch or version pin applies to this item. There is no software vulnerability to remediate.

## 5\. Indicators of compromise

No indicators of compromise available in the source material. No hashes, domains, IP addresses, file paths, registry keys or command lines are reported by any source. The company whose access was abused is unnamed, and no source describes the access mechanism, the tooling used, or the query infrastructure.

The sources do describe observable behaviour at the register operator, which is worth monitoring in your own register-access logs if you hold lookup rights.

### Behavioural indicators

| behaviour                                                                                                 | where to observe                                                              | confidence                                                                                                                                    |
| --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| Register queries during September 2026 that do not match the authorised use case for the access holder    | CPR register access logs, or your own logs if you hold lookup rights          | Medium. The September activity window is reported from the CPR administration's statement; the query pattern is not described.                |
| Bulk or high-volume record retrieval inconsistent with a defined group of individually identified persons | Register access logs, API gateway logs for any register integration           | Medium. Access under section 38(1) is meant to concern a defined group identified in advance, so bulk retrieval is the deviation to look for. |
| Access from a source address or client that has not previously queried the register                       | Register access logs, authentication logs for the access holder's integration | Low. No source describes the access path, so this is a general control rather than a reported observation.                                    |

## 6\. Detection

Insufficient indicators to author detection rules.

The source material contains no distinctive strings, command-line flags, mutex names, scheduled-task or service names, file names or paths, registry keys, ransom-note text or hard-coded values. The only named artefacts are the register itself, the Danish statute and the ministry's access terms, none of which are threat artefacts. A rule built on those would detect reporting about the incident, not the incident.

If you hold CPR lookup rights, the detection that applies is a log-based volume and pattern rule over your own register queries, not a signature. Baseline the query volume and record-count per access holder, alert on deviations, and alert on any query from a client or address not previously seen for that holder. That rule has to be written against your own log schema and cannot be authored from this source set.

## 7\. Sources

- The Register, "Denmark's ID register spills more people's details than the country has residents", https://www.theregister.com/security/2026/10/06/denmarks-id-register-spills-more-peoples-details-than-the-country-has-residents/5301307, 6 October 2026.
- Help Net Security, "Data breach at Denmark's population register exposes 8.8 million people", https://www.helpnetsecurity.com/2026/10/06/denmark-central-population-register-cpr-data-breach/, 6 October 2026.
- The Hacker News, "Denmark Says Attackers Accessed CPR Data for 8.8 Million People via Company Account", https://thehackernews.com/2026/10/denmark-says-attackers-accessed-cpr.html, 5 October 2026.

The CPR administration's statement and the ministry's access terms are referenced as PDFs by The Register but were not retrieved for this advisory. Figures attributed to those documents here are as reported by The Register.

## 8\. Adverse Trace position

Adverse Trace assesses this as a high-impact identity-data exposure with no associated CVE, no CVSS score and no CISA KEV entry, because the access was lawful and the abuse was of the access grant rather than of a software flaw. The verified reference data resolved nothing for this item, so no severity score is quoted and none should be inferred from the reporting. The client impact for EMEA financial services is concentrated in Danish onboarding and identity verification: any process that accepts a CPR number as sufficient proof of identity is now operating against a credential set that has been copied at scale, and the number of affected records exceeds the resident population because the register retains deceased and emigrated persons. We treat the access mechanism as unknown. No source states how the unauthorized party obtained or used the company's access, the company is unnamed, and the "small company" characterisation is a single-sourced ministerial statement. We will not attribute this to any actor, and no MITRE ATT&CK profile is available in the verified data for this item. We will track the Danish Data Protection Agency and police findings, the ministry's decision on whether CPR numbers are reissued, and any published detail on the access path, and we will reissue this advisory if the access mechanism is established. Clients with Danish register access or CPR-dependent onboarding should treat the P1 items in section 4 as the immediate action set.

---

[Read the original source →](https://www.theregister.com/security/2026/10/06/denmarks-id-register-spills-more-peoples-details-than-the-country-has-residents/5301307?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*