# The Permission That Exposed a Nation
Denmark, 8.8 million identities, and the architecture of misplaced trust
Volume 66 · Edition 3 · 2026-10-09
Category: E · Systems & Trust (https://www.thierry-gilgen-ict.ch/library/systems-trust)
Canonical: https://www.thierry-gilgen-ict.ch/field-notes/the-permission-that-exposed-a-nation
> A government may delegate access to its citizens’ data. It cannot delegate away its responsibility for what that access makes possible.
**Research cutoff: 9 October 2026.** The criminal investigation and regulatory assessment are ongoing. Numbers below are approximate unless otherwise stated.
## 1. The invoice
The first visible warning was not a photograph of a masked intruder. It was a bill.
On the evening of 2 October 2026, the administrators of Denmark’s Central Person Register became aware of unusual activity from September. Officials later described the clue: a much larger-than-expected charge for lookups conducted through a smaller Danish company’s account. Commercial registry access generated a cost for each query. The quantity had become too conspicuous to ignore.[^1][^2]
Three days later, the country’s authorities explained that an unauthorised party had used the company’s lawful access to retrieve records concerning roughly 8.8 million people. The company was cut off. The police and privacy regulator became involved.[^3][^1][^4]
The obvious headline writes itself: a nation exposed through a password. But that is not yet the established story. On 9 October, an anonymous claimant told *Politiken* that a password as weak as `123456`, associated with a former company employee and present in an earlier leak, had opened the way. A report relaying DR’s investigation found that such a password had indeed appeared in a leak associated with the company, while stressing that its use in this particular incident was not confirmed.[^5][^6]
That allegation may prove true. It may also require substantial revision once forensic records emerge. The more durable fact is already public: the suspicious activity passed through an authorised business connection.[^3][^1]
This is the architecture of the story. The registry did not need to disappear. The government did not have to lose every database. The system needed only one permitted path through which an attacker could do something vastly beyond the purpose for which permission had been granted.
**A legitimate door was used for an illegitimate scale of action.**
## 2. What 8.8 million means—and what it does not
The CPR is not a password vault for every public service. It is Denmark’s central civil-registration system. Its records serve identification and administration, including information used across public and private-sector interactions.[^3][^1][^7]
The confirmed accessed categories include names, addresses, CPR identification numbers and other information described only generically by authorities. The exact itemised field inventory has not been publicly established in the sources reviewed. Officials said the access did **not** include the names and addresses of people protected by Denmark’s name-and-address protection arrangement. That statement is narrower than saying those individuals were not exposed in any field or at all.[^3][^1]
The government said the CPR held about 11 million registered individuals. It explicitly included people who had left Denmark and those who had died. Comparing the 8.8 million affected records to the country’s contemporary resident population would inflate the apparent share, and claiming that the breach affected “every Dane” would turn an already enormous incident into a false statistic.[^1]
Approximately 8.8 million affected registered people against roughly 11 million records in Denmark’s CPR, including former residents and deceased people. The ratio is indicative because both values are rounded.
This is a breach of confidentiality: information was obtained by someone who was not entitled to receive it. Public reporting does not establish that the core register was destroyed, that records were irretrievably deleted, or that tax, medical, banking, and police databases were all extracted.[^3][^4]
That precision is not a minor editorial courtesy. Exaggeration makes accountability harder. Authorities, suppliers, politicians and security engineers must answer for the mechanism that actually failed—not for an imaginary total system collapse.
## 3. An authorised path, an unauthorised operation
Denmark permits certain private organisations to retrieve defined information from the CPR within a legal framework. Section 38 of the CPR Act describes rights to receive information regarding a defined group of persons previously individually identified, subject to legal conditions. The exact terms of this specific company’s access agreement have not been published in the sources examined.[^7]
A company being allowed to look up information is not equivalent to the company being authorised to compile a population-scale dataset.
The difference can appear trivial at the level of a single request. An approved client presents acceptable credentials. An application asks for a record. The registry returns what the client’s permissions allow. No obvious perimeter has been crossed.
Repeat the transaction millions of times and the security question changes. What was proportionate for a customer check can become extraction at national scale. A control that decides only whether an organisation *may access a field* does not necessarily decide whether a particular sequence of requests is legitimate in context.
The regulator said automated lookups were made to identify valid CPR numbers. Reports drawing on the notification say there were about 14 million searches—a number far beyond the company’s customer base—and that the company denied initiating them.[^4][^8]
Danish officials established misuse of a private company’s lawful CPR lookup rights; automated searches and large-scale access followed. The supposed leaked password and separate export programs remain attributed hacker claims.
The alleged initial credential route matters for remedial action. It raises questions about offboarding, password strength, account rotation, multifactor authentication, credential monitoring and remote access. But those should remain **investigation questions**, not a disguised verdict about which protections were or were not deployed. Public source material does not independently establish the full authentication stack, the internal systems traversed, or the method of external transfer.[^5][^6]
Even if a complicated exploit is ultimately found, the wider issue remains: a third party was able to trigger an extreme number of legitimate-looking operations before access was stopped.
Permission is a starting condition. It is not a complete security model.
## 4. A sovereignty problem with a clock
The timeline matters at least as much as the scale.
The official ministry statement says administrators noticed September irregularities on **2 October**; the regulator confirms receiving notification on **4 October**, and the government disclosed the incident on **5 October**.[^1][^4]
Reporting published on **9 October** says the unauthorised access window ran from **10 September** until **2 October**, approximately 21 days and 17 hours. The investigation’s preliminary account places actual exploitation from **10 September to around 20 September**. These are different intervals: *access remained possible* is not the same as *confirmed continuous harvesting*.[^8]
The hacker, separately, claims an entry date of **11 September**. That discrepancy is unresolved. The access-window account—press-reported from TV 2’s reading of a regulatory notification, not an official publication—takes precedence for the timeline visualisation; the claimant’s date is noted but not silently merged into it.[^8][^5]
Reported period of unauthorised access from 10 September to 2 October 2026, with apparent active harvesting until about 20 September. The regulator was notified on 4 October; disclosure followed on 5 October. The hacker’s claimed 11 September entry is not shown.
A state can own its systems, define legal permissions and prosecute unauthorised access. Yet a critical element of operational control is *time*: the interval between misuse, detection, decision and effective revocation.
Consider the sequence. Suspicious lookups reportedly ended around 20 September. Revocation came on 2 October. Even if no further data were taken in between, the apparently exploitable access survived after the main harvesting interval.[^8]
Detection is not only an information-security problem; it is an exercise of authority. Before a registrar can revoke a permission, it must know the permission is being misused. A right to intervene that operates only after a fortnight of silent extraction is weaker than it looks on an organisational chart.
The finding connects to a broader argument in this Library: sovereignty is operational, and operational sovereignty has a clock. That does not mean every breach proves a state lacks sovereignty. It means claims of control should be tested against the actual time it takes to detect, decide and contain misuse.[^9]
## 5. The identifier that survives the breach
A CPR number identifies a person. It should not be treated as a reusable secret proving that the person presenting it is the person to whom it belongs.
The distinction sounds elementary. Identification asks: *Which record are we talking about?* Authentication asks: *What proves this claimant controls a valid authenticator for that identity?* Modern digital identity guidance makes the difference foundational. An identifier is what an authenticated session can assert; it is not, by itself, an adequate authentication factor.[^10]
Static personal details can help locate a person in a database, but cannot by themselves prove that the claimant controls a valid authenticator. Based on NIST guidance and the Danish business alert.
The Danish breach is an illustration of why this matters. A mass release of stable numbers can lower the cost of impersonation attacks wherever a business still mistakes familiarity with a personal record for proof of legitimacy. Industry guidance issued after the incident expressly warned organisations against relying on CPR numbers, names and addresses as stand-alone verification of a customer’s identity.[^11]
The risks include targeted phishing, social engineering and fraud against services with weak identity checks. Those are credible exposure scenarios, not evidence that every affected person has suffered financial fraud or that stolen CPR numbers alone grant access to MitID or bank accounts. We should not frighten people with claims the mechanism does not support.
There is also a stubborn asymmetry. Passwords can be reset. An administrative identifier is designed to remain stable. Even if the compromised account is closed and the registry perimeter repaired, a copied dataset—if retained—can continue to provide contextual material for later attacks. The incident has a short operating window and potentially long-lived consequences.
And that leads to a difficult policy question. The answer cannot simply be to change every identifier. That could introduce administrative disruption without correcting organisations that use identifiers as secrets. The more defensible priority is to remove identifier-only trust from sensitive transactions, strengthen fraud controls, and design future credentials to disclose only what is necessary.[^10][^11]
## 6. The European mirror
It would be comfortable to read this as a uniquely Danish failure. It is not safe to assume the same access model, logging configuration or weakness exists elsewhere; but the underlying design tension is widely relevant.
Governments hold authoritative records. Hospitals depend on external software. Banks rely on third-party identity services. Contractors and specialist vendors need some access to deliver legitimate work. A mature digital society therefore has a growing number of *edges* at which one institution’s identity and authorisation decisions become another institution’s risk.
The question is not whether third-party access is inherently irresponsible. Modern public services cannot function without delegated operations. The question is whether delegation is constrained by **purpose, volume, scope, time, and a reachable principal able to stop it**.
Switzerland offers a useful—not equivalent—contrast in digital-identity design. Official descriptions of its e-ID and swiyu Wallet emphasise user-controlled sharing and data minimisation. In 2026, the Swiss government announced additional measures intended to limit requests for the AHV number to legally entitled parties, require providers to register the purpose of requested attributes, and enable warning or exclusion for improper use. These measures concern a **different identity architecture**; they do not prove Swiss registries are immune to bulk exposure or that every announced change is already operating.[^12][^13]
The Swiss AHV number, like Denmark’s CPR number, is a persistent administrative identifier with a specific legal regime; one should not equate either identifier with cryptographic proof of identity.[^14]
The week of Denmark’s disclosure offered two genuinely different Swiss tests of that boundary. On **9 October 2026**, in a media release distributed via EQS at 14:01, Ricardo’s parent **SMG Swiss Marketplace Group** reported that a security vulnerability had permitted unauthorised access to personal data linked to orders on its platform, relating to roughly **890,000 user accounts**. Exposed information included names, postal addresses and telephone numbers, as well as business names where applicable. SMG said email addresses and passwords were not affected and that the vulnerability had been closed. The release added that Ricardo had notified the Federal Data Protection and Information Commissioner (FDPIC).[^15][^16] In an SRF report published at 14:40 the same day, an SMG spokesperson told the news agency AWP that the affected data had at no time been freely accessible and that no unauthorised access to personal data linked to orders on the platform had been detected. According to the spokesperson, the cyberattack had so far led to neither extortion nor ransom demands.[^17] Both statements are recorded here as reported, with their times; this edition does not reconcile them. The exact vulnerability type, attacker’s route and fate of any retained external copies had not been publicly established. This is an application-security case—**not** evidence that an authorised supplier account was misused in the Danish manner.[^15][^16]
One day earlier, **Publica**, the Swiss federal pension fund, had announced in a media release published on the federal administration’s websites that one of its software suppliers had been attacked. The supplier, **PK Softech AG** in Reinach, said that malware had enabled an intrusion into part of its infrastructure and that data must be assumed to have left its systems. Publica told its members that personal data had probably left in the attack, and named information such as AHV numbers, addresses and salary and pension details that **could** be involved; which data had actually left, and how many members were affected, was not established. This is the closer structural comparison: **a public institution’s information-processing boundary reached into a private supplier’s environment**. Yet unlike Denmark’s case, it does not establish misuse of lawful population-register lookup permissions.[^18][^19][^20][^21] The final part of this chapter follows that supplier relationship further.
Three boundaries, three ways to fail: a misused lookup permission in Denmark, an intrusion at Publica’s software supplier, an application vulnerability at Ricardo. A comparative framework, not evidence of a common attacker, campaign or vulnerability.Two SMG statements on 9 October 2026, shown as reported: the 14:01 release (EQS) reported unauthorised access to personal data linked to orders for about 890,000 user accounts; at 14:40 a spokesperson told AWP (via SRF) that no such access to order-linked data was detected.
The three cases should not be merged into a single alleged campaign or exploit. Their common lesson is more exacting: *data can leave its proper audience through more than one form of permission failure, supplier compromise or application vulnerability*. **Sovereignty and stewardship have to survive every boundary—not merely the one visible in a government organisational chart.**
A proposed risk-control model: authorisation should be coupled with limits on purpose, scope, rate, observability and revocation. This is not a verified depiction of Danish CPR’s deployed technical controls.
Europe’s challenge is not simply to put more data in national data centres. Localisation can matter for jurisdiction and resilience, but a sovereign database can still be abused by an authorised intermediary in the same jurisdiction. Neither residency nor ownership alone proves operational control.
A useful test is adversarial: *What can the smallest legitimate client do with the permissions we have given it, at the maximum speed its software permits, before anyone is empowered to interrupt it?*
If the answer includes a meaningful portion of a national population register, the issue lies in the design of the delegated authority as much as in the security of the client.
### PUBLICA: when a supplier relationship becomes a shared security boundary
Few people outside the pensions trade have heard of PK Softech AG, yet its software runs inside many Swiss pension funds. The company, based in Reinach in the canton of Basel-Landschaft, builds and maintains PK/S, a core system that administers active members and pensioners in one place, together with add-ons such as the PK/S.Live member portal.[^22] In 2017, after an open tender, Publica awarded it the contract for its pensions administration application: about CHF 12.6 million covering licence, introduction, migration, maintenance and support, for an operating period of up to 16 years.[^23]
By its own account, PK Softech was attacked at the end of September. Unknown parties used malware to gain access to part of its IT infrastructure; the company says it disconnected the affected environment at once, called in outside specialists and filed a criminal complaint. According to Publica, the Office of the Attorney General has opened an investigation. Since 2 October, PK Softech says, it has again been “fully available” to its customers.[^19][^18]
From a 2017 contract to an open question in 2026. The award and the 2026 statements are dated; the attack itself can be placed only at the end of September, as the institutions describe it.
**An outflow at the supplier; an open question at the customer.** Two statements need to be kept apart. The first concerns the supplier. On 8 October PK Softech wrote that data must be assumed to have left its systems; later that day it described a “confirmed data outflow” from its own IT infrastructure, “not from our customers’ systems”, adding that whether customer data were affected was under investigation.[^19][^20] The second concerns the customer. Publica told its members that personal data had probably left in the attack, and that the analysis of which data actually had was continuing. The possible categories it listed were surname, first name, date of birth, AHV number, address, business and private telephone numbers and email addresses, pension data such as salary, insured salary and pension assets, marital status, and details of a spouse or partner. Publica’s information page adds IBAN; the email to members does not.[^24] At the end of 2025 Publica had about 70,000 active members and 41,600 pensioners.[^21] Those figures describe the fund, not the number of people affected, which has not been made public.
**The network.** Five other pension institutions are documented customers of the same supplier. The Migros pension fund and the Swiss Post pension fund both obtain software from PK Softech to administer member data, and both say they are still establishing whether their data could be involved. The Post fund states that its data held at PK Softech are anonymised and that especially sensitive records, such as disability-insurance files, are not stored there.[^25][^26] The Bern cantonal pension fund (BPK) and the Bern teachers’ pension fund (BLVK) refer to an external software supplier, which the BPK says is the same company that serves Publica. The canton of Bern says there is no indication that either fund’s data were stolen, though this cannot be ruled out entirely.[^27][^28][^29] The Syngenta pension fund runs a PK/S.Live member portal that PK Softech provides and maintains; no statement about the incident from Syngenta could be found by 10 October.[^30] A customer list is not a victim list. At the research cutoff, no outflow of any of these funds’ data had been confirmed.
One supplier, multiple pension institutions. The links represent documented software relationships, not confirmed data exfiltration.
**Why federal, cantonal and corporate funds share one dependency.** A federal fund, two cantonal institutions and three company funds have different sponsors and different members. What they share is the administrative work of occupational pensions, which, according to PK Softech, is mostly done on standard software offered by about 15 vendors across Switzerland.[^22] Buying such a product means sharing a supplier with others. It does not show that the same version, the same hosting location, the same administrator access or the same security weakness is involved. A shared product, a shared supplier, shared hosting, shared infrastructure, shared administrator access and a shared failure are six different findings. What the public record shows is the shared supplier and, as the place where the attack occurred, that supplier’s own infrastructure.
**Different statements, different degrees of certainty.** Publica’s release was headed “data leak confirmed”, yet its text said that the extent to which Publica data were affected was still being established.[^18] PK Softech wrote that its test systems hold no clear-text data “as a rule”, without saying whether the affected environment was a test system.[^20] The BPK’s director told Keystone-SDA that, according to the software company, a rather small amount of data had left, possibly business data unrelated to member files.[^31] These statements are set side by side here; they are not netted against each other.
**Restoring service is not restoring confidentiality.** “Fully available” describes availability. Publica’s sentence “Your pension assets are safe” concerns the integrity of balances and payments.[^24] Neither says whether copies of personal data are in other hands. A file that has left cannot be recalled by switching the server back on.
**Who keeps account of the data held by the supplier?** For each fund the question is not whether it licenses a product but which of its data sit with the supplier, in what form, for what purpose and for how long: support, migration or testing. The terms are not interchangeable. Properly anonymised data can no longer be linked to anyone. Pseudonymised data carry a code instead of a name, and anyone with the key or enough additional information can reverse it. Encrypted data are only as safe as the place where their keys are kept. Whether “anonymised” holds in the strict sense for the Post fund cannot be checked from public sources. For Publica’s 2017 contract, the subject, the service components and the term are public; the specification, the security requirements, the supplier’s access rights, any subcontractors, audit rights and incident-notification duties are not.[^23] None of this shows that anyone was negligent. It shows how little members or a supervisor could verify today.
**Back to operative sovereignty.** In Denmark a permission was abused; at Publica a supplier was intruded upon; at Ricardo an application failed. No common attacker has been shown. A permission boundary, a supplier boundary and an application boundary may fail in different ways. Every one of them tests whether an institution’s claimed control extends to where its information is actually handled. Operative sovereignty therefore means being able to say, within hours, which of one’s data sit with which third party, and who there can do what with them.
## 7. What a defensible control architecture would require
There is no single switch that repairs this class of failure. A credible response has several layers.
**Authenticate the operator.** Verify the identity of systems and human administrators, maintain credential inventories, revoke leavers’ access quickly, and require suitable multifactor or cryptographic authentication where technically applicable. Treat the reported weak password as a question to investigate—not a proven universal cause.[^5][^10]
**Bind access to a purpose.** Define the business reason, allowable records and permitted operations for each client. Mere organisational membership should not grant unlimited lookup authority. Review exceptions and make high-volume use require explicit approval. This is a proposed control architecture, not a claim about the exact current CPR design.
**Watch cumulative behaviour.** Monitor query rate, number of distinct people returned, unusual valid-identifier discovery patterns, spikes relative to customer population, and shifts in time of day. A million individually valid requests should not look like a million independent routine events.
**Make intervention automatic and accountable.** Define throttling, graduated circuit breakers, urgent human review, clear revocation ownership, and evidence-preserving containment. Fraud-detection heuristics will produce false positives; safety controls therefore need transparent thresholds and reviewable overrides rather than arbitrary shutdowns.
**Treat identity attributes as exposed.** Downstream relying parties should not use CPR-like identifiers or address knowledge as stand-alone authentication. Adopt risk-proportionate authenticators and transaction verification. NIST’s digital identity guidance is useful here, although it does not prescribe Danish legal responsibilities.[^10]
**Produce auditable outcomes.** After containment, publish incident boundaries, confirmed data categories, a carefully scoped chronology, governance findings, and the remediation controls that can be described without helping an attacker. The EDPB offers authoritative guidance on notification and handling of personal data breaches; it does not pre-judge this investigation.[^32]
Operational design recommendations derived from the incident’s disclosed route, not an official Danish remediation specification.
The standard should be evidence rather than theatre. A new dashboard is not proof of detection. A policy document is not proof of revocation. A vendor attestation is not proof that abnormal access will be blocked in time. The meaningful evidence is an exercise: can a simulated misuse of a lawful account be detected and constrained before it becomes a population-scale export?
## 8. The darknet question—and the limits of this edition
As of this edition’s cutoff on **9 October 2026**, the public-source review identified **no independently verified public darknet listing** offering the complete CPR dataset. That is not a certificate that the data is safe. It is simply the limit of available verification.
Confirmed exposure and automated access must not be conflated with the unverified password story, a confirmed darknet sale, or loss of all national data.
The anonymous claimant told journalists that they did not intend to sell or publish the numbers. The claimant reportedly furnished a sample or file to *Politiken*, which shared material with an expert; this lends weight to the claim of possession but not to the claimant’s motive, exclusivity of copies, or ability to prevent later circulation.[^5]
We did not buy leaked data, enter private criminal markets, interview the alleged perpetrator, inspect evidence preserved by investigators, or perform continuous leak monitoring. Therefore we cannot establish whether a private exchange took place. The honest reporting status is: **data harvesting strongly supported; public darknet sale not confirmed; onward distribution unresolved**.
The temptation to fill those gaps with certainty is understandable. It is also exactly how incident analysis turns into unreliable commentary.
## 9. Who holds the keys to a nation?
The Danish incident is not evidence that central registries should never exist. It is evidence that a registry’s security boundary is larger than the servers on which it runs.
It includes the company allowed to query it, the departed employee whose account may remain in a database, the commercial arrangement that measures usage, the security team that interprets patterns, the official empowered to revoke access, and the institutions that later treat a permanent identification number as though it were a secret.
Every one of these is an authority relationship. Every one can fail at a different speed.
We should eventually have a better forensic record of who obtained access, how they authenticated, what data they retained, and whether the copied material ever circulated. Those findings may change details of the narrative. They are unlikely to erase the central engineering question: **how did permission to perform an ordinary lookup become the practical ability to obtain records about millions of people?**
Digital sovereignty cannot stop at owning the database. It must reach the permissions, the behaviour, the monitoring, the revocation process, and the identity assumptions of every system that relies upon its contents.
> **The state may hold the registry. The risk lives in every door it authorises.**
---
## Sources
[^1]: Danish Ministry of Research, Education and Digitalisation (Forsknings-, Uddannelses- og Digitaliseringsministeriet), press release (distributed via Ritzau), 5 October 2026. [Omfattende uautoriseret adgang til borgeres CPR-oplysninger](https://via.ritzau.dk/pressemeddelelse/15205753/omfattende-uautoriseret-adgang-til-borgeres-cpr-oplysninger?publisherId=2869389). In Danish. About 8.8 million affected registered persons, including living, emigrated and deceased; a register of about 11 million; irregular activity noticed on 2 October.
[^2]: The Local Denmark, 6 October 2026. [Danish national registry hack only discovered after unusually large invoice](https://www.thelocal.dk/20261006/danish-identity-number-breach-only-discovered-after-unusually-large-invoice). Ministry department head Mikkel Leihardt on the invoice as the detection cue.
[^3]: CPR Administration, official incident notice, 5 October 2026. [Omfattende uautoriseret adgang til borgeres CPR-oplysninger](https://www.cpr.dk/cpr-nyt/nyhedsarkiv/2026/okt/omfattende-uautoriseret-adgang-til-borgeres-cpr-oplysninger). In Danish.
[^4]: Datatilsynet, 5 October 2026. [Datatilsynet er opmærksom på sag om opslag i CPR](https://www.datatilsynet.dk/presse-og-nyheder/nyhedsarkiv/2026/okt/datatilsynet-er-opmaerksom-paa-sag-om-opslag-i-cpr). In Danish. Report received on 4 October; very large number of automated lookups to identify valid CPR numbers.
[^5]: Ritzau via The Copenhagen Post, 9 October 2026. [Hacker claims simple password allowed access to 8.8 million Danish CPR numbers](https://cphpost.dk/2026-10-09/news/round-up/hacker-claims-simple-password-allowed-access-to-8-8-million-danish-cpr-numbers/). Reports an anonymous claimant’s account to *Politiken*; the claims are not independently confirmed.
[^6]: DR reporting, relayed by ddig.dk, 9 October 2026. [DR: Fynsk softwarevirksomhed er i centrum for historisk CPR-læk](https://ddig.dk/dr-fynsk-softwarevirksomhed-er-i-centrum-for-historisk-cpr-laek). In Danish. A syndicated summary; it states that the leaked password is not confirmed as the credential used.
[^7]: Danish CPR Act (CPR-loven), consolidated text 2023, section 38. [Retsinformation](https://www.retsinformation.dk/eli/lta/2023/1010/dan). In Danish.
[^8]: Ritzau via DK-Sundhed, 9 October 2026. [Medie: IT-kriminel havde adgang til CPR-register i 21 dage og 17 timer](https://www.dk-sundhed.dk/ritzau/f67ea040-b0ff-42b4-bb4b-aed78c817286). In Danish. TV 2’s reading of the notification to Datatilsynet, obtained through access to documents; the notification itself was not independently examined.
[^9]: Thierry Gilgen, Library, 23 July 2026. [Sovereignty Is Measured in Response Time](https://www.thierry-gilgen-ict.ch/field-notes/sovereignty-is-measured-in-response-time). A conceptual reference, not evidence about the Danish incident.
[^10]: NIST, July 2025. [SP 800-63B-4: Digital Identity Guidelines — Authentication and Authenticator Management](https://csrc.nist.gov/pubs/sp/800/63/B/4/final); [technical text](https://pages.nist.gov/800-63-4/sp800-63b.html). American guidance, not a Danish legal obligation.
[^11]: DI Digital (Confederation of Danish Industry), 6 October 2026. [8,8 millioner CPR-numre er lækket. Sådan beskytter du din virksomhed](https://www.danskindustri.dk/brancher/di-digital/nyhedsarkiv/nyheder/2026/10/cpr-lak/). In Danish.
[^12]: Swiss Confederation, e-ID. [Die elektronische Identität (e-ID) — Wie funktioniert die e-ID?](https://www.eid.admin.ch/de/e-id/wie-funktioniert-die-e-id) In German. Accessed 9 October 2026.
[^13]: Swiss Federal Council, 25 February 2026. [Akzeptanz der E-ID mit zusätzlichen Massnahmen stärken](https://www.eda.admin.ch/de/newnsb/L6Nbf7gStnDm). In German. Announced measures, not yet a description of an operating system.
[^14]: Central Compensation Office (ZAS), 5 March 2026. [AHV-Nummer](https://www.zas.admin.ch/de/ahv-nummer-identifikator). In German.
[^15]: SMG Swiss Marketplace Group Holding AG, media release via EQS, 9 October 2026, 14:01. [Ricardo fixes security vulnerability affecting user data](https://www.boersennews.de/nachrichten/meldungen/eqs/ricardo-fixes-security-vulnerability-affecting-user-data/5306126/); [mirror](https://www.finanzwire.com/press-release/smg-swiss-marketplace-group-holding-ag-etr-ricardo-fixes-security-vulnerability-affecting-user-data-mAttlF99iiE). The company’s own disclosure, not a forensic report.
[^16]: AWP via cash.ch, 9 October 2026. [SMG: 890'000 Ricardo-Nutzerkonten von Sicherheitslücke betroffen](https://www.cash.ch/news/top-news/smg-890000-ricardo-nutzerkonten-von-sicherheitslucke-betroffen-975470). In German.
[^17]: SRF News (with AWP), 9 October 2026, 14:40. [Online-Marktplatz gehackt – «Keine Erpressung» – Ricardo meldet Datenleck bei 890’000 Konten](https://www.srf.ch/news/schweiz/online-marktplatz-gehackt-keine-erpressung-ricardo-meldet-datenleck-bei-890-000-konten). In German; the SMG spokesperson’s statements to AWP are reported in indirect speech.
[^18]: Swiss Federal Pension Fund Publica, media release published on the federal administration’s websites, 8 October 2026. [Cyberangriff auf Softwarelieferant von Publica: Datenabfluss bestätigt](https://www.astra.admin.ch/de/newnsb/FjG4XOIms04s); [English version](https://www.ebg.admin.ch/en/newnsb/FjG4XOIms04s).
[^19]: PK Softech AG, 8 October 2026. [Cyberangriff auf die PK Softech AG](https://pksoftech.ch/de/newsreader/Cyberangriff-auf-die-PKSoftechAG). In German. The company’s own statement, not a forensic report.
[^20]: watson, 8 October 2026. [Cyberangriff auf Software-Lieferanten des Bundes: Hacker erbeuten Daten – Ausmass unklar](https://www.watson.ch/schweiz/digital/228405160-pensionskasse-des-bundes-cyberangriff-auf-publica-softwarefirma). In German. Reproduces PK Softech AG’s statement, its later email statement (supplier infrastructure, not customers’ systems; test systems) and Publica’s letter listing data that could be affected.
[^21]: AWP via cash.ch, 8 October 2026. [Angriff auf Publica-Lieferanten: Lohndaten könnten betroffen sein](https://www.cash.ch/news/top-news/angriff-auf-publica-lieferanten-lohndaten-konnten-betroffen-sein-975247). In German.
[^22]: PK Softech AG, product and company pages, accessed 10 October 2026. [Produkte](https://pksoftech.ch/de/produkte); [Unternehmen](https://pksoftech.ch/de/unternehmen). In German. The company’s self-description; it says nothing about hosting or access arrangements.
[^23]: Publica, open tender published 19 August 2016; contract awarded to PK Softech AG on 23 March 2017 for CHF 12,628,800, as recorded in OpenTender data. [Vorsorgeapplikation Pensionskasse des Bundes Publica](https://sociedad.info/switzerland/contract/CH_ocds-70d2nz-e9b0784b-3f0a-4234-84cc-b4c86562b3be-award-1). A secondary record of the official notices; the original notices, the specification and the contract were not available for this edition.
[^24]: Swiss Federal Pension Fund Publica, information page and FAQ, status 8 October 2026. [Cyberangriff auf Softwarelieferanten](https://www.publica.ch/de/cyberangriff-auf-softwarelieferanten); [English version](https://www.publica.ch/en/cyber-attack-software-supplier); [French version](https://www.publica.ch/fr/cyberattaque-contre-un-fournisseur-de-logiciel); [email to members of 8 October 2026](https://www.publica.ch/de/dokumente/newsletter-08102026-cyberangriff-auf-softwarelieferanten) (PDF, in German). The page lists IBAN among the possible categories; the email does not.
[^25]: Migros-Pensionskasse, 8 October 2026. [Cyberangriff auf Softwarelieferant der Migros-Pensionskasse](https://www.mpk.ch/ueber-uns/mitteilungen/_detail-11/4236%252Fcyberangriff-auf-softwarelieferant-der-migros-pensionskasse). In German.
[^26]: Pensionskasse Post, 9 October 2026. [Cyberangriff auf Softwarelieferant der Pensionskasse Post](https://www.pkpost.ch/news/260-cyberangriff-auf-softwarelieferant-der-pensionskasse-post). In German. That its data held by the supplier are anonymised is the fund’s own statement and cannot be verified from public sources.
[^27]: Bernische Pensionskasse (BPK), 9 October 2026. [Cybervorfall bei Softwarelieferantin der Bernischen Pensionskasse (BPK)](https://bpk.ch/fileadmin/redaktion/3_Kundenservice/3.4_Mitteilungen/Cybervorfall_Softwarelieferantin_BPK_D.pdf) (PDF). In German.
[^28]: Bernische Lehrerversicherungskasse (BLVK), 8 October 2026. [Cyberangriff auf Softwarelieferant von der BLVK](https://blvk.ch/wp-content/uploads/2026/10/20261008_Cyberangriff-auf-Softwarelieferant-von-der-BLV.pdf) (PDF). In German.
[^29]: Canton of Bern, Finance Directorate and Education and Culture Directorate, 9 October 2026. [Cyberangriff auf externe Softwarelieferantin von Pensionskassen](https://www.be.ch/de/start/dienstleistungen/medien/medienmitteilungen.html?newsID=829da168-ed31-4dd9-b7fd-b106b6c6af84); [French version](https://www.be.ch/fr/start/dienstleistungen/medien/medienmitteilungen.html?newsID=829da168-ed31-4dd9-b7fd-b106b6c6af84). In German. The canton does not name the supplier.
[^30]: Pensionskasse Syngenta, terms of use of the member portal, in force since 1 April 2025. [Nutzungsbedingungen – Webportal](https://www.pensionskasse-syngenta.ch/nutzungsbedingungen-webportal). In German. Documents the product relationship only; not a statement about the incident.
[^31]: Keystone-SDA via swissinfo.ch, 9 October 2026. [Cyberangriff auf Softwarefirma betrifft auch Berner Pensionskassen](https://www.swissinfo.ch/ger/cyberangriff-auf-softwarefirma-betrifft-auch-berner-pensionskassen/92192081). In German. The BPK director’s account of what the software company told the fund; not a statement published by PK Softech.
[^32]: European Data Protection Board, 4 April 2023. [Guidelines 9/2022 on personal data breach notification under GDPR](https://www.edpb.europa.eu/documents/guideline/guidelines-92022-on-personal-data-breach-notification-under-gdpr_en), version 2.0. General guidance; it does not decide this case.
## Connected reading
- [Sovereignty Is Measured in Response Time](https://www.thierry-gilgen-ict.ch/field-notes/sovereignty-is-measured-in-response-time)
- [Proof of Human](https://www.thierry-gilgen-ict.ch/field-notes/proof-of-human)
- [Incident Ownership Without a Principal](https://www.thierry-gilgen-ict.ch/field-notes/incident-ownership-without-a-principal)
- [Access Is Not Authority](https://www.thierry-gilgen-ict.ch/field-notes/access-is-not-authority)
- [The Sovereignty Gap](https://www.thierry-gilgen-ict.ch/field-notes/the-sovereignty-gap)
## Published evidence references
- [Omfattende uautoriseret adgang til borgeres CPR-oplysninger](https://via.ritzau.dk/pressemeddelelse/15205753/omfattende-uautoriseret-adgang-til-borgeres-cpr-oplysninger?publisherId=2869389) — primary, Danish Ministry of Research, Education and Digitalisation; Danish Ministry of Research, Education and Digitalisation (Forsknings-, Uddannelses- og Digitaliseringsministeriet), press release (distributed via Ritzau), 5 October 2026. Omfattende uautoriseret adgang til borgeres CPR-oplysninger. In Danish. About 8.8 million affected registered persons, including living, emigrated and deceased; a register of about 11 million; irregular activity noticed on 2 October.; retrieved 2026-10-09
- [Danish national registry hack only discovered after unusually large invoice](https://www.thelocal.dk/20261006/danish-identity-number-breach-only-discovered-after-unusually-large-invoice) — secondary, The Local Denmark; The Local Denmark, 6 October 2026. Danish national registry hack only discovered after unusually large invoice. Ministry department head Mikkel Leihardt on the invoice as the detection cue.; retrieved 2026-10-09
- [Omfattende uautoriseret adgang til borgeres CPR-oplysninger](https://www.cpr.dk/cpr-nyt/nyhedsarkiv/2026/okt/omfattende-uautoriseret-adgang-til-borgeres-cpr-oplysninger) — primary, CPR Administration; CPR Administration, official incident notice, 5 October 2026. Omfattende uautoriseret adgang til borgeres CPR-oplysninger. In Danish.; retrieved 2026-10-09
- [Datatilsynet er opmærksom på sag om opslag i CPR](https://www.datatilsynet.dk/presse-og-nyheder/nyhedsarkiv/2026/okt/datatilsynet-er-opmaerksom-paa-sag-om-opslag-i-cpr) — primary, Datatilsynet; Datatilsynet, 5 October 2026. Datatilsynet er opmærksom på sag om opslag i CPR. In Danish. Report received on 4 October; very large number of automated lookups to identify valid CPR numbers.; retrieved 2026-10-09
- [Hacker claims simple password allowed access to 8.8 million Danish CPR numbers](https://cphpost.dk/2026-10-09/news/round-up/hacker-claims-simple-password-allowed-access-to-8-8-million-danish-cpr-numbers/) — secondary, Ritzau via The Copenhagen Post; Ritzau via The Copenhagen Post, 9 October 2026. Hacker claims simple password allowed access to 8.8 million Danish CPR numbers. Reports an anonymous claimant’s account to *Politiken*; the claims are not independently confirmed.; retrieved 2026-10-09
- [DR: Fynsk softwarevirksomhed er i centrum for historisk CPR-læk](https://ddig.dk/dr-fynsk-softwarevirksomhed-er-i-centrum-for-historisk-cpr-laek) — secondary, DR reporting; DR reporting, relayed by ddig.dk, 9 October 2026. DR: Fynsk softwarevirksomhed er i centrum for historisk CPR-læk. In Danish. A syndicated summary; it states that the leaked password is not confirmed as the credential used.; retrieved 2026-10-09
- [Retsinformation](https://www.retsinformation.dk/eli/lta/2023/1010/dan) — primary, Danish CPR Act; Danish CPR Act (CPR-loven), consolidated text 2023, section 38. Retsinformation. In Danish.; retrieved 2026-10-09
- [Medie: IT-kriminel havde adgang til CPR-register i 21 dage og 17 timer](https://www.dk-sundhed.dk/ritzau/f67ea040-b0ff-42b4-bb4b-aed78c817286) — secondary, Ritzau via DK-Sundhed; Ritzau via DK-Sundhed, 9 October 2026. Medie: IT-kriminel havde adgang til CPR-register i 21 dage og 17 timer. In Danish. TV 2’s reading of the notification to Datatilsynet, obtained through access to documents; the notification itself was not independently examined.; retrieved 2026-10-09
- [Sovereignty Is Measured in Response Time](https://www.thierry-gilgen-ict.ch/field-notes/sovereignty-is-measured-in-response-time) — secondary, Thierry Gilgen; Thierry Gilgen, Library, 23 July 2026. Sovereignty Is Measured in Response Time. A conceptual reference, not evidence about the Danish incident.; retrieved 2026-10-09
- [SP 800-63B-4: Digital Identity Guidelines — Authentication and Authenticator Management](https://csrc.nist.gov/pubs/sp/800/63/B/4/final) — primary, NIST; NIST, July 2025. SP 800-63B-4: Digital Identity Guidelines — Authentication and Authenticator Management; technical text. American guidance, not a Danish legal obligation.; retrieved 2026-10-09
- [8,8 millioner CPR-numre er lækket. Sådan beskytter du din virksomhed](https://www.danskindustri.dk/brancher/di-digital/nyhedsarkiv/nyheder/2026/10/cpr-lak/) — secondary, DI Digital; DI Digital (Confederation of Danish Industry), 6 October 2026. 8,8 millioner CPR-numre er lækket. Sådan beskytter du din virksomhed. In Danish.; retrieved 2026-10-09
- [Die elektronische Identität (e-ID) — Wie funktioniert die e-ID?](https://www.eid.admin.ch/de/e-id/wie-funktioniert-die-e-id) — primary, Swiss Confederation; Swiss Confederation, e-ID. Die elektronische Identität (e-ID) — Wie funktioniert die e-ID? In German. Accessed 9 October 2026.; retrieved 2026-10-09
- [Akzeptanz der E-ID mit zusätzlichen Massnahmen stärken](https://www.eda.admin.ch/de/newnsb/L6Nbf7gStnDm) — primary, Swiss Federal Council; Swiss Federal Council, 25 February 2026. Akzeptanz der E-ID mit zusätzlichen Massnahmen stärken. In German. Announced measures, not yet a description of an operating system.; retrieved 2026-10-09
- [AHV-Nummer](https://www.zas.admin.ch/de/ahv-nummer-identifikator) — primary, Central Compensation Office; Central Compensation Office (ZAS), 5 March 2026. AHV-Nummer. In German.; retrieved 2026-10-09
- [Ricardo fixes security vulnerability affecting user data](https://www.boersennews.de/nachrichten/meldungen/eqs/ricardo-fixes-security-vulnerability-affecting-user-data/5306126/) — primary, SMG Swiss Marketplace Group Holding AG; SMG Swiss Marketplace Group Holding AG, media release via EQS, 9 October 2026, 14:01. Ricardo fixes security vulnerability affecting user data; mirror. The company’s own disclosure, not a forensic report.; retrieved 2026-10-09
- [SMG: 890'000 Ricardo-Nutzerkonten von Sicherheitslücke betroffen](https://www.cash.ch/news/top-news/smg-890000-ricardo-nutzerkonten-von-sicherheitslucke-betroffen-975470) — secondary, AWP via cash.ch; AWP via cash.ch, 9 October 2026. SMG: 890'000 Ricardo-Nutzerkonten von Sicherheitslücke betroffen. In German.; retrieved 2026-10-09
- [Online-Marktplatz gehackt – «Keine Erpressung» – Ricardo meldet Datenleck bei 890’000 Konten](https://www.srf.ch/news/schweiz/online-marktplatz-gehackt-keine-erpressung-ricardo-meldet-datenleck-bei-890-000-konten) — secondary, SRF News; SRF News (with AWP), 9 October 2026, 14:40. Online-Marktplatz gehackt – «Keine Erpressung» – Ricardo meldet Datenleck bei 890’000 Konten. In German; the SMG spokesperson’s statements to AWP are reported in indirect speech.; retrieved 2026-10-09
- [Cyberangriff auf Softwarelieferant von Publica: Datenabfluss bestätigt](https://www.astra.admin.ch/de/newnsb/FjG4XOIms04s) — primary, Swiss Federal Pension Fund Publica; Swiss Federal Pension Fund Publica, media release published on the federal administration’s websites, 8 October 2026. Cyberangriff auf Softwarelieferant von Publica: Datenabfluss bestätigt; English version.; retrieved 2026-10-10
- [Cyberangriff auf die PK Softech AG](https://pksoftech.ch/de/newsreader/Cyberangriff-auf-die-PKSoftechAG) — primary, PK Softech AG; PK Softech AG, 8 October 2026. Cyberangriff auf die PK Softech AG. In German. The company’s own statement, not a forensic report.; retrieved 2026-10-10
- [Cyberangriff auf Software-Lieferanten des Bundes: Hacker erbeuten Daten – Ausmass unklar](https://www.watson.ch/schweiz/digital/228405160-pensionskasse-des-bundes-cyberangriff-auf-publica-softwarefirma) — secondary, watson; watson, 8 October 2026. Cyberangriff auf Software-Lieferanten des Bundes: Hacker erbeuten Daten – Ausmass unklar. In German. Reproduces PK Softech AG’s statement, its later email statement (supplier infrastructure, not customers’ systems; test systems) and Publica’s letter listing data that could be affected.; retrieved 2026-10-10
- [Angriff auf Publica-Lieferanten: Lohndaten könnten betroffen sein](https://www.cash.ch/news/top-news/angriff-auf-publica-lieferanten-lohndaten-konnten-betroffen-sein-975247) — secondary, AWP via cash.ch; AWP via cash.ch, 8 October 2026. Angriff auf Publica-Lieferanten: Lohndaten könnten betroffen sein. In German.; retrieved 2026-10-10
- [Produkte](https://pksoftech.ch/de/produkte) — primary, PK Softech AG; PK Softech AG, product and company pages, accessed 10 October 2026. Produkte; Unternehmen. In German. The company’s self-description; it says nothing about hosting or access arrangements.; retrieved 2026-10-10
- [Vorsorgeapplikation Pensionskasse des Bundes Publica](https://sociedad.info/switzerland/contract/CH_ocds-70d2nz-e9b0784b-3f0a-4234-84cc-b4c86562b3be-award-1) — secondary, OpenTender via Sociedad.info; Publica, open tender published 19 August 2016; contract awarded to PK Softech AG on 23 March 2017 for CHF 12,628,800, as recorded in OpenTender data. Vorsorgeapplikation Pensionskasse des Bundes Publica. A secondary record of the official notices; the original notices, the specification and the contract were not available for this edition.; retrieved 2026-10-10
- [Cyberangriff auf Softwarelieferanten](https://www.publica.ch/de/cyberangriff-auf-softwarelieferanten) — primary, Swiss Federal Pension Fund Publica; Swiss Federal Pension Fund Publica, information page and FAQ, status 8 October 2026. Cyberangriff auf Softwarelieferanten; English version; French version; email to members of 8 October 2026 (PDF, in German). The page lists IBAN among the possible categories; the email does not.; retrieved 2026-10-10
- [Cyberangriff auf Softwarelieferant der Migros-Pensionskasse](https://www.mpk.ch/ueber-uns/mitteilungen/_detail-11/4236%252Fcyberangriff-auf-softwarelieferant-der-migros-pensionskasse) — primary, Migros-Pensionskasse; Migros-Pensionskasse, 8 October 2026. Cyberangriff auf Softwarelieferant der Migros-Pensionskasse. In German.; retrieved 2026-10-10
- [Cyberangriff auf Softwarelieferant der Pensionskasse Post](https://www.pkpost.ch/news/260-cyberangriff-auf-softwarelieferant-der-pensionskasse-post) — primary, Pensionskasse Post; Pensionskasse Post, 9 October 2026. Cyberangriff auf Softwarelieferant der Pensionskasse Post. In German. That its data held by the supplier are anonymised is the fund’s own statement and cannot be verified from public sources.; retrieved 2026-10-10
- [Cybervorfall bei Softwarelieferantin der Bernischen Pensionskasse (BPK)](https://bpk.ch/fileadmin/redaktion/3_Kundenservice/3.4_Mitteilungen/Cybervorfall_Softwarelieferantin_BPK_D.pdf) — primary, Bernische Pensionskasse; Bernische Pensionskasse (BPK), 9 October 2026. Cybervorfall bei Softwarelieferantin der Bernischen Pensionskasse (BPK) (PDF). In German.; retrieved 2026-10-10
- [Cyberangriff auf Softwarelieferant von der BLVK](https://blvk.ch/wp-content/uploads/2026/10/20261008_Cyberangriff-auf-Softwarelieferant-von-der-BLV.pdf) — primary, Bernische Lehrerversicherungskasse; Bernische Lehrerversicherungskasse (BLVK), 8 October 2026. Cyberangriff auf Softwarelieferant von der BLVK (PDF). In German.; retrieved 2026-10-10
- [Cyberangriff auf externe Softwarelieferantin von Pensionskassen](https://www.be.ch/de/start/dienstleistungen/medien/medienmitteilungen.html?newsID=829da168-ed31-4dd9-b7fd-b106b6c6af84) — primary, Canton of Bern; Canton of Bern, Finance Directorate and Education and Culture Directorate, 9 October 2026. Cyberangriff auf externe Softwarelieferantin von Pensionskassen; French version. In German. The canton does not name the supplier.; retrieved 2026-10-10
- [Nutzungsbedingungen – Webportal](https://www.pensionskasse-syngenta.ch/nutzungsbedingungen-webportal) — primary, Pensionskasse Syngenta; Pensionskasse Syngenta, terms of use of the member portal, in force since 1 April 2025. Nutzungsbedingungen – Webportal. In German. Documents the product relationship only; not a statement about the incident.; retrieved 2026-10-10
- [Cyberangriff auf Softwarefirma betrifft auch Berner Pensionskassen](https://www.swissinfo.ch/ger/cyberangriff-auf-softwarefirma-betrifft-auch-berner-pensionskassen/92192081) — secondary, Keystone-SDA via swissinfo.ch; Keystone-SDA via swissinfo.ch, 9 October 2026. Cyberangriff auf Softwarefirma betrifft auch Berner Pensionskassen. In German. The BPK director’s account of what the software company told the fund; not a statement published by PK Softech.; retrieved 2026-10-10
- [Guidelines 9/2022 on personal data breach notification under GDPR](https://www.edpb.europa.eu/documents/guideline/guidelines-92022-on-personal-data-breach-notification-under-gdpr_en) — primary, European Data Protection Board; European Data Protection Board, 4 April 2023. Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0. General guidance; it does not decide this case.; retrieved 2026-10-09
