Skip to content
HACKTECH
BreachesReported Published 5 sources

Denmark's CPR register: data on about 8.8 million people accessed via a company account

Denmark's Ministry of Research, Education and Digitalisation said on 5 October 2026 that names, addresses and CPR numbers of about 8.8 million registered people in the Central Population Register (CPR) had been accessed without authorisation. Someone misused a private Danish company's lawful access to search the register, and the ministry said the irregular activity took place during September 2026. The CPR administration noticed it on the evening of 2 October, blocked the company's access and reported the case to the Danish Data Protection Agency (Datatilsynet), and police are investigating.

  • Denmark
  • government
  • national ID numbers
  • third-party access
  • API abuse
  • enumeration
  • GDPR

What the sources report

  • The ministry said about 8.8 million registered people were affected, including living, emigrated and deceased persons, out of about 11 million people registered in CPR; the names and addresses of people with name and address protection were not included.
  • Datatilsynet said it received the report from the CPR register on Sunday 4 October and that, according to the report, a very large number of automated lookups were made against the CPR system to identify valid CPR numbers.
  • The Next Web, citing TV 2, reported that the company's account made well over 14 million lookup attempts over ten days in September, of which 8.8 million returned a record, and that the breach came to light when the CPR administration billed the firm, since companies pay for every lookup.
  • Minister Christina Egelund called it a deeply serious incident, said she had informed the Danish Parliament's Business and Digitalisation Committee and asked for a thorough security review of the CPR system.
  • The ministry said it was not yet possible to say who was behind the access; BleepingComputer said it had contacted the agency for more details but had not received a response by publication.
  • Citizens were told never to give out passwords or other confidential information by phone, email or similar channels, even if the person contacting them appears to know their name, address and CPR number.

What it means for your organisation

According to the ministry, the register was reached through a private company's lawful, paid lookup access rather than a direct intrusion, and according to The Next Web the activity came to light through billing rather than a security alert. Organisations that expose search or lookup interfaces to partners should treat partner credentials as part of their own attack surface, with per-client volume limits and real-time anomaly detection. The case also undermines the practice of accepting a national identity number as proof of identity in call centres, password resets and onboarding.

What we check

  • Review partner and B2B API access for per-client rate limits, quotas and real-time alerts on query volume, rather than relying on billing or monthly reports.
  • Test lookup and search endpoints for enumeration, including whether responses reveal which identifiers are valid.
  • Assess how partner credentials are issued and protected (MFA, IP allowlisting, client certificates) and whether misuse of a valid partner account would be detected.
  • Check whether national ID numbers or similar quasi-public identifiers are accepted as an authentication factor in support, account recovery or onboarding processes.
  • Confirm per-partner audit logging and retention are sufficient to scope an incident and support a regulator notification.

Sources

Services that cover these checks

  • Application security audit

    A white-box review of your application: source code, architecture, dependencies and build pipeline. Automated analysis finds the candidates; reviewers confirm each one by reading the code path, and only confirmed defects reach the report, each with a file and line reference.

    Duration: 5 to 15 working days, depending on codebase size

  • Web application testing

    Authenticated, role-aware testing of your application and its API surface, with an account for every role. We chain small findings into the access they lead to, such as a sequential invoice ID and a missing tenant check that together let one customer read another's invoices.

    Duration: 5 to 10 working days

  • Database security audit

    A configuration and access review of your production databases: who can connect, from where and with which privileges, whether data is encrypted at rest and in transit, what is logged, and whether backups would survive the same attacker. We read each instance's live configuration.

    Duration: 3 to 7 working days

  • Threat modelling

    Facilitated workshops that map how a system or feature could be attacked before it is built or shipped. We draw the data flows with your engineers, walk them with STRIDE, rank the threats by likelihood and impact, and turn the result into backlog items and test cases your team owns.

    Duration: 2 to 5 days per system, remote or on site

  • Incident response

    Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow incident response works