TL;DR: Large-scale identity leaks turn names, emails, and phone numbers into reusable fraud inputs, while OTP-centric recovery and static attributes fail under automated abuse, according to Prove Identity. The core issue is that identity programs still assume copyable data can anchor trust after it has already been widely exposed.
At a glance
What this is: This is an argument that leaked identity data now behaves like fraud infrastructure, and that point-in-time KYC flows are too fragile for automated abuse.
Why it matters: It matters because IAM, KYC, and account recovery teams need controls that distinguish possession, continuity, and current ownership after attributes have been compromised at scale.
By the numbers:
- On top of that, humans can only spot deepfakes correctly about 40% of the time.
👉 Read Prove Identity's analysis of why identity leaks are becoming fraud infrastructure risk
Context
Identity verification breaks down when attackers can reuse the same leaked attributes across many attempts. Once personal data is broadly exposed, recovery, onboarding, and step-up checks stop being one-time trust decisions and become repeatable fraud surfaces.
The problem is not only bad data, but stolen correct data used at machine speed. That makes account recovery, OTP-centric flows, and static trust signals weak points for identity, KYC, and consumer IAM programmes that were designed around human-paced abuse.
For practitioners, the governance question is whether identity proofing still relies on copyable attributes or whether it can maintain assurance across device changes, number changes, and account recovery events. That distinction matters in any programme that treats phone possession, device continuity, or KYC evidence as trust anchors.
Key questions
Q: How should identity teams reduce fraud when personal data has already leaked?
A: Treat exposed attributes as compromised inputs, not trust anchors. Shift high-risk decisions toward current possession, device continuity, and verified custody, then reserve static data for correlation rather than authentication. The goal is to make stolen correct data insufficient on its own, especially in onboarding, recovery, and step-up journeys.
Q: Why do OTP-based recovery flows fail under automated fraud?
A: OTP flows fail when attackers can intercept, reroute, or socially engineer the delivery channel and then repeat the attempt at scale. If the workflow equates channel reachability with identity, it creates a fast path for takeover. Stronger recovery requires checking present ownership, not just reachable contact details.
Q: What do security teams get wrong about using phone numbers as identity factors?
A: They often confuse possession of a number with durable identity assurance. In reality, numbers change hands, move between SIMs, and get reassigned by operators. If the application does not re-check the number’s current SIM context, the factor can authorize a different person than the one originally verified.
Q: How do you know if an identity verification flow is too fragile?
A: If it can be satisfied by copied attributes, reused OTPs, or support scripts that rely on past history, it is too fragile for automated fraud conditions. A resilient flow should still hold under repeated attempts, device changes, and recycled contact details, because attackers will test all three.
Technical breakdown
Why copied identity data becomes reusable fraud fuel
Names, emails, phone numbers, and even accurate personal details lose much of their value as trust signals once they have been exposed in repeated breaches. Attackers can replay that data across onboarding, recovery, and support workflows until they find a path that accepts it. In practice, the attacker is not trying to invent identity. They are trying to industrialise identity reuse at scale, using the same data that legitimate systems continue to accept as proof. This is why static attribute checks age badly under fraud pressure.
Practical implication: Treat leaked personal data as an input to adversary testing, not as evidence of identity.
Why OTP-centric recovery flows are structurally fragile
OTP-based authentication assumes the channel delivering the code still represents the right person and the right device. That assumption weakens when SIM swaps, number recycling, interception, and social engineering become part of the threat model. Recovery flows often have the weakest security and the highest business urgency, which makes them attractive to attackers. The issue is not only that OTP can be intercepted. It is that the workflow often treats possession of a reachable channel as equivalent to trustworthy continuity, even when the underlying ownership has changed.
Practical implication: Review recovery paths as high-risk authorisation journeys, not as low-friction support steps.
How cryptographic custody changes identity assurance
Cryptographic custody shifts the trust question from 'does this data match?' to 'does this party still control the verified instrument right now?' That is a stronger model because custody can be checked continuously across device upgrades, carrier changes, and number reassignment. It does not eliminate fraud, but it changes the basis of trust from copied attributes to verifiable possession and continuity. For identity programmes, this is closer to an ongoing assurance model than a one-time verification event, which is what modern fraud pressure now requires.
Practical implication: Anchor high-risk identity decisions to continuity signals that survive normal customer change.
NHI Mgmt Group analysis
Identity leakage has become a fraud infrastructure problem, not just a privacy problem. Once the same attributes are exposed repeatedly, attackers can industrialise onboarding abuse, account takeover, and recovery attacks. That changes the economics of fraud because the cost of each attempt drops while the number of attempts rises. Practitioners should stop treating leaked identity data as damaged information and start treating it as a reusable attack substrate.
OTP-centric trust models fail because they confuse channel access with identity continuity. SMS and similar factors can still play a role, but they are brittle when number recycling, SIM swaps, and social engineering are in scope. The governance gap is not the absence of a factor, but the assumption that possession of the channel proves current ownership. IAM and KYC teams need to recognise that channel-based proof has a short trust half-life.
Continuous assurance is the right design pattern when identity data is already public. The article's core concept is persistent, cryptographically anchored identity, which is less about a single check and more about maintaining custody and context over time. That is especially relevant for consumer identity, account recovery, and KYC journeys where legitimate changes are common and fraudsters exploit them. Practitioners should reframe trust as an ongoing state rather than a successful verification event.
Phone tenure is not ownership, and that distinction is becoming operationally critical. Carrier recycling, porting, and reassignment mean a number can look legitimate while belonging to a different person. This breaks a common trust shortcut in identity stacks that use tenure or history as a proxy for current control. The implication is that identity programmes need to separate historical familiarity from present custody before authorising recovery or account changes.
From our research:
- Humans can only spot deepfakes correctly about 40% of the time, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
- That is why practitioners should also review Ultimate Guide to NHIs for lifecycle, rotation, and offboarding controls that reduce reuse risk.
What this signals
Persistent identity assurance is becoming a governance requirement, not an optional enhancement. When personal data is already circulating widely, programmes that depend on static verification steps will continue to produce false confidence. Teams should move toward evidence of current custody, while also validating recovery paths against repeated abuse and support-led escalation.
Identity teams should expect fraud to behave more like infrastructure abuse than one-off account crime. That means monitoring for repeatable patterns across onboarding, recovery, and phone-based trust signals, then tightening the points where historical legitimacy is mistaken for present ownership. The operating model needs to follow the attacker’s repetition, not the user’s last successful login.
Phone tenure is a useful history signal, not a trust verdict. Once numbers are recycled or ported, the programme needs a stronger control boundary around current control of the device or channel. For teams building identity assurance, this is the difference between knowing something was true and knowing it is true now.
For practitioners
- Reassess recovery journeys as attack surfaces Map every step-up and account recovery flow where leaked PII, OTP delivery, or support intervention can be replayed. Add stricter assurance to the paths attackers are most likely to automate, especially where one-time codes and help-desk overrides still dominate.
Key takeaways
- Leaked identity data now feeds automated fraud campaigns, so static KYC evidence degrades quickly once it is exposed.
- The scale problem is compounded by deepfake and replay abuse, which makes human judgment alone unreliable in recovery and onboarding.
- Practitioners need continuity-based identity assurance, not just one-time verification, if they want to reduce takeover risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-1 | Identity proofing and recovery integrity are central to this fraud pattern. |
| NIST SP 800-63 | SP 800-63A | Identity proofing guidance applies to onboarding and recovery decisions. |
| NIST Zero Trust (SP 800-207) | Zero trust assumptions break when recovery flows overtrust stale identity data. |
Validate identity assurance journeys against PR.AA-1 and remove static data as a primary trust anchor.
Key terms
- Identity Assurance: The confidence an organisation has that a person or system is truly who it claims to be before access or action is granted. In modern IAM, assurance depends on evidence quality, channel trust, and the strength of verification around high-risk decisions.
- Cryptographic custody: Who controls the encryption keys and related protection boundaries for sensitive integrations. In identity governance, custody matters because access to the data path is only part of the control story. If the enterprise does not own the keys, it may not fully own the trust model.
- Identity Replay Exposure: Identity replay exposure is the period during which a stolen credential remains valid and usable across one or more systems. It is a governance problem, not just a detection problem, because the risk persists until the secret is revoked, rotated, or otherwise rendered unusable.
What's in the full article
Prove Identity's full blog covers the operational detail this post intentionally leaves for the source:
- How Prove ties phone ownership continuity to recovery and onboarding decisions across real customer lifecycle changes.
- The specific trust logic used to distinguish legitimate device upgrades and number porting from borrowed or recycled identity.
- Examples of where static attributes and OTP-centric flows fail under repeated abuse.
- The product framing behind persistent, cryptographically anchored identity across changing customer states.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.
Published by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org