SearchSubscribe

P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

Breaches and Incidents

Denmark says one company's lawful access reached 8.8 million of the 11 million entries in its CPR register

A private Danish company's lawful access to the CPR register was misused to gain access to names, addresses and CPR numbers on about 8.8 million people, 80 per cent of its entries. The ministry has not named the company, said how the access was used or said what left the register.

By Parminder Kumar Sharma · · 27 min read

A dark government records room: an open laptop on a wooden desk shows a table of blank rounded rows beside a black server rack with a few indicator lights, and a shelf of identical blank grey ring binders sits behind. The headline reads Denmark's population register: 8.8 million of 11 million entries reached through one company, with the figure about 80 per cent.

8.8 million is 80 per cent of the register, and more than the people who live there

Denmark's ministry responsible for research, education and digitalisation says unauthorised persons obtained access to names, addresses, CPR numbers and more on about 8.8 million registered people, by misusing a private Danish company's lawful access to search the Central Person Register (CPR). The register holds about 11 million entries. Divide one by the other and the count is 80 per cent of the register: our arithmetic on two rounded figures, both the ministry's. The same release describes the 8.8 million as "living, emigrated, dead and others". That matters because Statistics Denmark's population page, labelled August 2026, gives 6,032,304 people with a Danish residence address. The count is bigger than the population, so at least 2.77 million of the 8.8 million, 31 per cent, are not residents. At most 4.97 million can be, which leaves between 3.83 million and 6.03 million residents in the count: between about 64 and 100 per cent of everyone who lives in Denmark. The split inside that range is not stated.

What that does not establish. It does not say who did it: the ministry says it is not possible, at this stage, to say who is behind it. It does not say what the company's role was, whether victim, route or origin, and the company is not named. It does not say that data left the register in bulk: the ministry's wording is that the unauthorised persons obtained access to the information, and TV 2 lists how many of the 8.8 million were taken out as an open question. It does not say that anything has been published, sold or used: nothing in the ministry's release, in Datatilsynet's statement or in the coverage we read reports a claim, a demand or a leak, and we did not search criminal forums or leak sites. And the figures may move. The ministry's own caveat is that further mapping of the incident may lead to the specific information being consolidated.

The second number is a rate. The release gives no duration. The minister, Christina Egelund, told the news agency Ritzau that the unauthorised access ran for about ten days, as reported by DR and TV 2, which makes that figure secondary. Taking the ten days at face value, 8.8 million records in ten days is 880,000 a day, or about 10.2 a second around the clock, if each lookup returned one person. That is derived, and it rests on two things the primaries do not give: the duration and the one-record-per-lookup assumption. A rate like that is a design question for whoever runs the register, and it is the control question this briefing returns to.

This site published a brief earlier today on a different Danish breach that also involves CPR numbers, at the Technical University of Denmark. No source we read links the two incidents. The ministry's release and Datatilsynet's statement do not mention the university, and the university's notice, as we read it on 3 October, does not mention the register. The CPR number is the only thing they share, which is why they sit in the same news cycle. It is not evidence that they are one event.

The three counts, to one scale

The bars set the ministry's two rounded figures against Statistics Denmark's. Protection is the one exclusion the ministry gives. cpr.dk's monthly table shows 152,223 current name-and-address protections on 1 October 2026, so that exclusion explains at most about 7 per cent of the roughly 2.2 million entries outside the count. The other 2.05 million are not accounted for by any source we read. The sources do not say why they were not reached.

Three bars to one scale. The register: about 11.0 million entries, 6.03 million of them residents. The 8.8 million reached: at least 3.83 million residents, 2.2 million that could be either, at least 2.77 million not residents. Not reached: about 2.2 million, of which 152,223 are name and address protections on 1 October 2026, about 7 per cent.
Drawn from Statistics Denmark's population page (6,032,304, labelled August 2026), the ministry's release of 5 October 2026 (about 8.8 million and about 11 million) and cpr.dk's protections table of 1 October 2026. The splits are our subtraction on rounded figures.

The record, with times

Times are as the source gives them, with UK time added where a Danish time is used. Danish summer time is one hour ahead of UK time.

Dates and times on the public record as of 16:00 BST on 5 October 2026. Primary rows come from the ministry's release, Datatilsynet's statement and cpr.dk; secondary rows from Ritzau-based and TV 2 reports.

  1. When
    September 2026 (days not stated)
    What the record says
    Irregular behaviour in the CPR system "during September". The minister says the unauthorised access ran about ten days.
    Basis
    Release for September. The ten days: minister to Ritzau, reported by DR and TV 2. Secondary.
  2. When
    Fri 2 Oct, evening
    What the record says
    The CPR administration becomes aware of the irregular behaviour. The minister says an employee of the administration noticed it.
    Basis
    Release. The employee: Ritzau report carried by Faglig Senior. Secondary.
  3. When
    Sat 3 Oct, and over the weekend
    What the record says
    A clearer picture that it is a security incident. The administration learns that unauthorised persons obtained access to about 8.8 million entries.
    Basis
    Release (weekend). Saturday: minister to Ritzau. Secondary.
  4. When
    Sun 4 Oct
    What the record says
    Datatilsynet receives the notification from the CPR register. A notice to two parliamentary committees is sent the same day.
    Basis
    Datatilsynet's statement. Committee notice: TV 2. Secondary.
  5. When
    Mon 5 Oct, 07:00 CEST (06:00 BST)
    What the record says
    The ministry's release is distributed through Ritzau. cpr.dk posts its notice, page metadata 07:37 UTC (08:37 BST).
    Basis
    Ritzau time stamp; cpr.dk page. Primary.
  6. When
    Mon 5 Oct, time not stated
    What the record says
    Datatilsynet publishes that it has taken the case under processing and cannot yet assess the circumstances.
    Basis
    Datatilsynet page, dated 5 October. Primary.
  7. When
    Mon 5 Oct, about 12:14 CEST
    What the record says
    The National Unit for Special Crime (NSK) says the investigation is at an early stage and highly prioritised.
    Basis
    TV 2 live blog. Secondary.
  8. When
    Mon 5 Oct, 16:00 CEST (15:00 BST)
    What the record says
    The minister was due to brief two parliamentary committees. What was said is not in anything we read.
    Basis
    TV 2, planned time. Secondary.
  9. When
    Mon 5 Oct, 16:00 BST (17:00 CEST)
    What the record says
    No source we read names the company, gives a lookup count or reports a claim of responsibility.
    Basis
    Our check at the time of reading.

Two intervals can be derived, and neither is a finding of lateness. From the Friday evening to the notification on Sunday is under three days. From the same Friday evening to the 07:00 CEST release on Monday is about 61 hours, if "evening" means 18:00. The first sits inside the 72 hours that Article 33 of the GDPR gives a controller to tell the regulator, counted from awareness, and our earlier briefing on that clock explains how it differs from what the public is told. The interval the record does not give is the other one: how long the access ran before anyone noticed. If the minister's ten days are right and every day of the access fell in September, as the release says, detection came at least about 40 hours after the last of them (the end of 30 September to the evening of 2 October). That is a derived minimum, and it holds only if "during September" is exact.

The number and the access path, as the sources draw them

The left side is the CPR number as CPR-kontoret describes it, drawn with placeholder letters because no real number belongs in a briefing. The right side is the access path as far as the ministry and Datatilsynet go, and no further. Dashed boxes are the parts they are silent on.

On the left, the ten positions of a CPR number drawn with placeholder letters: day, month and year of birth without the century, then a four-position serial number, with notes on the century and sex digits, the check rule before 2007, the room per birth date and the rule on new numbers. On the right, the access path: unnamed unauthorised persons, one private Danish company's lawful access, lookups under section 38, and about 8.8 million entries obtained. Dashed boxes mark what is not stated.
Drawn from cpr.dk's page on the structure of the number, a 2008 CPR-kontoret document, cpr.dk's page on new numbers, section 38 of the CPR Act, the ministry's release of 5 October 2026 and Datatilsynet's statement of the same day.

Two boxes do the work. The statute's list of identifiers, a CPR number, a birth date and name, or a name and address, is the key a company supplies. And Datatilsynet's account of the notification, a very large number of automated lookups "with a view to identifying valid CPR numbers", is the closest any source comes to saying how the set of numbers was assembled. It is the notifier's description relayed in Datatilsynet's words, and the first sentence of the statement says "allegedly".

What is stated, and what is not

The table sets the ministry's release, the cpr.dk notice and Datatilsynet's statement against the questions a reader will ask. Quotation marks are our translation of the Danish.

Questions checked against the ministry's release (Danish, 5 October 2026), cpr.dk's notice, Datatilsynet's statement and CPR's published documents, as of 16:00 BST on 5 October 2026. Quotation marks are our translation of the Danish.

  1. Question
    What was obtained?
    Stated
    "Names, addresses, CPR numbers etc." on about 8.8 million registered people, "living, emigrated, dead and others" (ministry).
    Not stated
    What "etc." covers. Under section 38 a private company can receive, among other things, current name and address and the date of the move, a position, marketing and credit-warning markings, a death, an emigration with a new address abroad, a contact address and guardianship, and insurers and pension funds also civil status. Which of these were in the count is not stated.
  2. Question
    Were protected persons affected?
    Stated
    The review shows the access "does not include names and addresses" of people registered with name and address protection (ministry; cpr.dk).
    Not stated
    Whether their CPR numbers were included. How the review was done. In one private-company product the omission of protected data is a setting that defaults to yes, and the standard terms say credit rating agencies are the exception, so the exclusion is what the company's class of access would predict. That is our inference.
  3. Question
    How did the access work?
    Stated
    Unauthorised persons "used a private Danish company's lawful access to search information in the CPR system within the scope of the information that private companies have access to" (ministry).
    Not stated
    Which route: CPRWeb single queries, the XML lookup services, program-to-program lookups or file extracts. The credential. Whether the company's systems were compromised, a person inside it was involved, or a public self-service function was used as a relay.
  4. Question
    Was it enumeration?
    Stated
    A "very large number of automated lookups" with a view to "identifying valid CPR numbers", from the notification; "allegedly" retrieved through automated lookups (Datatilsynet).
    Not stated
    That the numbers were guessed. The number of lookups, their rate, or the keys they carried.
  5. Question
    When, and for how long?
    Stated
    Irregular behaviour "during September"; noticed on the evening of Friday 2 October (ministry). About ten days (minister to Ritzau, secondary).
    Not stated
    The start and end dates. When the company's access was stopped.
  6. Question
    Who, and what was the company's role?
    Stated
    "Unauthorised persons"; not possible to say who is behind it (ministry). A "smaller" company (minister, secondary).
    Not stated
    The company's name. Whether it was a victim, a route or an origin. Whether any other company's access was changed.
  7. Question
    Has the access been revoked?
    Stated
    The CPR administration "has stopped the company's access" (ministry).
    Not stated
    When. What the "initiatives" to prevent similar incidents are. What the security review of CPR will cover or when it will report.
  8. Question
    Are the police involved?
    Stated
    The case is "being investigated by the police in cooperation with relevant authorities" (ministry). The NSK calls the investigation early and highly prioritised (TV 2, secondary).
    Not stated
    Any suspect, arrest or charge. Which other authorities.
  9. Question
    What has the regulator said?
    Stated
    Datatilsynet received the notification on Sunday 4 October, has taken the case under processing and will look at what happened, how it was possible and who is responsible for the processing; it cannot yet assess it.
    Not stated
    Whether formal proceedings are open. The rest of the notification.
  10. Question
    Has anything been published or demanded?
    Stated
    Nothing in the release, the statement or the coverage we read reports a claim, a demand or a leak.
    Not stated
    Whether any exists. We did not search criminal forums or leak sites.
  11. Question
    Will individuals be told?
    Stated
    Public advice: be alert, and see sikkerdigital.dk; the cyber hotline run by Styrelsen for Samfundssikkerhed (the Danish Agency for Societal Security) has extended hours, 08:00 to midnight, for the coming days.
    Not stated
    Any direct notice to the 8.8 million, or a decision to give public notice instead.
  12. Question
    How many are residents, dead or emigrated?
    Stated
    A mix of "living, emigrated, dead and others"; the register holds about 11 million, with more than 6 million living there (ministry; Statistics Denmark).
    Not stated
    The split. Our bounds are in the section above.

"Legitimate access" is a credential and an interface, not a limit

The ministry's phrase is a "lawful access to search information in the CPR system", and the release says the unauthorised persons used it "within the scope of the information that private companies have access to". Both describe the route accurately. Neither is a control. A lookup service answers a valid caller; if the caller is the wrong person, the register's own walls have not been breached, because the register is being read through the door built for reading. "Legitimate" describes the credential and the interface. It says nothing about the volume, the pattern or the purpose of what comes through them. The ministry's wording points the same way: the fields were inside the allowed scope, so the anomaly was the quantity.

The statute does set a limit, in prose. Under section 38 of the CPR Act a company may be given information about "a larger defined circle of persons" whom it has "previously identified individually", by CPR number, by birth date and name, or by name and address. A company that has already identified each person is not browsing the population. Whether any system enforces that sentence, as opposed to a contract and a fine for breaking it, is not stated. A count of 80 per cent of the register is hard to square with that sentence. The minister's own remark, in Ritzau's report, is that the security measures that should surround this type of access "have not been solid enough". She also agreed that red lights should have lit over so long a period.

Controls named in CPR's own documents, and what each leaves open. Read on 5 October 2026: the standard terms for data deliveries and for CPRWeb (English PDFs dated 16 June 2026), the CPR Direkte PRIV interface document (Danish, updated 1 July 2026) and section 38 of the CPR Act.

  1. Control as written
    Persons must be identified in advance, one by one
    Source
    CPR Act, section 38(1) and (5)
    What it leaves open
    Whether a system tests it. A legal condition, with a fine for breaking the terms.
  2. Control as written
    A security officer, one system user ID and password per program, IP address verification for batch deliveries
    Source
    Standard terms, sections 3 and 4; interface document
    What it leaves open
    The interface document lists an "IP address wrong" error. Whether the abused access was tied to an address is not stated.
  3. Control as written
    Online batches need prior approval
    Source
    Standard terms, section 3
    What it leaves open
    Whether this company had approval, and whether the system can tell a batch from a series of single lookups.
  4. Control as written
    All CPRWeb queries are logged with user ID, time and data; for program-to-program access "the CPR usually only registers the system user ID" of the client's program
    Source
    CPRWeb terms, section 3; data delivery terms, section 4
    What it leaves open
    The register may see a program, not a person. The client is asked to tie each search to an employee in its own system.
  5. Control as written
    The client's security officer checks usage statistics each month
    Source
    Both sets of terms
    What it leaves open
    A check once a month sees a ten-day pattern, at best, after it has happened.
  6. Control as written
    The CPR administration may end an agreement at once for breach
    Source
    Both sets of terms
    What it leaves open
    A remedy after the fact, not a limit on the day.
  7. Control as written
    Not in the documents we read
    Source
    All of the above
    What it leaves open
    A rate limit, a query budget, a volume cap, an alert on the share of unknown numbers, or a duty on the client to report an incident. The interface document's error list has no code for a quota. A page that is silent is not proof that the system is.

Read together, the documents put the monitoring at the customer's end and the logging at the register's, and they leave a gap between them. The register's own record may show a program, the customer is asked to read a monthly summary, and the CPR administration says it noticed on the evening of 2 October. What prompted the notice, whether a register-side alert, a monthly report or a person's eye, is not stated.

Rate limits are the control question, and they are not exotic. NHS England's Personal Demographics Service FHIR API states a default of 5 transactions a second per application and returns an error above it. Companies House states 600 requests in five minutes per application, which is 2 a second, and reserves the right to ban applications that regularly exceed or try to bypass the limit. Over ten days those ceilings allow 4.32 million and 1.73 million requests, 49 and 20 per cent of 8.8 million. A budget of one a second would allow 0.86 million, 10 per cent. These are different services with different users, so the comparison is one of scale, and a ceiling that can be raised on request, as both of these can, is a decision somebody owns and not a wall. The point is that each is a number a person chose and published. For CPR we found none.

Bars to scale for lookups in ten days: at least 8.8 million implied by the ministry's count and the minister's ten days, about 10.2 a second; 4.32 million at the NHS England PDS default of 5 a second; 1.73 million at the Companies House limit of 600 requests in five minutes; 0.86 million at one a second. Below, a strip of September and early October shows a ten-day window of unknown position against a one-month check and the dates of detection, notification and release.
Arithmetic on the ministry's 8.8 million, the minister's ten days (secondary), the NHS England Digital PDS FHIR API page and the Companies House API rate-limiting page, all read on 5 October 2026. The window's position in September is not stated.

Who owns the number? cpr.dk says the ministry is the controller for CPR and that DXC Technology, a company, operates and develops the system as its data processor; the interface document we read is credited to DXC. Nothing we read ties DXC to the incident, and no source says which party sets query limits. Datatilsynet says it will look at who is responsible for the processing. Under the standard terms, a company that receives CPR data is the controller for what it received. Those three facts are why a regulator will have a long file.

The number is an identifier and, in Denmark, a de facto shared secret

A CPR number has ten digits. The first six are the birth date, the last four a serial number, and the tenth digit says whether the person is a man or a woman. So the number is not a random handle: it carries a date and a sex. The Record notes that it is used for healthcare, banking and government transactions. Danish commentators in the coverage say it has also been treated as something only the person and their institutions know, and the ministry's own release shows the limit of that. It reminds people never to hand over passwords or confidential information to a caller or an e-mail sender "even if the recipient appears to know your name, address and CPR number". That is an official statement that knowing all three is not proof of identity.

Secondary reactions on 5 October show how far the secret status has slipped. Dansk Industri, the employers' organisation, told TV 2 that companies can no longer treat a CPR number as sufficient proof of a customer's or an employee's identity, and recommended MitID, security questions or a customer-portal login. Haderslev municipality said its staff will ask control questions when a caller identifies themselves by number. A cybersecurity professor told DR that the era of treating CPR numbers as something others do not know must be over. These are reactions and not findings, and we name no one.

The tail is long because the number is. CPR-kontoret's 2008 document says a number is never reused and always follows the person. Its page on new numbers says one can be issued only in special cases where the number is part of actual misuse of the person's identity, usually in several cases over time, with documentation and a police report. Fear of future crime does not by itself justify a new number. The ministry's advice instead points to alertness and, on concrete suspicion, a credit warning: a marking in CPR that makes it harder to take out credit in your name. On 1 October 2026 cpr.dk counted 240,632 active persons with one, about 4 per cent of 6.03 million residents (our arithmetic). Whether the criteria for a new number will change for this incident is not stated.

Does "automated lookups to identify valid CPR numbers" mean enumeration? The words are Datatilsynet's, relayed from the notification, and they are consistent with it. They do not say it, and nobody has said which keys the lookups carried. The arithmetic shows why the idea is not far-fetched. Birth dates from 1937 to 2026 are 90 years of 365.25 days, 32,872 dates, at up to 6,000 serial numbers each: about 197 million numbers in the format, against a register of 11 million entries in all. At most about one candidate in eighteen is real, before any pruning. Before 2007 a published check rule removed most candidates, since the 2008 document counts about 540 of the 6,000 per birth date as carrying a valid check digit. A defender should assume a number space of that size can be searched.

On the statute's list, the CPR number is a key a company supplies, not a field it is entitled to receive. A count of CPR numbers with names and addresses is what a sweep of guessed keys would leave: each hit confirms a valid number and returns the name and address behind it. That is our inference from the statute and Datatilsynet's wording, not a statement by any authority. The interface document for one private-company lookup product, CPR Direkte PRIV, is public. Its request carries one CPR number and its response returns data if the number exists and an "unknown number" error if not. Which product the company used is not stated. The relevance is to the control: a service that tells a caller "exists" from "unknown" gives one bit per lookup, and a run of unknowns is a pattern an alert can watch for.

The UK angle: no single number, several bulk feeds, the same control question

The UK has no single number doing the CPR's job across health, tax, banking and government. It has narrower ones, and each has a published rule about who may use it.

UK identifiers and bulk feeds, as the publishers describe them. Read on 5 October 2026: NHS England Digital, GOV.UK, the ICO's electoral register page (last updated 8 March 2024, flagged as under review) and Companies House's developer specification.

  1. Identifier or feed
    NHS number and the Personal Demographics Service
    What the published source says
    An NHS number alone is unlikely to identify someone, but should be treated as an identifier wherever the viewer can reach a system that links it to identifiable details, such as PDS. The PDS FHIR API needs a legal basis and a valid use case at onboarding, a default of 5 transactions a second per application, and for healthcare-worker access strong authentication and role-based access.
    The control question
    Who may raise the 5, and does the request leave a record?
  2. Identifier or feed
    National Insurance number
    What the published source says
    Two letters, six numbers and a final letter, the same for life, not to be shared with anyone who does not need it (GOV.UK). The format as described includes no birth date.
    The control question
    What else in your processes accepts it as proof of identity?
  3. Identifier or feed
    Electoral register
    What the published source says
    Credit reference agencies, and government departments for duties such as crime prevention, can buy the full register, and passing it on without a lawful reason is a crime. The open register can be bought by anyone (ICO).
    The control question
    What stops a licensed copy being used beyond its purpose?
  4. Identifier or feed
    Companies House API
    What the published source says
    600 requests in five minutes per application, an HTTP 429 error beyond it, and the right to ban applications that regularly exceed or attempt to bypass the limit.
    The control question
    Is your own limit as explicit?

The regulators' guidance asks for the controls the Danish documents do not describe. The ICO's security outcomes guidance says access to personal data should be understood, documented and limited, that you should "appropriately constrain legitimate access" and keep an audit trail, and that you should monitor user access to personal data "including anomalous user activity". The NCSC's supply chain principles ask you to understand what access suppliers have to your information and how you control it, to keep supplier connections "limited, controlled and monitored", reviewed periodically and removed when no longer required, and to set incident-reporting requirements in contracts, including timescales. Under Article 33(2) of the UK GDPR a processor must tell the controller without undue delay, and the controller has 72 hours, where feasible, to tell the regulator. Since 30 September 2026 that regulator is the Information Commission (S.I. 2026/1015), although the ICO pages we read still carry the ICO's name and two of them say they are under review after the Data (Use and Access) Act.

The Danish case has three parties: the register, a licensed consumer, and whoever turned up holding the consumer's credential. A UK organisation can sit in either of the first two. As a consumer, the credential you hold is a key to somebody else's register: its misuse is an incident you owe the provider notice of, and one they should be able to cut off without asking you first. As a provider, the budget and the alert are yours to design. Our briefing on Sweden's fine on a processor shows how far one supplier's breach can reach, a fifth of a country's people. The French tax authority's own report describes stolen staff passwords opening two portals with no second factor. The Pentagon's breach letter said "accessed" and not "stolen", 64 days after discovery, and an account of a firewall rule shows a path that sat open for years before it mattered. Nothing in the Danish record says the CPR case resembles any of them.

What to do, in the order worth doing it

The list is for a UK organisation that consumes a bulk feed or an API, provides one, or both. It is ours, drawn from the controls the Danish documents describe and the UK guidance above, and it is not a claim that any Danish party skipped a step.

Take this with you

Actions, in order

  • List every data feed you consume and every one you provide: registers, bulk files, APIs and partner credentials. For each, write down the fields returned, the legal basis, the owner and who can use the credential.
  • For feeds you consume, find the credential and where it lives: a person, a program or a shared service account. Check which people and systems can use it, whether it is tied to an address or network, and read the usage report your supplier gives you this week, not at month end.
  • For feeds you provide, give every credential a rate limit and a daily budget set from the customer's real use, with a named person who can raise it. A budget anyone can raise by e-mail is a request, not a control.
  • Alert on patterns and not only totals: a high share of not-found answers, keys that run in sequence, steady rates through the night and the weekend, and volume far above the customer's own population. Test that the alert fires and that a named person is paged.
  • Make the logs name the person or job behind a shared credential. If the supplier logs only a program identity, log the human or the job on your side.
  • Put incident terms in the contract: a notice period in hours, in both directions, who may cut access without asking first, and what usage data the other side must hand over.
  • Run a revocation drill: time how long it takes to disable one credential, one address range and one customer, on a weekend. The Danish record says the access was stopped. It does not say how long that took.
  • Return only the fields each customer needs, and decide whether an answer that says a key exists or does not is needed at all.
  • Pre-write the notice for the people on the feed: the fields, the likely consequences such as targeted phishing and identity fraud, what you are doing, a contact and advice. Decide the channel for people who have left or died, for whom a letter may have no recipient.
  • Treat identifiers as identifiers. Do not accept a national number plus a name and address as proof of identity for anything that matters. Add a second factor or a question you can verify.

Method, interest and what could change the picture

The ministry's release, cpr.dk's notice and Datatilsynet's statement are the primary record, and we quote the Danish and give our translation. The ministry is the controller for CPR and has its own interest in the framing; its release is unusually specific about the legal route and the exclusion of protected persons, and it says what it does not yet know. The Record is a pointer. It reports the same core facts, and the points where it adds colour are labelled: it says this is the most significant CPR incident since 2015, and the 2015 case, as DR described it in 2016, was two unencrypted CD-ROMs of health-register data keyed by CPR numbers, sent by Statens Serum Institut and delivered to the wrong company, which said in writing that nobody there had viewed or copied the data. That was not a breach of the register, and we cannot confirm The Record's comparison. A cybersecurity professor quoted by DR calls this the biggest breach ever against the Danish CPR register. That is a view and not a finding.

We name only the minister, who is named in the ministry's own release. Everyone else, including the police officer, the professor and the consultants quoted in the coverage, is given by role. We have no commercial interest in the story. The CPR documents we read are a mix of long-standing and recent: the structure page and the standard terms are current, the interface document is dated 1 July 2026, and the number-space document dates from 1 July 2008, so its capacities describe the design and not today's usage. The cpr.dk protections table is monthly. The interface document is a public page, and we read it at defender level: what a request carries and what a response says, with nothing about how to use it.

Things that could be overtaken within the hour, as of 16:00 BST on 5 October 2026: the company being named; a lookup count or date range; the outcome of the 16:00 CEST committee briefing; a police statement, arrest or charge; a claim of responsibility, extortion demand or publication; Datatilsynet opening proceedings; the ministry consolidating the 8.8 million; and an English version of the release. We could not confirm the ten days from a primary source: it rests on the minister's remarks to Ritzau as reported by DR, TV 2 and Faglig Senior. We found no time stamp for Datatilsynet's statement. Our resident bounds assume all 6.03 million residents are in the register's 11 million, and the two counts differ slightly in coverage, as Greenland shows.

The question that exposes the gap

If one valid credential you hold or issue began returning close to a million records a day, which alarm would ring first, who would it wake, and could they cut the credential off before the second day?

Key facts

Sources

  1. PrimaryThe ministry's release of 5 October 2026, Danish, read in full: 8.8 million, living, emigrated, dead and others, a private company's lawful access, protected persons excluded, access stopped, Datatilsynet notified, police, the section 38 fact box, the minister's statement, hotline hours.Forsknings-, Uddannelses- og Digitaliseringsministeriet (ministry)accessed 2026-10-05
  2. PrimaryThe same release as distributed, stamped 5 October 2026 07:00:00 CEST, used for the time of publication.Ritzau press service (the ministry's release)accessed 2026-10-05
  3. PrimaryThe CPR administration's own notice of 5 October 2026, Danish: the incident in short, protected persons not included, police and Datatilsynet; page metadata 07:37 UTC.CPR-administrationen (cpr.dk)accessed 2026-10-05
  4. PrimaryDatatilsynet's statement of 5 October 2026, Danish: notification received Sunday 4 October, a very large number of automated lookups to identify valid CPR numbers, case under processing, no assessment yet.Datatilsynet (Danish Data Protection Agency)accessed 2026-10-05
  5. PrimaryHow a CPR number is built, Danish: positions 1 to 6 birth date, 7 to 10 serial number, century from positions 5, 6 and 7, position 10 sex, modulus 11 check until 1 October 2007.CPR-kontoret (cpr.dk)accessed 2026-10-05
  6. PrimaryCPR-kontoret document 'Personnummeret i CPR-systemet' of 1 July 2008, Danish, read in full: numbers never reused, 8,781,985 numbers assigned on that date, 4,000 or 6,000 serial numbers per birth date, about 540 with a check digit, the check method.CPR-kontoret (cpr.dk)accessed 2026-10-05
  7. PrimaryOverview of CPR access products for private companies, Danish: web search access, program-to-program communication and extracts.CPR-administrationen (cpr.dk)accessed 2026-10-05
  8. PrimaryCPRWeb, Danish: a company that knows a person's name and a birth date, CPR number or former address gets current name, position, address, move date, marketing protection and any date of death.CPR-administrationen (cpr.dk)accessed 2026-10-05
  9. PrimaryCPR Direkte, Danish: program-to-program transactions from the customer's system to CPR.CPR-administrationen (cpr.dk)accessed 2026-10-05
  10. PrimaryCPR Services, Danish: lookups in XML format, delivered on the same terms as CPRWeb.CPR-administrationen (cpr.dk)accessed 2026-10-05
  11. PrimaryInterface document for CPR Direkte PRIV, Danish, updated 1 July 2026: a request carries one CPR number, data returned if it exists, an unknown-number error, authentication with token, IP address error, protected persons omitted by default, no quota code in the error list.CPR documentation (Confluence), credited to DXC Technologyaccessed 2026-10-05
  12. PrimaryStandard terms and conditions for data deliveries from CPR to private enterprises, English PDF dated 16 June 2026, read in full: section 38, security officer, one system user ID per program, IP verification, prior approval for online batches, monthly transaction statistics, termination.Ministry of Science, Higher Education and Digital Affairs (CPR Administration)accessed 2026-10-05
  13. PrimaryStandard terms for private access to CPRWeb, English PDF dated 16 June 2026, read in full: section 39, all queries logged, monthly check of transaction statistics, protected names and addresses not available.Ministry of Science, Higher Education and Digital Affairs (CPR Administration)accessed 2026-10-05
  14. PrimaryThe CPR Act, consolidated act no. 1010 of 23 June 2023, marked in force, section 38 read in full through a browser: the larger defined circle, the list of data in subsection 2, the identification keys in subsection 5.Retsinformation (Danish law database)accessed 2026-10-05
  15. PrimaryMonthly table of protections in CPR: 152,223 current name-and-address protections and 240,632 active persons with a credit warning on 1 October 2026.CPR-administrationen (cpr.dk)accessed 2026-10-05
  16. PrimaryThe ministry as controller for CPR, the categories of data held, DXC Technology as processor operating the system.CPR-administrationen (cpr.dk)accessed 2026-10-05
  17. PrimaryThe CPR administration's place in the ministry's department.CPR-administrationen (cpr.dk)accessed 2026-10-05
  18. PrimaryWhen a new CPR number can be issued: documented misuse of identity, usually several cases, a police report; fear of future crime not enough on its own.CPR-administrationen (cpr.dk)accessed 2026-10-05
  19. PrimaryOfficial advice of 5 October 2026: be alert to contact that uses your details, credit warning on concrete suspicion, hotline hours 08:00 to midnight.Sikkerdigital.dk (Danish Agency for Societal Security)accessed 2026-10-05
  20. PrimaryPopulation page: 6,032,304 people with a Danish residence address, labelled August 2026.Statistics Denmarkaccessed 2026-10-05
  21. PrimaryPolice item of 18 March 2026 on a different, earlier abuse of CPR lookups by an insider at a municipal office; used only to show the category exists.Danish police (National Unit for Special Crime)accessed 2026-10-05
  22. PrimaryThe electoral register page, last updated 8 March 2024 and flagged under review: full register users, the offence of passing it on, the open register.Information Commissioner's Officeaccessed 2026-10-05
  23. PrimaryPDS FHIR API: legal basis and valid use case, access modes, default rate limit of 5 transactions a second per application, 429 error.NHS England Digitalaccessed 2026-10-05
  24. PrimaryNHS numbers as identifiers, last edited 7 May 2026: an NHS number alone is unlikely to identify someone but is an identifier where a linking system is reachable.NHS England Digitalaccessed 2026-10-05
  25. PrimaryThe National Insurance number: format, same for life, do not share with anyone who does not need it.GOV.UKaccessed 2026-10-05
  26. PrimaryAPI rate limiting: 600 requests in five minutes per application, 429 beyond, right to ban applications that exceed or bypass the limit.Companies Houseaccessed 2026-10-05
  27. PrimarySecurity outcomes: identity and access control, constraining legitimate access, audit trail, monitoring anomalous user activity, processors and the supply chain.Information Commissioner's Officeaccessed 2026-10-05
  28. PrimarySupply chain principles 4 to 9: supplier connections limited, controlled and monitored, reviewed and removed; incident reporting requirements and timescales in contracts.National Cyber Security Centreaccessed 2026-10-05
  29. PrimarySupply chain principles 1 to 3: know what access suppliers have and how it is controlled.National Cyber Security Centreaccessed 2026-10-05
  30. PrimaryPersonal data breaches: 72 hours, telling individuals, processor duty under Article 33(2), phased notification.Information Commissioner's Officeaccessed 2026-10-05
  31. PrimaryUK GDPR Article 33, notification of a breach to the regulator, including the processor's duty in paragraph 2.legislation.gov.ukaccessed 2026-10-05
  32. PrimaryS.I. 2026/1015: the office of Information Commissioner abolished and its functions transferred to the Information Commission from 30 September 2026.legislation.gov.ukaccessed 2026-10-05
  33. Reported byReport of 5 October 2026 that prompted this briefing, used as a pointer: 8.8 million, a domestic company's access, the 2015 comparison, expert comments.The Record from Recorded Future Newsaccessed 2026-10-05
  34. Reported byReport of 5 October 2026, published 07:17 CEST, relaying the ministry's release.DRaccessed 2026-10-05
  35. Reported byReport of 5 October 2026 with a cybersecurity professor, the minister's ten days to Ritzau, and the NSK investigation.DRaccessed 2026-10-05
  36. Reported byLive blog of 5 October 2026: ten days, a smaller company, the committee briefing at 16:00, reactions from Dansk Industri and Haderslev municipality, the NSK, open questions.TV 2accessed 2026-10-05
  37. Reported byReport of 5 October 2026 carrying the minister's remarks to Ritzau: about ten days, a smaller company, security measures not solid enough, an employee noticed on Friday.Faglig Senior (Ritzau-based report)accessed 2026-10-05
  38. Reported byRitzau report of 5 October 2026, 07:16 CEST: the release, Datatilsynet's statement and the NSK.Kristeligt Dagblad (Ritzau)accessed 2026-10-05
  39. Reported byReport of 5 October 2026, 09:49 CEST, repeating the release and its section 38 fact box.Version2accessed 2026-10-05
  40. Reported byOverview of 20 July 2016 of the 2015 CD-ROM case: Statens Serum Institut discs delivered to the wrong company; used to qualify The Record's 2015 comparison.DRaccessed 2026-10-05

Share this briefing

Know someone who owns this problem? Send it to them.

LinkedInXWhatsAppEmail

Related briefings

The briefing, in your inbox

Practitioner analysis of cyber and AI security news. No vendor noise.

How often

Every new briefing in one email, at 7am, or at 7am, 12:30pm and 6pm. Nothing is sent when nothing is new. Unsubscribe any time.