Failure modes: loops, lockouts, social engineering of support

Risk-based authentication fails in two directions. It can be too weak, letting an attacker through; earlier chapters dealt with that. It can also be too strong in the wrong way, trapping legitimate users in states they cannot leave. The second failure is quieter — it does not appear in breach reports — but it erodes trust, floods support and, worst of all, creates pressure on support agents to bypass controls. That pressure is where social engineering lives.

This chapter catalogues the three failure modes Marisol found in Tidewater Mutual’s first quarter of risk-based policy, using sanitised and illustrative examples from member complaints and one red-team exercise.

Failure mode 1: the challenge loop

A loop happens when completing a step-up does not change the facts that triggered it. Member Yusra Delacroix-Ng uses a corporate VPN that exits through a hosting provider. Every value-moving action evaluates as unfamiliar, she completes the OTP, the payment succeeds — and the next payment five minutes later asks again, because nothing in the decision remembered the success. On mobile it was worse: the app re-evaluated after each screen transition and challenged her three times for one transfer.

The fix is to treat a successful step-up as a new fact. After Yusra completes a strong factor on a device, the session records stepup.recent = true with the factor strength and expiry, and policy consumes it like any other fact. Separately, if the same device repeatedly completes step-ups from the same network, the device becomes known; the step-up is the evidence that should graduate it. Loops are almost always a sign that the policy has inputs but no memory.

Failure mode 2: the lockout with no exit

A lockout becomes a trap when every exit requires the thing that is missing. Member Bram Oyelaran-Fitch lost his phone abroad. Login required an SMS code to his number; recovery required an SMS code to his number; the support line required him to confirm a code sent to his number. Every path converged on the one factor he did not have. He was locked out for nine days, and the member complaint that followed was justified.

The pattern to look for is convergence: draw the graph of every login and recovery path and the evidence each requires, and check that no single factor appears on every path. Tidewater now guarantees at least two disjoint paths for every account: an enrolled factor path and an evidence path that does not depend on it — recovery codes, a second enrolled device, or an in-branch document check. Members who have only one factor are nudged, at a calm moment, to add a second.

Failure mode 3: the persuasive caller

When automated paths fail, people call. A support desk under pressure from genuine lockouts is exactly the environment social engineers prefer. During a red-team exercise an engineer posing as a distressed member called Tidewater claiming to be at a hospital with a dying parent and an urgent bill to pay. He had the member’s name, address, date of birth and last card digits from a breach dataset. The agent, trained to be helpful and told that lockouts were hurting satisfaction scores, attempted to remove the second factor.

The attempt failed only because the agent tool, updated the previous month, refused: removing a factor from a passkey account required a branch document check or a recovery that triggered the delay and notifications from chapter 4. Training helps, but the durable control is that agents cannot do more than the self-service recovery policy allows. An agent can start the process, explain it and expedite a branch appointment. An agent cannot skip a delay, silence notifications or accept knowledge as sufficient evidence.

Make the safe path the easy path for agents

Agents bypass controls when the controls make their job impossible. Tidewater gave agents what they need to help without bypassing: a view of the decision log reason codes, so they can explain why a member was challenged; a button to start a staged recovery with the right evidence tier; a way to issue a temporary “read-only” access while recovery runs, so a member abroad can at least see balances; and an escalation path to a small fraud team for the truly unusual cases. Satisfaction scores now exclude calls closed by starting a secure recovery, so agents are not penalised for following policy.

Measure the failure modes

• Loop rate: sessions with more than one step-up for the same action tier within ten minutes.
• Trap rate: accounts with a failed recovery attempt and no successful login within seven days.
• Agent override requests: tool actions refused by policy, reviewed weekly for both attack and process gaps.
• Cancel rate: recoveries cancelled via “This wasn’t me”, which are confirmed attacks worth studying.

This closes the series. Signals become facts, facts and action sensitivity become a small readable policy, step-ups keep users in flow, recovery is staged rather than instant, and failure modes are measured and designed out. The final series turns to the other half of the loop: seeing what is happening in production, through detection engineering.