1. Executive summary
At least three user accounts at Pays, a Funen-based IT company, were reportedly protected by the password "123456" when attackers gained access, and one of those accounts held administrator rights. The compromised environment is linked to a breach of Denmark's Central Person Register (CPR), the national identity database. The reporting comes from Ritzau via databreaches.net and is single-sourced; no victim statement, supervisory finding, or technical incident report has been reviewed for this note. No CVE, CVSS score, or CISA KEV entry applies: this is a credential and access-control failure, not a software vulnerability. For EMEA financial services clients the exposure is indirect but real, because CPR data underpins Danish customer onboarding and KYC, and any institution relying on Pays or on CPR-derived identity checks should treat the supplier's account hygiene as an open question rather than a closed one.
2. Regulatory framing
| Article | Trigger (the fact in this item) | Practical impact |
|---|---|---|
| DORA Art. 28: ICT third-party risk, general principles | The breach is attributed to accounts at Pays, an external IT supplier, not to the financial entity itself | Clients using Pays or comparable identity-data suppliers must establish whether the supplier is in scope of their ICT third-party register and whether contractual risk controls cover credential management at the supplier |
| DORA Art. 30: key contractual provisions with ICT third-party providers | An administrator account at the supplier used a trivially guessable password, which is a control failure the contract should have addressed | Contract review: confirm the agreement obliges the supplier to enforce authentication controls and to notify the client of access-control incidents within a defined window |
| NIS2 Art. 21(2)(d): supply chain security measures | The same supplier-account failure, viewed as a supply chain security gap | Entities in NIS2 scope must be able to evidence supply chain security measures for identity-data providers; a supplier running default passwords is a documented gap |
DORA Art. 17, 18, 19 and 24 are not engaged on the facts available: nothing in the source establishes that a financial entity's own ICT systems were disrupted, that a major incident classification is required, or that resilience testing would have surfaced this. UK NIS 2018 is not engaged; the incident is Danish and the source names no UK OES or RDSP.
3. Technical analysis & attack chain
The source does not describe the intrusion technique beyond credential weakness. What follows is limited to what Ritzau reported through databreaches.net.
- Attackers obtained access to at least three user accounts at Pays.
- Each of those accounts was reportedly protected by the password "123456".
- At least one of the three was an administrator account.
- The access is linked to a breach of Denmark's CPR register.
No initial access vector beyond credential use is stated. The source does not say whether the passwords were guessed, sprayed, reused from another breach, or obtained through phishing, and it does not describe multi-factor authentication status, session handling, or the authentication protocol in use. No malware, implant, persistence mechanism, command-and-control channel, lateral movement path, or exfiltration method is named. No timeline is given beyond the publication date.
The material point for a defender is the administrator account. An administrative credential on a supplier that handles or can reach national identity data converts a weak password into a path to bulk personal data, and the source's own framing places the CPR register at the end of that path. Whether the administrator account was the entry point or was reached after the initial three accounts were compromised is not stated.
Confidence caveat: this entire section rests on a single source, Ritzau's reporting as republished by databreaches.net. The account count, the password string, the administrator privilege level, and the link to the CPR breach are all single-sourced and have not been corroborated by a second outlet, by Pays, or by a Danish authority in the material provided. Treat the specifics as reported rather than confirmed.
4. Mitigation & containment
The source names no vendor fix, no patch, and no affected product version, because none applies. The actions below address the control failure the item actually describes.
P1 (within 24 hours)
- If your institution consumes Pays services or CPR-derived identity data, ask the supplier in writing for the scope of the affected accounts, whether any client-facing credential store was reachable from them, and whether multi-factor authentication was enforced on the administrator account. Do not accept a verbal assurance.
- Rotate any credential your institution holds for a Pays-operated system, and any credential shared with Pays staff, regardless of whether the supplier has confirmed exposure. Rotation is cheap; waiting is not.
- Search your own authentication logs for successful logins to supplier-facing or identity-data systems from unexpected source addresses or at unexpected hours over the period the supplier identifies.
P2 (within 72 hours)
- Audit administrator accounts across your identity-data supply chain for password-only authentication. Any administrator account that can authenticate with a password and no second factor is a finding, not a hardening item.
- Enforce a minimum password policy that rejects the common-password list. "123456" is the first entry on every published list of this kind; a policy that permits it is not a policy.
- Confirm that supplier contracts in scope of DORA Art. 30 require the supplier to notify you of access-control incidents within a defined window, and that the window is short enough to be useful.
P3 (within 7 days)
- Add the supplier to your ICT third-party register with the incident recorded against it, and record the concentration question: how many of your identity-verification or onboarding processes depend on this supplier or on CPR data reaching you through it.
- Where CPR data feeds KYC or onboarding, review whether a period of degraded or unverifiable identity data requires retrospective customer file review. This is a process decision, not a technical one, and it belongs with compliance rather than IT.
5. Indicators of compromise
No indicators of compromise available in the source material. The source names no hashes, domains, IP addresses, file paths, registry keys, or command lines.
Behavioural indicators
| behaviour | where to observe | confidence |
|---|---|---|
| Successful authentication to a supplier or identity-data system using a weak or default password | Authentication logs on the supplier-facing system; identity provider sign-in logs | Low. The behaviour is inferred from the reported password weakness, not observed in any log reviewed for this note |
| Administrator-level authentication to a supplier system without a second factor | Identity provider sign-in logs; privileged access management logs | Low. The source reports an administrator account with a weak password but does not state the authentication method |
Both rows are single-sourced inferences from the reporting, not confirmed observations. Verify against your own logs before acting on them.
6. Detection
Insufficient indicators to author detection rules. The source provides no distinctive strings, command-line flags, mutex names, scheduled-task or service names, file names or paths, registry keys, ransom-note text, or hard-coded values. The only artefact named is the password string "123456", which is a credential value rather than a threat artefact and would produce a rule that matches legitimate traffic and every published password list. No YARA or Sigma rule is emitted.
7. Sources
- databreaches.net, "`123456' password used in massive Danish CPR data breach", https://databreaches.net/2026/10/10/123456-password-used-in-massive-danish-cpr-data-breach/, 2026-10-10. Cites Ritzau. Single source for all facts in this advisory.
8. Adverse Trace position
We assess this as a supplier access-control failure with national-identity-data consequences, not as a software vulnerability, and we are not assigning a CVSS score because none applies. The client impact for EMEA financial services is indirect: exposure runs through onboarding, KYC, and any process that depends on CPR data reaching you intact and unaltered, and it is concentrated in institutions with Danish retail or corporate operations or with suppliers in that chain. The reporting is single-sourced and the technical detail is thin, so we are treating the account count, the administrator privilege level, and the causal link to the CPR breach as reported rather than confirmed. We will watch for a Danish authority statement, a Pays statement, or a second outlet carrying the account details, and we will issue a follow-up if any of those confirm or contradict the account-level specifics. Clients who need a supplier-scope determination for DORA Art. 28 or Art. 30 should raise it with their Adverse Trace contact rather than wait for that follow-up.
Published via PulseTrace — Adverse Trace threat intelligence.