Step-up authentication

Step-up authentication is demanding stronger proof of identity when the stakes of a request rise: a wire release, a password change, a new payee. Rather than one fixed bar at login, the system holds a graduated set of bars, and risk signals, a fresh SIM change, a new device, unusual behavior, decide which bar a given action must clear.

The design difficulty is choosing the trigger rather than the challenge. Stepping up on every sensitive action costs completion; stepping up on a risk score costs a threshold that has to be tuned against outcomes nobody logs consistently. A binary fact about the account's underlying channel, such as a SIM change inside a defined window, is easier to defend in review because it can be re-checked.

Choosing the trigger is where most implementations spend their effort and where the durable answer is usually the simplest. Binary facts about the account's underlying channel, a SIM change inside a window, a new device, a first payment to a new payee, can be restated at review time and defended; a composite risk score cannot be re-derived once the model behind it is retrained, which turns every dispute into a question nobody can answer.

The cost of stepping up is measured in abandoned actions, and it is paid by legitimate users, so the trigger has to be rare enough that the challenge stays credible. A challenge users see constantly is a challenge they complete without reading, which reproduces the reflex problem that defeats push approval.

The challenge itself should not travel over the channel that prompted the step-up. Where the trigger is a change to the phone line, sending an SMS OTP to that line asks the suspicious party to approve its own request, which is the most common way a correct trigger is paired with a useless challenge.

A recent change in SIM tenure is the canonical example of a binary trigger that can be restated months later.