A payments console requires a hardware-key tap at login. About 3% of its monthly sessions create a payout or change bank details and 97% only read reports; support handles roughly 40 lost-key tickets a month and 12% of users keep a browser session open for days. Which change reduces the loss the control exists to prevent while lowering total friction?

The deciding property

A control on a session protects the moment of authentication, not the action that loses money. Ninety-seven percent of the taps in this system are spent protecting report reading. The 3% that could move money happen inside a session that was authenticated hours or, for 12% of users, days ago - so for the operations that matter, the control is already absent.

Both realistic threats operate inside a valid session. A stolen session cookie and an insider acting beyond authority both arrive after login, and neither is touched by a login-time factor. Re-authentication bound to the transaction is the only mechanism that defeats a live session, and it is strongest when the signed challenge contains the operation's own parameters - the payout amount and destination account - so a tap cannot be harvested and replayed against a different transfer.

What the change buys and what it costs

Taps per month fall by roughly 97%, which is where the lost-key tickets go: the key is needed for a few operations a month rather than every login. Coverage of the loss-bearing operation rises from "whatever was true at login" to 100%.

The cost is real and it is engineering, not friction. Two authentication paths now exist, so the step-up token needs a short validity - 60 to 120 seconds is typical - and an audit record tying that token to the specific operation, or the control is unprovable to an auditor. Bank-detail changes have to be protected as hard as payouts, or the attacker changes the destination first and uses the unprotected payout path. And every machine route to the same operation - a service account, an API token, a bulk upload - must either carry an equivalent control or be removed, or the original hole is simply relocated.

Why the other options fail

• Shorter idle timeout. It addresses abandoned sessions, which is a smaller threat than live session theft, and it does nothing about an attacker who is actively using the session. It also adds friction to the 97% who were never the risk. A reasonable hygiene measure sold as a mitigation.
• SMS one-time codes. This optimises the support metric and gives up the security property. SMS is phishable in real time and vulnerable to SIM swap; replacing a phishing-resistant factor with a phishable one on a payments console trades the thing you were buying for a cheaper ticket queue.
• A tap every 30 minutes. Friction multiplied by session length, with no change in coverage: the attacker with a live session simply acts within the 30-minute window. High cost, near-zero benefit, and the control people most reliably work around.
• Taps on every financial page. More friction again, still protecting reads rather than writes. Rendering a balance does not lose money; initiating a transfer does.

When this is the wrong answer

When nearly every session performs the risky action. On an internal payments operations console where approving payouts is the job, per-action step-up is friction on 100% of work and the right design is strong session authentication, short sessions and dual approval on the payout itself. The general rule: put the control on the operation when the risky operations are rare, and on the session when they are the norm - and in both cases make sure the second channel, whether a service account or a support tool, carries the same control, because an attacker will always use the cheapest path to the same outcome.