Nobody broke into Denmark's national population register. Someone used a key the system had already handed out.
In early October, the Danish Ministry of Research, Education and Digitalisation disclosed that the names, addresses, and personal identity numbers (CPR numbers) of about 8.8 million people had been pulled from the Central Person Register. According to BleepingComputer, threat actors misused the legitimate access of a private Danish company. The register holds about 11 million records, so the exposure reached roughly 80% of them.
The incident is still under investigation, and some details are provisional. But the pattern is already clear, and it is one every organization with a data-sharing arrangement should recognize. The real lesson is not about a perimeter that failed. It is about what happens when access that is valid, but far too broad, is the only control standing between a requester and the data.
What Happened
Based on public reporting, the facts so far are these:
- Access route: A small Danish company used its lawful access to the register under the Civil Registration System Act, according to The Next Web. The ministry has not named the company, and how the company itself was compromised is unknown.
- Method: BleepingComputer reports that the Danish Data Protection Agency described the attack as brute-forcing to enumerate valid CPR numbers, then extracting the related data from each entry.
- Volume: The Next Web reports that the company's account made well over 14 million lookup attempts over ten days in September, and about 8.8 million returned a record.
- Discovery: Companies pay per lookup, and The Next Web reports that an unusually large invoice on Friday, October 2 revealed the activity. The ministry announced the breach on Monday, October 5.
- Data exposed: Names, addresses, and CPR numbers. People with name and address protection were reportedly not affected.
- Response: The company's access was cut off, police opened an investigation, and Minister Christina Egelund ordered a security review of the system.
No one has been charged, and the ministry has said little about the technical details. We will not speculate beyond what has been reported.
Valid Credentials Are Not the Same as Valid Use
Most breach coverage centers on an intrusion: a vulnerability, a stolen password, a misconfigured server. This one is different. By the reported account, the register did what it was designed to do. An authorized account asked for records, and the system returned them.
That is a hard category of failure to catch, because every individual request looks legitimate. The credentials were real. The company was entitled to look up some records. What nobody appears to have bounded was the shape of the use: how many lookups, how fast, and how much of the register one party could walk through in ten days.
Seen this way, the discovery detail is telling. Reportedly, the signal that surfaced the problem was a billing anomaly, not a security alert. The monitoring that mattered was the one designed to charge for the service. Security teams should ask whether their own access logs would have noticed first.
An Identifier Is Not a Password
The second lesson sits in how the data is used elsewhere. After the disclosure, Laila Reenberg of Denmark's civil security agency told companies and authorities to stop accepting a CPR number alone as proof of identity. As reported by The Next Web, she said: "You cannot use it to authorise things, to buy something or to get sensitive personal information."
Many organizations treat a national identifier the same way, as a fact about a person that doubles as a secret. In the United States, the Social Security number plays a similar role. Once identifiers like these are exposed in bulk, anything that relies on them for authentication is weakened at once, and the exposure cannot be recalled.
This is why the data itself matters. An identifier that can be enumerated, copied, and sold will outlive any single incident. We covered a related problem in The Sensitive Data Supply Chain: every copy of sensitive data is another place for it to leak, and every authorized recipient is part of that chain.
Shared Access Is Part of Your Attack Surface
Registers, data brokers, partner portals, APIs, and shared analytics environments all follow the same model. A trusted third party gets credentials, and those credentials get a defined scope. In practice the scope is often defined by what the interface can do, not by what the partner needs.
The Danish case shows the cost of that gap. A single account could, in principle, retrieve a large share of an entire national register. Whether the right limits were in place, and why they did not stop this activity, is what the ministry's review is meant to answer. Any organization that shares data with outside parties can ask the same question about its own arrangements.
Five Questions to Ask About Third-Party Access
Use these as a starting point for reviewing any partner, vendor, or customer who can query your sensitive data:
- What is the intended volume? Define a normal pattern of use for each external account, then enforce limits on lookups per minute, per day, and in total.
- Can one account enumerate your data? If valid identifiers can be guessed or iterated, rate limits and anomaly detection are not optional.
- What does a lookup return? Return the minimum fields needed for the purpose. Masked or tokenized values are often enough for a business process that only needs to match a record.
- Who is watching usage, not just logins? Alert on behavior: unusual volume, sequential access, and activity at odd hours. Do not rely on the invoice to tell you.
- Can you revoke quickly? Know how fast you can cut off one partner without taking down every other one. In Denmark, the company's access was cut off only after the activity was noticed, following ten days of lookups.
What Data-Centric Protection Changes
Access controls at the door are necessary. They are not sufficient, because a request that passes the door check receives the data as is. Data-centric security adds protection that travels with the data and is evaluated per request, per user, and per field.
In practice, that means sensitive values are encrypted or tokenized at the data layer. Decryption is a policy decision tied to identity and purpose, not a side effect of having a valid connection. A partner that only needs to confirm a record exists can be given a token. A partner that needs a name can be given a name, and nothing else. When behavior drifts from the expected pattern, the policy and the logs are positioned to notice, because every decryption is an event, not just every login.
This does not make breaches impossible. It changes what a misused credential is worth. For related thinking on limiting what each requester can see, read our piece on the zero-trust mindset for data protection.
OnData's Take
The Danish register breach is a reminder that authorized does not mean appropriate. An organization can do everything right at the front door and still lose data to a trusted party whose access was too broad, whose credentials were misused, or whose own defenses failed. The question is not only who can get in. It is what they can read once they do.
OnData SecureDB protects sensitive data at the database layer with runtime encryption and identity-based access control, so a connection alone does not mean readable values. For files that move between partners, OnData SecureFile keeps encryption and access policy attached to the file wherever it travels. And where data feeds analytics or generative AI, OnData SecureAI applies de-identification, masking, and need-to-know access so each user, application, or agent sees only what it is authorized to know.
A key that opens every door is a liability, however trusted its holder.
To see how this works in your environment, you can book a demo.
