Risk-Based Authentication (RBA)
Risk-based authentication (RBA) adjusts what a user must do to prove themselves according to the assessed risk of the specific attempt. A familiar device signing in from a familiar place at a familiar time passes on a password alone. The same account reached from a new device in a new country is asked for more — or refused.
It is also called adaptive authentication. The defining idea is that the requirement is a variable rather than a constant.
| Also called | Adaptive authentication, contextual authentication |
| Decision made | At each authentication attempt, and often mid-session |
| Typical signals | Device, IP and network, geolocation, time, behavior, velocity, transaction value |
| Typical responses | Allow, step up to a second factor, step up to identity evidence, block |
| Regulatory anchor | PSD2 strong customer authentication and its transaction risk analysis exemption |
| Common failure | Escalating to a factor the attacker already controls |
How risk-based authentication works
An RBA system builds an expectation and measures the attempt against it. The expectation comes from what the account has done before — the devices it uses, the networks it appears on, the hours it is active, the pace at which it moves. Some signals are attributes of the session (a device fingerprint, an IP reputation, whether the connection is a known proxy). Others are behavioral: typing cadence, navigation patterns, the sequence of actions once inside.
Those signals produce a score, and the score selects a response. Low risk passes silently. Medium risk triggers a step-up. High risk blocks, or routes to review. The same machinery runs during a session, not only at the door, so a request to change a payee or raise a limit can be scored separately from the login that preceded it.
Most of the value is in what RBA does not ask. Friction is a budget, and spending it on every login exhausts it — users route around a control applied uniformly, and the business pays in abandoned sessions. Spending it on the small share of attempts that warrant it is what makes a strong second step tolerable at all.
Why it matters for identity verification
The decisive question about any RBA deployment is not how good the score is. It is what the step-up escalates to.
A risk engine that correctly flags a suspicious login and then sends a one-time code by SMS has escalated into a channel the attacker may already hold. Phone-based factors are the ones taken first in an account takeover — through SIM swap, port-out, or a compromised email that controls the recovery path. The engine did its job; the escalation landed inside the attacker’s perimeter.
Escalating instead to identity evidence — a government document plus a liveness-checked selfie matched against it — asks for something no amount of account compromise supplies. It is expensive, slow, and precisely the reason a risk score is worth having: it identifies the few moments where that cost is justified.
The same logic covers account recovery, which is where most takeovers actually succeed. A user who has lost their device fails every contextual signal an RBA system uses, and so does an attacker impersonating them. Context cannot separate the two; identity evidence can.
How RBA relates to MFA
| Risk-based authentication | MFA | |
|---|---|---|
| What it decides | Whether more proof is needed | What the additional proof is |
| Applied | Conditionally, per attempt | Uniformly, by policy |
| Optimizes for | Friction placed where risk is | Credential strength |
| Fails when | The baseline is wrong or poisoned | The second factor is phishable |
| Relationship | Decides when to invoke MFA | Is what RBA invokes |
They are complements, not alternatives. RBA without a strong factor to escalate to is an accurate alarm connected to a weak lock. A strong factor without RBA is a lock applied so often that users find ways around it.
What risk-based authentication cannot do
It scores the session, not the person. A high-confidence pass means this attempt resembles previous ones. If the account was opened fraudulently, every subsequent login is consistent with a history that was never legitimate, and RBA will keep confirming it.
A patient attacker can move the baseline. An attacker with persistent access can log in normally for weeks before doing anything, and the model adapts to them. This is the same weakness sleeper fraud exploits at the account level: time spent behaving well is time spent lowering the score.
Legitimate users generate genuine anomalies. Travel, a new phone, a work VPN and a house move all look like risk. Tuning for fewer false positives loosens the control; tuning the other way penalizes ordinary life, and unevenly — people who travel, share devices or change circumstances absorb most of the friction.
Signal quality degrades. Privacy protections, IP randomization and anti-fingerprinting measures reduce the distinctiveness of exactly the signals RBA depends on. The direction of travel makes contextual signals weaker over time, not stronger.
Frequently asked questions
What is the difference between risk-based and adaptive authentication?
In practice, none. Both describe adjusting authentication requirements to assessed risk. Vendors use the terms interchangeably, occasionally reserving “adaptive” for systems that also learn continuously from outcomes.
What signals does risk-based authentication use?
Device and browser characteristics, IP address and network reputation, geolocation and the plausibility of movement between locations, time of day, behavioral patterns such as typing and navigation, the velocity of attempts, and the sensitivity or value of the action being requested.
Does risk-based authentication satisfy PSD2 strong customer authentication?
Not by itself — SCA requires two independent factors. RBA is relevant through the transaction risk analysis exemption, which allows lower-value payments to skip SCA when the provider’s fraud rates stay under set thresholds. The exemption rests on measured fraud performance, not on having a risk engine.
Should a step-up use SMS one-time codes?
Only where nothing better is available. SMS is the factor most often compromised in an account takeover, through SIM swap or port-out, so escalating to it can deliver the challenge to the attacker. A phishing-resistant factor, or document and biometric verification for the highest-risk cases, is materially stronger.
Related reading
- Multi-factor authentication — what a risk-based step-up usually invokes
- Account takeover fraud — the attack RBA is most often deployed against
- Behavior-based fraud analysis — the behavioral signals that feed the score
- Identity proofing — establishing the identity that authentication later re-checks
