Why do recycled mobile numbers create identity risk for IAM programmes?

They create identity risk because the lifecycle of the phone number is separate from the lifecycle of the account. If a number is reassigned, the old trust relationship survives in systems that still rely on it for recovery or step-up. IAM teams need to treat number reuse as a trust revocation event, not as routine contact maintenance.

Why This Matters for Security Teams

Recycled mobile numbers are an identity problem because many IAM programmes still treat a phone number as if it were a stable person-bound factor. It is not. A number can be reassigned after churn, theft, or carrier recycling while the old trust relationship persists in recovery flows, SMS step-up, and help desk verification. That creates a gap between account lifecycle and telecom lifecycle that attackers can exploit.

Practitioner guidance has shifted toward treating contact data as an untrusted attribute unless it is re-verified at the moment of use. That is consistent with broader identity guidance in the NIST Cybersecurity Framework 2.0 and NHI lifecycle thinking in the Ultimate Guide to NHIs, both of which emphasise continuous validation rather than static trust. In NHI Management Group research, 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a useful reminder that identity failures often begin with weak trust assumptions.

In practice, many security teams only discover recycled-number risk after an account recovery abuse has already succeeded, rather than through intentional lifecycle testing.

How It Works in Practice

The risk appears wherever a mobile number is used as proof of continuity. Common examples include SMS one-time passcodes, password reset links delivered after a phone check, call-back verification, and fallback factors when primary authenticators fail. If the number has been reassigned, the new holder may receive sensitive messages or satisfy a control designed for the previous user. The account owner and the phone number holder are no longer the same trust subject.

Security teams should map every workflow that accepts a phone number as an authenticator, then separate the number from identity assurance. Current best practice is to treat the number as a mutable contact attribute and require stronger proof for recovery, such as phishing-resistant authenticators or validated in-person processes. This aligns with the control intent behind the OWASP Non-Human Identity Top 10, even though the specific issue here is human IAM rather than NHI. The lesson carries over: do not let stale trust survive object reuse.

Useful operational checks include:

• Inventory every system that sends secrets, reset links, or step-up prompts to a phone number.
• Set explicit re-verification rules when a number changes, is ported, or is inactive for a defined period.
• Remove SMS from recovery paths for privileged users where possible.
• Log number-change events as security-relevant identity events, not help desk metadata updates.
• Require out-of-band confirmation before accepting a recycled number for account recovery.

The NHI Lifecycle Management Guide is useful here because it frames identity as a lifecycle problem, not a static registration problem. These controls tend to break down in consumer-scale environments with high churn and outsourced support, because number validation, account recovery, and carrier state are often handled by different teams and systems.

Common Variations and Edge Cases

Tighter recovery controls often increase user friction and support cost, requiring organisations to balance account takeover resistance against help desk volume and false rejects. That tradeoff is real, especially where mobile numbers are still the only broadly available recovery attribute.

There is no universal standard for how long a number must be unused before it is considered unsafe, and that threshold varies by carrier, region, and risk appetite. For high-risk roles, current guidance suggests moving away from SMS altogether and using stronger authenticators or step-up checks tied to device possession and cryptographic proof. For lower-risk consumer journeys, some organisations keep SMS only as a low-assurance fallback while reserving sensitive actions for stronger methods.

Edge cases also matter. Shared devices, prepaid numbers, international roaming, and VoIP services can all weaken assumptions about who controls the number. Help desk staff should not treat caller ID or knowledge of a recycled number as proof of identity. The practical test is simple: if a number can be reassigned, it cannot be the sole anchor for trust. That principle is consistent with lifecycle-centric controls in the Top 10 NHI Issues, where stale trust and poor revocation discipline repeatedly create exposure.

Related resources from NHI Mgmt Group

• Why does manual evidence collection create governance risk in IAM programmes?
• Why do identity providers still create security risk in mature IAM programmes?
• Why do passwords create persistent identity risk even in mature IAM programmes?
• Why do shadow AI tools create identity risk for IAM programmes?