Around ten days of automated CPR lookups through one private company's lawful access. The controls did not stop it in time. The company still has no public name.
CPR confirms that unauthorized parties obtained names, addresses, CPR numbers and other information on about 8.8 million registered people through one private company’s lawful access. Datatilsynet’s notice confirms mass automated lookups used to identify valid CPR numbers. The minister says the security around that access was not good enough. None of those statements puts the copied data back under control or identifies the control that failed.
My CPR is part of the same national identity infrastructure. I earn my living outside IT, pay for my own tools and do this investigation independently. I do not have a ministry, a press office or a consultancy budget behind me. I have their documents, their timestamps, their rules and the evidence I can preserve.
CPR confirms the data exposure. The supervisory notice confirms mass automated enumeration. The minister confirms the security around the access was not good enough. The missing record is operational: product, credential path, request curve, baseline, first anomaly, first alert and the control that failed to stop it.
CPR says unauthorized parties obtained access to names, addresses, CPR numbers and other data concerning about 8.8 million registered persons. The register also contains deceased persons and people who have moved abroad.
The minister told Ritzau that the misuse continued for around ten days in September. CPR says the administration became aware of irregular behavior on the evening of 2 October.
The access route was a private Danish company's lawful ability to search CPR. Authorities have not publicly identified the company or the specific CPR product used.
Datatilsynet says the notification describes a very large number of automated lookups against CPR with the purpose of identifying valid CPR numbers.
Christina Egelund said the security measures around this type of access were not solid enough and that warning lights should have gone off earlier.
CPR published the incident on 5 October. Datatilsynet says it received the breach notification on Sunday 4 October.
Unauthorized automated activity takes place for around ten days, according to the minister's statement to Ritzau.
A CPR administration employee notices irregular activity in the evening.
The picture develops into a security incident during the weekend.
Datatilsynet receives the breach notification from CPR.
The incident is announced publicly. Police investigation and a security review are underway.
CPR publishes that private companies’ access to CPR has been restored.
CPR's own terms describe logs, transaction statistics, named security responsibility and recurring review for private access paths. Those requirements matter now because they describe records that should help reconstruct this incident. The product used in the breach is still undisclosed, so the product must be named before the exact audit trail can be judged.
For private Datafordeler access, CPR terms say searches and queries are recorded with the client user or certificate, transaction type, date and time, and the data the query concerns. Designated security users can generate reports for selected or all searches and receive transaction statistics.
Logpoint export with user or certificate, transaction type, date and time, queried data, plus selected or all-search reports and transaction statistics.
If Datafordeler was the route, publish the incident-period Logpoint trail, alert history and the security-control record.
For private system-to-system deliveries outside Datafordeler, the client must designate a security officer, produce monthly transaction statistics by transaction type and have that officer check them. The same terms say system-to-system access must not be used for online batches without prior CPR approval.
September transaction statistics by type, security-officer review, client-side employee attribution and any CPR approval for online batching.
If another system-to-system route was used, publish the monthly statistics and the user mapping that the client was required to maintain.
The private CPRWeb terms say every query is logged with user ID, date and time, and the data the query concerns. The security officer must review each user's transaction statistics every month and can request detailed terminal traffic for a defined period.
Per-query user ID, timestamp and query target, monthly per-user transaction statistics and detailed terminal traffic for the relevant users and period.
If CPRWeb was the route, publish the query report built for suspected-abuse review and the September user statistics.
The CPR application page asks for the applicant CVR number, the data controller, a named security officer with contact details, a billing contact and the requested CPR products. The company may be unnamed publicly, but the access model is built around an identified customer and responsible contacts.
Customer application, CVR, approved purpose, requested product, named security officer and responsible contacts.
The public still has no company name, product name or accountable security contact for the access path at the center of the incident.
Published private pricing counts CPRWeb searches, CPR Direkte lookups, CPR Services transactions and Datafordeler usage. REST counts transactions even when zero persons are returned. GraphQL pricing counts returned person objects. Those counters should be cross-checked against the incident telemetry.
Usage counters and billing records for searches, lookups, REST transactions or returned GraphQL person objects, depending on product.
Publish the customer baseline, September usage curve and the point where volume departed from normal behavior.
If the route was Datafordeler, publish the relevant log search and transaction statistics. If it was CPRWeb, publish the query log and per-user statistics. If it was another system-to-system product, publish the monthly statistics, system user and client-side user attribution. Product identity determines which control record should exist.
Product identity, transaction semantics, limits, approvals, IP or certificate history and the exact control path that applied during the incident.
Without the product, every claim about which control failed remains incomplete. Name the route, then show its trail.
The public still lacks the exact request count, peak rate, normal baseline and exact CPR product used. Those missing numbers decide whether the public can test when the activity departed from normal customer behavior and how long the detection chain took to react.
One request may return zero, one or multiple person objects depending on the product and query. Failed enumeration attempts would increase the real request count. The company and product must be disclosed before an exact request rate can be calculated from public data.
CPR documents several private access paths. Some are manual, some program-to-program, some support recurring or large-population data flows. The product decides which credentials, logs, approvals, counters and review duties applied during the incident.
Web-based searches for private companies. CPR describes searches using identity information and returns current name, address and related permitted data.
Program-to-program communication from a customer system to CPR. A customer sends a transaction with identifying information and receives relevant CPR data in return.
Service integration for customer systems using CPR services and structured requests.
CPR person data exposed through Datafordeler services. CPR lists REST and GraphQL for private customers. Pricing is tied to transactions or returned person objects.
Status and change extracts can deliver flat files, including recurring updates for defined populations.
Names, addresses, CPR numbers and other information were obtained by unauthorized parties. Access can be closed. Copies already obtained cannot be pulled back by disabling the account. The risk therefore continues after containment and can outlive the incident response.
The ministry tells citizens never to provide passwords or confidential information merely because an incoming call, email or message appears to know those identity details. The same data can keep making phishing, impersonation and social-engineering attempts more convincing long after one access path is disabled.
CPR published a notice stating that private companies’ access to CPR had been restored at 11:57. The public material reviewed for this snapshot does not identify the concrete monitoring, throttling, suspension or access-control changes completed before restoration. Publish those changes and their timestamps.
Later on 5 October, after briefing parliamentary committees, Christina Egelund said it was too early to say whether some citizens might need new CPR numbers after the leak. No replacement decision has been announced. The possibility itself shows how serious the remediation assessment remains.
Herning Municipality says CPR number must, for now, not be used as the sole basis for identifying a citizen and has tightened identity checks. That is a concrete downstream consequence of the breach, not a theoretical risk model.
A route can be disabled in minutes. A copied identity record cannot be made secret again by flipping that switch. The downstream burden can mean stronger identity checks, time spent proving who you are, documenting fraud attempts, contacting banks or authorities and staying alert to convincing impersonation for years. The public record reviewed here does not say who covers that time or cost when the burden lands on the people whose data was taken.
The official pages give an aggregate figure and one protection exception. They still do not give a person an incident-specific answer showing whether that person's record was queried, which fields were returned, when it happened or through which product.
The 8.8 million figure includes living people, people who moved abroad and deceased people. CPR says names and addresses of people with name and address protection were excluded from the unauthorized access.
For an individual, the unanswered questions remain basic: was my record queried, which fields were returned, when did it happen, through which product and how many times?
Depending on the product used, CPR’s own terms describe per-query logs, Logpoint records, monthly transaction statistics and user attribution. The undisclosed product determines which trail can map the incident back to people and requests.
CPR is operated through the CPR administration. Datatilsynet is the independent supervisory authority. Its 5 October notice says the case is under investigation and responsibility has not yet been established. That is a starting point, not the end of accountability. The public record reviewed here still does not answer what prior supervisory work tested around private CPR access, automated high-volume lookups or the controls meant to catch abuse.
Datatilsynet’s own description says it supervises compliance with data-protection rules, handles complaints and carries out inspections of public authorities and companies. The breach path belongs to CPR and the private access route. The supervisory history is a separate accountability record that should also be published.
Publish which prior inspections, audits or supervisory actions covered private-company CPR access, bulk automated querying, anomaly detection, access review and the audit trails described in CPR’s own terms. If none covered those points, say that plainly.
Datatilsynet says it is examining what happened, how it could happen and who is responsible. The outcome should identify the responsible processing roles, the control failures, any orders or sanctions and the remediation that can actually be verified.
Datatilsynet’s own guidance says breach risk must include future misuse after data leaves the controller’s control. Previous decisions recognize that personal identification numbers combined with other information can create high risk. The same standard applies here. Advice to citizens does not answer notification, affected-person mapping, remediation or accountability.
CPR says it noticed irregular behavior on 2 October. Datatilsynet says it received the notification on 4 October. The available dates do not support an accusation that the 72-hour supervisory notification deadline was missed.
When a breach is likely to create high risk, GDPR requires communication to affected people without undue delay, subject to the exceptions in Article 34. A public notice may substitute in some cases when individual communication would require disproportionate effort, but it must inform people in an equally effective way.
The official incident pages cited here still provide an aggregate number rather than an incident-specific self-check for each person. The question is operational: can the incident logs map a person to the exact queries and returned fields, and when will affected people receive that answer?
CPR says the unauthorized access did not include names and addresses for people with name and address protection. The announcement does not clearly state whether CPR numbers for that protected group were accessed. That point should be answered explicitly.
Revoking one company’s route prevents further use of that route. It does not retrieve copies already obtained or identify every downstream copy. Datatilsynet’s own risk guidance recognizes that misuse can occur years after data leaves the controller’s control.
CPR's access model is built around an identified customer, CVR, requested product and named security responsibility. The company at the center of this incident is still unnamed publicly while the investigation continues. That leaves the people whose data was obtained without a basic accountability fact.
Private Danish company. Lawful CPR search access. Access was abused by unauthorized parties. Company access has been stopped.
Company name. CPR product. Credential type. Compromise mechanism. Exact request count. Peak rate. Baseline rate. Alert thresholds. First anomaly timestamp. Full affected-person mapping. Data destination after retrieval.
People can be told to watch for fraud, but that does not answer how the access ran for days, what product was used, what the monitoring saw, who was affected or what changed before access was restored. Those answers should exist in logs, contracts, configuration, incident tickets and formal risk records.
The public download is deliberately narrow: official incident record, control matrix, written findings and hashes. I removed operational hardening matrices, error-path inventories, preproduction/password workflow details and the full crawl index from the public package because they are not established as the breach path and add attack-relevant detail without strengthening the accountability case.
The incident facts are anchored in CPR, the ministry, Datatilsynet, the minister’s reported statement, CPR’s own access terms and documented operational responses. I use the supervisory authority as a source where it has evidence, and I separately ask what supervision existed before the breach and what enforcement follows now.
I live in Denmark and my own CPR sits inside the same national identity system. I earn my living outside IT, finance my own tools and do this investigation independently. No ministry staff. No press office. No consultancy budget. A title, office or degree does not turn a failed control into a working one. Show the record.
I stopped at public, unauthenticated material. I did not test live identity paths, submit forms, enumerate CPR numbers, bypass access controls or touch private data. Operational security observations that do not establish the breach path stay out of the public download. A hard case gets stronger when irrelevant attack detail is removed, not weaker.
The company. The product. The credential. Exact request count. Peak rate. Normal baseline. First anomaly. First alert. User attribution. Affected-person mapping. Control changes before 11:57. Prior supervision. Final responsibility. These are records, not slogans.
THE DATA WAS OBTAINED. THE PUBLIC STILL DESERVES THE FULL TECHNICAL RECORD.