What is Risk-Based Authentication?

Back to learning

Risk-based authentication is a decision system for logins. It answers a practical question: should this login be allowed as normal, challenged, slowed down, blocked, or sent for review? The point is to avoid challenging every user every time, while still applying pressure when the request path looks wrong.

Password-only authentication treats two very different events the same way. A customer logging in from their usual phone during business hours gets the same base treatment as a bot using a breached password through a residential proxy. Multi-factor authentication helps, but asking for MFA on every login adds friction and can train users to approve prompts without thinking. RBA uses context to decide when extra proof is worth the interruption.

How the decision is made

RBA works by scoring signals that describe the login and the account history around it. The exact model can be rule based, statistical, machine learned, or a mix of all three. The implementation matters less than the discipline: collect useful signals, weight them against confirmed outcomes, and keep the response proportionate.

• Device and browser familiarity, including whether the account has used this device before
• Location, time of day, travel pattern, and whether the login fits the account's history
• Network context, including hosting, VPN, mobile, ASN, and residential proxy signals
• Behaviour before and after login, such as reset attempts, rapid retries, or high-risk account changes
• Credential risk, including known breached passwords or unusual failure patterns
• Current threat pressure on the route, such as a credential stuffing campaign against the login endpoint

No single item should carry the whole decision. A traveller using hotel Wi-Fi from a new country is not automatically an attacker. A login using a breached credential through unfamiliar infrastructure, after repeated failures across many accounts, deserves more scrutiny.

Outcomes, not just scores

The risk score has to connect to an action. Low-risk logins can proceed with normal authentication and background logging. Medium-risk attempts might require MFA, email verification, or a lower rate limit. High-risk attempts can be blocked, held for manual review, or forced through account recovery. A sensitive action after login, such as changing the email address, adding a payment method, or making a large transfer, can trigger a fresh step-up even if the original login looked acceptable.

This is where RBA differs from a static policy. The system can let a known device perform routine actions with little friction, then require stronger proof when the same account suddenly behaves differently. The user experience improves because the challenge appears when there is a reason, not as a blanket tax on every session.

MFA fallback and recovery risk

MFA, passkeys, and remembered devices often have fallback paths: SMS recovery, email reset, support-assisted recovery, device change, or account unlock. Attackers look for these paths because they may be easier to automate than the primary login. A risk-based system should treat fallback and recovery routes as sensitive actions, not as low-risk customer-service exceptions.

Useful evidence includes credential exposure, failed attempts across many accounts, unfamiliar devices, residential proxy signals, user-agent inconsistencies, and sudden changes after recovery. Those signals can feed bot management, account protection, and rate-limit decisions so the response fits the risk: allow, step up, slow down, log, block, or review.

False positives and privacy

RBA can create problems if the model is opaque or too aggressive. Shared mobile networks, corporate NAT, travel, accessibility tools, and privacy tools can all make legitimate traffic look different. Security teams need to measure false positives as carefully as missed attacks. If good customers cannot log in, they will reset passwords, contact support, abandon transactions, or lose trust.

Privacy also needs a deliberate design. RBA should collect the minimum data needed to make the account decision, keep retention periods clear, and restrict access to raw evidence. Device, behaviour, and network signals are useful because they reduce blind trust in a password, but they still need governance.

Where Peakhour fits

For web applications and APIs, RBA is strongest when it can use edge and account signals together. Peakhour Account Protection can combine breached credential checks, bot detection, residential proxy evidence, rate limiting, and request context so the authentication layer gets better inputs. The result is not "more MFA". It is a clearer decision about when to allow, challenge, rate limit, block, log, or review a login.

Good risk-based authentication should be almost invisible most of the time. It earns the right to interrupt a user by showing that the request, account, device, credential, or network context has changed enough to justify the extra step.