Step-Up Auth Lab
Good authentication is not a wall in front of every action — it is the right friction at the right moment. Work a queue of account actions and make the call: allow it silently, step up with a re-challenge, or deny and force out-of-band recovery. A new payee, a change to the MFA device / email / password / payout account, a privileged op, a new device or impossible travelearn a challenge. A big-but-recurring payment, a benign re-login and a verified own-account transfer do not — and a tiny payment to a brand-new payee still does. Challenge everything and you train users to click through the one prompt that mattered. Calibrate the queue.
The real job. More noise, a tighter clock.
Authorization queue
For each action decide: allow silently, step up, or deny. Challenge where risk justifies the friction — not everywhere.
#1
View account balance
user pattern: Checks balance most mornings from this device
#2
Add new payee / beneficiary
user pattern: Has paid 4 saved payees for 2 years; this one is new
#3
Change account password
user pattern: Routine security hygiene change
#4
Wire $45,000 to payroll vendor
user pattern: Same vendor, same ~$45k, monthly for 2 years
#5
Send $4.20 to a new payee
user pattern: User is US-based and has never paid this payee
#6
Log in
user pattern: Logs in from this device daily around this time
#7
Change registered email address
user pattern: Current email unchanged for years
#8
Download monthly statement (PDF)
user pattern: Downloads a statement most months
#9
Raise daily transfer limit to $100k
user pattern: Limit untouched since account opening
#10
Wire $900 to a recurring payee
user pattern: Always pays this payee from the usual Austin device
#11
Log in again
user pattern: Normal: reopens the app several times a day
#12
Update notification & marketing preferences
user pattern: Routine preference tweak
#13
Transfer $3,000 to a newly-added payee
user pattern: Regularly sweeps cash to this own-name account
#14
Add first-ever payee
user pattern: New account; has never added a payee before
Right friction, right moment
Decide each action, then grade. So far 0/14 called, 0 under-challenged, 0 over-challenged.
How it is scored
Under-challenging (allowing a risky action, or merely challenging one that needed a hard deny) is the heavier penalty — it is the security failure.
Over-challenging (friction on a routine action) takes a lighter bite — a system that cries wolf trains users to click through the prompts that matter.
Harder tiers add subtler context and traps: a big recurring payment that should allow, a new payee that should still step up, and takeover-in-progress cases that should deny.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based step-up / risk-based authentication lab: work a queue of ~20 account actions and decide each one — allow silently, step up (re-challenge), or deny and route to out-of-band recovery.
- The whole skill is balance: step up where risk justifies the friction (a new payee, an MFA / email / password / payout / limit change, a privileged op, a new device, impossible travel, a high risk score) and allow silently where it does not — because challenging every click trains users to click through the prompts that matter.
- Deliberate traps on both sides: a large payment to a known recurring payee that should allow, a tiny payment to a brand-new payee from a new device that should step up, a verified own-account transfer that should allow, and a “setting change” that is only marketing preferences.
- A separate deny tier at Elite: when impossible travel, failed-MFA bursts or credential stuffing coincide on a high-impact action, the session is probably attacker-controlled and a self-service challenge cannot be trusted — you block and force verified out-of-band recovery.
- You are graded on calibration: under-challenging (the security error) costs more than over-challenging (the friction error), and after grading every action explains why its call is right.
Frequently asked questions
What is the Step-Up Auth Lab?
A free, in-browser exercise in risk-based (adaptive) authentication. You work a queue of account actions — payments, adding a beneficiary, changing a security setting, logins, privileged operations — each with its context (amount, payee history, device, location / travel, risk score, recent activity, and what is normal for the user). For each you make the authorization call: allow it silently, step up with a re-challenge (MFA / re-authentication), or deny it and route to verified out-of-band recovery.
When should an action step up versus allow silently?
Step up when a risk factor crosses a threshold: a new payee / beneficiary, a change to a takeover-anchor setting (MFA device, recovery email, password, payout account, transfer limit), a privileged operation, a new / unrecognised device, anomalous context (impossible travel, an elevated model risk score), or a payment far outside the user’s established pattern. Allow silently when the action is low-sensitivity or routine for this user — a recurring payment that matches the standing pattern, a benign re-login, a read, a non-security preference change. The reason not to challenge everything is real: needless prompts cause MFA fatigue and train people to click through the challenge that actually matters.
When is a step-up not enough — when do you deny?
When several strong account-takeover signals coincide on a high-impact action, the session itself is probably attacker-controlled and a pushed second factor may be answered by the attacker (MFA fatigue, SIM-swap). Example: changing the payout account during impossible travel from a new device with a burst of failed MFA pushes, or a password reset in the middle of a credential-stuffing run. There a self-service step-up can be defeated, so you deny the flow and require verified out-of-band identity proofing instead.
Does it connect to a real auth system or move money?
No. Nothing is uploaded, no account is touched and no money moves. The actions are authored, realistic decision snapshots bundled with the page, judged with no clock and no randomness so the queue is deterministic. It runs entirely in your browser — no account, no install, nothing sent anywhere.
Who is it for?
IAM, fraud and platform-security engineers who design adaptive-auth and SCA policies, risk and fraud analysts tuning step-up rules, and anyone prepping for a security interview who wants to feel why a $45k recurring payroll run can sail through while a $4 payment to a brand-new payee from a new device must be challenged.