Adaptive authentication

In short

Adaptive authentication is the scheme in which authentication requirements vary based on the estimated risk of each attempt or operation. A routine access from the usual device goes through with no friction; an unusual transfer from a new device asks for a stronger factor.

It is also called risk-based authentication. That name captures the underlying shift well: the policy stops being a fixed rule per screen and becomes a decision per event.

The decision is built from signals, not a single condition

No single signal is enough on its own. The quality of the scheme depends on how many of these are actually available at the moment of deciding, which is an architecture constraint before it is a policy one.

• Device — whether it is a known device associated with that person, or one seen for the first time.
• Network and location — where the connection comes from, and above all any sharp change relative to usual behavior.
• Behavior — usage patterns, time of day, the pace of the interaction.
• The operation — the amount, the payee, whether it is the first time it appears, whether it touches contact or security data.
• Session state — how long ago the person authenticated, and which factor they used at that time.

A change in contact information deserves special attention, because it is usually the step right before an account takeover: whoever changes the associated phone number redirects, along the way, every factor that reaches that phone.

There are three possible outcomes

The policy evaluates the signals and produces a decision. Naming all three outcomes avoids the most common design mistake, which is only having the first and the third.

• Allow — the estimated risk is low and the operation continues with no added friction.
• Raise the requirement — an additional or stronger factor is requested before continuing. This is the step-up, and it is the outcome that gives the whole scheme its purpose.
• Block — the operation is stopped or routed to manual review.

The step-up is what allows raising average security without raising average friction. A scheme that only allows or blocks forces a choice between asking too much of everyone or letting through what should be looked at more carefully.

For the step-up to work, factors of different strength need to be available within the same flow. It is the direct connection to MFA: adaptive authentication decides when, and the inventory of factors determines what can be asked for.

Adaptive authentication is not fraud monitoring, and they need each other

Both assess risk with similar signals and act at different moments.

• Adaptive authentication — decides at the moment of access or operation, before executing it, and its response is to ask the person for something more.
• Fraud protection — evaluates the operation with rules and models, in real time or afterward, and its response is to approve, hold, or flag it.

The point of contact is evidence. A fraud engine that does not know which factor a person authenticated with evaluates half the context blindly, and an access policy that does not see that account's risk history decides with the other half. It is the practical reason both layers should consult the same digital identity instead of each keeping its own record.

What it covers and what it does not

It pays to be precise about the scope, because the term is often sold as if it solved the whole category.

It covers well access from an unknown device, which is what follows a successful credential stuffing attack, and sensitive operations within a session that looks legitimate.

It does not cover a phishing attack where the person hands over, in real time, the factor they were asked to step up with. The requirement went up and the attacker satisfied it, with the account holder's unwitting help.

Nor does it cover what happens in the middle of an already-established session with no operations that trigger the evaluation. That is the gap continuous authentication addresses.