Reassigned Phone Numbers, Account Bindings, and Recovery Traffic

What do the four live provider cells establish?

The four cells do not establish that an old account binding survived number reassignment or that recovery or notification traffic reached a new holder.

Proton's account-creation record says Proton may ask a person creating a Proton Account to complete a CAPTCHA or verify a phone number or email address to prevent bots and spam; Proton says it stores a cryptographic hash rather than the email address or phone number. (source) The record concerns a person creating a Proton Account. It does not record a disconnected number, a later reassignment, a prior holder's account, or a message delivered to a new holder.

AT&T's United States record says AT&T says Wireless Account Lock blocks account features including device upgrades, SIM and eSIM swaps and changes, IMEI changes, phone-number changes, and transfers to or from another wireless carrier. (source) Those are controls on listed account actions when Wireless Account Lock is enabled. The cell does not document what happens after a disconnected number is reassigned.

Verizon's United States record says Verizon says Number Lock can prevent a mobile number from being moved to another line or carrier until the lock is removed, and says Number Lock does not prevent SIM-card or equipment changes. (source) The distinction matters: a number move, a SIM change, and an equipment change are not the same event, and this cell does not turn any of them into evidence of number reassignment or account recovery.

The Federal Communications Commission's United States record says The FCC's 2023 Report and Order says wireless providers must use secure methods to authenticate customers before performing SIM changes and number ports, and says providers must offer account locks that block processing of those changes and ports. (source) This is a carrier-authentication requirement before SIM changes and number ports. It is not a record of a recycled number, an old account binding, or traffic sent through that binding.

Is account-creation verification evidence of a surviving account binding?

No. The Proton cell does not establish whether a prior holder's phone-number binding survived a later reassignment.

The Proton record is narrow: Proton may ask a person creating a Proton Account to complete a CAPTCHA or verify a phone number or email address to prevent bots and spam; Proton says it stores a cryptographic hash rather than the email address or phone number. (source) Its event is account creation. The cell does not identify a prior account, a carrier disconnection, a reassignment date, a new holder, a recovery request, or a notification sent after reassignment.

That boundary prevents two different propositions from being collapsed. A service can ask for a phone number during account creation without the cell establishing how that number is used later. Separately, a phone number can be reassigned without this evidence showing that any service still binds the number to a prior account. The four-cell evidence set contains no joined record connecting those events.

A claim about a surviving binding would need a dated reassignment event tied to a specific earlier account and a later observation showing that the binding remained active. A claim about misdirected traffic would need an additional record showing that a recovery or notification message was delivered to the new holder. Neither outcome appears in the accepted cells, so neither is stated as fact here.

Do number locks and SIM-change controls prove a reassignment outcome?

No. The AT&T, Verizon, and Federal Communications Commission cells do not record number reassignment, a surviving stale binding, or delivery of recovery traffic.

AT&T's Wireless Account Lock cell states AT&T says Wireless Account Lock blocks account features including device upgrades, SIM and eSIM swaps and changes, IMEI changes, phone-number changes, and transfers to or from another wireless carrier. (source) The claim stays attached to AT&T, to the named feature, and to the feature's enabled state. It does not describe every carrier, every account action, or the handling of a disconnected number after reassignment.

Verizon's Number Lock cell states Verizon says Number Lock can prevent a mobile number from being moved to another line or carrier until the lock is removed, and says Number Lock does not prevent SIM-card or equipment changes. (source) Verizon's own limit keeps number movement separate from SIM-card and equipment changes. The record cannot support a broader statement that one lock controls all three events, and it does not record a new subscriber receiving an old subscriber's account traffic.

The Federal Communications Commission cell states The FCC's 2023 Report and Order says wireless providers must use secure methods to authenticate customers before performing SIM changes and number ports, and says providers must offer account locks that block processing of those changes and ports. (source) The requirement concerns authentication before two named carrier actions: a SIM change and a number port. A number port is not silently treated as number reassignment, and a secure-authentication requirement is not evidence that a particular recovery request succeeded.

These records belong together only as a boundary comparison. AT&T identifies actions blocked by one account feature. Verizon identifies what one number-lock feature blocks and what it does not. The Federal Communications Commission identifies a carrier-authentication requirement. Their shared subject is control around numbers, accounts, SIMs, and ports; their evidence does not establish the post-reassignment event named in the unanswered question.

What evidence would show a surviving binding or misdirected traffic?

A surviving-binding claim needs a dated chain from number reassignment to a specific prior account, while a misdirected-traffic claim also needs proof that recovery or notification traffic reached the new holder.

The first missing record is the reassignment event itself. It would need to identify the phone number in a controlled evidence record, establish that the number moved from a prior holder to a new holder, and preserve the date and scope of that change. The four accepted cells do not contain such an event.

The second missing record is continued attachment to a specific prior account after that event. It would need to show that the service still accepted, displayed, or used the reassigned number as a recovery or notification destination for the earlier account. An account-creation verification statement or a carrier control cannot supply that later observation.

The third missing record is delivery. A message being generated, a number remaining on an account, and a new holder actually receiving traffic are separate facts. Evidence of delivery would need to bind the message category, destination, time, and new-holder context without exposing personal account material. No accepted cell records that delivery.

Even that chain would not prove everything a reader might infer. Delivery would not establish that the recipient passed another authentication step. A successful recovery step would not establish access to every part of an account. Account access would not establish access to every stored record. Each step requires its own evidence rather than being inferred from the step before it.

1. Record the dated reassignment from a prior holder to a new holder.
2. Record whether a specific prior account still used the number after reassignment.
3. Record whether recovery or notification traffic was actually delivered to the new holder.
4. Keep identity proof, successful recovery, account access, and stored-record access as separate later questions.

How should the mechanism be read as separate events?

Read verification, carrier controls, number reassignment, binding survival, traffic delivery, recovery, and record access as separate events; evidence for one event does not fill another event's empty field.

The provider ledger has four populated entries. Proton supplies an account-creation verification entry: Proton may ask a person creating a Proton Account to complete a CAPTCHA or verify a phone number or email address to prevent bots and spam; Proton says it stores a cryptographic hash rather than the email address or phone number. (source) AT&T supplies an account-lock entry: AT&T says Wireless Account Lock blocks account features including device upgrades, SIM and eSIM swaps and changes, IMEI changes, phone-number changes, and transfers to or from another wireless carrier. (source) Verizon supplies a number-lock and portability entry: Verizon says Number Lock can prevent a mobile number from being moved to another line or carrier until the lock is removed, and says Number Lock does not prevent SIM-card or equipment changes. (source) The Federal Communications Commission supplies a pre-change carrier-authentication entry: The FCC's 2023 Report and Order says wireless providers must use secure methods to authenticate customers before performing SIM changes and number ports, and says providers must offer account locks that block processing of those changes and ports. (source)

The next fields remain unpopulated in this evidence set: a dated reassignment to a new holder, continued use of that number by a specific prior account, delivery of recovery or notification traffic to the new holder, successful recovery, account access, and access to stored records. Calling those fields unpopulated is not a claim that the events never occur. It means these four cells do not record them.

This event-by-event reading keeps the route useful without converting adjacent controls into an incident story. It also makes later correction possible. A future accepted cell could fill one missing field without rewriting what Proton, AT&T, Verizon, or the Federal Communications Commission currently document.

• Proton account-creation verification — Proton may ask a person creating a Proton Account to complete a CAPTCHA or verify a phone number or email address to prevent bots and spam; Proton says it stores a cryptographic hash rather than the email address or phone number. (source)
• AT&T Wireless Account Lock — AT&T says Wireless Account Lock blocks account features including device upgrades, SIM and eSIM swaps and changes, IMEI changes, phone-number changes, and transfers to or from another wireless carrier. (source)
• Verizon Number Lock — Verizon says Number Lock can prevent a mobile number from being moved to another line or carrier until the lock is removed, and says Number Lock does not prevent SIM-card or equipment changes. (source)
• Federal Communications Commission carrier safeguards — The FCC's 2023 Report and Order says wireless providers must use secure methods to authenticate customers before performing SIM changes and number ports, and says providers must offer account locks that block processing of those changes and ports. (source)
• Number reassignment — not established by the four accepted cells.
• Surviving prior-account binding — not established by the four accepted cells.
• Recovery or notification traffic delivered to the new holder — not established by the four accepted cells.
• Identity proof, successful recovery, account access, and stored-record access — not established by the four accepted cells.

What are the limits and non-findings?

This reference does not establish a post-reassignment incident, a frequency, a timing pattern, a compromise, or a remediation outcome.

The evidence universe is limited to the four exact cells cited in this page's source passages. Provider wording and scope remain attached to each record. No cell is generalized into a claim about every service, carrier, number, account, or recovery flow.

The three required non-findings are direct. A stale binding is not identity proof. Receiving traffic is not successful recovery. Successful recovery is not access to stored records. The page also does not infer that a stale binding exists, that traffic was received, or that recovery succeeded.

No anecdote, incident count, prevalence estimate, delivery interval, compromise claim, or universal prevention step is supported by this brief. The page therefore does not compare the controls as winners or losers, promise anonymity, claim that any one feature prevents every unauthorized change, or endorse a provider.

For the neighboring authentication question, see Why SMS second factors are a weak shared channel. For the migration procedure, see Parking a legacy phone number. The Private Phone-Number Apps comparison keeps product-level identity, retention, porting, and limitation evidence on its own route.

Frequently asked questions

Related research

• Why SMS second factors are a weak shared channelSeparates the authentication-channel risk from the evidence needed to show a post-reassignment outcome.
• VoIP and Carrier Numbers: What a Number EstablishesKeeps number characteristics and carrier controls separate from claims about surviving account bindings.