When Denmark's national citizen registry (CPR) was breached in September, the unauthorized party didn't exploit a zero-day vulnerability or deploy ransomware. They used legitimate access credentials from a company already connected to the system. Over 10 days, they ran more than 14 million searches and extracted records on approximately 8.8 million people before administrators noticed unusual activity on October 2.
This wasn't a sophisticated attack. It was a failure of access governance that exposed nearly every person in Denmark. It happened because the same mistakes keep showing up in how organizations manage access to sensitive systems.
Why These Mistakes Keep Happening
National registries, healthcare databases, and financial systems share a common problem: they grant broad access to legitimate business partners, then fail to monitor what those credentials actually do. The access model assumes trust. The monitoring assumes compliance. Neither assumption holds when credentials are compromised or misused.
These systems were designed for a different threat model. They prioritized availability and ease of integration over granular access control. Adding authentication layers or monitoring feels like friction, so it gets postponed. Until someone runs 14 million searches in 10 days and no alarm goes off for a week.
Mistake 1: Treating Credentials as Identity Verification
Why it happens: Organizations issue service accounts or API credentials to business partners, then treat the presence of valid credentials as proof that the access is legitimate. If the credentials authenticate, the system assumes the request is authorized.
The consequence: When those credentials are stolen or misused, there's no secondary check. The CPR breach demonstrates this perfectly. The company had valid credentials. The system accepted them. No one questioned why a single account was suddenly running searches at a rate inconsistent with normal business activity.
The fix: Implement behavioral baselines for every service account. Track search volume, query patterns, time-of-day access, and IP geolocation. Set thresholds that trigger alerts when an account deviates from its historical pattern. For the CPR system, a service account that typically runs 50 searches per day suddenly executing 1.4 million searches per day should have triggered an immediate lockout, not a discovery 10 days later.
Mistake 2: Single-Factor Authentication for High-Value Systems
Why it happens: Legacy integrations and batch processes make it difficult to enforce Multi-Factor Authentication (MFA) on service accounts. The system was built to accept a username and password (or API key), and adding MFA requires rearchitecting how those integrations authenticate.
The consequence: A stolen credential set is sufficient to access the entire system. There's no second factor to block automated harvesting. In the CPR breach, if the compromised account had required a cryptographic device or time-based challenge, the unauthorized party would have needed to compromise both the credential and the MFA mechanism, significantly raising the difficulty.
The fix: Require Multi-Factor Cryptographic Devices or certificate-based authentication for any service account with read access to personally identifiable information (PII). For systems that can't support interactive MFA, implement mutual TLS authentication where both the client and server validate certificates. This ensures that even if credentials leak, the attacker can't authenticate without the private key.
Mistake 3: No Rate Limiting on Bulk Data Access
Why it happens: Rate limiting is seen as a performance optimization, not a security control. Systems are designed to handle high query volumes from legitimate users, so they don't impose strict limits on how many records a single account can retrieve in a given timeframe.
The consequence: An attacker with valid credentials can exfiltrate the entire database before anyone notices. The CPR breach involved 14 million searches over 10 days. That's approximately 1.4 million searches per day, or roughly 1,000 searches per minute if spread evenly. A system with no rate limiting allowed this to continue undetected.
The fix: Implement tiered rate limits based on account type and historical usage. A service account that typically queries 100 records per hour should be hard-limited to 200 records per hour, with any excess triggering an alert and temporary suspension. For national registries, consider implementing a "break-glass" approval workflow for any account that needs to exceed its normal rate limit, requiring a second administrator to review and approve the request.
Mistake 4: Relying on Static Identifiers for Verification
Why it happens: CPR numbers (and equivalents like Social Security numbers in the U.S.) were designed as unique identifiers, not secrets. Organizations began using them for identity verification because they're convenient and widely known. But once a CPR number is exposed, it can't be revoked or changed like a password.
The consequence: After the breach, Danish officials warned that the exposed CPR numbers could enable fraud and identity-related abuse. Organizations that rely on CPR numbers alone for identity verification now face a problem: millions of people's "verification factor" is in the hands of unauthorized parties.
The fix: Never use static identifiers as the sole verification mechanism. Denmark is now advising organizations to use MitID (Denmark's national digital identity system), Two-Factor Authentication, or One-Time Passwords alongside CPR numbers. Treat the CPR number as a correlation key, not a secret. Verification should require a dynamic factor that the individual controls, such as a FIDO2 security key, Time-Based One-Time Password, or push notification to a registered device.
Mistake 5: No Continuous Certification Campaign for Service Accounts
Why it happens: Service accounts are provisioned during integration projects and then forgotten. Unlike human accounts, they don't leave the organization or change roles, so they're excluded from Certification Campaigns. No one reviews whether the account still needs access, or whether its access level is still appropriate.
The consequence: Service accounts accumulate Entitlement Drift. They retain access long after the business need expires. When the company in the CPR breach was cut off from the system after the incident, it raised an obvious question: was that level of access still necessary? Had anyone reviewed it in the past year?
The fix: Include service accounts in quarterly access reviews. For each service account, document the business justification, the scope of access, and the expected usage pattern. Set an expiration date on all service accounts (e.g., 12 months), requiring explicit re-approval to maintain access. Implement automated Reconciliation to detect when a service account's actual usage diverges from its documented purpose.
Prevention Checklist
Before granting access to sensitive systems, verify:
- Does this account require Multi-Factor Authentication or certificate-based authentication?
- Have we established a behavioral baseline for expected query volume and access patterns?
- Are rate limits configured to prevent bulk data exfiltration?
- Do we have alerting in place for unusual search volumes or access times?
- Is this account included in our quarterly Certification Campaign?
- Does the account have an expiration date requiring re-approval?
- Are we logging all queries with sufficient detail to reconstruct activity during an incident?
- Have we documented the business justification and expected usage pattern?
- Can we verify identity without relying solely on static identifiers?
- Do we have a process to immediately revoke access if suspicious activity is detected?
The CPR breach wasn't the result of an advanced persistent threat. It was the result of treating access as binary (granted or denied) rather than conditional (granted, monitored, and revocable). Every search should have been logged. Every deviation should have triggered review. Every service account should have been subject to the same scrutiny as a privileged human user.
Your national registry might not be the target. But your customer database, your financial system, or your healthcare records face the same risk. The question isn't whether your credentials will be compromised. It's whether your controls will detect and stop the exfiltration before it reaches 8.8 million records.
