<p>Three prompts reached Lara’s screen during the busiest hour at the pharmacy. One asked her to approve a refund, another to confirm a sign-in from a new device, and a third to authorize an urgent care-home order. With customers waiting at the counter, she tapped “not now.” This was not an unusual lapse. It was the predictable response of someone asked to decide quickly without knowing which of three signals was worth stopping work for.</p>
<p>Multi-factor verification protects people when it creates a useful pause before a sensitive action. It loses that value when every pause looks alike, arrives without context, or interrupts work that cannot wait. That is MFA fatigue: repeated prompts teach people to dismiss the next one. Designing a second check that earns its place means deciding which risk deserves the effort, what information lets a person recognise it, and what route remains available for someone who genuinely needs to act.</p>
Making the context clear#
<h2>Different consequences deserve different effort</h2>
<p>The pharmacy team first stopped calling every notification an “alert.” For two weeks they recorded what triggered each prompt, when it arrived, what the screen showed, whether it could be delayed, and what the user eventually did. The same request appeared when a shift began, when a browser changed, and when staff opened inventory. The account that approved refunds also received almost identical messages for viewing a delivery note. Volume made the highest-impact signal impossible to distinguish.</p>
What changes in practice#
<p><strong>An extra check should distinguish the seriousness of an action, not merely repeat the act of signing in.</strong> Looking up stock from the usual computer could require a calm verification at the start of a shift. Approving a large refund, changing a supplier’s payment details, or signing in from an unexpected location called for another route: a short explanation of the change, confirmation through a separate channel, and time to stop. That hierarchy does not remove all friction. It places friction where a mistake would be difficult to undo.</p>
<p>To make that distinction, the group did not begin by buying another tool. It listed actions that could affect patients, payments, personal information, or service continuity. Then it asked what would happen if each action were accepted by mistake and who would have to repair the result. A late inventory check might delay an order; a fraudulent refund could affect a family and the accounts; an export of prescription records could expose information that cannot be retrieved. The contrast turned a technical list into a conversation about real consequences.</p>
Deciding with information#
<h2>A prompt must say why it matters now</h2>
<p>The original high-risk message said only, “Confirm your identity.” The records showed that many people approved it without reading it, just as they approved the others. The team changed the message. If someone tried to authorise a refund from an unrecognised device, the screen named the order involved, the device making the request, the amount at stake, and the result of confirming. It also presented two equally visible choices: approve through the pharmacy app or select “I do not recognise this request.”</p>
Reviewing and adjusting#
<p>That detail was not decorative. Context lets a person spot a mismatch that a generic order conceals. A worker at the counter knows whether they are reviewing order 472, whether they changed computer, and whether that amount belongs to the shift. Without those clues, they must guess or interrupt a colleague. With them, they can compare the request with the reality of their task without becoming a fraud specialist. A useful prompt makes an informed decision possible before habit supplies an automatic answer.</p>
<p><strong>A clear alert does not demand heroism; it gives understandable reasons to continue or to stop.</strong> The pharmacy avoided blame and alarmist wording. “New device and €480 refund” was more useful than “suspicious activity.” “Confirm with the duty phone if you were not doing this” was more useful than “contact support.” Precision reduces both automatic approval and the uncertainty that can freeze legitimate work.</p>
<h2>An exception route prevents shortcuts becoming routine</h2>
<p>Calibration exposed a second problem: some prompts were ignored because the legitimate path took too long. During an urgent delivery, a technician who had forgotten the corporate phone would have to wait for an administrator to return from lunch before regaining access. More than once, someone asked for a colleague’s code “just for today.” The safeguard looked strict, yet it encouraged secret sharing and left the event outside every useful record.</p>
<p>The team created a short, traceable exception. The person on duty could verify a fact by phone that did not depend on the locked session, issue limited access for thirty minutes, and record the reason. The exception could not export data or change payments. At the end of the shift, the responsible colleague checked that it had closed and reviewed what caused it. This route acknowledged that real work contains urgency, substitutions, and lost devices; it did not treat those realities as a reason for an unguarded door.</p>
<p><strong>If a verification process works only on a perfect day, it will fail on ordinary days.</strong> A route for someone unable to complete the normal step should be harder than the usual path, but possible enough that they do not need an unsafe workaround. Repeated exceptions are useful evidence. They may show that the standard process is poorly calibrated, rather than that the person using it is the problem.</p>
<h2>Test fatigue, not just the technology</h2>
<p>The pharmacy ran an exercise on a normal afternoon. It did not stage a spectacular attack. It introduced legitimate low-priority requests, one high-risk request from an unknown device, and a moment when the authorised person was helping a patient. The team observed how long each prompt took to understand, which words confused people, and which prompts were dismissed unread. Afterwards it asked why: some appeared too often, others arrived before the person had the necessary information, and one did not make clear that refusing it would not block the order.</p>
<p>The purpose was not to measure obedience. It was to find out whether the design distributed limited attention well. From the results, the team removed two routine prompts, grouped others at the start of the shift, and reserved immediate confirmation for three genuinely sensitive actions. Its monthly review does not count messages sent. It examines how many prompts were understood, how many were correctly rejected, how many exceptions were opened, and which adjustment followed. Counting noise would only reward noise.</p>
<p>The review must include people who live with the procedure. An administrator can see logs and patterns; a counter technician knows when a queue turns a screen into pressure. When she says she ignored a request because it always appeared while connecting the barcode reader, she is not asking for less security. She is identifying a condition that makes real risk invisible. Listening to that information lets the team repair the design before someone exploits the habit.</p>
<h2>A practical step for next week</h2>
<p>Any team can choose one action that currently requires a second verification and observe it for a week. Without collecting unnecessary names, record when it appears, which decision it protects, what context it displays, how it delays work, and what the person does. Then separate prompts that merely confirm a routine from prompts that can authorise a hard-to-reverse change. Redesign one of the latter so it names the action, the change, and a safe way to say no.</p>
<p>A second check is not valuable because it is second. It is valuable because it helps a person recognise risk while it can still be limited. At the pharmacy, the improvement was not more screens. It was a scale: fewer routine interruptions, more context for a meaningful change, and an exception that did not require sharing credentials. The next review should not ask, “Have we added more security?” It should ask, “Which signal still makes someone stop for a good reason?”</p>
