Most enterprise teams already understand the critiques of Short Message Service (SMS). Codes can be intercepted, phished, or redirected. Yet phone numbers remain embedded in too many critical flows. They are still a standard recovery channel and second-factor authenticator.
The problem is that a phone number is not a stable identity object. It can be ported or SIM-swapped. The National Institute of Standards and Technology’s (NIST’s) latest digital identity guidance, NIST Special Publication 800-63B, treats the use of phone numbers for out-of-band authentication as a restricted authenticator. It also notes that out-of-band authentication is not phishing-resistant and says verifiers should consider risk indicators such as device swap, SIM change, and number porting.
Phone-based authentication is still important, but phone possession by itself is an unstable signal. Mature identity threat detection should treat the phone as a context source, not a verdict.
The phone number is a moving part, not an identity anchor
Princeton University researchers found that 35 million phone numbers are disconnected in the U.S. every year, and that most available numbers they sampled were recycled. In their study, 215 of 259 sampled numbers were recycled and vulnerable to at least one attack path, including personally identifiable information (PII) lookup and account hijacking. The researchers also found that 171 of those sampled numbers remained tied to existing accounts at popular sites.
That should change how security and identity fraud teams think about phone-based trust. A phone number may still resolve, still receive a code, and still appear “validated” in a basic workflow, even when it no longer belongs to the same person who originally bound it to the account.
SIM swapping is more visible, but it points to the same architectural flaw. The European Union Agency for Cybersecurity’s (ENISA’s) guidance on SIM swapping emphasizes the role of social engineering against carrier staff and notes that the human factor remains central to the attack. In the U.S., the Federal Communications Commission (FCC) responded by adopting baseline rules that require wireless providers to use secure customer authentication methods before redirecting numbers and to notify customers when SIM changes or port-out requests occur.
Those rules are important, but they do not resolve the problem on the enterprise side. They do not tell a bank, insurer, or healthcare portal whether a specific phone should be trusted for a specific action at a specific moment.
Why factors-about-factors matter
A more useful model is to separate authentication factors from the evidence that helps interpret them. The password, passkey, push approval, or one-time code is the factor. The SIM change timestamp, line tenure, number portability status, carrier data, device continuity, line type, and number reuse history are factors about the factor.
That second layer is what turns phone data from a weak yes-or-no control into a risk signal. NIST points in this direction by saying verifiers should consider indicators such as SIM change and number porting before sending a Public Switched Telephone Network (PSTN) out-of-band secret. The GSMA Open Gateway and the Linux Foundation’s CAMARA project, through their work on SIM Swap APIs, point in the same direction. These interfaces exist because enterprises increasingly need a way to ask not only whether a phone can receive a message, but whether the relationship with that phone has changed recently enough to make that message untrustworthy.
Once you frame the problem this way, the solution space becomes clearer. A passkey or Fast Identity Online (FIDO) credential is still the stronger primary answer for many workforce and consumer use cases because it is phishing-resistant by design. But enterprises cannot eliminate the phone overnight. They still need recovery channels and customer-friendly step-up options across platforms. The real question becomes how much trust to place in a particular phone within the context of each access decision.
The practical solution is not “remove the phone,” but “stop trusting it blindly”
There are several ways enterprises respond, and each has tradeoffs. The weakest approach is to keep using SMS or voice one-time password (OTP) as if possession alone settles the matter. It is familiar, inexpensive, and easy to deploy across broad populations. It also leaves teams exposed to SIM swaps, port-outs, recycled numbers, and relay attacks. User friction may appear low at first, until identity fraud and manual review queues rise.
A better approach is to reserve phone-based challenges for lower-risk moments and inspect the phone’s surrounding context before using it. This reduces attack surface without forcing an all-at-once migration. If the line was just swapped, ported, or rebound to a new device, the system should stop treating SMS delivery as meaningful proof. It should route the user to a different authenticator, require a stronger step-up, or hold the action for review.
The strongest long-term pattern is layered. Use phishing-resistant authentication where coverage allows. Keep the phone as a contextual signal and fall back only where necessary. Then instrument the decision so the fallback is conditional, not automatic. Microsoft’s guidance on evolving identity attacks makes the same point from another angle: multi-factor authentication (MFA) by itself is no longer enough when adversaries target tokens, device code flows, and consent paths. Identity decisions need real-time signals and policy.
How identity threat detection strengthens digital trust
This is where identity threat detection becomes more useful than another standalone authenticator. The goal is not to declare the phone good or bad in the abstract. It is to evaluate phone trust in context and connect that judgment to an action.
ID Dataweb™ treats phone intelligence as one decision input inside a broader orchestration layer. If a user presents a known device, a normal location, stable phone history, and low-risk session context, the system can keep the path light. If the phone shows a recent SIM change, a fresh port, unusual velocity, or inconsistent identity risk signals during a sensitive event, the workflow can step up to stronger authentication or block the attempt before the OTP becomes the breach path.
That matters because the enterprise problem is rarely confined to one channel. A user may enroll in one channel, recover in another, and transact in a third. ID Dataweb’s value in that environment is not simply phone verification. It is the ability to correlate risk signals around the phone with the rest of the identity event, then drive the right next action across login, recovery, onboarding, and transaction flows. That is how teams reduce both identity fraud exposure and unnecessary challenge rates.
Conclusion
The phone is not going away anytime soon. Too many enterprise processes still depend on it. But teams should stop asking whether the phone can serve as a second factor in the abstract. That framing is too coarse for the threat environment they face.
The sharper question is whether the phone remains a trustworthy factor for this event, after considering the factors about the factor.
That is the move from static MFA to identity threat detection. It reflects what NIST now says about PSTN-based out-of-band authentication, what Microsoft is reporting about modern phishing, what regulators and telecom standards groups are doing around SIM and port events, and what incident data continues to show in the field. A phone signal without context is weak evidence. A phone signal interpreted through current risk, continuity, and orchestration can still be useful.
For enterprises that still rely on the phone in critical paths, that distinction is no longer academic. It is the difference between using the phone as a convenience feature and letting it become the attacker’s shortcut.
