Credential stuffing is the automated attempt to log into accounts using username and password pairs stolen from other services. It is not a sophisticated attack — attackers simply take leaked credential lists and try them at scale. But it is devastatingly effective. In 2026, credential stuffing attacks against business accounts increased by 325% according to the Verizon 2026 Data Breach Investigations Report. For SMEs, a single successful credential stuffing attack can lead to data loss, ransomware deployment, and regulatory fines.
How Credential Stuffing Works
When a large service is breached — a recent example being the Canvas breach affecting 275 million records — the stolen credentials are posted on criminal forums. Attackers use automated tools like OpenBullet or SNIPR to test these credentials against business accounts: Microsoft 365, Google Workspace, Slack, Salesforce, and banking portals.
The automation is sophisticated. Attackers rotate IP addresses through residential proxy networks to avoid rate limiting. They randomise the timing of login attempts. They test credentials against multiple services simultaneously. The goal is to find even one working account before the organisation detects the activity.
According to CISA guidance published in May 2026, a credential stuffing tool can test 10,000 credential pairs against a single service in under 30 minutes using a modest proxy network.
Why Businesses Are the Primary Target
Business accounts are the primary target because they provide access to sensitive data, financial systems, and communication channels. A compromised business email account, for example, can be used to run invoice scams against suppliers and customers. The IBM Cost of a Data Breach 2026 report found that credential stuffing was the initial vector in 22% of SME breaches, with an average cost of £18,000 per incident.
Small and medium businesses are particularly vulnerable because they often lack the monitoring infrastructure that large enterprises deploy. An SME may not notice ongoing credential stuffing attempts for days or weeks.
The Most Effective Defences
The most effective defence against credential stuffing is also the simplest: every account must use a unique password. If a credential pair is stolen in a breach, it provides access only to the breached service — not to any other account. A business password manager makes this practical by generating and storing unique passwords for every service.
The second defence is MFA on every account. Even if a credential pair is valid, the attacker cannot log in without the second factor. Hardware security keys (FIDO2/WebAuthn) are the most resistant, followed by authenticator app TOTP codes. SMS-based MFA is better than nothing but is increasingly targeted by SIM-swap attacks.
The third defence is monitoring for compromised credentials. Services like Have I Been Pwned (HIBP) allow you to check whether any business email addresses appear in known breaches. Microsoft 365 and Google Workspace also offer built-in credential monitoring.
Rate Limiting and Account Lockout Policies
Rate limiting is your application layer defence. Configure your email and cloud platforms to limit login attempts per IP address and per user account. A reasonable policy is: lock the account for 15 minutes after 10 failed attempts within 5 minutes. This stops automated login attempts while allowing legitimate users to recover quickly.
However, attackers have adapted to rate limiting by using large proxy networks. Each IP address makes only one or two attempts before moving to the next. This is why rate limiting alone is insufficient — it must be combined with unique passwords and MFA.
Detecting a Credential Stuffing Attack in Progress
Signs of an ongoing credential stuffing attack include: an unusual number of failed login attempts across multiple user accounts, failed MFA challenges from unfamiliar locations, users receiving password reset emails they did not request, and login attempts from IP addresses in regions where your business has no operations.
Most cloud platforms provide security dashboards showing failed login attempts. Review these weekly. Set up email alerts for suspicious login patterns. CISA recommends monitoring these logs at least once every 24 hours for businesses with sensitive data.
What to Do If Your Business Is Hit
If you detect that an account has been compromised by credential stuffing: immediately reset the affected account's password, revoke all active sessions, check whether the attacker accessed any connected services or data, notify affected customers or partners as required by data protection law, and report the incident to your national cyber security centre (NCSC in the UK).
The most dangerous aspect of credential stuffing is that the attacker may not use the access immediately. They may wait weeks or months. This is why proactive defence — unique passwords, MFA, and monitoring — is far more effective than reactive response.
FAQs
How is credential stuffing different from a brute force attack?
Brute force attacks try to guess a single account's password through repeated attempts. Credential stuffing uses known username and password pairs from data breaches to try against multiple services. Credential stuffing is far more successful because the credentials are real.
Can credential stuffing be blocked entirely?
No, but it can be made practically ineffective. With unique passwords and MFA on every account, credential stuffing attempts will fail every time. The goal is not to block the attempts but to ensure they never succeed.
Does a password manager protect against credential stuffing?
Yes, primarily by ensuring every account has a unique password. Even if one service is breached, attackers cannot use those credentials against any other service because the passwords are different.
Should I use a credential monitoring service for my business?
Yes. Have I Been Pwned's domain monitoring is free for organisations and alerts you when any business email addresses appear in known breaches. Microsoft 365 Defender also includes credential monitoring for Exchange Online.