TL;DR: Phone-centric identity uses mobile, telecom, and bank signals to support digital identity verification, reduce reliance on OTPs, and meet PSD2/SCA requirements with less friction, according to Prove Identity. The governance issue is not whether mobile signals can improve assurance, but how banks and fintechs avoid turning device possession into a proxy that outlives its real trust boundary.
At a glance
What this is: This is Prove Identity’s explanation of phone-centric identity as a possession-based verification model that can support PSD2 SCA while reducing customer friction.
Why it matters: It matters because IAM teams in regulated banking and fintech need authentication patterns that improve assurance without weakening step-up decisions, account recovery, or fraud controls.
By the numbers:
- Top banks and FinTechs reported a 25% increase in day-one digital registrations.
- Prove states its platform serves over 1,000 enterprises across 195 countries.
- Prove says 9 of the top 10 US financial institutions use its platform.
👉 Read Prove Identity's article on phone-centric identity for PSD2 SCA
Context
Phone-centric identity is a verification approach that uses mobile and telecom signals to decide whether a customer is likely in possession of a trusted device. In banking and fintech, that matters because PSD2 SCA requires strong customer authentication without creating so much friction that legitimate users abandon the flow.
The governance question is whether device possession is being used as a control or merely as a convenience signal. For IAM leaders, that distinction affects step-up design, fraud decisioning, customer recovery, and the extent to which a phone-number-based token can safely persist across the customer journey. See the Ultimate Guide to NHIs for the broader identity governance model, including the way identity signals become operational controls.
Prove Identity frames this as a way to improve verification and reduce OTP dependence, but the underlying issue is broader than one vendor or one channel. Financial institutions are increasingly trying to balance regulatory assurance, fraud prevention, and user experience inside the same authentication flow, which is where weakly governed identity signals often become overtrusted.
Key questions
Q: How should banks use phone-centric identity without overtrusting device possession?
A: Banks should treat device possession as one authentication signal, not as proof of full identity legitimacy. It works best when paired with policy-driven step-up, transaction risk scoring, and recovery controls that re-verify users after number changes, device swaps, or anomalous behaviour.
Q: When does phone-centric authentication create more risk than it reduces?
A: It creates more risk when teams let a phone-linked signal become a standing trust anchor after onboarding. If account recovery, SIM change handling, or number reassignment are weak, attackers can turn a convenient signal into a persistent impersonation path.
Q: What do security teams get wrong about replacing OTPs with mobile intelligence?
A: They often assume the problem is solved once OTPs disappear. In practice, the real work shifts to governing fallback logic, signal quality, and re-binding events, because those are the places where fraud and account takeover attempts move next.
Q: Who should own phone-based identity policy in a financial institution?
A: Ownership should sit jointly with IAM, fraud, and compliance, but one team needs final authority over authentication thresholds and exception handling. Without that governance, the same phone signal can be accepted in one workflow and rejected in another.
Technical breakdown
Possession-based verification and PSD2 SCA
Phone-centric identity uses the mobile device as a possession factor, meaning the control is based on whether the caller or user is demonstrably in control of a trusted handset. The article describes this as a binary yes or no outcome rather than a probabilistic score. That distinction matters because regulators and risk teams often need a decision, not a confidence band, when applying step-up authentication and exemption logic under PSD2 SCA.
Practical implication: treat possession checks as one input to SCA policy, not as a blanket replacement for all authentication steps.
Why OTP replacement changes the fraud model
One-time passwords are vulnerable because the attacker only needs to intercept, socially engineer, or redirect a code once. A possession-based model shifts the burden from message interception to device control and trusted signal correlation across telecom and banking data. That does not eliminate fraud, but it changes the attacker’s cost structure and the failure modes IAM teams need to monitor.
Practical implication: review fraud workflows for OTP bypass, SIM-swap exposure, and fallback paths that reintroduce the same weaknesses.
Phone-number-based identity tokens across the customer journey
The article also points to a phone-number-based identity token that can persist across onboarding and subsequent interactions. Architecturally, that creates a continuity layer between verification events, but it also raises lifecycle questions when numbers change, devices are replaced, or account recovery is triggered. A durable identifier is useful only if its revocation, refresh, and re-binding logic are tightly governed.
Practical implication: define re-verification triggers for number change, device change, recovery, and suspicious step-up outcomes.
Threat narrative
Attacker objective: The attacker aims to impersonate the customer well enough to pass authentication and complete high-value account activity.
- Entry occurs when an attacker tries to bypass customer authentication through OTP interception, social engineering, or account recovery abuse.
- Escalation occurs if the attacker can exploit weak fallback processes or reused identity signals to convince the system they control the legitimate phone-linked identity.
- Impact occurs when unauthorized access leads to account takeover, fraudulent transactions, or reduced trust in the institution’s authentication flow.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Phone possession is not the same as identity assurance: The article correctly treats the mobile device as a possession signal, but that signal is only one control layer in a broader identity decision. A trusted handset can support authentication, yet it does not by itself prove account legitimacy, user intent, or transaction integrity. Practitioners should therefore separate possession evidence from policy decisions that govern step-up, recovery, and transactional risk.
PSD2 SCA pushes identity teams toward decision-grade evidence, not just user-friendly flow design: The central value of phone-centric identity is that it can produce a binary authentication outcome in flows where step-up friction is costly. That is useful in regulated banking, but it also means IAM teams need clear policy boundaries for when possession is sufficient, when additional checks are required, and when fallback paths become the weakest part of the design.
Phone-number-based identity creates a lifecycle problem as much as an authentication problem: A persistent token can improve continuity across the customer journey, but it also increases governance pressure around number reassignment, device replacement, and account recovery. The implication is that customer identity governance now spans onboarding, authentication, and re-binding events rather than ending at login.
Identity assurance built on mobile signals must be treated as a governed control surface: The article’s strongest point is not the marketing language around convenience, but the reminder that multiple authoritative signals can be correlated into a trust decision. That is valuable only when fraud, IAM, and compliance teams agree on ownership for signal quality, override logic, and exception handling.
From our research:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- From our research: 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- If you are extending these controls into workload and machine identity, Ultimate Guide to NHIs is the right baseline for lifecycle, rotation, and offboarding governance.
What this signals
Phone-linked identity is becoming part of the broader assurance stack, not a standalone answer. For financial institutions, that means the programme question shifts from whether mobile intelligence is useful to where its trust boundary ends. Once a phone number becomes an operational identity token, reassignment, device replacement, and recovery events must be governed with the same discipline as any other high-value credential.
Device possession will only scale if governance keeps pace with exception handling. The practical risk is that teams deploy a cleaner authentication flow and then leave exception paths, manual overrides, and recovery desks untouched. That is where attackers usually concentrate, because the frictionless path becomes the hardened path while the alternate path stays soft.
For practitioners
- Define where possession checks are authoritative Map which authentication journeys can rely on a phone possession check and which must always require additional step-up, especially for payment changes, recovery, and high-risk transactions.
- Rebuild recovery flows around device change Require explicit re-verification when a user changes phone number, replaces a device, or triggers account recovery, because those are the points where phone-linked identity weakens.
- Audit fallback paths for OTP dependence Find every recovery, exception, or call-centre path that still depends on OTPs or shared secrets, then remove the social engineering exposure they create.
- Align fraud and IAM policy ownership Assign clear ownership for signal quality, exemption rules, and override decisions so authentication policy does not drift between fraud operations and IAM governance.
Key takeaways
- Phone-centric identity improves authentication only when teams treat the mobile device as a governed signal, not as complete proof of identity.
- OTP replacement changes the attack surface, but recovery, number change, and override handling remain the real control points.
- Financial institutions need shared ownership between IAM, fraud, and compliance if they want possession-based authentication to remain trustworthy over time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63B | The article is about authentication assurance and possession factors. |
| NIST CSF 2.0 | PR.AC-7 | The topic concerns access mechanisms and authentication decisions. |
| NIST Zero Trust (SP 800-207) | 3.1 | Zero trust requires continuous verification of identity claims and device trust. |
| PCI DSS v4.0 | Payment and authentication flows in financial services often intersect with PCI obligations. |
Map phone-centric authentication to PR.AC-7 and ensure access decisions are risk-based and consistently enforced.
Key terms
- Phone-Centric Identity: Phone-centric identity uses mobile device, number ownership, and reputation signals to infer trust. It is designed to reduce dependence on physical documents by leveraging indicators that are harder to counterfeit and easier to reassess during onboarding, recovery, and ongoing authentication.
- Possession factor: An authentication factor that depends on control of a device or physical token. It is stronger when the secret cannot be exported or reused easily, because an attacker must obtain the item itself instead of only the stored credential value.
- Step-up Authentication: Step-up authentication is an additional verification step triggered when a session becomes higher risk or a user attempts a sensitive action. It is used to reduce exposure without forcing extra friction across every interaction, which makes it useful for runtime access governance.
- Identity Re-binding: The process of attaching a new factor or device to an existing identity after loss, reset, or enrollment change. In passwordless environments, this becomes a high-risk control point because weak re-binding can undo the benefit of stronger login methods.
What's in the full article
Prove Identity's full article covers the operational detail this post intentionally leaves for the source:
- Real-world examples of how phone-centric identity is applied in banking and fintech onboarding flows.
- The specific ways Prove describes possession-based checks as a binary yes or no outcome.
- Use cases for reducing OTP reliance while preserving PSD2 SCA compliance.
- The vendor's explanation of how phone-number-based identity tokens persist across the customer journey.
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 responsible for identity security strategy or NHI governance in your organisation, 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