Denmark's CPR incident: How third-party access became a national-scale data risk

Independent analysis - not an official investigation. This article is an independent cybersecurity case study based on publicly available official statements, contractual guidance, archived company material and attributed news reporting. It is not a forensic finding or statement by Danish law enforcement, intelligence or security authorities, CPR Administration, or Pays ApS. Allegations, attacker claims, technical hypotheses and verified facts are differentiated. Diagrams and animations are illustrative, not verified representations of any internal system or attack sequence. No unauthorised access or testing was undertaken for this article. Information cut-off: 10 October 2026.

What happens when a small data-services company holds legitimate access to a national population register - and someone abuses that access at scale?

Denmark’s CPR incident offers a striking case study in third-party access governance. The public account points not to a confirmed compromise of the CPR register’s core infrastructure, but to misuse of a private organisation’s authorised connection. Reports describe approximately 14 million lookups and information relating to approximately 8.8 million registered individuals. Those are different measures: lookups are transactions, not unique people. The affected population includes historical registrations, and the figure must not be read as the number of currently living Danish residents [1][2][3].

The question for security leaders is broader than the strength of any single password: Who can use an integration, how much can they retrieve, and how quickly would anyone notice abuse?

1. What is confirmed - and what is not?

Finding	Evidence and limitation
CPR data was accessed through a private organisation’s authorised connection	Supported by Danish official reporting and CPR/industry statements [1][2][3].
Pays ApS was the company involved	Pays publicly acknowledged misuse of its lawful access, as reported by Danish media [5][6].
Pays marketed CPR-related data-quality services	Supported by archived Pays website and its publicly described business model [8].
Millions of individuals were affected and lookup volume was extraordinary	Approximate figures reported by authorities and media; distinguish people from transactions [1][2][3].
An unusually large bill triggered scrutiny	Described in DR reporting and Danish Industry’s account [3][4].
Weak passwords and leaked credentials existed in reporting	Journalistic findings and alleged attacker account; not a confirmed complete forensic chain [4][5][7].
A specific Pays CPR service account used `123456` to perform the attack	Not established. Do not infer this from an employee credential leak or another account’s password.
CPR had no logging, no monitoring or no rate limits	Not established. Billing records and transaction accounting existed; exact security detection configuration is unknown.
Pays used a specific CPR API, OAuth flow, client certificate, Datafordeler or a particular firewall	Not established. Do not confuse possible access models with the actual implementation.

2. Who was Pays ApS, and why did it have CPR access?

Pays ApS described its services as improving and enriching organisational data, including CPR/CVR-related validation and updating. This is a plausible business reason for lawful access to population data: a company may need to validate or correct records it already holds, subject to legal permissions and contractual restrictions. The archived website also describes a connection with CharityGuard and the nonprofit sector. These business descriptions do not prove which customers or datasets were involved in the incident [8].

Historical source: Pays’ archived website

A comparison of Pays ApS’s historical website and its current public-facing page reveals a notable change.

The archived website from February 2025 promoted data-driven services, customer database improvements and GDPR compliance. As of 10 October 2026, the website instead displays a maintenance notice stating that the page is under reconstruction.

The reason for this change has not been independently established, and it should not be assumed to be a direct consequence of the CPR incident.

Before - Archived website (February 2025)	After - Current website (October 2026)

View archived website	Visit current website

Figure 1: Pays ApS’s public website before and after the reported CPR incident. Screenshots document the website’s appearance at different points in time, not the reason for the change.

The website’s marketing references to SSL, encryption and GDPR compliance are relevant as historical claims, not evidence that particular security controls worked or failed. Encrypted transport can protect a session from interception while still allowing a legitimately authenticated but compromised account to retrieve data.

3. Why could a two-employee company access Denmark’s national population register?

For readers outside Denmark, this is a natural question. CPR is a public register, but selected CPR information can legally be supplied to private organisations. Danish rules permit disclosures to eligible private recipients when the applicable conditions are met. A legitimate business purpose and an approved access arrangement do not amount to permission to search the entire population without restrictions [15][16].

Legitimate reasons for private-sector access

Banks, insurers, pension providers and data-quality specialists may need to keep customer information accurate. Depending on their legal basis and CPR agreement, authorised uses can include checking existing customer identities, validating names or addresses, and updating records when information changes. Pays marketed data-cleansing and enrichment services, which helps explain its business model, but does not establish the scope of its actual CPR permissions [8][15].

How does an organisation obtain access?

An organisation must obtain access under the relevant CPR legal and administrative framework. The precise permitted fields, purposes, authentication arrangements and contractual duties depend on the service and agreement. CPR makes information available through different products, including interactive searches, system-to-system services and certain Datafordeler arrangements. These are not interchangeable, and public reporting has not established which technical interface Pays used [9][10][15].

An illustrative legitimate workflow is:

Organisation with an existing customer relationship -> authorised data-quality provider -> permitted CPR lookup or update service -> information returned within the approved scope.

This describes a possible business process, not Pays’ verified infrastructure or the attack path.

The trust boundary that matters

A national register may be well protected internally while still being exposed through an authorised external connection. The security of that connection depends on both the register operator and the recipient organisation. An integration can be technically authenticated while the person or process operating behind it is unauthorised.

The questions are therefore practical: who can initiate lookups, which records can be requested, how are individual users attributed, what volume is normal, and who can revoke access immediately? CPR’s published conditions for certain private-sector system-to-system services already describe security ownership, individual authorisation, logging and transaction-statistics review. The obligations applicable to Pays’ specific agreement remain to be established [9][10].

The central lesson: private-sector access to CPR is not inherently improper. The risk emerges when the scope and volume of a trusted third-party connection exceed what its security controls can reliably govern and detect.

4. The third-party access path

Illustrative Pays-CPR business-level architecture

Figure 2 if the archive screenshot is added). Simplified conceptual flow. The specific CPR interface, customer identities, network architecture, credentials and attack entry point have not been independently verified.

The distinction is crucial: the attacker does not necessarily need to compromise the central register. If a connected organisation can query sensitive information, compromise of that organisation or its credentials may be sufficient to misuse its permitted access. That is a third-party access compromise, not evidence of a software supply-chain attack involving a malicious update.

The exact technical arrangement matters. CPR offers different forms of access with different conditions, including conventional system-to-system arrangements and Datafordeler-related services. This article does not assert which was used by Pays [9][10].

5. Credentials: what the reporting shows

DR reported finding a login page that might have been relevant to the intrusion, together with credential information from earlier leaks. Other reporting described Pays-related accounts using the extremely weak password 123456, including an administrative profile. The alleged attacker also claimed to have used a former employee’s leaked credentials [4][5][7].

These are three distinct evidentiary propositions: a credential existed in a leak; a weak password was used by some accounts; and the attacker claims a particular method. None alone proves that 123456 authenticated the CPR integration or was the exact credential used to perform the reported lookups.

For defenders, the general control lesson is unchanged: revoke departed users promptly, protect privileged access with phishing-resistant MFA where technically applicable, avoid shared human accounts, store machine secrets securely and rotate credentials when exposure is suspected.

6. Why the invoice matters

According to DR’s reporting and Danish Industry’s subsequent explanation, the abnormal volume of CPR lookups came to attention during preparation or review of an unusually large invoice. This suggests that usage accounting was available, but the incident was not surfaced early enough through the reported detection process. It does not establish that CPR lacked API logs or that no automated monitoring existed anywhere [3][4].

Animated illustrative billing anomaly and alert

Animated illustration only. The cartoon’s baseline and elevated invoice figures - DKK 10,000 and DKK 1,400,000 - are hypothetical, not Pays invoices or documented CPR charges. Its interface, employee, alert button, charts and timing are fictional. It is not a reconstruction of what a specific employee saw or did.

This difference matters. A billing system is designed to charge for usage; a security-monitoring system is designed to detect misuse in time to stop it. A bill should not be the first effective warning of high-volume extraction.

7. What CPR required before the incident

The June 2026 standard conditions for private organisations already addressed a number of safeguards for certain system-to-system arrangements. Danish Industry’s 7 October analysis summarises them, including: [3][9]

A designated security-responsible person.
Authorisation limited to employees who need access.
Personal identification within the customer’s own system, rather than shared human logins.
Records of authorised users and systems, including access start and end dates.
Logging of individual searches against the responsible employee in the customer’s own environment.
Review of monthly transaction statistics.
Encryption and IP-address restrictions under the relevant arrangement.
Restrictions on mass automated online lookups without approval.

Important: These provisions must be interpreted according to the actual CPR service and agreement. Separate terms apply to Datafordeler. We cannot conclude from the public incident report alone that Pays breached each - or any particular - condition.

8. The official response: security requirements reinforced

On 9 October 2026, CPR Administration published a notice reinforcing the rules and conditions for organisations with CPR access. It specifically highlighted the need for a security officer and ongoing control and monitoring of the number of CPR lookups. The notice linked to an official letter sent to affected companies [2][11].

Official documents:

The nuance is essential: reinforcement is not necessarily the creation of new obligations. Some controls were already part of the June 2026 terms. The relevant question is whether the controls were appropriately implemented, checked and enforced, not simply whether they appeared on paper.

9. Security requirements I would demand before approving this type of access

Control domain	Minimum expectation	Evidence to request
Identity and personnel	Named user identities, timely offboarding, strong MFA for human administration	Access reviews, offboarding test, MFA policy
Machine authentication	Dedicated, scoped integration identity; managed secrets and rotation	Integration design, secret lifecycle evidence
Least privilege	Queries restricted to lawful, necessary purposes and approved datasets	Entitlement matrix, purpose restrictions
Query governance	Appropriate per-user/service volume limits and safeguards against enumeration	Rate-limit policy, abuse-case tests
Logging	End-user attribution in the customer environment; central service usage visibility	Sample logs, retention and correlation design
Detection	Baselines and near-real-time alerts on spikes, unusual targets and hours	Detection rules, test alerts, response runbooks
Network controls	Restricted origins and segregated integration where supported	Approved IPs, architecture and firewall rules
Third-party oversight	Security owner, contractual controls, audits and prompt notification	Agreement, control attestations, review schedule
Response readiness	Ability to suspend access rapidly and preserve evidence	Revocation procedure and tabletop results

These are my recommendations, not a claim that every item was required by CPR, implemented by Pays or missing during the incident.

10. Questions that remain unanswered

Which exact CPR access product, interface and authentication method did Pays use?
Which credential or internal account was actually compromised, and when?
Were there technical query limits or anomaly rules, and what did they detect?
Which organisations, datasets and permitted fields were actually involved?
What did the available logs show, and when did incident responders first see them?
Which requirements applied to Pays’ specific agreement, and were they complied with?

Without these answers, an illustrative diagram must not be presented as a forensic reconstruction.

11. The larger lesson

This is a case about the blast radius of trusted connections. An organisation can operate a small team and still possess access to information affecting millions of people. Security approval must therefore reflect the sensitivity and reach of the connected dataset - not the size of the supplier.

An access agreement should never be mistaken for a security boundary. Strong authentication, constrained queries, attributable logs, active monitoring and rapid revocation are what turn contractual trust into enforceable technical controls.

Sources and further reading

Editorial note: This article may be updated as official investigations release additional findings. Sources are attributed according to their evidentiary status; Reddit comments and attacker statements are not treated as independently verified facts.

1. What is confirmed - and what is not?#

2. Who was Pays ApS, and why did it have CPR access?#

Historical source: Pays’ archived website#

3. Why could a two-employee company access Denmark’s national population register?#

Legitimate reasons for private-sector access#

How does an organisation obtain access?#

The trust boundary that matters#

4. The third-party access path#

5. Credentials: what the reporting shows#

6. Why the invoice matters#

7. What CPR required before the incident#

8. The official response: security requirements reinforced#

9. Security requirements I would demand before approving this type of access#

10. Questions that remain unanswered#

11. The larger lesson#

Sources and further reading#