Adaptive authentication: the device signal that decides when to step up

Every login is a small bet. Challenge everyone on every sign-in and you protect the account but train your best customers to resent you. Challenge no one and a stolen password walks straight in. The average cost of a data breach reached $4.88 million in 2024, so the stakes on the wrong bet are real. Those stolen passwords are the common case rather than the exception, too: the 2025 Verizon Data Breach Investigations Report found stolen credentials behind 22 percent of confirmed breaches, the single most common way in. Adaptive authentication is the way out of that trade-off: instead of a fixed rule for everyone, it reads the context of each login and asks for more proof only when the sign-in looks risky. The single factor that carries the most weight in that decision is whether the device behind the login is one the account has used before. We build device-recognition signals for a living, and across the login traffic we have tested, the recognized device is the input most tightly tied to a genuine return.

Key takeaways

• Adaptive authentication (also called risk-based authentication) adjusts how much proof a login requires based on the risk of that specific attempt, rather than challenging every user the same way.
• It works by scoring context signals at sign-in: the device, the network and location, the time, and the behavior, then stepping up only when the score is high.
• The device signal does the heavy lifting. A login from a device the account has used for months is low risk; the same credentials on a brand-new device behind a masked connection is not.
• The point is to move friction to where the risk is: a recognized returning user glides through, and the second factor is saved for the sessions that actually look wrong.
• Recognizing the device is a signal your auth stack consumes. The engine, the MFA challenge, and the policy stay in your identity platform.

What is adaptive authentication?

Adaptive authentication is an approach to login security that varies the amount of verification a user must provide based on the risk of the individual sign-in. A low-risk login, a returning customer on their usual laptop and network, is allowed through on the password alone. A high-risk login, the same credentials arriving from an unfamiliar device in a new country, is asked for a second factor, held for review, or denied. The system adapts the requirement to the context instead of applying one blanket rule.

The reason it exists is that a fixed policy is wrong in both directions. Requiring a second factor from everyone on every login is secure but heavy, and the friction pushes teams to weaken or disable it. Requiring nothing beyond a password is frictionless but defenseless against a credential that has leaked. Adaptive authentication resolves the tension by spending friction only where the risk is. A 2019 study that measured risk-based authentication on real traffic, published in the proceedings of IFIP SEC, found it blocks the large majority of account-takeover attempts while challenging only a small fraction of legitimate logins, which is the balance a blanket rule cannot strike.

Adaptive vs risk-based authentication: are they the same?

In practice the two terms are used interchangeably, and this guide treats them as one idea. If a distinction is drawn, it is one of emphasis:

• Risk-based authentication (RBA) names the mechanism: score the risk of a login, then require more proof when the score is high.
• Adaptive authentication names the behavior: the system adapts, over the same signals, and often across the whole session rather than just the login moment.

Both describe the same loop, read the context, compute a risk level, and adjust the challenge. The vocabulary varies by vendor and by document; the underlying model does not. Throughout this guide, "adaptive" and "risk-based" point at the same thing.

How adaptive authentication works: the signals it weighs

An adaptive system builds a risk picture from context signals gathered at the moment of sign-in, then compares that picture against how the account normally behaves. No single signal is a verdict; the risk score is how far the login drifts from the account's baseline. The signals that carry the most weight:

Signal at login	What it tells the risk engine	Weight in the decision
Is this a device the account has used before?	a recognized device is the strongest sign the login is genuine	High
Network and connection: is it masked by a VPN, proxy, or datacenter?	a masked origin is common in credential resale and stuffing	Medium-High
Location and impossible travel	a jump the account could not physically make points to a shared credential	High
Time and pattern of the attempt	an odd hour or a burst of failures across accounts looks automated	Medium
Behavior during the session	actions that do not match the account's history raise the risk mid-session	Medium

The engine combines these into a single risk level and maps it to an action: allow, step up to a second factor, or deny. The whole point is that most logins are ordinary and score low, so the extra proof is reserved for the minority that look wrong. That reserve is what keeps a recognized customer from meeting a challenge they do not need.

The device is the signal that decides when to step up

Read down that table and one signal is doing more than the others. The network can be masked, the location can be moved with a VPN, the time can be chosen, but the machine behind the login is the thing an attacker who bought a password did not inherit along with it. That is why device recognition is the anchor of an adaptive decision: it is the factor most correlated with "this is really the account owner" and the hardest for an impostor to fake.

The logic is simple in both directions. When an account has signed in from the same handful of devices for months and a new login arrives on one of them, the risk is low and the user should glide through. When the same credentials appear on a device the account has never touched, especially behind a masked connection, the risk is high and a step-up is warranted. Recognizing the returning device is what lets the system be confident enough to skip the challenge, and unfamiliar-device is what triggers it. The recognized device is consistently the cleanest predictor of a genuine return, which is why it deserves the most weight in the score.

We measured that ranking rather than assumed it. Grading each signal on its own across real login traffic, we ran the comparison and saw the recognized device separate genuine returns from impostor sessions more cleanly than the network, the location, or the time, each of which an attacker can shift at will. The machine behind the login is the one input a stolen password never arrives with, which is why our score leans on it hardest.

This is also where adaptive authentication meets device-based authentication: the recognized device is the input, and the adaptive engine is what acts on it. A durable device identifier that survives a cleared cookie and a rotated IP is what makes "have we seen this machine before" answerable at all.

Adaptive authentication vs MFA

Adaptive authentication and multi-factor authentication are often set against each other, but they do different jobs and work best together. MFA is the control: the second factor, a one-time code, a push, a passkey, that proves the user beyond a password, the mechanism NIST's digital identity guidelines define through authenticator assurance levels. Adaptive authentication is the decision: whether, and when, to demand that factor.

A blanket MFA policy prompts every user on every login, which is secure but adds friction to your most loyal customers and, in practice, gets weakened because of it. Adaptive authentication keeps MFA in place but aims it: a recognized device on a normal connection is trusted through, while an unfamiliar or masked session is the one asked to complete the second factor. The device signal decides when MFA is worth asking for, working alongside the MFA you already run. The same targeting is what makes passwordless authentication smoother too, since a recognized device can raise the confidence of a passkey login.

Where the device signal fits with your auth stack

The honest scope here is narrow on purpose. The risk engine that computes the score, the MFA challenge, the passkey ceremony, the session policy, and the final allow-or-deny all live in your identity and authentication stack, where they belong. A device-recognition layer works alongside them, supplying one input those systems weigh: an independent read of whether this session comes from a device the account has used before, and whether the connection behind it is masked.

In practice the two halves chain together. The device layer scores the session and names the signals; your auth rules decide what a given score earns, a second factor, a hold, a re-verification, or a clean pass. That keeps your step-up challenges aimed at the logins that deserve them and the decision inside your own system. It is a supporting signal weighed into your policy, not a verdict handed down in place of it, which is the same shape as the detection side of account takeover, read from the friction-reduction angle rather than the attack-catching one.

Adding the device signal to adaptive authentication with ShieldLabs

ShieldLabs gives your adaptive authentication the device signal it turns on. You add one JavaScript snippet to your login page, and on each attempt it returns persistent identification plus a risk score from 0 to 100 with the named signals behind it: whether the device is one this account has used before, and whether the connection carries anonymity signals such as a VPN, an anonymous proxy, a datacenter, or an anti-detect browser. The identifier is derived and survives a cleared cookie and a rotated IP, so a returning customer is recognized as the same machine and a genuinely new device stands out.

ShieldLabs scores the session and names the evidence. You read the risk score and named signals through the API and webhooks and decide, by your own rules, when to let a recognized device glide through and when to step up an unfamiliar one, so the policy stays in your application. Recognition is probabilistic, up to 99 percent rather than a guaranteed unique ID, and a privacy browser or incognito session reduces it, which is why the read is a weighted signal and not a verdict. The same identity layer carries into account takeover prevention on the security side. The free tier covers your first 5,000 identifications.

Sources

1. Wiefling, Lo Iacono, Dürmuth: Is This Really You? An Empirical Study on Risk-Based Authentication Applied in the Wild (IFIP SEC, 2019)
2. Gavazzi et al.: A Study of Multi-Factor and Risk-Based Authentication Availability (USENIX Security, 2023)
3. NIST: SP 800-63B Digital Identity Guidelines (authentication and authenticator assurance)
4. IBM: Cost of a Data Breach Report 2024
5. Verizon: 2025 Data Breach Investigations Report (2025)
6. Wikipedia: Multi-factor authentication