Adaptive MFA changes how much proof a login requires based on risk signals such as location, device, network and behavior. A familiar device at a usual hour may pass with a light check, while an odd location triggers a stronger one. It tunes friction. It does not replace phishing-resistant factors.
What does NIST say about risk-based signals?
NIST SP 800-63B-4 allows the idea explicitly. At all authentication assurance levels, indicators of potential fraud may be used to lower the risk of misauthentication. Its example: authentication from an unexpected geolocation or an address block belonging to a cloud service might prompt additional risk-based controls.
The guideline also mentions leveraging risk-based or adaptive authentication techniques to identify claimant behavior that falls within or outside of typical norms, using signals such as IP address, geolocation, timing of request patterns or browser metadata. It adds that those using fraud indicators must assess them for efficacy and to identify and mitigate potential negative impacts. That is a useful reminder that a risk engine can also harm users, for example by blocking people who travel or use a VPN.
What signals do adaptive systems use?
Common ones are device recognition, IP reputation and location, time of day, velocity such as many attempts in a short period, impossible travel between two logins, and the sensitivity of what the user is trying to reach. Higher-risk actions such as changing payment details or creating API keys can demand a fresh, stronger check even in a trusted session.
What can adaptive MFA do well?
It can reduce friction on routine, low-risk logins, so people accept MFA. It can step up for unusual activity, block clearly bad attempts such as a login from an address block known for abuse, and add a check on high-impact actions inside a session. Zero trust thinking points the same way: NIST SP 800-207 describes access decisions made per session using dynamic policy rather than trust granted by network location.
What are its limits?
First, it is a decision layer on top of factors, not a factor. If the lowest tier is a password alone, adaptive logic leaves a weak path. Set a floor: all logins use at least two factors, and risk raises the bar from there.
Second, attackers adapt. A phishing site can relay a session from a plausible location and device. This is why phishing-resistant factors matter more than risk scoring against that threat. NIST also warns about authentication fatigue, where repeated prompts wear users down. An adaptive system that sends more prompts when it is suspicious could add to that, so prefer a stronger factor over a repeated push.
Third, false positives and fairness. Travelers, remote workers on shared networks, and people with accessibility needs may trip rules more often. Track who gets challenged and provide a clear recovery path.
Fourth, privacy. Signals such as location and browser metadata are personal data in many places. Collect only what you need and say so in your policy.
A constructed example
A software company sets three tiers. Tier one: a known device on a usual network signs in with a passkey and gets no extra prompt. Tier two: a new device or a new country requires a security key or app code with number matching, and sends the user an email. Tier three: any attempt to create an API key, change a payout account or export user data requires a new check in the session even on a known device. After two months the team reviews challenge data and finds that staff on one mobile carrier were challenged constantly because the carrier's addresses looked like a foreign country. They adjust the rule to rely on device recognition for that case and add an allowance for it.
How to check or apply this
- Set a floor of two factors for every login before adding adaptive rules.
- List the signals you can collect reliably, and drop the ones you cannot defend.
- Define tiers: allow, step up, block. Write what each means.
- Add step-up checks to high-impact actions inside sessions.
- Prefer a stronger or phishing-resistant factor over repeated push prompts.
- Measure challenge rates, false positives and recovery tickets by user group.
- Review rules monthly for bias and drift, and document the data you use.
Quick check
Is adaptive MFA the same as MFA?
No. MFA requires multiple factors. Adaptive MFA decides, per login, how much additional proof to ask for.
Can risk signals be spoofed?
Yes. Attackers can imitate location and device characteristics, which is why risk scoring should sit on top of strong factors, not instead of them.
Sources
- NIST SP 800-63B-4 full text
- NIST SP 800-63B-4 publication page
- NIST SP 800-207, Zero Trust Architecture
Last reviewed: 18 October 2026.
