Credential stuffing is usually described as a login problem. An attacker takes breached username and password pairs, tests them against a site, and tries to find accounts where people reused passwords.
That description is accurate, but incomplete. The login is only the first gate. The real damage often happens in the flows that follow a successful login: password reset, email change, saved cards, loyalty balances, gift cards, account recovery, address changes, and checkout.
If account protection only watches the login form, it can miss the part of the attack that matters most to the business.
A successful credential stuffing attempt does not always look dramatic. The attacker may have valid credentials. They may come through residential proxy infrastructure. They may spread attempts across many IP addresses. They may slow the attack down to stay below simple thresholds. If the site treats a valid username and password as the end of the risk decision, the attacker inherits whatever the account can do.
That is why account takeover prevention needs to cover account actions, not just authentication.
The Attack Continues After the Password Works
Once an attacker is inside an account, they usually want persistence, value, or both.
A password reset or password change can lock the real customer out. An email change can move alerts, receipts, and recovery messages away from the owner. A phone number change can weaken later verification. A new shipping address can redirect physical goods. Stored payment methods can turn account access into immediate fraud. Gift cards, store credits, loyalty points, and refunds can be easier to monetise than a card transaction.
Checkout is often where the compromise becomes visible, but the risk builds earlier. A login from unfamiliar infrastructure followed by a profile change, then a saved-card purchase, is different from a returning customer browsing previous orders. A dormant account that suddenly redeems gift cards, changes email, and ships to a new address deserves more scrutiny than an ordinary login.
These flows are also common in APIs. Mobile apps, single-page applications, partner integrations, and checkout backends expose account actions through endpoints that may not share the same controls as the web login page. Attackers do not care whether the valuable step is behind /login, /api/account/email, or /checkout/payment. They follow the path that works.
Breached Credentials Are a Risk Signal
Breached credential checks are useful because they add context before the account is fully trusted. If a credential pair is known to have appeared in a breach, the site can treat the session differently from the start.
That does not mean every breached credential attempt should be handled the same way. A user may be genuinely logging in with a reused password. An attacker may be testing a combo list. A customer may be returning after a long period away. The point is to make the risk visible and carry it through the session.
Peakhour has written before about managing breached credential usage. The practical lesson is that credential risk should feed the wider account protection decision. A breached credential signal should be considered alongside client evidence, network context, request rate, route sensitivity, behaviour, and the action being attempted.
A low-risk page view and a stored-card checkout should not inherit the same confidence just because both follow a successful login.
MFA Helps, But It Does Not Close Every Path
Multi-factor authentication remains useful. It can stop many direct account takeover attempts and raise the cost of abuse. But MFA is not a complete defence when attackers use social engineering, session theft, weak recovery flows, trusted devices, or post-login actions that do not require step-up verification.
The better pattern is adaptive control. Let the login succeed when the evidence is low risk. Step up when the action matters. Ask for stronger verification before changing the email address, adding a new payout method, redeeming a stored balance, or checking out with saved payment details from an unfamiliar context.
This is not about adding friction everywhere. It is about reserving friction for the points where compromise turns into loss.
What to Monitor After Login
The useful signals are operational and specific:
- Credential risk at login, including known breached username and password pairs.
- New client, browser, or network evidence on an existing account.
- Password reset, password change, email change, and phone change attempts.
- New shipping addresses, payment method changes, stored-card use, gift card redemption, and loyalty balance activity.
- Sudden changes in behaviour, such as rapid checkout after login or repeated account recovery attempts.
- API routes that perform sensitive account actions without the same scrutiny as browser flows.
The response should match the confidence and consequence. Some events only need logging. Some need tighter rate limits. Some need a browser challenge, MFA step-up, temporary hold, customer notification, or review.
Credential stuffing defence is not finished when a password works or fails. The more useful question is: what does this session try to do next, and does the evidence justify trusting it?
For account protection, that is the line that matters.
