Email, passwords, and SMS OTP rely on users to create, remember, and approve authentication steps, which makes the process easy to phish and hard to secure consistently. When trust depends on human action, attackers can exploit credential reuse, social engineering, and message interception. Mobile identity reduces that dependency by moving verification into the device and network layer.
Why This Trust Model Breaks Down
Email, passwords, and SMS OTP all depend on a human being available, attentive, and correctly choosing the right signal at the right time. That sounds simple, but it creates a brittle trust chain: password reuse weakens secret strength, phishing targets the person rather than the system, and SMS adds a channel that can be intercepted, redirected, or socially engineered. The result is not just weaker authentication, but weaker assurance that the account holder is the one actually approving access.
This is why the model struggles under real-world pressure. Security teams are asking people to carry too much of the burden for identity verification, while attackers only need one successful deception, one stolen password, or one diverted code. Even when controls are technically “working,” the trust decision still rests on a user action that can be manipulated. In practice, many security teams discover this only after a phishing campaign or account takeover has already shown how thin the assurance really was.
How It Works in Practice
The weakness comes from treating separate factors as if they are independent proofs of identity when they often are not. A password is usually a memorised secret that can be reused, guessed, harvested, or entered into a fake login page. Email is often both the account recovery path and a second trust anchor, which means compromise of the mailbox can collapse the rest of the account model. SMS OTP is better than a password alone, but it still relies on a shared telephone network and on the user noticing and approving the right prompt in time.
In a modern attack path, the adversary often focuses on the easiest human failure point: credential stuffing, phishing, help-desk social engineering, or SIM-swap style interception. The target is not always the primary app itself. Often it is the recovery channel, the inbox, or the mobile number that makes takeover possible. That is why current guidance increasingly favours phishing-resistant authentication, device-bound verification, and reduced dependence on user-entered secrets for high-value accounts.
Mobile identity shifts the trust decision away from something a user must manually type or transcribe and toward a device-bound, network-aware verification step. That does not eliminate risk, but it reduces the number of places where an attacker can impersonate the user through simple deception. NHI Management Group research on secrets exposure shows why this matters operationally: leaked credentials can be reused quickly, and remediation often lags far behind the attacker’s first attempt.
- Use email as a notification and recovery channel with care, not as the primary trust anchor for sensitive access.
- Assume passwords will be reused or phished unless the login flow is phishing-resistant by design.
- Treat SMS OTP as a weaker step-up factor, not as a durable proof of possession for high-risk systems.
- Prefer device-bound or cryptographic verification where the trust decision can be enforced by the platform rather than the person.
These controls tend to break down in environments with broad legacy support, shared service desks, or account recovery workflows that still trust email and phone number possession more than the original authentication event.
Common Variations and Edge Cases
Tighter authentication usually improves assurance, but it also increases recovery complexity, device dependence, and user support overhead, so organisations have to balance resilience against usability. That tradeoff becomes especially visible in bring-your-own-device environments, contractor access, and consumer apps where not every user can support the same method.
Best practice is evolving, and there is no universal standard for every use case. For low-risk accounts, password plus SMS may still be tolerated as a transition state. For privileged, administrative, financial, or administrative recovery paths, it is increasingly hard to justify because the model fails exactly where the cost of compromise is highest. Email-based reset links are another common edge case: they are convenient, but they can silently turn mailbox compromise into full account compromise if recovery is too permissive.
For organisations that still depend on legacy trust factors, the real question is not whether to remove every password overnight. It is which accounts, recovery flows, and support processes can no longer afford human-mediated approval as the final trust decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST Zero Trust (SP 800-207), NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Controls account authentication and recovery paths that weaken trust when misused. |
| Recommendation — Restrict recovery and privileged access to stronger, verified authentication methods. | ||
| NIST Zero Trust (SP 800-207) | 3 — Identity Strategy | Applies to reducing implicit trust in user-entered secrets and weak factors. |
| Recommendation — Base access on continuous, context-aware verification instead of one-time trust claims. | ||
| NIST AI RMF | GV.1 — Govern, Map, Measure, and Manage AI Risk | Relevant where identity trust decisions are automated or embedded in digital workflows. |
| Recommendation — Govern automated trust decisions so identity assurance is measurable and bounded. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Directly addresses weak authentication assurance and access control design. |
| Recommendation — Replace weak factors with phishing-resistant authentication for sensitive accounts. | ||
| MITRE ATT&CK | T1110 — Brute Force | Credential reuse and password weakness enable repeated login abuse patterns. |
| Recommendation — Detect and rate-limit password reuse and automated credential attacks. | ||
Practitioner Guidance
What to prioritise: Start with the highest-value accounts and the recovery flows that can reset them. If email or SMS can re-establish trust without stronger re-verification, that path deserves attention before ordinary login friction does.
Decision rule: If a factor can be phished, forwarded, or socially engineered, do not treat it as sufficient on its own for privileged access or account recovery. Reserve it for lower-risk scenarios or for transitional use while stronger controls are introduced.
What to verify: Confirm whether mailbox access, phone-number possession, and help-desk approval can each independently lead to account recovery. If any one of them can, the trust model is narrower on paper than it is in practice.
Practitioner takeaway: The real failure is not that these factors exist, but that organisations keep using them as if human attention were a reliable security boundary.
Related resources from NHI Mgmt Group
- Why do SMS OTP and other legacy MFA methods create so much operational and security risk?
- Why can a single SaaS app create such a large blast radius?
- Why do passwords create a weak foundation for zero trust in enterprise environments?
- Why do magic links create a different trust model than passwords in enterprise environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
