A two-person data cleansing firm in Odense has confirmed that its approved access to Denmark’s national population register was the route into a breach covering around 8.8 million CPR numbers. Danish reporting now says several of its accounts, an administrator among them, were protected by the password “123456”.
What happened
On Friday 9 October, Pays ApS told the Danish broadcaster TV 2 that its account had been used in the attack on the Central Person Register (CPR). In an emailed statement, managing director and owner Sophie Laursen confirmed that the company’s lawful search access to the register had been misused. Pays says it is working with the Ministry of Research, Education and Digitalisation, the police, the National Unit for Special Crime (NSK) and Datatilsynet, the Danish data protection authority. It has declined further comment.
A day later, the Copenhagen Post and Ritzau reported Politiken’s findings. The newspaper found that at least three Pays user accounts had the password “123456”, including an administrator account. Jens Myrup Pedersen, a cyber security professor at Aarhus University, told Politiken the company’s password practice was “hopeless” and described it as an open door.
The breach itself became public on 5 October. That day the ministry said the CPR office had noticed irregular activity a few days earlier, and that unauthorised people had used a private company’s legitimate access to obtain the names, addresses and CPR numbers of roughly 8.8 million registered people. The total is well above Denmark’s resident population of about six million because the register also holds people who have died or moved abroad. Christina Egelund, the minister responsible for digitalisation, has told Ritzau that security around the CPR system was not good enough. New measures and a security review have followed.
The technical picture
Nothing reported so far points to an exploit or a flaw in the CPR platform itself. This was credential abuse against a trusted third party.
- Initial access. On 8 October an anonymous individual told Politiken they were responsible. They said they logged in using a former employee’s password, which had appeared in an earlier, unrelated data leak. TV 2 says its own research matches this: an email containing the “123456” password was included in a larger leak.
- Collection. The individual says they wrote two simple programs, one to query the register through the Pays account and one to store the results somewhere else. They say they will not sell or publish the data. Experts who examined a sample supplied by the individual, including Emil Hørning of Defend Denmark, told the paper they believe the claim is genuine.
- Scale and timing. TV 2 reports more than 14 million lookups between 11 and 20 September, which produced the 8.8 million unique records. Danish reporting puts the total period of access, starting on 10 September, at 21 days and 17 hours.
- Detection. According to TV 2, the activity was only noticed about 12 days after the bulk extraction finished. The trigger was the CPR office spotting an unusually large bill for Pays’s lookups, after which the account was closed.
Why it matters for UK organisations
The UK has no direct equivalent of the CPR, but the same model of trusted third-party access is common here. Credit reference agencies, debt tracing and data cleansing firms, vehicle keeper lookups, identity verification providers and the many processors working for local authorities and the NHS all reach into large personal datasets over legitimate connections.
Under UK GDPR, a controller that gives a processor access is still responsible for making sure that processor has appropriate security in place, and the ICO will expect evidence of that when it investigates. The NCSC’s supply chain security guidance makes the same point: you set minimum security requirements for suppliers and you check that they meet them.
There is a fraud risk too. The Danish authorities have warned citizens that criminals may quote a correct CPR number and address to make a phishing call or email seem genuine. UK firms with Danish customers or staff should expect pretexting that uses accurate identity data, and help desks should not accept knowledge of personal details as proof of identity.
Expert view
In my experience, this is the failure mode I expect to see on a supplier assessment, more than at the primary organisation. The small firm plugged into it often has two staff, a shared admin account and no joiners, movers and leavers process. In this case, every control that mattered lived with the weakest party.
Three things stand out. First, an account belonging to a former employee was still usable, which is a basic offboarding failure. Second, nobody should be able to set a password like “123456” on any system, let alone one with access to a national register; any password policy or banned-password list would have rejected it. Third, the platform allowed more than 14 million queries from one small customer in about ten days without anyone intervening. Rate limits, volume baselines and alerts on unusual query patterns would most likely have caught this within hours. When we test API integrations, missing per-client throttling is one of the most common findings; it is a data loss control, not just a performance setting. Nor should a finance team be your exfiltration detector.
What to do now
- List every third party that can query your personal data. Record which accounts they use, what each one can see and who is responsible for the relationship. Revoke any access nobody can justify.
- Require MFA on all supplier access to sensitive systems. Cyber Essentials user access control already expects MFA on cloud services and protection against easily guessed passwords. Put the same requirements in contracts and check that they are met.
- Enforce offboarding at the supplier. Ask for evidence that leavers’ accounts are disabled promptly, and where you can, prefer named individual accounts over shared ones so you can see who is logging in.
- Rate-limit and baseline every data interface. Set realistic per-client query ceilings, alert on sudden jumps in volume, and treat bulk enumeration as a security incident.
- Check for exposed credentials. Compare staff and supplier logins with breach data, and reset any that appear.
- Update help desk verification. Personal details such as an ID number, date of birth or address should not be enough to verify a caller.
- Rehearse a supplier compromise scenario in your incident response plan, including how you would meet the 72-hour ICO notification deadline when the breach happened at someone else’s premises.
Bottom line
A national register holding records on more people than Denmark has residents was copied through a two-person supplier using a password that sits at the top of every wordlist, and the alarm was raised by an invoice. The lesson for UK organisations is simple: your data is only as well protected as the weakest login that can reach it. Find those logins, enforce MFA on them and put limits on what they can extract.
Sources
- The Copenhagen Post: ‘123456’ password used in massive Danish CPR data breach
- The Local Denmark: Cybercriminal claims to have used simple password to hack Danish CPR system
- TV 2: Her er den fynske virksomhed cpr-lækket gik igennem
- Se og Hør (Ritzau): Nye detaljer om CPR-læk: Mindst tre profiler brugte 123456-adgangskode
- Ritzau via dkindkob: Den fynske it-virksomhed Pays er blevet udnyttet i CPR-sagen
- Infosecurity Magazine: Danish CPR Breach Highlights Challenge of Supply Chain Risk
