Security · 2026-04-09

Silent Number Recycling and the Carrier Signal Most Identity Stacks Ignore

By J. W. Bouckaert

The number you verified last year may belong to someone else today

Every identity stack that uses phone numbers as an authentication factor makes an implicit assumption: the person who controls a phone number today is the same person who controlled it when the number was bound to an account.

That assumption is wrong approximately 35 million times per year in the United States alone.

Mobile number recycling—the routine carrier practice of reassigning disconnected phone numbers to new subscribers after a quarantine period—is one of the most underestimated threats in modern identity architecture. It is a designed, documented, and regulated carrier process, neither a bug nor an edge case, and it systematically undermines phone-number-based authentication at scale.

When a carrier recycles a number, it does not notify your authentication service, your password reset flow, or your OTP delivery pipeline. The first indication that a number has been recycled is when the wrong person receives a one-time password.

This article examines the mechanics of number recycling, quantifies the risk surface, and introduces a carrier-signal entropy check that detects reassignment before the first inbound OTP arrives at the wrong device.

Number recycling

The MSISDN lifecycle

A phone number—formally an MSISDN (Mobile Station International Subscriber Directory Number)—follows a defined lifecycle within carrier infrastructure:

The quarantine period varies by carrier and jurisdiction. The FCC's numbering rules do not mandate a minimum quarantine duration, though industry practice has settled around 90 days. Some carriers in high-demand area codes recycle numbers in as few as 30 days. International carriers in number-constrained markets (e.g., Singapore, Hong Kong) may recycle within 14 days.

The scale of recycling

The numbers are significant:

| Pre-paid numbers can re-enter the assignment pool faster than the 90-day norm | varies by carrier and area code | T-Mobile / Verizon prepaid terms, cited in Princeton study |

A 2021 Princeton study (Lee, Yu, Jaffe & Mayer) acquired 259 recycled phone numbers from two major US carriers and found that 171 of them—66%—were still linked to previous owners' accounts on popular online services. The researchers were able to receive password-reset codes and complete account-takeover preconditions on accounts that belonged to the previous number holders. The paper is the most-cited primary source on the operational risk of MSISDN reassignment.

Ghost accounts

When a number is recycled, every service that bound that number to an account creates what we call a ghost account—an account where the registered phone number now belongs to a different person.

Ghost account taxonomy

The cascading ghost scenario is the most dangerous. If a recycled number is linked to an email account that uses SMS-based recovery, the new subscriber can:

1. Reset the email account password via SMS OTP
2. Use the email account to reset passwords on every service linked to that email
3. Access financial accounts, cloud storage, social media, and enterprise systems
4. Establish persistence by changing recovery methods to their own credentials

This attack chain is documented in NIST SP 800-63B, which explicitly warns that SMS-based authentication is vulnerable to number reassignment and recommends against its use as a sole authentication factor.

Failures of current defenses

OTP timing

Most identity platforms detect SIM swaps by monitoring for suspicious number portability events. This is the wrong signal to watch for number recycling, because number recycling is not a port. Instead of transferring between carriers, the number is deactivated and later reactivated within the same carrier's infrastructure. Port-monitoring services (Twilio Lookup SIM Swap, Vonage Number Insight) detect recent SIM-change events; an absent or stale "last SIM change" signal on a recycled MSISDN does not, by itself, surface the reassignment.

Database staleness

Services that maintain phone-number-to-identity mappings rarely implement proactive validation. The typical pattern is:

1. User registers with phone number → number stored in database
2. User authenticates with OTP → OTP sent to stored number
3. No periodic revalidation of number ownership

Between steps 1 and 2, the number may have been disconnected, quarantined, and reassigned to a new subscriber. The identity platform has no mechanism to detect this change because it never re-checks the binding.

No carrier notification

Carriers do not provide proactive notification of number recycling to third-party services. There is no webhook, no API callback, and no industry-standard protocol for carriers to inform identity providers that a number has been reassigned. The GSMA's Mobile Connect initiative attempted to address this gap, but adoption remains limited to a handful of carriers in specific markets.

This notification gap means that identity platforms operate on stale data by default. The only way to detect number recycling is to actively query carrier signals at authentication time—not passively wait for a notification that will never arrive.

Carrier-signal entropy: A pre-OTP detection model

PasskeyBridge introduces a carrier-signal entropy check that executes before any OTP is generated or delivered. The model treats number recycling as a detectable discontinuity in the carrier-signal profile associated with a phone number.

The entropy model

When a phone number is first bound to an identity, PasskeyBridge captures a baseline carrier-signal profile derived from the data its upstream providers actually expose. None of the dimensions below require, or persist, the raw MSISDN, IMSI, or ICCID—each is reduced to a keyed HMAC-SHA-256 digest under a server-held pepper before storage (non-enumerable, unlike a plain SHA-256 of these low-entropy identifiers), consistent with the zero-PII architecture:

Baseline Profile (captured at binding time):
├── Carrier + MVNO Hash       → SHA-256(MCC+MNC+brand)
├── Line Type                 → Postpaid / Prepaid / VoIP / Mobile
├── Last SIM-Change Indicator → "swap_within_7d": true/false (from carrier API)
├── Last Port-Out Indicator   → "port_within_30d": true/false (from carrier API)
├── Number Tenure Bucket      → days_since_first_seen, bucketed
├── Device Capability Flags   → VoLTE, VoNR, eSIM support where exposed
├── Reachability State        → Active / Suspended / Unknown
└── Roaming Status            → Home / Visited network

At each subsequent authentication event, PasskeyBridge queries the same signal dimensions and computes the Shannon entropy delta between the current profile and the baseline:

H(Δ) = -Σ p(xᵢ) · log₂(p(xᵢ))

Where:
  xᵢ = binary divergence indicator for each signal dimension
  p(xᵢ) = normalized weight of dimension i
  H(Δ) = total entropy delta (bits)

Signal dimension weights

Not all signal changes are equal. A change in roaming status is expected (the user traveled). A simultaneous flip in line type, carrier brand, and a freshly observed SIM-change indicator is the signature of a recycled-and-reactivated number. PasskeyBridge assigns dimension-specific weights:

When the weighted entropy delta exceeds a configurable threshold (default: 0.7 bits), the system classifies the number as potentially recycled and suppresses OTP delivery.

Decision flow

┌───────────────────────────────────────────────────┐
│         AUTHENTICATION EVENT TRIGGERED             │
│  (OTP request, password reset, 2FA challenge)      │
└──────────────────────┬────────────────────────────┘
                       │
                       ▼
┌───────────────────────────────────────────────────┐
│         QUERY CARRIER SIGNAL PROVIDERS             │
│  Twilio Lookup + Vonage Number Insight             │
│  (parallel, in-request at edge)                    │
└──────────────────────┬────────────────────────────┘
                       │
                       ▼
┌───────────────────────────────────────────────────┐
│         COMPUTE ENTROPY DELTA H(Δ)                 │
│  Compare current profile vs. binding baseline      │
└──────────────────────┬────────────────────────────┘
                       │
              ┌────────┴────────┐
              │                 │
     H(Δ) < 0.7          H(Δ) ≥ 0.7
              │                 │
              ▼                 ▼
┌──────────────────┐  ┌──────────────────────────┐
│   PROCEED WITH   │  │   SUPPRESS OTP DELIVERY  │
│   OTP DELIVERY   │  │   Flag binding for review │
│                  │  │   Notify via alt channel  │
│                  │  │   Log to audit trail      │
└──────────────────┘  └──────────────────────────┘

Entropy rather than binary matching

A binary match (did the line type change? yes/no) produces unacceptable false positive rates. Users legitimately change SIM cards, switch between eSIM profiles, and move between carriers via MVNO migrations. The entropy model captures the aggregate divergence across all signal dimensions simultaneously, distinguishing between legitimate subscriber activity (low entropy delta, 1–2 dimensions change) and number recycling (high entropy delta, 4+ dimensions change simultaneously).

Implementation: The pre-OTP gate

PasskeyBridge implements the entropy check as a pre-OTP gate in the authentication pipeline. The check executes before OTP generation, ensuring that a recycled-number recipient never receives authentication material.

Integration with the signal correlation engine

The entropy check plugs into PasskeyBridge's existing multi-provider carrier signal correlation architecture. Rather than adding a new API call, the entropy computation runs as an additional analysis pass on carrier data that is already being fetched for signal correlation:

Standard Signal Correlation Flow:
  1. Fetch Twilio Lookup response        ─┐
  2. Fetch Vonage Number Insight response ─┴── Already happening
  3. Correlate signals (existing)
  4. Compute entropy delta (new)          ←── Added: low-millisecond overhead
  5. Gate OTP delivery on entropy result  ←── Added: conditional

The entropy computation runs entirely on data the pipeline already fetches, so it adds only low-millisecond CPU overhead against the platform's measured decision path.

Binding lifecycle management

When a number recycling event is detected, PasskeyBridge does not silently drop the OTP. It initiates a binding quarantine workflow:

1. Suppress the OTP delivery to the recycled number
2. Notify the account holder via alternative channels (email, push notification, backup phone)
3. Flag the phone-number binding as stale in the identity record
4. Log the detection event to the immutable audit trail with the entropy delta, signal dimensions that diverged, and provider timestamps
5. Require the account holder to re-verify their current phone number through a fresh binding ceremony

This workflow ensures that legitimate account holders are not locked out—they receive a notification on an alternative channel and can rebind their account to their current number.

Regulatory requirements

Number recycling sits at the intersection of telecommunications regulation and identity-layer security, and neither regime adequately addresses the risk.

Current regulatory gaps

The regulatory gap is clear: telecommunications regulators manage number assignment but do not address the downstream identity implications. Identity regulators (where they exist) do not have jurisdiction over carrier numbering operations. The result is a no-man's-land where number recycling creates identity risk that neither regime is equipped to mitigate.

NIST guidance

NIST SP 800-63B Section 5.1.3.3 explicitly acknowledges the risk:

"Verifiers SHOULD consider risk indicators such as device swap, SIM change, number porting, or other abnormal behavior before using the PSTN to deliver an out-of-band authenticator."

NIST classifies PSTN-delivered out-of-band authenticators (SMS, voice) as a restricted authenticator—meaning the verifier must assess the risks of the channel, including reassignment, before using it. PasskeyBridge's entropy check implements the risk monitoring that NIST recommends but does not prescribe.

Operational considerations

Calibrating the threshold

The entropy model's threshold (0.7 bits in the default profile) is a tenant-tunable parameter. Tighter thresholds catch more recycling events at the cost of routing more legitimate users to an alternative verification channel; looser thresholds reduce false positives but widen the window in which a recycled number can receive authentication material.

PasskeyBridge ships the 0.7-bit default based on internal simulation against the dimension weights above and the recycling-pattern signatures documented in the Princeton study. Production tenants should re-calibrate against their own carrier-mix and false-positive tolerance; the entropy delta and per-dimension divergence are surfaced in the audit log so the threshold can be tuned without re-deploying code.

Users flagged by the entropy gate are never silently blocked. They are routed to an alternative verification channel (email, push, or backup phone) and can complete authentication within seconds while the binding is reviewed.

Multi-provider signal correlation

The entropy model benefits from PasskeyBridge's multi-provider architecture. By querying Twilio and Vonage in parallel—and any additional carrier-signal providers a tenant has configured—the platform obtains independent observations that reduce the probability of single-provider data staleness affecting the entropy calculation.

When providers disagree—for example, one reports the number as active in its home network while the other surfaces a recent SIM-change indicator and a line-type flip—the entropy model increases the delta, correctly flagging the number for review.

Consequences for your identity stack

If your identity stack uses phone numbers for any authentication purpose—OTP delivery, account recovery, two-factor authentication, or identity binding—you are exposed to number recycling risk. Your users' numbers will be recycled. The useful question is whether you will detect it before or after the wrong person receives an OTP.

PasskeyBridge's carrier-signal entropy check provides pre-OTP detection inside the request. It runs as an additional analysis pass on carrier signals that the platform already fetches for signal correlation and SIM swap detection, adding minimal overhead to the existing pipeline.

The alternative is to continue treating phone numbers as stable identifiers and hope that the tens of millions of annual recycling events in the US alone do not affect your users. That is a bet rather than a security strategy—and the odds are getting worse every year.

---

PasskeyBridge detects number recycling before the first OTP is delivered. Request a demo or explore the carrier signal architecture to understand how pre-OTP entropy checks integrate with your existing identity stack.

Start free · Test the API