What Happened
On September 10, an attacker accessed Denmark's Central Register of Persons (CPR) using credentials from Pays ApS, an IT company with legitimate access. The attacker used the password "123456" to authenticate and performed 14 million automated searches between September 10 and September 20, accessing data for 8.8 million people.
The breach went unnoticed for 12 days after the final unauthorized searches. A government employee discovered it on October 2 when reviewing an invoice showing unusual activity from Pays. The Danish government notified Datatilsynet on October 4 and publicly disclosed the breach on October 5.
Reports indicate that at least three company accounts, including an administrator account, were protected by the same weak password.
Timeline
September 10: Unauthorized access gained through Pays ApS credentials
September 10-20: Attacker conducts 14 million automated searches in the CPR system
September 20: Last unauthorized searches recorded
October 2: Breach detected by government staffer reviewing invoice
October 4: Datatilsynet notified
October 5: Public breach disclosure
Which Controls Failed or Were Missing
Password Strength Requirements
Pays ApS used "123456" on at least three accounts with access to a national identity register. This password is easily cracked and appears on every compromised credentials list. No technical control prevented its use.
The administrator account also used this password, allowing a single compromise to grant elevated access across the vendor's systems.
Multi-Factor Authentication
The system relied solely on passwords. No second factor was required, even though the account accessed sensitive government data.
Account Activity Monitoring
The attacker executed 14 million searches over 10 days without triggering any alerts. The breach was discovered manually through invoice review, not security monitoring.
Vendor Security Assessments
Pays ApS had authorized access to validate customer records. The CPR administration granted this access without enforcing password complexity or detecting credential misuse.
Access Provisioning Controls
Three accounts shared the same password, indicating no process ensured unique, strong credentials. No automated system enforced password policies at account creation.
What the Relevant Standard Requires
GDPR Article 32: Security of Processing
Article 32 mandates "appropriate technical and organisational measures" based on the state of the art and processing risks. Measures must include:
- Pseudonymisation and encryption where appropriate
- Systems ensuring ongoing confidentiality, integrity, and availability
- The ability to restore availability after incidents
- Regular testing and evaluation of measure effectiveness
A password like "123456" doesn't meet the "state of the art" standard. Basic password complexity requirements have been standard for decades.
GDPR Article 28: Processor Obligations
Article 28(3)(c) requires controllers to ensure processors implement "appropriate technical and organisational measures." The controller must verify these measures before granting access.
The CPR administration's failure to audit or enforce security standards at Pays violates this obligation.
ISO/IEC 27001 A.9.4.3: Password Management System
This control requires enforcing password quality rules, including minimum length, complexity, and prohibition of common passwords. Administrator accounts must use stronger authentication than standard users.
NIST SP 800-63B: Digital Identity Guidelines
NIST requires checking proposed passwords against lists of commonly used or compromised values. "123456" appears on all such lists. NIST also recommends multi-factor authentication for accounts accessing sensitive data.
Lessons and Action Items for Your Team
Implement Technical Password Controls
Use automated password screening against breach databases. Tools like Have I Been Pwned's API can reject compromised passwords at creation. Enforce strong passwords programmatically.
Prevent password reuse across accounts. If identical passwords are detected, especially on administrator accounts, force immediate resets.
Require Multi-Factor Authentication on Third-Party Access
Require MFA for any vendor account accessing personal data. Configure your identity provider to enforce this at the authentication layer. Use time-based one-time passwords (TOTP) at minimum; prefer hardware tokens or biometric factors for administrator access.
Monitor Vendor Activity Baselines
Establish normal activity ranges for each vendor account. If Pays typically runs 500 searches per day, alert when searches hit 50,000. Configure your logging infrastructure to track API calls, search volumes, and data exports per account per hour.
Don't rely on invoices to reveal anomalies. Your security information and event management (SIEM) system should detect unusual patterns in real time.
Audit Vendor Security Before Granting Access
Article 28 makes you responsible for your processor's security measures. Before granting vendor access:
- Request evidence of password policies (minimum length, complexity, rotation requirements)
- Verify MFA is enabled on all accounts accessing your systems
- Review their access logging and monitoring capabilities
- Require annual security assessments or SOC 2 reports
Document these reviews. If a breach occurs, you'll need to demonstrate due diligence.
Segment Vendor Access by Function
Pays needed to validate customer records, not search 8.8 million records in 10 days. Implement rate limiting on vendor API access. Define maximum searches per hour based on legitimate business need and enforce it technically.
Use role-based access control to restrict vendors to the minimum data set required for their function. If they validate addresses, they don't need access to full identity records.
Test Your Detection Capabilities
The 12-day gap between the final unauthorized searches and detection is unacceptable. Run tabletop exercises simulating a credential compromise. Measure detection time. If detection relies on invoice review, you have a gap.
Deploy user and entity behavior analytics (UEBA) tools that baseline normal account behavior and flag deviations automatically. Configure alerts to notify your security operations center when vendor accounts exceed activity thresholds.
This breach was preventable. The password "123456" has been known as insecure since the early 2000s. Every failed control is documented in frameworks you reference. The question isn't what to do; it's whether you're doing it.
