Denmark CPR Data Breach: How Should Third-Party API Access Security Be Designed?

Denmark's Civil Registration System (CPR) has exposed an alarming data access incident: approximately 14 million queries retrieved 8.8 million records from the system, and all of these requests passed legitimate authentication. The core issue is not "who is accessing" but "how much was accessed, for what purpose, and how broad is the impact" — dimensions that are almost entirely absent from traditional API authentication models.

Incident Review: Why Legitimate Credentials Failed to Prevent Abuse

According to security media reports, the party involved was a company with legitimate access rights that had obtained API access to the CPR system through proper channels. However, under the guise of legitimate identity, the company initiated approximately 14 million queries, ultimately reaching 8.8 million sensitive records of Danish citizens.

What makes this incident particularly notable is that every single request was correctly authenticated. There was no credential leakage, no brute-force attack, no zero-day vulnerability. The system faithfully executed what it was designed to do — verify the caller's identity, then grant access.

This exposes a widespread blind spot in API security design: Authentication does not equal Authorization, and authorization itself often lacks constraints on "volume" and "intent."

CPR (Det Centrale Personregister) is Denmark's central civil registration system, in operation since 1968, assigning a unique 10-digit CPR number to every person with resident status in Denmark. This number serves not only as the unique identifier for tax and healthcare systems but also as an essential credential for everyday matters such as opening bank accounts, renting housing, and employment. The CPR database stores names, addresses, dates of birth, citizenship, marital status, family relationships, and more — its comprehensiveness and data sensitivity are among the highest in Europe. For this reason, API access to CPR is strictly regulated in Denmark, typically granted only to government agencies and approved specific commercial entities. In this incident, the company involved had obtained access through a proper approval process, which makes the boundary between "legitimate access" and "large-scale abuse" particularly blurred — a legally compliant access credential became, at the technical level, a master key capable of repeatedly opening the entire database.

Three Missing Dimensions in Third-Party API Access

Traditional API security models are typically built around "who can access": API Keys, OAuth tokens, mTLS certificates. But this model has structural deficiencies in third-party data sharing scenarios because it ignores three critical dimensions.

Data Scope: Should the Records Visible Be Restricted?

The CPR system contains core identity information for all Danish citizens. When a third-party company obtains API access, it effectively gains the ability to query the entire database. Even if basic field filtering is implemented at the interface level, the attack surface remains enormous — because queries themselves can target any individual.

A more reasonable approach is to establish partitioning or data domains at the data layer: different third-party accessors should only be able to reach data subsets directly relevant to their business purpose. For example, an address verification service should not have the ability to query a citizen's medical records or marital status.

Query Volume: Abnormal Aggregation of Legitimate Requests

14 million queries corresponding to 8.8 million records means a large number of queries were concentrated on nearly the entire target population. This ratio itself should be an anomaly signal.

A healthy data access system needs to establish query volume baselines. When a third party's query frequency, coverage, or query patterns significantly deviate from its historical behavior or the normal levels of similar institutions, the system should trigger alerts rather than continue granting access. This is similar to anti-fraud logic in the financial sector: a single transaction being legitimate doesn't mean ten thousand simultaneous transactions are normal.

Purpose of Use: Can Intent Be Verified Through Technical Means?

The "purpose check" mentioned in the original report is an easily overlooked but crucial dimension. There may be a huge gap between the declared purpose of use when a third party obtains access (such as identity verification, address confirmation) and actual query behavior.

What can be done at the technical level is: map declared purposes to specific query permission templates, and intercept or audit when query patterns deviate from the declared purpose. For example, if an integration claiming to be used for "address change notifications" begins batch-querying records of minors, this constitutes a clear signal of purpose deviation.

How to Implement "Three-Dimensional Checks" in Your Own APIs

For enterprises and institutions that need to open data access to third parties, the CPR incident provides an actionable framework reference.

Authentication Layer: Identify but Do Not Trust

Retain existing authentication mechanisms as a foundation, but design with the assumption that "an authenticated caller can still cause harm." This means every request needs to pass through subsequent dimension checks, rather than one-time authentication granting full trust throughout.

Zero Trust Architecture centers on the principle of "Never Trust, Always Verify," originally proposed by Forrester analyst John Kindervag in 2010. It breaks the traditional perimeter security model's assumption that internal networks are trustworthy by default, requiring every access request — whether from internal or external networks — to undergo identity verification, device inspection, and permission evaluation. In API security scenarios, zero trust means: completing identity authentication via OAuth or mTLS only signifies "you are the entity you claim to be," not "you have the right to perform this current operation." The system needs to re-evaluate the caller's current behavioral context, the data scope of the request, and historical behavior patterns with each request. The CPR incident is a textbook case of missing zero trust: all 14 million requests were unconditionally granted after a single authentication, and the system never re-evaluated "is this access reasonable" at the request level.

Authorization Layer: Bind Data Domains to Business Scenarios

In OAuth scopes or custom permission models, bind data access scope to specific business scenarios. Rather than granting "read user data" permission, grant fine-grained permission to "read the current address field when the user actively initiates address verification." The minimization of permissions itself limits the feasibility of large-scale data extraction.

OAuth 2.0's Scope mechanism is currently the most widely used implementation of fine-grained authorization. A scope is essentially a string identifier for a permission (such as read:address, write:profile), and the resource server decides whether to respond to a request based on the scope contained in the token. However, standard OAuth scope design is primarily oriented toward user-authorized third-party application scenarios, and in B2B data sharing, its granularity is often insufficient — a scope like read:user_data appears clear but actually allows the holder to traverse the entire user database. A more refined approach is to introduce Attribute-Based Access Control (ABAC), extending authorization decisions from static scopes to dynamic attribute combinations: caller attributes (institution type, contract scope), resource attributes (data sensitivity level, domain), and environmental attributes (time, frequency, declared purpose) all participate in the judgment. For example, reading a record is only allowed when the declared purpose is "address verification" and the current request targets only the address field.

Behavioral Layer: Real-Time Monitoring and Anomaly Detection

Establish an independent API behavior analysis layer, focusing on the following signals:

• Query frequency per unit time
• Proportion of users covered by queries (whether approaching full volume)
• Regularity of query patterns (whether exhibiting automated scanning characteristics)
• Consistency between declared purpose and query types

When multiple signals simultaneously trigger thresholds, the system should have the capability to automatically degrade or suspend access, rather than only conducting post-hoc audits.

Implications for API Security Design

The CPR incident is not an isolated case; it represents a class of problems that repeatedly emerge against the backdrop of increasingly prevalent data sharing. Security design for third-party API access needs to shift from a "gatekeeper" model to a "behavior regulator" model.

A gatekeeper only checks whether the person entering holds a key; a behavior regulator, after the person enters, continuously observes which rooms they visit, how long they stay, and whether they attempt to open locked cabinets. For APIs carrying large amounts of personal data, the latter is the more reasonable architectural choice.

This incident also reminds API designers and data protection officers: compliance reviews and contractual constraints are necessary but not sufficient conditions. When the technical architecture itself lacks constraint capabilities, any paper-based data usage agreement will struggle to prevent 8 million records from being extracted in a single "legitimate" access.

One-line Summary

Denmark's CPR system was queried 14 million times by a legitimate third party, extracting 8.8 million records, exposing the lack of controls across data scope, query volume, and purpose verification in API security.

Paragraph Summary

Denmark's Civil Registration System (CPR) was subjected to approximately 14 million queries by a third-party company with legitimate API access, reaching 8.8 million sensitive citizen records, with all requests passing authentication. This incident reveals a widespread API security blind spot: authentication does not equal access control, and legitimate credentials cannot prevent large-scale data extraction. The article proposes that third-party API access must simultaneously check three missing dimensions — data scope (should be limited to data subsets relevant to business purpose), query volume (should establish baselines and alert on abnormal aggregation), and purpose of use (should map declared purposes to query permission templates for verification). At the implementation level, the article recommends adopting a zero trust model: identify but do not trust at the authentication layer, bind fine-grained data domains to business scenarios at the authorization layer, and real-time monitor anomaly signals with automatic degradation at the behavioral layer. The core conclusion is: compliance reviews and contractual constraints cannot replace access constraint capabilities at the technical architecture level.