Phone verification and adaptive MFA are changing customer identity

At a glance

What this is: This is a product-focused analysis of phone verification and adaptive MFA connectors, with the key finding that risk-scored branching can reduce friction while tightening login decisions.

Why it matters: It matters because customer identity, phone numbers, and step-up authentication are now part of the same control plane for preventing account takeover, bot abuse, and weak onboarding paths.

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.

👉 Read Descope's analysis of phone verification and adaptive MFA connectors

Context

Customer identity is no longer just a sign-in problem. When phone numbers become a primary identifier, identity teams have to decide whether the number is verified, whether the signal is trustworthy, and whether the login path should change in real time based on risk.

That makes adaptive MFA and phone intelligence part of the broader IAM control surface. The operational gap is not whether MFA exists, but whether it responds to risk without creating blanket friction for legitimate users.

For teams building customer authentication journeys, the practical question is how to combine verification, fraud signals, and step-up logic without hardcoding every branch into the application layer.

Key questions

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. Then define explicit branches for allow, step-up, and block. The key is to tune the policy to reduce unnecessary friction while still interrupting suspicious sessions before account takeover or abuse can progress.

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. Numbers can be reassigned, spoofed, or tied to synthetic identities, which means a valid-looking login can still be fraudulent. Security teams need verification and context, not just possession of a number, before treating it as a strong identity signal.

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. That weakens the audit story and can leave the highest-risk sessions outside the same control and monitoring standard as the rest of the user base.

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.

Technical breakdown

How phone intelligence changes customer authentication decisions

Phone intelligence turns a phone number from a static identifier into a risk signal. Carrier data, geolocation, and reputation checks can be used to judge whether the submitted number looks legitimate, whether it matches onboarding context, and whether it should trigger additional verification. In practice, that means the authentication flow becomes conditional. Instead of always allowing, always blocking, or always stepping up, the system can route users based on the score returned by the intelligence provider.

Practical implication: build decision branches around verified risk signals, not around a one-size-fits-all MFA rule.

Adaptive MFA and branching login paths

Adaptive MFA is a policy pattern that increases authentication friction only when the login attempt appears suspicious. In the Descope flow described in the article, a score under 30 permits sign-in, 30 to 80 triggers a magic-link step-up, and over 80 blocks the attempt. That is a classic policy decision engine use case: authentication is not a single event, but a sequence of conditional outcomes driven by external risk data and user journey context.

Practical implication: design MFA policies that can branch by risk tier, not just by user role or application.

No-code orchestration across verification and fraud tools

The connector model allows verification actions, risk scoring, and other fraud controls to be combined in a workflow rather than stitched together in application code. That matters because customer identity journeys change frequently, especially when organizations adjust thresholds, swap a block for passkeys, or add more user-facing checks. The architectural benefit is control-layer flexibility. The security risk, however, is policy drift if each branch is changed without consistent governance and review.

Practical implication: treat branching flows as governed identity policy, not as disposable low-code logic.

NHI Mgmt Group analysis

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.

Adaptive MFA works because it restores proportionality to authentication. Blanket MFA creates unnecessary friction, but static authentication paths create blind spots. Risk-scored branching lets teams raise controls only when the login attempt warrants it, which is the right balance for consumer identity programmes.

Customer identity control design should be built around decision latency, not just factor strength. If risk signals arrive too late or are not available to the journey layer, even strong MFA can be bypassed through weak verification logic upstream. Practitioners should align verification, fraud scoring, and step-up orchestration as one policy chain.

Phone verification is only as trustworthy as the lifecycle around it. A verified number can still become stale, reassigned, or compromised. That means customer identity programmes need periodic re-validation and exception handling, not one-time enrolment assumptions.

Risk-based authentication is becoming the default operating model for customer identity. The industry is moving away from static challenge patterns toward contextual decisions that combine identity proofing, fraud intelligence, and user experience. Teams that do not govern that shift will end up with fragmented controls and inconsistent access outcomes.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a blind spot for compliance and breach investigation.
• That gap makes OWASP Agentic AI Top 10 the right forward lens for teams evaluating how dynamic identity behaviour should be governed.

What this signals

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.

Identity trust branching: the moment a login flow changes based on score thresholds, the flow itself becomes part of the identity control surface. That means access reviews, policy testing, and exception logging need to cover the journey logic, not just the auth factor.

Teams that already use risk-based authentication should check whether their thresholds are still calibrated to current fraud patterns. Reassignment risk, synthetic identity abuse, and takeover attempts all change over time, so yesterday's safe branch can become today's weak point.

For practitioners

• 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.
• Monitor for stale or reassigned numbers Re-check high-risk numbers over time, especially after device changes, account recovery events, or unusual login behaviour.

Key takeaways

• Phone-based authentication is only as reliable as the verification and risk signals behind it.
• Adaptive MFA reduces friction only when the policy engine can branch cleanly on trustworthy context.
• Customer identity programmes now need governance for journey logic, not just for credentials and factors.

Key terms

• Adaptive MFA: A multi-factor authentication pattern that changes the challenge based on user context, risk, and policy. It reduces unnecessary friction by avoiding one-size-fits-all prompts, while still increasing assurance when a session, device, or location looks unusual.
• Phone Intelligence: Phone intelligence is the use of carrier, routing, and number-quality data to assess whether a phone number is likely to represent a legitimate user. In practice, it helps teams decide whether to send, challenge, or block an OTP before the message becomes a fraud event.
• Risk-Based Authentication: An access model that changes verification requirements based on the estimated risk of the request. It combines identity assurance, device posture, application sensitivity, and contextual signals to decide whether to allow, block, or step up verification before access is granted.
• Customer Identity: Customer identity is the authentication and account layer used for app users, sign-in, federation, and profile management. It is built to manage user access into applications, not to mediate privileged infrastructure activity or deep protocol-level control.

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

👉 Descope's full post covers the flow logic, risk branching, and connector actions in more implementation detail.

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.