All articles

NewsOctober 5, 20265 min read

Denmark: unauthorised access to the CPR and identity checks

Unauthorised access to names, addresses and CPR numbers in Denmark: SAMSIK’s recommendations for verifying identity beyond basic personal data.

Hand touching a transparent panel showing a padlock and the word IDENTITY

On 5 October 2026 the Danish authorities disclosed a serious security incident in the central population register, the CPR (Det Centrale Personregister). Unauthorised parties gained access to names, addresses and CPR numbers, among other data, for a very large number of registered citizens. The following day the Danish agency Styrelsen for Samfundssikkerhed (SAMSIK), which includes the national Centre for Cyber Security (CFCS), urged public bodies, organisations and companies to review their identity checks based on that data straight away.

For those responsible for security and business processes, the technical point is this: a piece of personal data, even an official one, is not an authentication factor. Once it is in someone else’s hands, every process that relies on it as proof of identity can be bypassed.

What happened

According to SAMSIK’s advisory of 5 October, the incident was reported in a press release by the Danish Ministry of Research, Education and Digitalisation (Forsknings-, Uddannelses- og Digitaliseringsministeriet). The access took place through the CPR system and was described as unauthorised.

The advisory stresses that personal data can be misused in fraud attempts and asks public bodies and citizens to be vigilant. For citizens, it points to the advice on the national portal Sikkerdigital.dk.

On 6 October SAMSIK issued a second advisory, addressed to public bodies, organisations and companies: sensitive information should no longer be handed out on the basis of CPR data alone.

What is known and what is not

The advisories published so far are brief. The following summarises what they say and what they leave out.

  • Data involved: names, addresses and CPR numbers, plus other unspecified data (“mv.”, meaning “etc.”, in the original text).
  • People affected: “a very large number” of registered citizens. No figure is given.
  • How access was gained: the advisories do not describe the vector, the timeline or who gained access. There are no CVEs and no public indicators.
  • Risk flagged by the authorities: use of the data for fraud and to obtain information or changes in citizens’ names.

Without details on how the access happened, no MITRE ATT&CK mapping is possible. SAMSIK’s recommendations focus on the aftermath: how to stop the stolen data from becoming a key to services.

SAMSIK’s recommendations

The agency asks organisations to pay particular attention to every situation where a CPR number, name or address is used to confirm someone’s identity. As a starting point, the check should rely on information other than CPR data, or on the history of contacts between the person and the organisation. This applies above all when sensitive personal data is shared or when a request may have financial consequences for the citizen.

Specifically, SAMSIK recommends to:

  1. direct the person to an authenticated login on a self-service system, for example with MitID, Denmark’s digital identity;
  2. send a one-time code to a phone number or email address already on record;
  3. ask verification questions tied to the specific relationship, not to data that may have been stolen: for a company, the customer number, contract number or latest invoice number; for a public body, the previous address or the latest contact and case history;
  4. call the person back on a number already on record, not the one given during the current contact;
  5. require an in-person visit with ID for special changes of a financial or security nature;
  6. introduce a manual check or a waiting period for changes with financial or security implications.

Impact on European and Italian companies

The incident directly concerns anyone with customers, users or employees in Denmark: banks, insurers, telcos, utilities, healthcare providers and e-commerce businesses that verify people by name, address and CPR number should apply the recommendations now.

The principle, however, applies everywhere. In Italy too, many processes confirm identity with personal data: name, address, date of birth, tax code (codice fiscale). This happens in call centres, support chats, service desks and the internal IT help desk, when a user asks to reset a password or register a new device for multi-factor authentication. This data circulates in many systems and documents: it should not be treated as a secret.

For entities in scope of NIS2, this falls under the risk-management measures required by the directive, which include access control policies and multi-factor authentication. In healthcare, where requests often concern health data, checking identity before disclosing information is even more sensitive.

What to do now

  1. Inventory your channels: phone, email, chat, front desk, portals and internal help desk. For each one, note how identity is verified.
  2. Identify weak checks: flag processes where personal data alone is enough to obtain information, change contact details, an IBAN or an address, or reset credentials or authentication factors.
  3. Apply SAMSIK’s six controls: authenticated login, one-time code to contact details on record, relationship-based questions, call-back, in-person visit for critical cases, manual check or waiting period.
  4. Protect the IT help desk: for password and MFA resets, require verification that does not rely on personal data, such as a call-back to a registered number or confirmation from a manager.
  5. Log and review changes: keep track of changes to contact details, bank details and accounts, and check those that are close together or unusual.
  6. Brief your staff: warn customer-facing teams that fraud attempts using genuine personal data are possible.

How ARXDOME helps

ARX Expose flags company accounts involved in breaches and domains similar to yours registered by others, often used in fraud. ARX Sentry collects server and firewall logs and shows failed logins, bursts of attempts and account changes in the SOC pages, helping you spot a reset obtained by deception.

Last updated:

Any questions?

Let’s talk about your company’s needs, with no obligation.

Contact us

Related articles