Denmark’s CPR Breach: How ‘123456’ Exposed 8.8 Million Records and the Systemic Collapse of Third-Party Trust

Denmark’s Central Person Register (CPR), the digital backbone of Danish civic life, was breached through a third-party IT vendor whose administrator account was reportedly protected by the password “123456.” The intrusion ran for roughly 21 days in September 2026 and exposed the names, addresses, and CPR numbers of about 8.8 million people. The CPR number works as the master key to Danish identity.

Neither the vendor’s security team nor government cybersecurity monitors caught the breach. The accounting department did, after noticing an unusually high invoice. The incident points to failures in third-party risk management and privileged access governance, and to the belief that perimeter security alone protects critical national infrastructure.

What the CPR is and why it matters

Denmark’s Central Person Register, Det Centrale Personregister (CPR), is the identity infrastructure Danish society runs on. Established in 1968, it assigns every person with a registered connection to Denmark a unique 10-digit number, the CPR-nummer. That covers citizens, residents, the deceased, and people who have emigrated.

The number follows a Dane everywhere: the doctor’s office, the tax return, the bank account, university enrollment, a mobile phone contract. It is the gateway credential for healthcare, banking, taxation, education, and welfare services. Someone who holds a person’s CPR number, name, and address holds the master key to that person’s digital and civic identity.

The register contains about 11 million records, more than Denmark’s living population of roughly 6 million, because it also holds data on deceased persons and citizens who moved abroad. That depth made the breach worse. The compromised records cover the dead and the diaspora as well as current residents, a permanent exposure that notifying people to change a password cannot fix.

The breach timeline: a 21-day window of exposure

The intrusion unfolded slowly over nearly three weeks, and automated queries hammered the CPR registry without setting off any alarm at the vendor’s IT department.

According to documents obtained by Danish broadcaster TV 2, the attacker gained access to the CPR system on September 10, 2026, through a compromised account at Pays ApS, a small IT and data services company in Odense on the island of Funen. Between September 10 and September 20, the attacker ran about 14 million automated searches against the registry. The searches used the vendor’s legitimate access privileges to enumerate valid CPR numbers and extract the associated personal data.

The activity appears to have stopped around September 20, but the compromised access stayed available until October 2, when CPR administration detected the irregular activity. Automated monitoring did not catch it. A person in an accounting department looked at an invoice and noticed something was off.

Datatilsynet, the Danish Data Protection Authority, received formal notification on October 4. The government disclosed the breach publicly on October 5, confirming that about 8.8 million registered people had their names, addresses, and CPR numbers accessed without authorization.

The “123456” password

The detail that made this breach famous is the password. It has produced headlines and become a grim meme in cybersecurity circles.

Politiken reported that at least three Pays ApS accounts, including an administrator account, were protected by “123456.” The person claiming responsibility told Politiken they obtained a leaked password belonging to a former employee of the company, and that the password was indeed “123456.”

The gateway to the personal data of 8.8 million people was guarded by six sequential digits. There was no zero-day exploit and no subtle misconfiguration, only negligence so basic that it borders on the surreal. I find it hard to overstate how elementary this failure is.

Mikkel Leihardt, a department head at Denmark’s Ministry of Research, Education and Digitalisation, said at a press conference that a staff member found the breach after noticing unusually high charges for the company’s CPR registry searches. Each lookup through the CPR system carries a nominal fee, so millions of rapid lookups produce a large bill. Accounting flagged the anomaly and IT investigated, but by then the damage was done.

The attacker reportedly told Politiken they had no intention of selling or leaking the data. That claim has not been independently verified, and Danish authorities have not confirmed the total extraction figure. Either way, public trust in Denmark’s digital infrastructure has already been badly damaged.

Third-party access: the soft underbelly of national security

Danish government systems were not hacked directly. The attacker compromised a third-party vendor with legitimate, authorized access to the registry.

Pays ApS is a small IT firm, reportedly a two-person operation, that provides data validation, CPR cleansing, and record verification to businesses that need to check customer information against the national register. Private companies and associations in Denmark can get access to the CPR registry if they have a legitimate need, such as verifying customer addresses or identifying deceased individuals.

The access model is not unique to Denmark. Governments everywhere rely on third-party vendors for services that touch sensitive databases: identity verification companies, background check providers, credit reporting agencies, and other intermediaries. Each vendor adds attack surface, a pivot point to data that attackers could not reach directly.

This is a textbook supply chain risk. The CPR registry itself may have been well protected at the network perimeter, but the vendor’s credentials created a trusted path that bypassed those defenses. The attacker did not need to breach the government’s firewalls. They needed to breach a small company with weak credentials, and the government’s own access controls did the rest.

The question security leaders should be asking is what limits a vendor once it has authenticated. In the case of Pays ApS, the answer appears to be virtually nothing.

The AI dimension: automated exploitation at scale

The attacker also reportedly used AI. The person claiming responsibility told Politiken they wrote two programs to retrieve CPR information and store it externally. Ritzau, Denmark’s national news agency, reported the claim that an AI-generated program retrieved 8,749,975 CPR numbers. Two experts examined more than 40,000 lines of code and concluded it appeared to be AI-generated. Their assessment covered the code’s apparent origin, and nobody has independently confirmed the claimed retrieval total.

The program reportedly contained an error: it searched for people born in 1877 instead of 1977, so CPR numbers tied to the 1977 birth year are missing from the material the attacker shared with Politiken. The mistake is ironic, but it points to a trend. Attackers are using AI tools to automate reconnaissance and exploitation.

Brute-forcing a national registry used to take real skill, custom tooling, and careful operational security. Today, large language models and AI coding assistants can produce working attack scripts with little human oversight, and the barrier to entry has collapsed. An attacker no longer needs to understand network protocols or API rate limiting. They describe what they want and the AI writes the code.

In this case, AI-generated code let one person, or a small group, automate the extraction of millions of records over a few days without triggering rate limits or anomaly detection that should have been in place. The attacker reportedly told Politiken that any AI model released within the past year could have been used to get CPR numbers. Whether that is accurate or hyperbolic, it describes a reality security teams have to face: the tools of mass exploitation are becoming democratized.

The accounting department as the last line of defense

The vendor had no security operations center to find the breach. Government monitoring did not extend into the vendor’s internal systems, and no intrusion detection system appears to have been in place. The accounting department found it.

Each CPR lookup generates a charge, and fourteen million lookups generate a very large one. When the invoice arrived, someone in accounting thought the numbers did not make sense. That human intuition led to the discovery of one of the largest data breaches in Danish history.

I would not call this a feel-good story about accountants. It reflects badly on the security posture of both the vendor and the government. If a financial anomaly was the first sign of a serious breach, no effective technical control was detecting unauthorized access. The evidence points to no rate limiting, no anomaly detection, no behavioral analytics, and no alerting on unusual query volumes. The vendor’s access to the registry was trusted implicitly and monitored not at all.

Security professionals call the principle of multiple protective layers defense in depth: if one layer fails, another catches the threat. Here there was one password and, behind it, an open door.

Technical anatomy of the breach

The CPR lookup API

The CPR registry exposes an API that authorized vendors can query for information about registered individuals. It is built for legitimate business uses such as verifying a customer’s address, checking whether someone is deceased, or validating a CPR number against the register. Each query returns a structured response with the individual’s name, address, and CPR number.

A properly secured API like this would normally have five layers: multi-factor authentication for every account, particularly administrators; role-based access control that gives users the minimum access their job needs; strict rate limits per account; machine learning models that monitor query patterns and flag deviations from normal behavior; and audit logging detailed enough for forensic analysis. Based on the available evidence, none of these controls appear to have been effectively implemented in the Pays ApS environment.

The authentication failure

Beyond the weak password itself, the system let it exist. Modern authentication systems can enforce complexity requirements, check passwords against known-breach databases, and require periodic rotation. That at least three accounts, including an administrator account, used “123456” suggests no password policy was being enforced.

There was reportedly no two-factor authentication either. With 2FA, even a weak password would not have been enough, because the attacker would also have needed a second factor. Without it, a weak credential became a single point of failure.

The authorization failure

Once authenticated as the compromised account, the attacker inherited its permissions. The account apparently had broad query privileges, so the attacker could run millions of queries with no further authorization checks. There was no separation of duties, no least privilege, and no mechanism limiting the scope of data the account could reach.

The monitoring failure

The worst technical failure was missing monitoring. Fourteen million queries over roughly 10 days is about 1.4 million per day, or roughly 16 per second. That volume should have triggered automated alerts within minutes, not days.

The activity went undetected for 12 days after the last query and 21 days after initial access, which means no one was watching API activity in real time. The vendor’s systems were generating huge volumes of data about the breach, and nobody looked at it.

What happens to 8.8 million compromised identities

For the 8.8 million people whose data was accessed, the consequences start now and last. Names, addresses, and CPR numbers are exactly what someone needs to impersonate a person in Denmark, because the CPR number is used for everything from opening bank accounts to accessing healthcare to filing tax returns. A malicious actor could potentially open fraudulent bank accounts, apply for loans or credit, redirect mail, impersonate the victim in dealings with government agencies, or run targeted phishing that uses personal details to look credible.

The Danish Ministry of Research, Education and Digitalisation urged citizens to be wary of unsolicited contact, especially from anyone who knows their personal details. Citizens should never share passwords, MitID credentials, or one-time codes, even if the caller knows their name, address, and CPR number.

The government also directed affected people to sikkerdigital.dk, a national cybersecurity advisory site, and encouraged them to set up a credit warning on borger.dk. A credit warning is a marker in the CPR system telling companies to notify the holder before extending credit in their name.

These measures are reactive. They do not recover the data or fix the weaknesses that made the breach possible.

The systemic implications: why this is bigger than Denmark

The CPR breach is not an isolated incident. It reflects an over-reliance on third-party access to sensitive databases without matching security controls.

In the United States, a similar breach earlier this year exposed the driver’s licenses of more than 130 million people through IDCan.net, a third-party identity verification company based in Louisiana. The company stored scanned IDs from car rental agencies, and when its systems were breached, the data of millions, potentially including the Secretary of Defense, was exposed.

In the United Kingdom, government agencies have reportedly warned that they expect significant cyberattacks from AI-powered adversaries. In Australia, government systems have been targeted by autonomous AI agents attempting to exploit vulnerabilities. The FBI has acknowledged that employee information was compromised in previous breaches, with the data “floating around on the internet” even if not publicly released.

The pattern across these cases is the same. Governments and large organizations delegate access to sensitive systems to vendors that lack the security maturity to protect it. The vendors hold the keys to the kingdom but are not held to the same standards as the entities that own the data.

The problem is not new, but the scale and frequency of these breaches suggest it is getting worse, for four reasons. Economic pressure pushes organizations toward the cheapest vendor instead of the most secure one. In many jurisdictions, third-party vendors are not subject to the same data protection regulations as the data controllers themselves. Securing third-party access takes identity governance, access management, and monitoring that many small vendors lack. And organizations often assume that a vendor with legitimate access can be trusted, which leads to thin oversight.

The CPR case touches all four. Pays ApS was a small company with access to a critical national database. The government trusted that access without verifying that Pays ApS had the controls to protect it, and when the breach occurred, the accounting department raised the alarm instead of a security team.

The path forward: a security review

After the breach, Digitalisation Minister Christina Egelund ordered a comprehensive security review of the CPR system. It is expected to examine access controls for third-party vendors, the registry’s monitoring and alerting, and the overall CPR access model. The Danish Data Protection Agency has opened a formal investigation, and police are conducting a criminal inquiry. Pays ApS’s access to the registry has been terminated and the company’s website taken offline.

Those are actions taken after the fact. Whether Denmark and other governments will make the structural changes that prevent the next breach is uncertain. Incidents this large tend to bring public outrage, then promises of reform, then a gradual return to the status quo, because the pressure to cut costs and keep workflows running usually overrides the push to invest in security.

The CPR is the identity infrastructure of an entire nation, and a breach reaches healthcare, banking, taxation, education, and social welfare. The 8.8 million people whose data was accessed deserve better.

Conclusion: a failure of governance

Nothing in this breach required a clever hacker or a zero-day exploit. A small IT company with access to a national registry used “123456” on at least three accounts, including an administrator account. The system did not enforce password complexity or multi-factor authentication. There was no rate limiting, no anomaly detection, and no real-time monitoring. Accountants found the breach, and security staff did not.

This is a global problem. Every government, organization, and vendor with access to sensitive data faces the same fact: security is only as strong as the weakest link in the chain, and that chain now extends far beyond any single organization.

The 8.8 million affected people will live with the consequences for years. Their CPR numbers are now in the hands of unknown actors. The government has promised a security review and urged vigilance, but vigilance does not replace structural change. Preventing the next breach means building systems that do not depend on human perfection, with strong authentication, least privilege, and continuous monitoring by design, and treating third-party access as the high-risk vector it has always been.

Until then, we will keep seeing headlines like this one, and keep wondering how, in 2026, a nation’s identity infrastructure ended up protected by “123456.”