Credential Stuffing: The Underestimated Compliance Risk

TL;DR: Although compromised passwords are the #1 security risk according to the Verizon DBIR, very few companies secure their login flows against them. However, guidelines from BSI and NIST are clear—making unchecked logins a tangible GDPR compliance risk.

Every year, Verizon publishes the Data Breach Investigations Report (DBIR), the global industry standard for security analytics. And every year, the picture remains the same: Stolen and leaked credentials indisputably top the list of the most successful attack vectors. Even though the widespread adoption of Multi-Factor Authentication (MFA) has reduced this share from over 80% (2024/2025) to just over 50% in 2026, the core message remains highly relevant: Compromised passwords cause significantly more damage than exploiting technical vulnerabilities in code.

This highlights a precarious imbalance in modern IT security. Companies invest heavily in penetration tests, automated vulnerability scanners, and bug bounty programs to close even the smallest gaps in their infrastructure. Yet, by far the largest attack vector on the web—user behavior and recycled passwords—is almost universally ignored when designing the login flow.

How Credential Stuffing Works

The mechanics of an Account Takeover (ATO) are simple and bypass even the most secure backend architectures: A large portion of users reuse passwords across multiple services. If any third-party system on the internet is compromised, the stolen email and password combinations end up in publicly accessible databases.

Cybercriminals use these lists to automate the login process across countless other services. The system recognizes a formally correct email address and the corresponding correct password. The login is authorized. There is no traditional breach of the infrastructure—the unauthorized access simply occurs using valid, but externally compromised credentials.

GDPR and Mandatory Breach Notification

Many companies mistakenly view compromised accounts purely as a customer support issue. From a legal perspective, however, the situation is different: An Account Takeover is a data breach.

As soon as credential stuffing grants access to a user's profile where personal data (billing addresses, order histories, contracts) is visible, Article 33 of the GDPR applies. The company is obligated to report this incident to the supervisory authorities. Arguing that the affected individuals "chose an insecure password themselves" does not protect operators from shared legal responsibility if the attack could have been prevented using established technical measures.

NIST and BSI Guidelines Are Clear

The fact that checking passwords against leak databases is not an optional extra, but a technical necessity, is officially mandated by the most important standardization organizations:

• NIST (National Institute of Standards and Technology): In the SP 800-63B (Digital Identity Guidelines) directive, section 5.1.1.2 unequivocally states that systems shall compare the prospective secrets against a list that contains values known to be commonly used, expected, or compromised.
• BSI (Federal Office for Information Security, Germany): The BSI has fundamentally modernized its guidelines in recent years. The requirement for regular, arbitrary password changes has been abolished. Instead, the current IT-Grundschutz-Kompendium (Module ORP.4) mandates that passwords must be checked against dictionaries and lists of known, leaked passwords.

Why the Risk is Ignored in Practice

If the threat landscape is proven by the DBIR and the guidelines from NIST and BSI are clear, a critical question arises: Why is the leak check missing in the overwhelming majority of European web applications?

The reasons lie not in a lack of technical expertise, but in a chain of structural hurdles:

1. Feature Pressure Displaces Security Topics
   Modern web frameworks (like Laravel, Django, or Spring) fortunately make basic authentication extremely simple. They provide strong password hashing and session management out of the box. However, the reality in product development is often: As soon as the login technically works, the ticket is marked as "done". In daily business, the focus of product managers and executives is understandably on new features that generate direct business value. Additional security layers like a leak check end up in the backlog and are often deprioritized because they do not generate measurable revenue in the short term—until the first incident occurs.

2. Lack of Standardization in Auth Flows
   Standard authentication libraries and UI templates fully cover classic processes—login, registration, forgot password. A status for "password is formally correct, but compromised on an external list" generally does not exist in these standard flows. Integrating a leak check therefore necessitates building custom routing and UX logic (e.g., intercepts in the login flow, force-reset redirects, specific error copy). This blows up the estimation of a standard "implement login" ticket and requires additional design and development resources.

3. Compliance Blockers with US Services
   When teams recognize the problem and attempt to integrate an existing leak check API (e.g., established US services), this often fails in regulated European companies due to vetos from Data Protection Officers. Even if passwords are transmitted anonymously, metadata, IP addresses, and timestamps flow to the US or through American CDNs. This fundamentally clashes with the GDPR and the US Cloud Act.

4. Operational Overhead of Self-Hosting
   If API usage is ruled out for compliance reasons, the only option left is self-hosting. This means downloading billions of leaked records, indexing them, and operating a highly available database that responds in under 50 milliseconds for every login attempt. This represents massive operational overhead and makes zero economic sense for small to medium-sized enterprises.

The result is the de facto acceptance of the risk. The problem is silently tolerated because a legally secure, simple solution has thus far been missing.

Taking Action Instead of Ignoring

The time for excuses is over. Account takeovers via credential stuffing are not an unavoidable fate, but a calculable risk for which there are clear regulatory guidelines from BSI and NIST. Ignoring this risk is no longer just technical negligence, but a tangible compliance issue.

Anyone building modern login systems must consider user behavior as an integral part of the security architecture. Automated checking against leaked passwords is the only way to close the gap between theoretical infrastructure security and the reality of recycled credentials.

Protecting against this is no longer a question of technical feasibility, but simply a conscious decision for greater security and compliance in your own login flow.