Step-up authentication: when and how to ask more from the user

Step-up authentication: when and how to ask more from the user

A user logs into their account from their usual device and checks their balance: no need to interrupt them. But if that same user adds a new beneficiary and transfers a large amount from a network they've never used before, the story changes. That's where step-up authentication comes in: asking for more evidence only when the risk justifies it, not by default, not out of operational inertia, and not as a defensive reflex.

Trust shifts from one moment to the next within the same session, and treating it as a fixed value is usually what fails. Defining how much evidence to request at each point in the journey—not just at login—is what turns authentication into a business tool instead of an entry-point formality.

For years, authentication was seen as a door that opens once: password, second factor, and the risk is considered settled. But that view breaks down when the session changes in real time—whether due to a new device, a location that doesn't fit, a password change, an unusual transfer, or an atypical sequence. Any of these signals can turn a routine interaction into one that demands much more than a static credential.

Step-up authentication makes it possible to move from a static model to a dynamic one. Instead of interrupting everyone equally, the system evaluates context and asks for more evidence when trust changes.

Step-up authentication turns authentication into a dynamic decision

Step-up authentication adds an extra factor when risk increases—whether due to an action, a session, or a particular signal. It doesn't replace login; it reinforces it at the points where the initial evidence is no longer enough.

Unlike the traditional model—where everyone goes through the same filters at entry—dynamic authentication evaluates risk throughout the journey and only tightens verification when needed. The result: adaptive security, not uniform rigidity.

Step-up authentication
Additional authentication triggered by risk
The system asks for more evidence when the session's trust level changes.

This approach borrows its logic from Zero Trust: trust is never granted implicitly and is continuously reassessed throughout the entire session, not just at the front door.

Back to the example at the start: if the session deviates from what's normal—new network, new beneficiary, large amount—the system should ask for more evidence. It's not adding friction on a whim, but because the risk changed and the decision needs more context to be reliable.

High-risk events define when to ask for more evidence

The "when" is the trickiest part of the design. Requesting step-up authentication too often fatigues legitimate users, but requesting it too late lets fraud through. The balance lies in identifying which events carry the greatest impact if something goes wrong, because not all actions carry equal weight, and treating them all the same is costly in both security and conversion.

Much account-takeover fraud attacks where the system lowers its guard: password recovery, new device registration, or contact information changes. The most common scenarios are:

• Sensitive transfers or payments — large amounts, new recipients, off-hours operations, or unusual patterns.
• Password change — especially from a new device, a different location, or after failed attempts.
• New device registration — a critical signal when the account already had known devices.
• Email or phone change — because it can affect account recovery and future control.
• Access recovery — one of the most exploited points for account takeover.
• Access from a new network or location — IP, country, proxy, VPN, or route that doesn't match history.
• Administrative operations — changes to permissions, roles, limits, beneficiaries, or sensitive data.
• Automation signals — speed, sequence, or behavior consistent with bots or scripts.

In financial services, these events tend to show up in transfers, adding recipients, account recovery, and data changes. In gaming, they show up in withdrawals, payment method changes, and promotion abuse; in government, in sensitive procedures or access to digital credentials.

A common mistake is treating all these cases as equivalent. A balance inquiry shouldn't require the same as a transfer, and a login from a known device shouldn't face the same friction as an account recovery from a newly registered phone. Distinguishing and prioritizing these scenarios is what allows the risk team to focus controls where they really matter, without legitimate users noticing unnecessary friction.

Session signals show when trust changes

Step-up authentication performs better when it combines risk signals instead of relying on isolated rules. A rule like "if the amount exceeds X, request MFA" is a good starting point, but insufficient against attacks that combine multiple signals.

Adaptive systems jointly evaluate user, device, and environment attributes—IP, geolocation, time, transaction type, and behavioral deviations—to make a decision. No single signal acts alone; what matters is the story they build together.

The most useful signals tend to be grouped as follows:

• Device — history, integrity, recent changes, emulators, or anomalous signals.
• Location — country, city, impossible travel speed, unusual networks, or intermediaries.
• Behavior — browsing pace, typing, action sequence, and deviations from the usual pattern.
• Identity — trust level from onboarding, biometrics, liveness detection, and prior verifications.
• Operation — amount, destination, sensitivity of the change, new beneficiary, or type of action.
• History — complaints, failed attempts, recent changes, and risk events.
• Regulatory context — industry, country, risk policy, and required evidence.

A legitimate user might travel, change devices, type quickly, or operate at unusual hours without any of it meaning anything. But if a user logs in from a new location, changes their phone, adds a beneficiary, and transfers money within minutes, you're not looking at four isolated events: you're looking at a risk sequence. And that's when it makes sense to ask for more—not out of general distrust, but because the session has stopped resembling what that user normally does.

Experience improves when friction shows up with judgment

When authentication is poorly designed, it interrupts indiscriminately: it applies the same friction to everything. When it's well thought out, it only steps in at key moments and, on top of that, lets the user know why an extra step is being requested. That detail transforms the experience, reduces abandonment, and improves user trust.

Users accept additional verification when they understand it's protecting a sensitive action. Fatigue, on the other hand, appears when the system demands codes or approvals for low-risk tasks. That's where the difference shows between a well-calibrated authentication policy and one that just piles on layers out of caution.

Step-up authentication should prioritize fast, familiar methods:

• Biometrics — useful for confirming presence and identity continuity with low friction.
• FIDO2 — that is, a passwordless authentication standard based on cryptographic device keys, strong against phishing-based impersonation and credential reuse.
• Contextual MFA — that is, requesting a second factor (code, push notification, biometrics) only when risk justifies it.
• Passwordless authentication — reduces reliance on remembered or reused passwords.
• Secure notifications — useful when they include clear context about the operation.
• Liveness detection — necessary when risk requires confirming real presence.

If a user has already been verified, that trust should be reusable intelligently: not every action needs a full new identity validation. At VU, we connect passwordless authentication and MFA with risk signals through Authenticate, while Verify provides the initial anchor with identity verification and biometric onboarding. The result is security that protects without interrupting, and that only asks for more when it's truly needed.

Best practices connect authentication, identity, and fraud prevention

Step-up authentication loses precision when it acts alone. An approach focused only on login arrives too late; one that only watches the transaction lacks context; one that only checks the device may confuse a valid change with a threat. Each partial view is a blind spot, and blind spots in security always come at a cost.

That's why defense gains precision when it connects identity, authentication, and fraud prevention into a single flow. That connection allows decisions to be made with more evidence and less friction for the legitimate user, because each layer contributes information the others can't see on their own.

Below are best practices worth applying:

• Define sensitive events — transfers, data changes, access recovery, new devices, and administrative operations.
• Assign risk levels — low, medium, high, or critical based on impact and accumulated signals.
• Use proportional factors — don't require liveness detection when local biometrics or FIDO2 will do.
• Avoid repetitive friction — don't challenge the user multiple times for the same reason within a short window.
• Show context — explain what operation is being validated and from where.
• Close weak recovery paths — review recovery via SMS, email, or manual support without sufficient evidence.
• Log decisions — record reason, signal, factor applied, and outcome.
• Measure false positives — a policy that blocks too much also generates losses.
• Review thresholds — fraud evolves, and risk models should too.
• Connect with fraud prevention — additional authentication should feed into the subsequent risk decision.

Adding authentication factors without a clear criterion isn't enough to reduce fraud. What really matters is choosing the right factor, at the right moment, with the least possible friction. Global reports on credential theft make it clear: abuse of this type of access continues to be one of the main entry points in reported attacks.

An attacker can gain access with valid credentials, hijack a session, or attack the password recovery flow. That's why reassessing trust at every stage of the journey—not just at the start—is the only way to stay ahead of a risk that changes in real time.

Adaptive authentication marks the next standard

The trend is clear: authentication is no longer resolved in a single step, but becomes a continuous evaluation. Step-up authentication is part of that model, but it doesn't cover everything. The fundamental shift is understanding that trust is built session after session, not just at the moment of login.

Adaptive authentication is the framework that ties it all together: it evaluates risk at every step, adjusts friction to context, protects critical operations, and sustains a smooth experience for the legitimate user.

At VU, we organize that architecture into three capabilities:

• Verify for identity verification and biometric onboarding.
• Authenticate for authentication, MFA, and passwordless access.
• Protect for real-time fraud prevention.

When these layers work together, the system makes better decisions: it lets a trustworthy session through without friction, requests biometrics for a sensitive operation, escalates a password recovery that shows risk signals, or blocks a sequence that matches account-takeover patterns.

Asking for more doesn't make an account safer by itself. Asking for it at the moment trust actually changed, does.

Restore trust in every digital interaction. Discover how VU connects adaptive authentication, MFA, and fraud prevention to ask for more only when risk justifies it.
Schedule a demo