Identity

The Technical University of Denmark (DTU) said on October 2, 2026 that attackers had compromised DTU user profiles and used them to log in to DTUBasen, the university's identity and access management system, and download a large amount of data. Records go back to 2003. DTUBasen holds about 40,000 active users and about 160,000 former users, so up to 200,000 current and former employees, students, guests and external partners may be affected. DTU says it cannot yet tell exactly which data was taken or how many people are in it.

The exposed fields include CPR numbers (the Danish civil registration number, used as a national ID), full names, home addresses, profile pictures, work email addresses, job titles, office locations and next-of-kin details. DTU reported the breach to Datatilsynet, the Danish Data Protection Agency, and referred it to the relevant authorities for investigation. If you run a central directory for staff, students or customers, this is a useful case to test your own setup against, because the access DTU describes came through logins to real accounts, which most monitoring treats as normal use.

How it works

An identity and access management (IAM) system is the source of truth for who someone is and what they may use. HR and student administration feed it, and it provisions accounts and access everywhere else. To do that job it has to hold the real-world identifiers that tie a person to an account, which at a Danish university means the CPR number, plus contact and organisational details for every person who has ever had an account.

That makes the directory a different kind of target from a mailbox or a file share. Breaking into one mailbox gives you one person; reading the directory gives you everyone, already joined up: name, national ID, home address, photo, job title, office and who to call in an emergency. DTU's own warning to affected people reflects this. It tells them to expect more convincing emails, text messages and phone calls, and not to approve login requests they did not start, because an attacker who knows your job title, office and next of kin can build a far more believable pretext.

The access path matters too. DTU says attackers compromised DTU profiles and used them to get into DTUBasen. It has not said how those profiles were compromised, whether they had multi-factor authentication (MFA, a second check beyond the password), or whether they were ordinary user accounts, administrators or service accounts used by other systems. A directory that lets a single logged-in identity export every record, with no alert on the volume, turns one stolen password into a full-population breach.

Retention is the third factor. For former users, DTU automatically deletes home addresses, profile pictures and next-of-kin details after six months, but DTUBasen keeps their CPR numbers and full names. That is why about four in five of the people potentially affected no longer study or work at DTU. A CPR number is also hard to make worthless: its first six digits are the date of birth, and people keep the same number for life in almost every case, so a leaked one stays useful to fraudsters for years.

What attackers are doing

DTU identified the breach on October 2, says its IT incident response team has contained the attack, and is working with external specialists to work out the full scope. No group has been named, DTU has not said what the attackers wanted, and no ransom demand or leak has been reported in the sources below.

Notifications go through e-Boks, Denmark's official digital mailbox, to current and former employees and almost all current and former students for whom DTU holds a CPR number. DTU holds CPR numbers for only a small number of guests and external partners and none for next of kin, so those people will not get a direct letter. For the people who are notified, DTU recommends changing passwords on any service where they reused their DTU password and considering a credit alert (kreditadvarsel) through Borger.dk, which asks lenders to confirm the request with the person before granting credit in that CPR number.

What to check in your own identity directory

The same checks apply to any IAM platform, HR-fed directory, Active Directory or Microsoft Entra ID tenant. Work through them in order.

1. List every identity that can read the whole directory. Include admin roles, help desk roles, provisioning connectors and service accounts used by other applications. For each one, ask whether it needs every attribute for every person, or whether a scoped view (no national ID field, no former users) would do. Remove standing bulk-read rights from personal accounts and grant them just in time where your platform allows.
2. Put MFA on every account that can reach the directory, including the ones people forget: service accounts that log in interactively, help desk tools and legacy protocols such as LDAP simple bind over the network. Where a service account cannot do MFA, lock it to known source IP addresses and a workload identity, and alert on any interactive sign-in.
3. Log reads, not only changes. Most directories audit writes by default and say nothing about who read 200,000 records. In Active Directory, enable Event ID 1644 (expensive and inefficient LDAP searches) by setting the 15 Field Engineering value under HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics to 5 on domain controllers, and use Event ID 4662 with a system access control list (SACL) on sensitive attributes. In Entra ID, send MicrosoftGraphActivityLogs to Log Analytics so bulk /users queries are recorded. For a custom IAM application, make sure exports and paged API reads write an audit row with account, source IP and record count.
4. Alert on volume against each account's own baseline. A help desk account that normally looks up 40 people a day and suddenly pages through the whole directory should page someone within minutes.
5. Cut former-user records down to what the law requires. DTU already deletes some fields after six months; the national ID it keeps is the field that does the most harm. Decide which attributes you truly must keep for leavers, move them out of the live directory into an archive that day-to-day accounts cannot read, and delete the rest. GDPR's storage limitation principle in Article 5(1)(e) expects this anyway.

If you think it already happened to you

Search the read logs above for any account that returned an unusually large number of objects, especially outside its normal working hours or from a new IP address or country. Check sign-in logs for the same accounts for MFA prompts the user did not start, new MFA methods registered shortly before the activity, and logins from hosting providers. If you find one, disable the account, revoke its sessions and refresh tokens, reset its password and MFA methods, and rotate the credentials of any service account that shares a host or vault with it. Then plan for the notification work DTU now faces: under GDPR you have 72 hours from becoming aware of a breach to notify the data protection authority.

The wider lesson

Teams spend most of their monitoring effort on the systems that look sensitive, such as finance, HR and email, while the directory that feeds all of them is treated as plumbing. It usually holds the most complete copy of personal data in the organisation, and more accounts and connectors can read it than almost any other system. Its read access deserves the same review and alerting as payroll.

If you want an outside look at who can bulk-read your directory and what that would expose, our safeguarding and hardening work covers identity platforms, and our security operations team builds the read-volume alerting described above. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: DTU notification (English), DTU notification (Danish), The Copenhagen Post, Cybernews, DR, TV 2.