Denmark is one of the most digitalised countries in the world, and that's exactly why what happened this autumn matters far beyond its borders. In a few weeks, two incidents exposed data on millions of people, and neither started with a sophisticated attack on the main system. Both started at the edges.
We work with Danish and Swedish companies, so here's a summary of what we know and the practical lessons for any organisation.
The CPR register: 8.8 million people
On 5 October 2026, the Danish authorities announced a serious security incident in the CPR register, the central register of everyone with a Danish personal identification number.
- Unauthorised parties used a Danish company's legitimate access to look up data in the register.
- Over roughly ten days in September, a very large number of automated lookups were made.
- About 8.8 million people, living and dead, were affected: names, addresses and CPR numbers. People with name and address protection had their names and addresses excluded.
- The activity was noticed by an employee of the register's administration on 2 October. The company's access was stopped, and the case was reported to the Danish Data Protection Agency and the police.
How the attackers got hold of the company's access, and what they've done with the data, are still being investigated.
The University of Copenhagen: 525,000 people
On 23 October, the University of Copenhagen (KU) disclosed a cyberattack detected on 20 October.
- The attackers got in through one of the university's test environments.
- Data on about 525,000 people was accessed: names, CPR numbers, phone numbers and private email addresses.
- The ID card PIN codes of about 20,000 staff and students were also compromised. New PINs have been issued.
- Several administrative systems were shut down as a precaution. On 27 October the university said a suspected second attack was in fact linked to the original breach.
The Technical University of Denmark (DTU) and Aarhus University have also faced attacks in recent weeks, and the minister for higher education called the heads of all eight Danish universities to a security meeting.
Five lessons for any company
1. Partners' access is your attack surface
The CPR register wasn't "hacked" in the classic sense: someone used access that a company was entitled to. Any company that gives partners, suppliers or integrations access to its data should ask:
- Does each partner only have access to exactly what they need?
- Are there limits on volume (how many lookups per hour or per day)?
- Is access protected with multi-factor authentication and reviewed regularly?
2. Detect what's unusual, automatically
A sudden flood of automated lookups is exactly the kind of pattern a system can flag in minutes. Alerts on unusual volume, unusual times or unusual sources turn ten days into ten minutes.
3. Test environments are production too
The KU breach started in a test environment. Test and staging systems are often less protected, but they're connected to the real network and sometimes hold real data. Use fake or anonymised data for testing, and protect test systems as seriously as live ones.
4. Don't keep data you don't need
National ID numbers, private phone numbers and personal emails are valuable to attackers. Every field you don't store is a field that can't leak. Review what you collect and how long you keep it.
5. Have a plan for the day after
Under the GDPR, a personal data breach must normally be reported to the data protection authority within 72 hours. Know in advance who decides, who informs customers and how, and who you call for technical help. And warn your customers about the phishing that usually follows a leak.
If your data was affected
- Be wary of unexpected calls, texts or emails that use your personal details to seem credible.
- Never share MitID codes, passwords or card details with anyone who contacts you, even if they "know" your CPR number.
- In Denmark you can set up a credit warning on borger.dk, and the government's Cyberhotline offers help.
The common thread
Neither incident needed a brilliant zero-day exploit. Both used weak points around the main system: a partner's access, a test server. It's the same message as the recent PHP2Shell vulnerability: security depends on the whole chain, including the unglamorous parts.
How we can help
At PDCG we help companies review how their systems are connected: who has access to what, what is exposed, how test environments are set up and where data is stored. We build with European infrastructure and data minimisation in mind. See tech consulting and European cloud & hosting, or get in touch.
This article is based on information published up to 27 October 2026. Both investigations are ongoing; we'll update it if anything changes.