Blog
Trusted access, untrusted volume: the Danish CPR register incident
A cyberattack on CEVA Logistics exposed how a single compromise at a shared service provider can trigger security, regulatory and reputational consequences for multiple organisations. While the affected companies were not themselves breached, the incident demonstrates how third-party cyber risk and supplier concentration can create widespread exposure. This blog explores the lessons security teams should take from the incident, from managing vendor dependencies and protecting customer data to strengthening resilience against supply chain attacks.
Jump to:
- An abuse of legitimate access, not a break-in
- Why the downstream risk is lasting
- Third parties as an extension of the register
- What security teams should prioritise as a result
- Where intelligence becomes practical
Danish authorities disclosed on 5 October that unauthorised parties obtained names, addresses and CPR numbers for roughly 8.8 million people, including residents, deceased persons and citizens who have moved abroad. The register holds about 11 million records, meaning that the exposure covers around 80% of it.
According to the Ministry of Research, Education and Digitalisation, the CPR administration first noticed irregular activity from September on the evening of 2 October. The activity was not detected by security monitoring, but during invoicing, when an unusually large bill drew attention to the volume of lookups; private companies are charged for each search. The administration confirmed the scale of the activity over the weekend and notified the Danish Data Protection Agency (Datatilsynet) on 4 October. Police are investigating, and no suspect has yet been named.
Considering that the CPR number is the backbone of Danish public and private administration, from tax and healthcare to banking, exposure at this scale affects an entire national identity system, not a single organisation.
An abuse of legitimate access, not a break-in
The ministry states that the attackers misused a private Danish company’s legitimate access to search the register and that they stayed within the data categories private companies are permitted to retrieve. However, legitimate access is not unrestricted access: under the CPR Act, a company may only retrieve information about a defined group of people with whom it has a lawful connection. It is difficult to see how a small private company could have such a relationship with 8.8 million registered people, including people who have died or moved abroad. Persons with name and address protection were not affected.
Datatilsynet adds a detail that most coverage omits: the notification it received describes a very large number of automated lookups against the CPR system, aimed at identifying valid CPR numbers. Available evidence therefore suggests enumeration through a trusted interface, rather than exploitation of a flaw in the register itself.
Several things remain unconfirmed: the company has not been named; it is not public whether the access was misused through compromised credentials, API keys, a compromised environment or an insider; the ministry also describes the data as names, addresses and CPR numbers “among others” and warns that figures may change as the mapping continues.
Under the CPR Act, private companies are supposed to receive data about a limited circle of individually pre-identified persons. Automated discovery of valid numbers is therefore a fundamentally different activity, and the open question for the security review is why volume at this level, over a period of weeks, was not constrained or flagged.
More recent reporting has added a significant detail: the abused user account reportedly had the password “123456” and was not protected by multi-factor authentication. If confirmed, this points to a basic access-control failure rather than a sophisticated initial compromise. It also reinforces a broader lesson from our own investigations, in which stolen or weak credentials remain by far the most frequently observed initial access vector. Privileged accounts, service accounts and API access to bulk lookup interfaces should require strong, unique credentials and MFA as a minimum.
Why the downstream risk is lasting
A CPR number is intended to be persistent, but it can be changed in limited circumstances, including legal gender recognition and documented identity misuse. That does not make replacement a practical response at population scale. Once name, address and number are paired for most of a population, they become a durable resource for fraud and social engineering. The ministry’s own warning – that callers who know your name, address and CPR number should still not receive confidential information – shows where the concern lies.
Any organisation that accepts these three data points as proof of identity now has a weaker control. Helpdesk resets, call-centre verification and account recovery flows deserve immediate review. Records of deceased and emigrated persons may also be less likely to be noticed or contested by the individuals concerned. That is a reasonable concern for fraud teams, though not something the sources confirm.
This is not the first time Danish CPR numbers have been exposed. Earlier incidents included a supplier-operated tax portal that leaked around 1.26 million numbers to analytics providers over several years. The mechanisms differ, but the pattern holds: every exposure of a persistent identifier adds to what attackers can correlate.
Conscia ThreatInsights
The only threat intelligence newsletter that focuses primarily on Europe According to Forrester, European organisations face several different cybersecurity threats compared to their global counterpar…
Third parties as an extension of the register
Companies with legitimate access to national registries are part of those registries’ attack surface. The register operator controlled the data, but the misused access sat with a third party. Datatilsynet is examining who is responsible for the processing, and the answer will matter for GDPR security obligations. Organisations in scope of NIS2 should read this as a practical example of supply chain risk management, where the supplier relationship is itself the exposure.
What security teams should prioritise as a result
- Start with identity verification
- Stop treating name, address and CPR number as a sufficient knowledge factor
- Add step-up checks for sensitive requests handled by phone or email
- Prepare staff and customer communications for a period of elevated phishing and vishing that uses accurate personal details.
Then look at your own bulk access to external registries, partner APIs and data services. Credentials for these interfaces should be tightly scoped, rotated, restricted by source and monitored for volume and query patterns. A service account that can retrieve ten thousand records but should normally retrieve ten is a detection opportunity.
Finally, ask the same questions of your suppliers – which of them hold lookup rights over data you are responsible for, and who would notice if those rights were abused?
Where intelligence becomes practical
Credential leak detection can provide early warning when usernames, passwords, API keys or session tokens associated with an organisation or its suppliers appear in criminal sources. Cyber Threat Intelligence can track whether this dataset surfaces for sale or is claimed by an actor, separating verified material from recycled or inflated claims. MDR teams can correlate unusual query volumes with authentication, endpoint and cloud telemetry to distinguish misuse of access from normal operations, while Offensive Security can test whether rate limits, anomaly alerts and verification workflows hold up under realistic abuse.
Report: Cyber Resilience Insights 2026
Move beyond headline threat trends. Cyber Resilience Insights 2026 connects our own European SOC and MDR data, forensic investigation, offensive security testing and global threat research to show whi…
About the author
David Kasabji
Head of Threat Intelligence, Conscia Cyber & AI Security
David Kasabji is the Head of Threat Intelligence at the Conscia Group. He leads the development and delivery of actionable intelligence across cyber defense and managed security operations, translating complex threat activity into clear outcomes for different audiences — from SOC analysts and incident responders to executive stakeholders and external communications. His work spans end-to-end intelligence operations: collection and analysis of adversary activity, threat actor and campaign profiling, IOC and TTP development, and intelligence-driven guidance for detection, threat hunting, and security prioritization. David is also actively involved in Digital Forensics and Incident Response, supporting investigations and crisis situations with rapid triage, context, and strategic recommendations. A strong focus of his role is continuously improving how intelligence is operationalized through standardization and automation to ensure it is timely, relevant, and measurable.nd strategic crisis management during incidents.
Related
