# MFA and Risk-Based Security

From [Descope Fundamentals](https://learn.descope.io/c/foundations) — Learn the platform by configuring your own project — every module ends in work the app checks for real.

Take this course interactively at https://learn.descope.io/c/foundations/mfa-and-risk

---

![Adaptive MFA and Risk Signals. 71 seconds.](video:mfa-and-risk-adaptive-mfa-and-risk-signals)

Adaptive MFA — also called risk-based authentication — triggers additional verification only when a login looks risky, instead of applying the same friction to everyone every time. A user who always signs in from the same laptop at home passes through with a single factor; the same user signing in from an unfamiliar device on the other side of the world gets challenged in real time.

Think of a doorman who has learned a building's regulars. Someone who lives there and comes home at the usual hour walks straight in. A stranger at 3 a.m., or someone who apparently badged into a building across the country ten minutes ago, gets stopped for an ID check.

## Common signals

- Whether the device has been seen before
- Whether the login's location is realistically reachable from the last one — an impossible travel check
- The reputation of the originating IP address
- Any additional risk score pulled in from a connector

> [!NOTE]
> Adaptive MFA is not a Console toggle. Descope surfaces the assessment through riskInfo, and a condition step in the flow decides whether to route the user into extra verification or let them through — so it is built the same way as any other branch.

## Key terms

- Adaptive MFA (risk-based authentication) — MFA triggered by contextual risk signals at login.
- riskInfo — the risk assessment Descope surfaces for use in flow conditions.
- Impossible travel — a signal flagging two logins from locations too far apart to reach in the time between them.

![The Flow Template Library filtered to the adaptive MFA templates. Each one is a different risk signal wired up for you — IP reputation through AbuseIPDB or Bitsight, impossible travel, an untrusted device, or several combined. The ones naming a provider say so in the description: the template is the flow logic, and the connector to that service is a prerequisite you set up first.](mfa-and-risk-adaptive-mfa-and-risk-signals)

## Summary

- Which signals commonly drive an adaptive challenge
- That it is implemented as flow conditions on riskInfo
- How adaptive MFA and step-up differ: one reacts to how a login looks, the other to what a signed-in user tries to do

---

![Bot and Abuse Protection. 2 minutes.](video:mfa-and-risk-bot-and-abuse-protection)

Bot protection covers the controls that detect or block automated abuse of sign-up, login, and other sensitive flows — credential stuffing at scale, fake account creation, scripted brute force. Most bot traffic is not sophisticated; it is high-volume and blunt, which means lightweight defenses filter out a large share before it reaches your user database.

Left unchecked the costs are real beyond the obvious security risk: fake signups pollute the user database, automated traffic drives up infrastructure spend, and credential stuffing — replaying stolen username/password pairs from other breaches — succeeds simply because so many people reuse passwords. MFA is one of the strongest defenses here, because a bot with the correct password still cannot produce a legitimate second factor.

The Bot Trap is a built-in mitigation you enable with a toggle in a screen's configuration. It adds an invisible field real users never see or touch; many basic bots fill every available field, and the moment that hidden one is populated Descope flags the attempt as automated and can block or fail the step.

> [!WARNING]
> Bot Trap catches roughly 60% of bots — the unsophisticated ones that blindly autofill. More advanced, human-mimicking automation gets around it, so it is meant to be layered with other defenses rather than used alone.

The Check Rate Limit action adds another layer directly inside a flow, on Growth and Enterprise plans: set a threshold for attempts per minute keyed on IP, ASN, or JA4 fingerprint, and Descope throws an error once a caller crosses it. One action covers several abuse patterns at once — brute force, email spam, and user enumeration, where an attacker probes a screen with many addresses to learn which already exist.

## Key terms

- Bot Trap — a honeypot adding an invisible field; bots that autofill it are flagged.
- Check Rate Limit action — a Flow action throttling attempts per minute by IP, ASN, or JA4 key.
- Credential stuffing — using stolen username/password pairs from other breaches to attempt logins at scale.
- User enumeration — probing to determine which login identifiers are registered.

![A condition reading `riskInfo.riskScore` — the score Descope's risk engine puts into flow context — with Greater Than `0.9` as the threshold. What makes this a rejection rather than a branch is Treat as an error: the High risk side ends the run with `Sign up rejected` instead of continuing, while the Else Low risk branch leaves the toggle off and carries on normally.](mfa-and-risk-bot-and-abuse-protection)

## Summary

- What Bot Trap catches and what it misses
- What the rate-limit action can key on, and which abuses it addresses at once
- Why MFA specifically defeats credential stuffing
- That effective protection layers Bot Trap, rate limiting, fraud connectors, and MFA inside one flow

---

![MFA Fundamentals. 3 minutes.](video:mfa-and-risk-mfa-fundamentals)

Multi-factor authentication requires a user to prove their identity with two or more independent pieces of evidence instead of one. The three recognized factor types are knowledge (something you know, like a password), possession (something you have, like a phone receiving an OTP), and inherence (something you are, like a fingerprint). Combining factors from different categories means a stolen password alone is no longer enough — an attacker would also need the phone, the email account, or the biometric device.

> [!WARNING]
> Factors must come from genuinely different channels. A magic link to an email address plus an OTP to that same address is not valid MFA: both rely on control of the same inbox, so they are not independent evidence.

Descope implements MFA as a sequence of authentication methods inside a Flow, not as a single fixed setting. Verification on subsequent logins uses the same Sign-In or Sign-Up-Or-In functions as regular authentication, with the mfa Login Option set to true and the user's refresh token from the first successful sign-in passed along.

Some second factors verify with an approve/deny tap on another device rather than a code. That convenience carries a known risk called MFA bombing: an attacker who already has the password sends repeated approval prompts, hoping fatigue produces an accidental tap. Number-matching or PIN-entry confirmation is a meaningfully stronger defense than simple push approval.

Fallback covers what happens when a user cannot complete their usual second factor — a lost phone, an uninstalled authenticator app. Descope supports recovery codes and security questions for exactly this, so one missing device does not permanently lock out a legitimate user. Resetting a user's MFA enrollment is an administrative action through the Management SDKs and Console; because it removes a security barrier, treat it like a password reset — verify the requester through another channel first, and log it in the audit trail.

## Key terms

- MFA — authentication requiring two or more independent pieces of evidence.
- Authentication factor — a category of evidence: knowledge, possession, or inherence.
- amr claim — Authentication Methods Reference; includes mfa after a successful multi-factor sign-in.
- MFA bombing — flooding a user with repeated prompts, hoping fatigue produces an accidental approval.

![An MFA flow with the enrollment and the challenge on separate branches. The green blocks are conditions: `Is phone number verified?` sends a user with no second factor through Set up MFA before the OTP action, while a user who already has one drops to `Is impossible travel found?` and is only challenged if that comes back true. Both paths converge on the same END, which is what keeps the step optional without duplicating the journey.](mfa-and-risk-mfa-fundamentals)

## Summary

- Why two codes to the same channel do not constitute MFA
- That Descope models MFA as a sequence inside a Flow, not a toggle
- Which claim and value prove a session was genuinely multi-factor
- What fallback options prevent a lost device becoming a lost account

---

![Step-Up Authentication. 2 minutes.](video:mfa-and-risk-step-up-authentication)

Step-up authentication requires a user who is already logged in to re-authenticate before performing a sensitive operation. It is a subset of MFA, but where MFA usually applies at login, step-up applies later — at the moment a specific high-risk action is attempted. It is triggered by what the user is trying to do, not by contextual signals like a new device or location; that is Adaptive MFA's job.

Front-loading every possible check at login creates friction for actions most users never take. Step-up keeps the initial login light and protects specific operations exactly when they are needed. A banking app is the classic case: a password gets you in to check a balance, but moving money or changing account settings triggers a fresh prompt first.

## Typical triggers

- Financial transactions — making a purchase or transferring funds
- Accessing sensitive personal information
- Administrative operations and role changes
- Changing account settings, such as an email address or password
- Any high-risk action that should not rely solely on a session established earlier

After a successful step-up, Descope updates the session token with an su claim set to true, and your application checks for it before allowing the action. The stepped-up state is not permanent: it lasts only for the Step Up Token Timeout configured in Project Settings, after which the session reverts to standard permissions.

```json title="A stepped-up session token"
{
  "amr": ["password"],
  "exp": 1735689600,
  "iat": 1735686000,
  "su": true,
  "sub": "U2xf..."
}
```

> [!WARNING]
> Do not assume a valid session token is enough — a regular, non-stepped-up session validates successfully too. Validate the session and then explicitly check that su is present and true before running the protected operation.

## Key terms

- Step-up authentication — additional identity verification before a sensitive action, even for an authenticated user.
- su claim — the JWT claim set to true after a successful step-up.
- Step Up Token Timeout — how long a stepped-up session stays valid before reverting.

![Descope's pre-built Step Up flow, open in the builder. It starts from a Step Up action rather than a sign-in — the user is already authenticated — and offers Magic Link or a social provider as the re-authentication. Every path lands on Verified Successfully or END, and it is reaching one of those that reissues the session token with the `su` claim.](mfa-and-risk-step-up-authentication)

## Summary

- Why an already-authenticated user is still asked to re-prove identity
- That the su claim, not session validity, is what gates the action
- That step-up can come from a Flow or from stepup: true in Login Options
- That the stepped-up state expires and reverts

---