Denmark warned about CPR guessing. 14 years later, 8.8M exposed

Summary

Denmark woke up on Monday to a national identity-data crisis. Someone had abused a small private company's legitimate access to the Central Person Register, CPR, and gained unauthorized access to information linked to around 8.8 million people. The activity ran for around ten days in September before irregular behaviour was noticed on Friday, October 2.¹¹³

The number is larger than Denmark's entire living population. Statistics Denmark counted 6,032,304 residents in August. CPR contains around 11 million registered people because records remain for people who have died or moved abroad. The 8.8 million therefore include living, dead and emigrated people.¹³

That is already a remarkable breach.

But the history behind it is worse.

Fourteen years ago, the authority running CPR warned companies that their systems must not reveal whether a name and CPR number matched. In 2013, the Danish government said it was tightening the rules specifically to stop people from being able to guess citizens' CPR numbers.⁴⁵

In 2017, improved logging and monitoring became a formal CPR security objective, with SIEM explicitly mentioned. In 2024, Denmark's Data Protection Agency described a central CPR security log detailed enough to record timestamps, person numbers, user codes and the type of lookup performed. And in CPR's 2026 performance plan, the administration itself described SIEM as a way to detect, among other things, deviations in user behaviour.⁶⁷⁸

Then came September 2026.

The Data Protection Agency says a very large number of automated queries were made against CPR for the purpose of identifying valid CPR numbers.²

This is not evidence that Danish authorities knew this exact attack was coming. It is evidence that the underlying failure mode had been on the table for years.

The warning came in 2012

On May 30, 2012, CPR published a notice aimed at companies that had integrated CPR Direkte into websites for customer registration and similar services.

A case in the telecom sector had shown the problem. Repeated submissions could allow an outsider to learn whether a name and a valid person number belonged together.

CPR told companies that even the response returned to a user had to be designed carefully:

“Responses to entered data must be designed so they do not reveal the result of a validation against CPR.”

— CPR Administration, May 30, 2012. Translated from Danish.⁴

The security problem is simple. A database does not have to hand over a secret directly. If it answers yes or no often enough, the answer itself can become useful data.

Security engineers often call this an oracle: a system that helps an attacker test whether a guess is right.

CPR understood that problem in 2012.

A year later, Denmark said the guessing had to stop

By June 2013, the issue had reached the Danish government.

Then Minister for Economic Affairs and the Interior Margrethe Vestager announced stricter requirements for companies using CPR validation. The government's own headline said the change was intended to prevent citizens' CPR numbers from being guessed.

Vestager was unusually direct:

“It must be the end of the possibility of ‘guessing’ citizens' CPR numbers.”

— Margrethe Vestager, June 28, 2013. Translated from Danish.⁵

The ministry described websites where an outsider could enter another person's name and try different number combinations until a system confirmed the correct one. Companies were ordered to change their systems so that possibility could be excluded.⁵

Now jump forward fourteen years.

On October 5, 2026, the Danish Data Protection Agency described the new incident this way:

“A very large number of automated queries” were made to identify valid CPR numbers.

— Danish Data Protection Agency, October 5, 2026.²

The 2012-2013 cases and the 2026 incident are not proven to involve the same interface, software or weakness. The earlier warnings concerned how companies exposed CPR validation through their own services. Authorities have not yet disclosed which CPR product was abused this time.

But the class of problem is strikingly familiar: a legitimate CPR relationship is used to establish whether identity numbers are valid.

What happened in September

The known facts are still limited.

A smaller Danish company had lawful access to search CPR. Someone abused that access for around ten days in September. On Friday evening, October 2, the CPR administration noticed irregular behaviour. Over the weekend, authorities established that the incident involved information linked to around 8.8 million registered people.¹¹³

The company has not been named. Authorities have not said whether credentials were stolen, whether a server at the company was compromised, whether an insider was involved or whether another route was used.

Police are investigating. Denmark's National Unit for Special Crime, NSK, told DR that it expects the case to involve a major data extraction, but how much data was actually removed rather than merely made accessible remains under investigation.¹³

The Data Protection Agency has provided the clearest technical description so far: automated lookups were being used to identify valid CPR numbers.²

That makes the volume particularly important.

More identities than people living in Denmark

Denmark had 6,032,304 residents in August 2026.³

The CPR register contains around 11 million people. It does not delete a person because they die or move abroad; the register includes people who have lived in Denmark since the national CPR system was established in 1968, along with later registrations.¹¹³

The incident therefore reached information connected to roughly 80 percent of the entire CPR population.

Eight point eight million is also about 46 percent more identities than the number of people currently living in Denmark.

Authorities have not published the total number of queries. And 8.8 million affected people does not necessarily mean 8.8 million requests.

If candidate CPR numbers were being tested to find out which were valid, failed attempts would come on top of successful ones.

Even using 8.8 million simply as a measure of scale, spread across ten days it is around 880,000 successful identities a day, about 37,000 an hour, or just over ten a second if the activity were continuous.

Ten requests a second is not a technical challenge for a modern service.

One private customer behaving as if it were working through a national population register is a very different matter.

Cybersecurity professor Jens Myrup Pedersen at Aarhus University told DR that CPR should have mechanisms that trigger alarms or blocks when an unusual number of lookups is made. He described the incident as probably the largest security breach the Danish CPR register has seen.¹³

CPR's current documentation shows why validation needs limits

Authorities have not said which CPR service was used in the incident. There are several ways for approved customers to obtain data, including web access, system-to-system services and Datafordeler APIs.⁹

So there is no basis for saying that CPR Direkte was the attack path.

But the current documentation for CPR Direkte PRIV, a system-to-system service for private companies, shows why repeated validation needs strong behavioural controls.

The service accepts a ten-digit CPR number as input. It can be called with DATA_TYPE=0, meaning no person data is requested. The service still returns a result code. One documented error is 05: PNR ukendt i CPR — person number unknown in CPR.⁹

In other words, the documented service can tell an authorized client whether a submitted CPR number exists even when the client asks for no person data back.

That is a legitimate function for a legitimate customer that already knows who it is dealing with.

At scale, it can also become a validation oracle.

Again, there is no evidence yet that this was the service abused in September. But the mechanism is relevant because it closely matches the Data Protection Agency's description of automated lookups being used to identify valid numbers.

The perimeter controls are real — but trust can still be abused

CPR's current documentation shows that CPR Direkte is not an open endpoint.

The service uses IP whitelisting per customer and per product. Address ranges are not accepted, and customers are normally limited to five individual source IP addresses. Connections are also subject to geographic restrictions.¹⁰

CPR Direkte currently authenticates with a customer number, an eight-character user ID and a password. CPR's password documentation says passwords for CPR Direkte must be exactly eight characters and expire after 90 days. Successful authentication returns a token used for subsequent lookups.⁹

None of that tells us how the September access was obtained.

If CPR Direkte was involved, an attacker may have needed more than a password. The traffic may have come through infrastructure CPR already trusted. Or CPR Direkte may have had nothing to do with the incident at all.

What the documentation does show is an architecture built to decide who is allowed through the door.

The September incident raises the next question: what happened after an approved customer was through it?

I found detailed public documentation for authentication, tokens, IP restrictions, error codes and customer permissions. I did not find a published per-customer query ceiling or automatic volume cut-off for CPR Direkte.

That does not prove such controls do not exist internally. CPR may have controls that are not documented publicly.

But whatever controls applied to the service used in September did not stop the activity before it reached national scale.

CPR was not short of logs

The obvious defence would be that CPR could not see what a customer was doing in enough detail.

The public record says otherwise.

In a 2024 decision, the Danish Data Protection Agency described CPR's central security log. It records the date and time of searches and lookups, the person number or numbers involved, the user code and the program or type of information used. The user code is assigned to a specific authority or company and can often be associated with the individual user.⁷

DR reported on Monday that CPR's IT manager had given similar evidence in an earlier criminal case involving abuse of lawful CPR access. According to that testimony, police can see the customer, a unique person ID and the commands performed in the security log.¹³

CPR was therefore collecting the raw information needed to reconstruct unusual behaviour.

The harder question is whether anyone — or anything — was analysing it quickly enough to stop it.

A forensic log is invaluable after an incident.

It is not the same as an alarm during one.

Monitoring had been an official goal since 2017

That question has its own history.

In CPR's 2017 performance plan, one of the formal objectives was improved logging and monitoring of the IT environment. The plan referred to guidance from Denmark's Centre for Cyber Security and listed centralisation of logs, activation of logs and a risk-based approach among the measures. It also explicitly mentioned SIEM, or Security Information and Event Management.⁶

Management was required to decide the desired level of logging and monitoring and whether SIEM should be used.⁶

This was nine years before the current incident.

The point is not that a line in a 2017 plan should somehow have stopped an attack in 2026.

It is that monitoring abnormal activity in CPR was already recognised as a cybersecurity problem at management level.

In 2026, CPR wrote about detecting deviations in user behaviour

Then comes the document that is hardest to read without thinking about what happened a few months later.

CPR's performance plan for 2026 opens with a project to make better use of CPR log data.

Authorities and companies can already generate logs concerning their employees' searches, lookups and updates in CPR. The new product is intended to let customers receive those log records as batch files and load them into local SIEM systems for automated analysis.⁸

CPR explains what SIEM can detect:

“deviations in user behaviour”

— CPR Administration, Resultatplan 2026.⁸

The project is aimed at customers' local SIEM systems. It is not evidence that CPR itself lacked central monitoring, and it is not evidence that this product would have stopped the September incident.

But it tells us something important about the threat model.

Before this breach, CPR itself had already written down that unusual user behaviour was something automated security analysis should find.

A few months later, irregular behaviour through one private company's lawful access continued for around ten days before it was noticed.

CPR had also warned against the “transaction cannon”

There is another revealing line in CPR's earlier standard terms for private system-to-system customers.

The Danish wording says access must not be used as a “transaktionskanon” — literally a transaction cannon — without prior approval. The official English version calls it an online batch.¹¹

The same terms required customers to generate monthly transaction statistics for review by their security officer. They also required customers to record system-to-system searches against individual employees in their own systems, while CPR would normally see the system user code used by the customer's program.¹¹

New standard terms took effect on June 16, 2026, so the 2024 wording should not be assumed to be the exact contract governing the company involved in September.¹²

But the older wording proves that bulk-like use of an ordinary system-to-system connection was already a recognised control issue.

And it exposes a timing problem.

Monthly review is useful for audit.

An automated client can do an extraordinary amount of work in ten days.

The normal model is the other way around

Private access to CPR is not supposed to be a fishing expedition.

CPR's terms describe private companies as receiving information about a defined group of people they have identified in advance and individually.¹¹

The expected flow is straightforward: the company knows the person, then asks CPR for information it is permitted to receive about that person.

The Data Protection Agency's description of the September activity turns that logic around.

Automated requests were being used to establish which CPR numbers were valid.²

The lookup had become part of the discovery process.

That is why the 2012 warning matters so much.

CPR had already identified the danger of a validation result revealing whether a guess was correct.

The breach is already weakening identity checks outside CPR

A CPR number does not give someone access to a Danish bank account or MitID by itself. Denmark's government has stressed that systems requiring MitID are not compromised by this incident.¹³

But identity fraud does not always begin by breaking cryptography.

It often begins with a convincing phone call, email or support request.

On Monday, Danish Industry warned that many companies have used CPR number, name and address as evidence of identity. It now says those details are no longer sufficient and has urged businesses to use stronger verification such as MitID.¹³

Municipalities have already tightened procedures. Herning says a CPR number must not, for the time being, be used as the sole basis for identifying a citizen.¹⁵

Denmark's official Sikker Digital guidance warns citizens about messages, calls and emails where the sender uses personal information to appear credible. It also advises people who suspect misuse to consider a credit warning in CPR.¹⁴

This may be the longest-lasting consequence of the incident.

The register itself can be secured again. Credentials can be revoked. Limits can be changed.

But once millions of names, addresses and national identifiers must be treated as potentially known to criminals, every organisation that has used those facts as a weak form of authentication has to adjust.

An identifier can be unique without being secret.

Denmark is even discussing new CPR numbers

The incident is serious enough that Digitalisation Minister Christina Egelund has not ruled out the possibility that some citizens may eventually need new CPR numbers. She has ordered a security review of the entire CPR system.¹³

Changing millions of national identity numbers would be extraordinary.

It would also not solve the wider problem on its own.

If a help desk, lender or other service treats knowledge of a CPR number as proof of identity, replacing the number changes the secret without fixing the assumption that made it a secret in the first place.

One unanswered question concerns protected citizens

The government's incident notice says the unauthorized access did not include the protected names and addresses of people registered with name and address protection.¹

It does not say those people were completely outside the incident.

Current CPR Direkte documentation shows that protected name and address fields can be withheld while a CPR number is still used as the input to a lookup.⁹

Given the Data Protection Agency's statement that automated queries were used to identify valid CPR numbers, authorities should clarify whether protected citizens' numbers could still be validated even when their names and addresses were suppressed.

There is no public answer yet.

Fourteen years of warning signs

The timeline is difficult to dismiss as hindsight.

In 2012, CPR warned that a validation response must not reveal whether a name and CPR number match.

In 2013, the Danish government said the ability to guess citizens' CPR numbers had to end.

In 2017, better logging and monitoring — with SIEM explicitly on the table — became a formal CPR security objective.

In 2024, public records showed that CPR's central security log already recorded individual queries, timestamps, person numbers, users and the type of operation performed.

In the 2026 performance plan, CPR described automated SIEM analysis as a way of detecting deviations in user behaviour.

Then, in September, a small private company's lawful access was abused for around ten days. Automated queries were used to identify valid CPR numbers. By the time the incident came to light, information connected to around 8.8 million living, dead and emigrated people had been exposed to unauthorized access.

More identities than there are people living in Denmark today.

No public evidence shows that Danish authorities knew this particular attack was coming, or even that the same technical mechanism warned about in 2012 was used in 2026.

They did know the class of problem.

Fourteen years later, Denmark is now investigating what may be the largest security failure the CPR system has ever seen — while its own documents show that the warning signs had been there for years.

Sources

Tags Cybersecurity Privacy Trust