What Changed
The Technical University of Denmark (DTU) revealed that compromised credentials allowed an attacker to access DTUBasen, its identity and access management (IAM) system, exposing data for up to 200,000 users over more than two decades. The exposed information included Danish civil registration numbers (CPR), home addresses, employment details, and next-of-kin contact information for nearly 40,000 active users and about 160,000 former users.
This breach highlights a common issue: educational institutions manage identity data at an enterprise scale but often lack the security resources to match the threat landscape. The IAM system's failure to detect and block unauthorized access after authentication underscores the need for improved security measures.
Key Findings
Compromised credentials bypassed all downstream controls. The attacker used valid credentials to authenticate to DTUBasen, which meant the system treated the access as legitimate. Once inside, the attacker downloaded decades of user data without triggering alerts that would flag bulk extraction as suspicious.
Long data retention periods amplified exposure. DTUBasen stored records for 160,000 former users alongside 40,000 active accounts. While the university's policy deletes certain fields (home addresses, profile pictures, next-of-kin data) after six months for former users, core identity records persisted. This created a high-value target: a system containing both current operational data and a historical archive spanning over 20 years.
Identity fraud risk extends beyond the institution. Danish CPR numbers serve as national identifiers used across government services, healthcare, banking, and employment verification. Unlike a compromised university email address, a leaked CPR number can enable identity fraud across multiple sectors. DTU warned that attackers could use the data for phishing attacks or identity fraud, creating systemic risk beyond the university's perimeter.
Notification gaps leave segments of the affected population unaware. DTU committed to notifying all current and former employees but stated it would not directly notify all students whose CPR numbers were stored in the system. The university relied on public disclosure and e-Boks (Denmark's official digital mailbox) to reach affected individuals, creating a notification model that depends on victims monitoring channels they may no longer actively use.
What This Means for Your Team
If your IAM system authenticates users but doesn't continuously evaluate access behavior, you're operating with a binary trust model: once credentials pass, the system assumes every subsequent action is legitimate. This model fails when credentials are compromised, whether through phishing, credential stuffing, or insider misuse.
The DTU breach demonstrates that authentication is not authorization. Your IAM architecture should enforce:
Behavioral baselines for privileged accounts. If an administrator account that typically accesses 50 records per session suddenly queries 200,000, that deviation should trigger automated review or temporary access suspension.
Time-bound access for bulk data operations. Routine administrative tasks rarely require unrestricted query access to decades of archived identity records. Implement request-and-approval workflows for operations that exceed normal access patterns.
Data minimization policies with enforcement mechanisms. DTU's six-month deletion rule for certain former-user data shows awareness of retention risk, but the policy didn't extend to core identity fields. Your retention schedule should balance operational need against exposure risk, and your IAM system should enforce deletion automatically rather than relying on manual processes.
The notification challenge also matters for your incident response planning. If your organization serves populations that cycle through (students, contractors, seasonal employees), you need a communication strategy that reaches people who no longer monitor your primary channels. Relying solely on internal email or portals won't suffice.
Action Items by Priority
Immediate: Audit privileged IAM account activity. Review access logs for accounts with permissions to query or export large datasets from your identity systems. Establish what normal looks like: how many records does a typical HR query touch? How often do system administrators perform bulk exports? Document these baselines so your SIEM can flag deviations.
This quarter: Implement behavior-based access controls. Configure your IAM system to flag or block access patterns that deviate from established norms. This includes unusual query volumes, access from new locations or devices, and operations performed outside typical working hours. These controls should apply even to authenticated sessions.
This quarter: Map your identity data retention requirements. Identify which identity fields you're required to retain for compliance (tax records, employment verification, audit trails) and which you hold for convenience. For data you're not required to keep, implement automated deletion schedules. For data you must retain, consider whether it needs to remain in your live IAM system or can move to a separate archive with more restrictive access controls.
Next 90 days: Test your breach notification process for former users. Run a tabletop exercise where your IAM system is compromised and you need to notify people who left the organization 5, 10, or 15 years ago. Do you have current contact information? What channels will you use? How will you verify that notifications reached their intended recipients? Document gaps and build contingency plans.
Ongoing: Require MFA for all IAM administrative access. If compromised credentials can unlock your entire identity database, you need a second authentication factor that's harder to compromise. Deploy phishing-resistant MFA (FIDO2, WebAuthn, or certificate-based authentication) for any account with permissions to query or export identity data at scale.
Danish civil registration numbers)
