Notifications
Clear all
Topic starter
19/08/2026 3:58 pm
TL;DR: Stolen credentials were the entry point for 50% of web application attacks in the 2024 Verizon DBIR, and Descope positions phone verification plus adaptive MFA as a way to raise friction only when risk signals justify it. The real shift is that customer identity now behaves like a risk-scored access layer, not a static login screen, so IAM teams need branching controls and fraud-aware verification.
NHIMG editorial — based on content published by Descope: Phone Verification & Adaptive MFA With Telesign & Descope Connectors
By the numbers:
- Stolen credentials were the entry point for 50% of web application attacks in the 2024 Verizon DBIR.
- Telesign prevents the transmission of 30+ million fraudulent messages each month.
- The connector flow blocks login when the phone risk score is greater than 80.
Questions worth separating out
Q: How should security teams implement adaptive MFA for customer logins?
A: Start with a risk signal that is meaningful for the customer journey, such as phone reputation, device context, or transaction history.
Q: Why do phone numbers create identity risk in customer authentication?
A: Phone numbers are widely used as identifiers, but they are not inherently trustworthy.
Q: What breaks when MFA is enforced for employees but not vendors or administrators?
A: The organisation ends up with inconsistent assurance, where the most powerful access paths are the least standardized.
Practitioner guidance
- Define risk bands for customer login decisions Set explicit score thresholds for allow, step-up, and block decisions, then validate them against real fraud and false-positive data before rollout.
- Align phone verification with onboarding assurance Require phone intelligence checks during enrolment so the number used for authentication is validated before it becomes a trusted identifier.
- Govern branching flows as policy assets Track MFA branches, step-up conditions, and block logic in the same change-control process used for identity policy updates.
What's in the full article
Descope's full post covers the connector actions and flow-building detail this summary intentionally leaves at a higher level:
- Step-by-step examples for using Telesign Messaging and Telesign Intelligence inside Descope Flows
- The exact branching logic used for score-based allow, magic-link step-up, and block decisions
- How to combine Telesign signals with reCAPTCHA Enterprise and AbuseIPDB inside a single journey
- Template flow examples for OTP sign-up, sign-in, and step-up authentication
👉 Read Descope's analysis of phone verification and adaptive MFA connectors →
Phone verification and adaptive MFA: what IAM teams should change?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
19/08/2026 4:35 pm
Phone-based customer identity has become an attack surface, not just an input field. Once phone numbers are used as identifiers, attackers can target verification gaps, synthetic identities, and takeover paths that sit between onboarding and authentication. That makes phone trust a governance problem, not simply a fraud-screening feature.
Customer identity teams should treat verification flows as a governed decision system, not a UX add-on. Once phone intelligence, fraud scoring, and step-up paths sit in the same control chain, policy drift becomes an access risk unless changes are reviewed like identity controls.
A question worth separating out:
Q: Which identity controls matter most when phone verification is part of onboarding?
A: Verification quality, step-up policy design, and exception handling matter most. If onboarding accepts weak phone data, later authentication decisions inherit that weakness. Teams should also define how stale numbers, account recovery, and unusual device changes are handled so trusted identifiers do not become long-lived attack paths.
👉 Read our full editorial: Phone verification and adaptive MFA are changing customer identity
