Account takeover: step up the challenge instead of blocking the customer
When a login looks like account takeover, do not guess. Let the session continue with limited rights, and ask for proof that only the verified person can give, such as a fresh selfie matched to their enrolment, before any payout, beneficiary change or password reset goes through.
Charles Archibong, Co-founder
· 5 min read
Key takeaways
- Most suspicious logins are genuine customers on a new phone or a trip; blocking them is costly.
- A step-up challenge should be something the attacker cannot supply, such as the verified person's face.
- Put the challenge in front of the sensitive action, not only at login.
- Treat a failed or abandoned step-up as a strong signal, and a passed one as fresh evidence.
When a login looks like account takeover, the best response is usually neither to let it through nor to lock the account. Let the session continue with limited rights, and ask for proof that only the genuine customer can give before anything sensitive happens: a payout, a new beneficiary, a changed phone number or password.
That proof should be tied to the person you verified at onboarding, not to something an attacker may already control. A fresh selfie with liveness, matched against the customer's enrolment, is the strongest everyday option. A text message code to a number the attacker may have just changed is the weakest.
Why is blocking the wrong default?
Most logins that look risky are not attacks. People buy new phones, travel, reinstall apps and borrow a sibling's handset. A rule that blocks every new device will mostly block customers, and each block turns into a support call, a lost transaction or a closed account.
Letting everything through is worse. A takeover that reaches a payout screen can empty an account in minutes, and the customer will expect you to have noticed.
A step-up sits between the two. It costs a genuine customer seconds. It costs an attacker the whole attempt, provided the challenge asks for something they do not have.
What makes a login look like account takeover?
Signals that suggest takeover usually describe a change against the customer's own history:
A device the customer has never used before.
A country change that is too fast to be travel, such as Lagos an hour ago and another continent now.
A new device followed quickly by a sensitive action, such as adding a beneficiary within minutes of logging in.
A password reset or phone number change just before a withdrawal.
An IP address from a hosting provider rather than a mobile network or home broadband.
Each of these has an innocent explanation on its own. Together, and followed by an attempt to move money, they deserve a challenge.
What is a good step-up challenge?
Rank challenges by whether an attacker who has taken over the account could complete them.
Challenge | Can a takeover attacker pass it? | Customer effort |
|---|---|---|
Password again | Yes, they already have it | Low |
Text message code | Sometimes, if they control the number or changed it | Low |
Email link | Sometimes, if the email is also compromised | Low |
Code from an app on a known device | Not from a new device | Low |
Selfie with liveness, matched to enrolment | Only by defeating liveness and face matching for this person | Medium |
Full re-verification with ID and selfie | Only with the customer's ID and face | High |
The pattern is simple: the stronger challenges are bound to the verified person rather than to a credential. Save the heaviest option for the riskiest moments, and never use a code sent to contact details that changed in the same session.
Where should the challenge sit?
Put the challenge in front of the action that causes loss, not only at login. An illustrative policy for a wallet app:
Login from a known device: allow.
Login from a new device, nothing else unusual: allow, but hide balances or limit transfers until the next step.
New device and a beneficiary added within the same session: require a selfie matched to enrolment before the beneficiary becomes active.
New device, fast country change and a withdrawal above the customer's usual amount: hold the withdrawal and require full re-verification.
Step-up failed, or abandoned twice: freeze outgoing payments and open a case for review.
This keeps the customer in the app in every case except the last, and even then they know what to do next.
How to use a step-up result
A passed step-up is fresh evidence that the right person is present. Record it, and let it lift the restriction for that session or action.
A failed step-up is one of the strongest takeover signals you will get. Treat an abandoned challenge carefully: a genuine customer may simply be busy, but an attacker cannot complete it, so repeated abandonment on a risky session deserves review.
Always tell the customer, through a channel you trusted before the session began, that a new device was used and a check was requested.
How Myaza Trust supports this flow
The pieces fit together as signals, a challenge and a result.
Signals. Your backend can send logins, password resets, beneficiary additions, device changes, payouts and withdrawals to POST /api/v1/activities, with your device reference, the customer's IP address and location, and receive an allow, review or block decision with the rules that fired (activity monitoring documentation). Reusing a stable device reference builds new-device evidence over time, and the built-in rules include new device and fast country changes. This Fraud Monitoring area needs the Fraud Prevention entitlement and an approved business profile.
Challenge. For individuals, a step-up re-verification can be requested from a workflow, through the API or from the dashboard. You receive entity.step_up_requested with a hosted challenge URL and its expiry, which you send or show to the customer (activity decision webhooks). Treat that URL as sensitive. For returning customers who have enrolled, biometric re-authentication matches a new selfie one-to-one against their enrolment reference.
Result. entity.step_up_completed tells you whether the customer passed; continue only when passed is true. Deduplicate each webhook by its event ID.
Your platform applies the outcome. Myaza Trust can recommend review or report a failed challenge, but it cannot disable a login, account or wallet hosted on your own systems.
A checklist before you ship
List the actions that can cause loss and put a challenge in front of each.
Decide which signals trigger which challenge, starting with new device plus a sensitive action.
Remove any challenge that relies on contact details changed in the same session.
Make sure a passed challenge lifts the restriction without a support ticket.
Route failed and repeatedly abandoned challenges to a case, and notify the customer through a trusted channel.
Review a month of challenges: how many genuine customers were stepped up, and how many attacks were stopped at the challenge.
Learn more about fraud prevention and fraud detection with Myaza Trust.
Sources
Charles Archibong
Co-founder
Charles Archibong co-founded Myaza Trust. He writes about identity verification, financial technology, and the practical work of building trusted digital services.
