What happened
On October 5, Denmark's government confirmed unauthorized access to the Central Register of Persons (CPR), a national database with records for about 11 million people, including deceased individuals and those who have moved abroad. The breach affected 8.8 million records.
The attacker gained entry using legitimate credentials from Pays ApS, a small IT company in Funen with authorized access to the CPR system. Pays provided validation services for business customers, checking records against the national register. The company's account was protected by the password "123456." Reports indicate at least three company accounts, including an administrator account, used this same password.
Between September 10 and September 20, the attacker ran 14 million automated searches against the database. The intrusion went undetected until October 2, when a government staffer noticed an invoice showing unusually high activity from Pays. The Danish supervisory authority, Datatilsynet, was notified on October 4.
Timeline
September 10: Initial unauthorized access through Pays ApS credentials
September 10-20: 14 million automated searches executed
September 20: Last recorded search activity
October 2: Breach detected via invoice review (12 days after final searches)
October 4: Datatilsynet notified
October 5: Public disclosure
October 9: Pays ApS managing director confirmed the company's access was exploited
Which controls failed or were missing
No password complexity requirements. The compromised account used "123456," a commonly exploited password globally. At least three accounts, including an administrator account, shared this password.
No multi-factor authentication (MFA). A single compromised credential provided full access to 8.8 million records. No second authentication factor was required.
Inadequate access monitoring. Fourteen million automated searches over ten days didn't trigger alerts. The breach was discovered through manual invoice review, not automated monitoring systems.
No anomaly detection. The volume and pattern of queries should have stood out immediately. Legitimate validation services don't require millions of rapid-fire searches.
Weak processor access governance. Pays ApS had broad access to the entire CPR database to provide validation services. There's no indication that access was limited to only the records necessary for their specific business function.
Delayed breach detection. Twelve days passed between the last unauthorized search and detection. During active exploitation, the window was even wider.
What the relevant standard requires
Article 32 GDPR requires controllers and processors to implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk. For a database containing 11 million national identity records, that risk is severe.
On authentication: Recital 83 mentions "pseudonymisation and encryption," but the broader requirement is risk-appropriate security. Industry standards (NIST, ISO 27001, CIS Controls) classify MFA as a baseline control for systems containing personal data at this scale. Password complexity requirements aren't optional for administrator accounts accessing national registers.
On access controls: Article 32(1)(b) requires "the ability to ensure the ongoing confidentiality, integrity, availability, and resilience of processing systems and services." This includes restricting access to the minimum necessary. A processor providing validation services doesn't need unrestricted query access to 11 million records.
On monitoring: Article 32(1)(d) requires "a process for regularly testing, assessing, and evaluating the effectiveness of technical and organizational measures." You can't evaluate what you don't monitor. Audit logs must exist, and someone must review them frequently to detect abuse before millions of records are compromised.
On processor oversight: Article 28(1) states you may only use processors "which provide sufficient guarantees to implement appropriate technical and organizational measures." Article 28(3)(h) requires processors to "make available to the controller all information necessary to demonstrate compliance" and "allow for and contribute to audits." If Pays ApS was acting as a processor, the CPR administration should have verified their security posture before granting access.
The 12-day detection gap also creates notification timeline pressure. Article 33 requires breach notification to the supervisory authority within 72 hours of becoming aware. That clock starts when you have reasonable certainty a breach occurred, not when you complete your investigation.
Lessons and action items for your team
Audit third-party authentication now. Don't wait for your next processor review cycle. If you're a controller, request evidence that every processor with system access uses MFA and enforces password complexity. If you're a processor with customer data access, implement these controls immediately. Document your current state and remediation timeline.
Implement query-level monitoring for high-risk systems. Invoice review shouldn't be your detection mechanism. Set thresholds based on normal usage patterns. For a validation service, what does legitimate daily query volume look like? Alert when accounts exceed 2-3 times that baseline. For administrator accounts, alert on any queries, because admins shouldn't be running production searches.
Scope access to business need. Ask: does this processor need access to your entire database, or just the ability to validate specific records on demand? API-based validation (processor sends a record identifier, receives a yes/no response) exposes far less data than unrestricted query access. Redesign integrations to minimize data exposure.
Require MFA for all privileged access, no exceptions. Administrator accounts, system accounts, and any credentials with bulk data access must use MFA. This includes service accounts. Yes, it's harder to implement. The alternative is a password like "123456" protecting 8.8 million records.
Test your detection capabilities. Run a tabletop exercise: if a processor account ran 10 times normal query volume tomorrow, how long until you'd notice? If the answer is "when we review the monthly invoice," your monitoring is insufficient. Implement automated alerting that notifies your security team within hours, not weeks.
Review Article 28 contracts and SLAs. Your processor agreements should specify minimum security requirements, including authentication standards and monitoring obligations. They should also grant you audit rights. Use them. Annual security questionnaires aren't enough for vendors with direct database access.
Document your risk assessment. Article 32 requires security "appropriate to the risk." For a national identity register, that risk is extreme. Document why you've implemented specific controls and how they address identified risks. When controls fail, you'll need to show the supervisory authority that your initial assessment was reasonable and that you're closing gaps quickly.
The person who claimed responsibility told media they had no intention of selling or leaking the data. That's cold comfort to 8.8 million people whose records were accessed without authorization, and it's legally irrelevant. Under GDPR, unauthorized access is a personal data breach regardless of the attacker's stated intent. Your obligation is to prevent the access in the first place.
