Scanned IDs and one-time passwords can be useful, but they do not reliably prove real-time presence or prevent account takeover. If an account is compromised, the attacker may inherit trusted identity data. If the verification step is too weak, organisations can onboard fake or duplicate identities and miss fraud until damage has already occurred.
Why This Matters for Security Teams
Scanned IDs and one-time passwords often create a false sense of assurance because they validate a document or a code, not the whole trust chain behind the person using it. That matters when fraudsters reuse stolen identity data, synthetic identities, or session hijacking to pass a narrow check and then operate as a trusted account holder. NIST SP 800-63 Digital Identity Guidelines makes clear that identity proofing and authentication are separate functions, and both have to be evaluated against the actual threat.
The operational risk is bigger in digital onboarding, remote support, and account recovery flows, where a weak step can become the easiest path into a privileged lifecycle event. NHI Management Group has seen similar patterns in research on credential abuse and exposed secrets, including the LLMjacking threat pattern and the State of Secrets in AppSec findings on slow remediation and fragmented control. In practice, many security teams encounter identity fraud only after an attacker has already converted weak verification into account takeover or downstream abuse.
How It Works in Practice
The failure mode is usually not that scanned IDs or OTPs are useless. It is that they are treated as proof of identity when they are really only one signal. A scanned document may confirm that a credential existed at some point, but it does not prove the presenter is the legitimate holder, the document has not been tampered with, or the interaction is happening in real time. An OTP can prove access to a channel or device, but if the channel is already compromised, the code simply authenticates the attacker.
Current guidance suggests combining proofing, authentication, and ongoing risk checks instead of relying on a single control. That means tying onboarding to liveness and anti-spoofing checks, validating device and session context, and using step-up controls for high-risk actions. For non-human and automated environments, the same principle applies through cryptographic workload identity rather than human-style verification. The DeepSeek breach analysis is a reminder that compromised credentials and exposed data can move quickly from theory to exploitation.
- Use scanned IDs only as one input to identity proofing, not the final trust decision.
- Bind OTP use to session integrity, device posture, and transaction risk.
- Require stronger verification for recovery, payout, admin, and account-change workflows.
- Prefer real-time policy evaluation over static approval rules when the fraud impact is high.
Where possible, align verification depth to the assurance level described in NIST SP 800-63 Digital Identity Guidelines and use the Ultimate Guide to NHIs — Standards as a reference point for moving from static checks to lifecycle-aware identity controls. These controls tend to break down when onboarding is high-volume and manual review is thin, because exception handling becomes the attacker’s easiest path.
Common Variations and Edge Cases
Tighter identity verification often increases friction, review time, and abandonment, so organisations have to balance assurance against user experience and operational cost. That tradeoff is real, especially in consumer onboarding, delegated administration, and support desk recovery where false rejects can damage conversion or delay service access.
Best practice is evolving, but there is no universal standard for how much document scanning alone should count toward assurance. Some programmes pair it with liveness detection and watchlist checks; others add database corroboration, possession checks, or callback validation. The important edge case is shared or recycled identifiers, where a valid OTP may still authenticate the wrong person if the recovery channel, email, or phone number has already been taken over. Another common failure is over-trusting a once-verified identity long after the original proofing event, even when the risk context has changed.
Security teams should also treat fallback paths as first-class attack surfaces. If password reset, support escalation, or offline review steps are easier to game than the primary path, attackers will route through them. That is why identity assurance has to be measured across the whole lifecycle, not just at enrollment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Narrow proofing can still lead to compromised identity trust chains. |
| OWASP Agentic AI Top 10 | A-03 | Static checks fail when autonomous actors inherit or abuse trusted identity state. |
| CSA MAESTRO | ID-02 | Identity assurance must reflect the full trust chain, not a single onboarding step. |
| NIST AI RMF | GOVERN | Weak assurance creates governance gaps in identity risk management. |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and authentication need distinct, auditable access controls. |
Treat identity proofing as one signal and enforce stronger lifecycle controls before issuing NHI access.
Related resources from NHI Mgmt Group
- What breaks when organisations rely on one-time identity checks?
- What breaks when organisations rely on SSO and password managers as their main identity controls?
- What breaks when organisations rely on one-time AI red teaming instead of continuous retesting?
- What breaks when organisations rely on persistent access instead of just-in-time controls?
