When the Technical University of Denmark (DTU) revealed that hackers used compromised credentials to access its identity and access management (IAM) system, exposing data on up to 200,000 individuals, many security teams responded with a familiar refrain: "We're different. Our IAM is secure."
This confidence often rests on myths that seem plausible until they're tested against real-world credential-based attacks. The DTU incident, where attackers accessed over two decades of user data through DTUBasen, shows why these misconceptions are dangerous. Let's dismantle the most persistent ones.
Myth 1: "If We Have MFA Enabled, Credential Compromise Isn't a Risk"
Reality: Multi-factor authentication (MFA) reduces risk but doesn't eliminate all credential-based attack vectors, especially in IAM systems with legacy integrations or administrative bypass routes.
MFA protects against password-only attacks. It doesn't stop an attacker who's compromised a session token, exploited an API with weaker authentication, or accessed a privileged account that predates your MFA rollout. IAM systems often maintain backward compatibility with older methods to support legacy applications, creating these vulnerabilities.
Your team should audit every authentication pathway into the system, not just the primary login flow. Document which service accounts, API endpoints, or administrative interfaces might authenticate without MFA. If you can't produce that map quickly, you've identified a vulnerability.
Myth 2: "We'll Know Immediately If Someone Downloads Large Amounts of Data"
Reality: Most IAM systems log access events, but few organizations have monitoring rules tuned to detect unusual data export patterns from their identity infrastructure.
DTU couldn't determine exactly what information was downloaded or how many people were affected. That's common. IAM systems store structured data that can appear as routine administrative queries. An attacker pulling thousands of records might generate logs that look like a legitimate HR report or system backup.
You need baseline analytics on normal data access volumes within your IAM platform. What does a typical administrator query return? How many records does your HR integration pull daily? Without these baselines, your alerts on "large data export" may either fire constantly or miss the breach entirely.
Set up specific monitoring for bulk exports of sensitive fields like civil registration numbers or national insurance numbers. Alert on any query returning more than a defined threshold of these fields, regardless of who's authenticated.
Myth 3: "Former User Data Isn't a Major Exposure Risk"
Reality: Former users often represent your largest and least-protected data population within IAM systems, and their information remains valuable for identity fraud and targeted phishing.
DTU's IAM system held data for nearly 40,000 active users but around 160,000 former users. That four-to-one ratio isn't unusual. Your IAM accumulates everyone who's ever needed access: former employees, past contractors, graduated students, expired partnerships.
Here's the danger: former users can't report suspicious activity because they're no longer monitoring their old institutional email. They won't notice if someone uses their DTU employment history to craft a convincing phishing email. The Danish civil registration numbers, addresses, and employment details exposed in this breach create a complete profile for identity fraud.
Article 5(1)(e) requires you to keep personal data no longer than necessary. For former users in your IAM, define "necessary" with specifics: how long do you need their employment dates for reference checks? Their email address for alumni communications?
DTU's automatic deletion of home addresses, profile pictures, and next-of-kin data after six months for former users demonstrates data minimization that reduced breach impact. Implement lifecycle rules in your IAM that automatically purge or pseudonymize fields based on user status and retention requirements.
Myth 4: "We Can Notify Everyone Affected Through Our Standard Channels"
Reality: A breach of your IAM system specifically compromises your ability to reach affected individuals through the channels that breach notification typically relies on.
DTU faced this directly: they couldn't notify all current and former students whose civil registration numbers they held. Their standard communication channel was e-Boks, but not everyone had access. Former users might have moved, changed contact details, or never provided personal email addresses.
When your IAM is breached, you've lost the verified contact information you'd normally use for Article 34 individual notification. Your institutional email addresses might be in the breach dataset. Your internal directory is exactly what was compromised.
Build a notification strategy now that assumes your primary communication channels are unavailable. Can you reach former employees through LinkedIn? Do you maintain an emergency contact list stored separately from your IAM? For high-risk data subjects, do you have postal addresses verified within the last year?
The GDPR doesn't excuse incomplete notification because your IAM was breached. You'll need to demonstrate that public disclosure and alternative notification methods reached substantially all affected individuals.
Myth 5: "Our IAM processor's Security Certification Means the Risk Is Theirs"
Reality: You're the controller for the personal data in your IAM system. The processor provides infrastructure; you're responsible for access controls, monitoring, and breach response.
This matters when supervisory authorities investigate. They'll ask why compromised credentials provided access to two decades of user data. They'll want to know what monitoring detected the breach, how quickly you contained it, and whether your data retention practices minimized exposure.
"Our processor is ISO 27001 certified" doesn't answer those questions. You need to document your own decisions: who has administrative access to the IAM platform? What approval process governs privilege escalation? How often do you audit administrative actions?
Review your processor agreement, but understand it covers the processor's security obligations, not your controller responsibilities under Articles 24 and 32. You must implement appropriate technical and organizational measures based on the risk to the data subjects whose information you're storing.
What to Do Instead
Start with an IAM-specific threat model. Assume an attacker has valid credentials to your identity system. What can they access? How much can they export before you'd notice? How would you contain the breach without locking out legitimate administrators?
Then audit your data minimization practices within IAM. For every field you store, document the lawful basis, retention period, and deletion trigger. Implement automated lifecycle management that removes or pseudonymizes data when individuals leave your organization.
Finally, test your breach notification plan against an IAM compromise scenario. If your directory is breached, how will you reach affected individuals? Draft the public disclosure now, while you're not managing an active incident.
The DTU breach exposed data on up to 200,000 individuals because compromised credentials opened access to decades of accumulated user information. Your IAM likely holds similar volumes. The question isn't whether credential-based attacks can succeed; it's whether you've minimized what they can reach when they do.
