How YubiKey stops credential stuffing at the protocol

Back to Glossary

Key Takeaways

• Credential stuffing succeeds because most humans have a limited ability to recall multiple complex series of numbers and characters, and thus tend to reuse their passwords. Statistically, over 51% of passwords are reused, and attackers use stolen credentials from one breach to log in across other services.
• FIDO2 and passkeys use origin-bound credentials that only work on the service where they were registered.
• Protecting only the login flow leaves gaps. Credential stuffing can also exploit weak registration and recovery processes, which is why phishing-resistant authentication must cover the entire user lifecycle to create truly phishing-resistant users.
• Hardware security keys like the YubiKey 5 Series provide the highest-assurance implementation of phishing-resistant MFA, by storing device-bound passkeys on a secure element that cannot be extracted, copied, or replayed across services.

What is credential stuffing?

Credential stuffing doesn’t require a sophisticated exploit or a zero-day vulnerability. An attacker takes a list of usernames and passwords stolen from one breach, points an automated tool at login forms across the web, and tests every combination at scale. Bots handle the volume, submitting stolen credential pairs faster than any human could. The bet is straightforward: if any users have reused the same credentials across multiple sites, the attacker will be able to compromise those accounts. The FIDO Alliance puts the exposure plainly: up to 51% of passwords are reused, making them subject to credential stuffing attacks.

NIST classifies it as a type of brute-force attack, but the distinction from traditional brute force matters, since the attacker is not guessing passwords randomly, but rather, is using real credentials that are confirmed to have worked somewhere else.

Additionally, unlike password spraying, which tries a small set of common passwords against a large number of accounts, credential stuffing uses specific stolen pairs. The databases of stolen credentials driving these attacks, known as combo lists, are assembled from years of accumulated breaches, giving attackers a ready-made inventory of real credentials to test at scale.

These attacks are also more adaptive than they first appear. Reporting from Brian Krebs has shown that attackers try several dozen variations on a password that each target had previously used at another site. Even users who make minor modifications to their passwords across services are still exposed, and the outcome is often account takeover.

The standard defense playbook represents real progress. Rate limiting, CAPTCHAs, IP address blocklists, bot detection, and account lockout policies triggered by repeated failed login attempts all raise the cost of an attack. Organizations running the aforementioned security measures are materially safer than those that are not. The challenge is that these defenses manage the volume of the attack without addressing the underlying reason it works: passwords are unintentionally reusable by design.

Why credential stuffing is an architectural problem

Conventional wisdom treats reusability as a user problem. If people chose stronger passwords or stopped reusing them, the attacks wouldn’t work. That framing is accurate but incomplete. The deeper problem is architectural: passwords are shared secrets, and shared secrets are inherently reusable across any system that accepts them.

When a user creates an account, the password they choose exists as a piece of knowledge that both the user and the service must store and verify. Since login credentials exist independently of any specific service, the verification process has no way to confirm the context in which access is being requested. The same string of characters works on any login page with a matching record.

According to the FIDO Alliance, passwords are the root cause of over 80% of data breaches, and up to 51% of passwords are reused, making them vulnerable to credential stuffing attacks. Compromised credentials circulate indefinitely. A password stolen years ago remains dangerous if it has not been changed, and even strong passwords offer no structural protection against credential stuffing if they are reused.

NIST reinforces this by noting that systems are especially susceptible to credential stuffing when they allow multiple incorrect logins without account lockouts. But even systems with lockout policies only slow the attack, and do not change the core equation – if the credential is valid, the login succeeds.

Most attackers don’t break in. They log in.

What credential stuffing costs your organization

When attackers can log in rather than break in, the consequences are immediate and far-reaching. Credential stuffing generates sustained, automated pressure on any organization with user accounts and a login page. Once an attacker authenticates as a legitimate user, they gain unauthorized access to the account and everything connected to it: personal data, financial records, connected systems, and downstream services.

For organizations in financial services, retail, healthcare, and SaaS, a single successful campaign can trigger fraud losses, regulatory investigations, breach notification obligations, and lasting damage to customer trust.

The indirect costs compound quickly. Account lockout policies designed to slow credential stuffing also lock out legitimate users. Support tickets spike, and productivity drops. High-volume campaigns can cause downtime that affects every user, whether targeted or not.

Microsoft Threat Intelligence has documented attackers launching credential stuffing campaigns specifically against accounts that didn’t have MFA enabled, underscoring that uneven coverage turns any unprotected user population into an entry point. Cybersecurity teams already stretched thin must triage millions of automated login attempts while managing the operational fallout.

Cyber insurance carriers have taken notice. Premiums are rising. Organizations that cannot demonstrate phishing-resistant MFA across their user base face higher costs and, in some cases, reduced coverage. Organizations subject to data protection regulations face mandatory breach notification and potential fines when customer data is exposed through successful credential stuffing.

Why MFA alone does not stop credential stuffing

The natural response to this exposure is to add a second factor. Any MFA will dramatically improve your risk posture over passwords alone. An attacker armed with a valid username and password cannot complete a login if a second factor is required and they cannot supply it. As CISA states, with MFA, stolen credentials are not sufficient to gain access to a user’s account because the attacker cannot bypass second-factor authentication.

However, not all second factors resist bypass equally.

An SMS code can be intercepted through SIM-swapping or captured in real time via an attacker-in-the-middle (AitM) proxy that relays it to the legitimate service. A TOTP seed stored in a software authenticator can be extracted if the device is compromised by malware, and the code itself is equally vulnerable to AitM relay since it has no awareness of which site is requesting it. Push notifications can be exploited through approval fatigue, where an attacker triggers repeated prompts until a user approves one to make them stop.

These are well-documented, actively exploited attack paths. Each of these methods still relies on a value, whether a code, a seed, or an approval tap, that is transferable. An attacker who obtains or intercepts that value can use it from their own device, against any service, with no mechanism to verify where the request originated.

Authentication method	Stops credential replay?	Why
Password alone	No	Shared secret, reusable across any service that accepts it
SMS / TOTP codes	Partially	Adds a second factor, but codes are interceptable and not origin-bound
Push notifications	Partially	Adds a second factor, but vulnerable to approval fatigue attacks
FIDO2 / passkeys	Yes	Credential is origin-bound and cannot be replayed on a different service

CISA has stated that legacy MFA is no match for modern threats. What matters is whether the authentication method is phishable or phishing-resistant.

How origin-bound authentication eliminates reusable credentials

Phishing-resistant authentication closes that gap by binding the credential to the specific origin where it was registered, making it impossible to reuse across services.

This is what FIDO2/WebAuthn, the modern authentication standards co-created by Yubico alongside Google and other FIDO Alliance members, delivers. When a user registers a passkey with a service, the authenticator generates a unique cryptographic key pair. The private key stays on the authenticator. The public key is shared with the service.

At login, the website or service (otherwise known as the relying party) initiates a challenge via the browser, which automatically injects the true origin. If the current authentication request is being sent from an origin that does not match the one recorded during registration, the authenticator will be unable to find a matching credential and thus returns an error back to the browser. The origin-bound credential never signs a malicious request, leaving nothing for an attacker to intercept, extract, or replay.

Google’s security team describes it precisely: since each passkey can only be used for a single account, there is no risk of reusing them across services. This is the property that makes credential stuffing structurally irrelevant. Even if an attacker obtained a user’s private key material, it would only authenticate against the single service it was registered to. But for device-bound passkeys, the private key cannot even be exported from the hardware at all, mitigating this risk entirely.

Origin binding is one of the congregating mechanisms that creates robust phishing resistance. It is important to distinguish this from shared secret methods, which protocols like OTP use. OTPs are cryptographically generated, but they have no awareness of which site is requesting them. A valid OTP works identically whether entered on a legitimate login page or a spoofed one because it lacks context. Origin binding closes that gap by mathematically ting the credential to the specific domain.

Currently, only two forms of authentication meet the bar for phishing-resistant MFA: PIV/Smart Card and the modern FIDO2/WebAuthn standard.

How hardware security keys defend against credential stuffing

Of those two, FIDO2/WebAuthn is the standard underlying passkeys, and universally supported across modern browsers, mobile devices and cloud providers such as Apple and Google. Furthermore, hardware security keys provide the highest-assurance implementation of it by ensuring that private key material never exists outside a secure element in the user’s possession.

However, the YubiKey 5 Series supports both FIDO2/WebAuthn, and the still widely used PIV/Smart Card standard, but also FIDO U2F, OATH OTP and OpenPGP, covering both modern and legacy authentication systems within a single device. 

Synced passkeys, where the private key is backed up and synchronized across devices via cloud infrastructure like iCloud Keychain or Google Password Manager, offer convenience and represent a meaningful security improvement over passwords and phishable MFA. Because the private key travels outside the original device, however, it is subject to the security properties of the hosting cloud infrastructure rather than remaining anchored to a single piece of hardware. In other words, a security breach at Google or Apple for example, could jeopardize any user credentials that have been stored there.

Device-bound passkeys on a hardware security key keep the credential anchored to a physical object under the user’s control. For environments that want a smoother login experience, the YubiKey Bio Series supports fingerprint recognition, greatly reducing the need for PIN entry with a tap-and-touch biometric match stored locally on the key. For organizations that need only FIDO2/WebAuthn without legacy protocol support, the Security Key Series provides a FIDO-only entry point. For federal and regulated environments that require FIPS validation, the YubiKey 5 FIPS Series delivers the same multi-protocol capabilities with FIPS 140-3 compliance.

The FIDO Alliance has noted that enterprises have expressed interest in passkeys but do not know where to start, and that synced passkey models may not meet every organization’s security requirements. Device-bound passkeys on hardware security keys like the YubiKey 5 Series provide the highest-assurance implementation of phishing-resistant authentication for any user who needs the strongest credential protection, from frontline workers to privileged accounts, while remaining portable across devices via USB and NFC. Organizations in regulated industries and high-assurance environments have particular urgency, but the protection applies to every user population.

All YubiKey models meet NIST Authenticator Assurance Level 3 (AAL3) requirements in a proper multi-factor configuration. That strength, however, only protects the surfaces it covers.

How to protect the full authentication lifecycle

Strengthening the login flow is a necessary step, but not sufficient to fully protect users. Effective credential stuffing prevention requires treating every authentication surface as a potential entry point. Credential stuffing and the account takeover it enables can exploit any step in the authentication lifecycle where a reusable credential is accepted.

An organization that deploys phishing-resistant MFA for login but still allows password-only registration or SMS-based account recovery has left two attack paths open. An attacker with stolen credentials can exploit accounts that have not registered a phishing-resistant authenticator, or they can trigger a recovery flow, intercept a one-time code sent via SMS, and bypass phishing-resistant MFA entirely by resetting the account to a weaker state.

Most credential stuffing guidance overlooks this lifecycle gap. Phishing-resistant authentication must cover the entire user lifecycle: registration, login, and recovery. That coverage is what creates phishing-resistant users. Without phishing-resistant users, you cannot have a phishing-resistant enterprise.

The practical requirements are straightforward:

• Registration should require identity proofing
• Recovery should require the same assurance level as primary login, not a fallback to a weaker method
• Every user population, from privileged accounts to frontline workers, needs coverage

An attacker who compromises a frontline employee’s account through a weak recovery flow could move laterally and eventually gain the same foothold as one who compromises an administrator through phishable means. Credential stuffing is a volume attack, and attempts to find the weakest entry point across the full lifecycle.

Get started with phishing-resistant authentication

Credential stuffing exploits a single architectural weakness: the reusable credential. Every defense that leaves that weakness intact raises the cost of the attack without eliminating it. The YubiKey 5 Series eliminates it structurally, with device-bound passkeys that are origin-bound, stored on a secure element, and cannot be replayed across services.

The YubiKey integrates with existing identity providers like Microsoft Entra, Okta, and Duo, so it fits into your current infrastructure without replacing it. For organizations ready to deploy at scale, YubiKey as a Service offers simple and scalable global deployments, with YubiKeys shipped directly to end users through Delivery services. Enrollment services include FIDO Pre-Reg, which ships pre-registered keys directly to users ready to activate with a PIN, and YubiEnroll for IT-managed deployments of any size. Explore the YubiKey 5 Series to see how device-bound passkeys work. Contact Yubico to start moving your organization from reusable credentials to phishing-resistant authentication.