Recently, I encountered a situation that was not, formally speaking, a hack —
but it resulted in the complete loss of a device from my account.
I want to treat it as a post-mortem: a breakdown of how a legitimate security flow can fail at the UX level — and why that matters.
The scenario
A phone is stolen.
The account owner attempts to sign in from another device, such as a laptop.
At roughly the same time, a critical account-related action is initiated from the stolen phone.
A security prompt is delivered to another device that is already registered within the same account.
The user approves the prompt.
From the user’s perspective, this action is understandable:
- they are actively trying to access their account,
- they expect a security-related confirmation,
- the timing aligns with what they are doing.
However, the approval authorizes a different, irreversible action initiated from the stolen device.
With a single confirmation, the phone is removed from the account.
No cryptography was broken.
No credentials were brute-forced.
No undocumented behavior occurred.
Everything worked exactly as designed.
Why this is not “user error”
It is easy to reduce this to:
The user should have been more careful.
That explanation is misleading.
The user:
- was under stress,
- was performing a legitimate action,
- interacted with a standard security confirmation flow.
The core issue is not inattentiveness.
It is that two critically different actions were confirmed through the same UX mechanism, at the worst possible moment.
This is not negligence.
It is a context collision.
Documentation does not save you here
Yes, recovery procedures and edge cases are documented.
But documentation:
- is not read during an incident,
- is not consulted in time-critical situations,
- does not help when multiple legitimate flows overlap.
If a system is only safe for users who are:
- calm,
- fully informed,
- perfectly attentive,
then it is not resilient.
Security must assume:
- partial attention,
- emotional stress,
- imperfect mental models.
Anything else is wishful thinking.
The real issue: UX-security failure
This was not a failure of authentication technology.
It was a failure at the UX-security layer — where human expectations meet irreversible system actions.
When systems rely on identical confirmation flows for actions with radically different consequences, a single reasonable decision can lead to permanent loss.
Security engineering often focuses on:
- cryptography,
- protocols,
- threat models.
But it frequently overlooks a simple fact:
one tap is also an attack surface.
Trust is built through constraint, not promises
Trust does not come from statements like:
We take security seriously.
It is formed by how difficult a system makes it for a user to accidentally shoot themselves in the foot.
A secure system should:
- slow users down before irreversible actions,
- align confirmations with intent,
- protect users from plausible, honest mistakes.
Not because users are careless —
but because humans are human.
The more complex a system is, and the higher the stakes,
the more responsibility shifts away from the user
and toward the design of the system itself.
Security without UX-safety(human-factor security) is incomplete security.
If a system allows a single reasonable action to result in total loss during a high-stress moment,
the problem is not education or documentation.
The problem is design.
And design is part of security.
Top comments (0)