DTU breach: identity systems need more than a login test

Sources checked: 30 October 2026. FailSafe Research.

The identity system is where an organization describes who people are and what they can access. Testing only its login screen leaves the more consequential authorization questions unanswered.

Disclosure date and attack date differ

DTU’s public notice of 2 October says attackers used compromised profiles to access DTUBasen and download data. The system held information relating to roughly 40,000 active and 160,000 former users, while the exact downloaded scope could not be determined. Its subsequent timeline places the initial attack in September. This article belongs to the October disclosure review; it does not date the intrusion to October.

A population in a database is an exposure boundary, not automatically a verified count of stolen individual records. Preserve that uncertainty when briefing executives or planning notifications.

Model the authority transitions

For your identity platform, list what an ordinary user, guest, helpdesk operator, application and administrator may read or change. Include role assignment, account linking, MFA enrollment and synchronization into downstream systems. Test the transitions between roles with synthetic users.

An authenticated account should not gain administrative authority merely by reaching another interface. Verify each server-side decision rather than trusting the navigation shown to that user. Record the policy that should apply and the resulting permission in the dependent service.

Historical records change the blast radius

A former user may no longer be able to sign in while their identity record remains searchable or exportable. Review retention separately from account disablement. Identify which fields are still necessary, why they remain and which operational roles can retrieve them.

Logs should explain sensitive reads and administrative changes. An investigation can be constrained if the only record is that an administrator performed a successful request. Preserve actor, scope, object and outcome in a protected audit trail appropriate to the system.

Build the retest around a real permission decision

FailSafe SWARM can evaluate agreed identity, API and application paths, reproduce a failed boundary and connect it to engineering work. For an identity-system assessment, ask for evidence that the unauthorized role transition fails after remediation, including alternate interfaces and dependent applications.

The Copenhagen test-environment case is a separate example of why sensitive data inventory should extend beyond the main production application.

Explore the October incident collection for related cases and existing FailSafe coverage. Incident descriptions are attributed to the linked sources; assessment recommendations are FailSafe’s analysis. We have not conducted forensic investigations of these incidents.