Separate a generated value from a bound authenticator
Four events are easy to confuse: software can generate a number-shaped test value; a provider can assign a live line; a user can demonstrate access to that line during a challenge; and an app can bind it to an account for authentication. Only the last two establish a current sign-in relationship, and a successful challenge does not prove that the same person will control the number forever.
| State | What it establishes | What it does not establish |
|---|---|---|
| Synthetic fixture | A string for parser, layout or workflow tests. | It cannot receive a call, SMS or account recovery code. |
| Provider-assigned line | A communications provider has assigned service under its own plan. | It does not prove who currently controls it or whether an app accepts it. |
| Access challenge passed | The user could receive and return a short-lived challenge at that moment. | It does not guarantee future access after a SIM, device, provider or number change. |
| Account authenticator bound | The app records the line as an authentication route for this account. | It should not be treated as the account's only recovery method. |
For a real account, never substitute a generated fixture for a provider-assigned line. For a test environment, keep synthetic values on a non-delivery path so a verification flow cannot accidentally send a message to a real person.
Use a controlled bind-and-replace sequence
NIST SP 800-63B treats setting or changing a pre-registered telephone number as binding a new authenticator. Its guidance also calls out device swaps, SIM changes and number porting as risk indicators, and calls for alternative authenticator types. Use those ideas to make number changes an explicit, reviewable account event.
| Step | Application action | Evidence to retain |
|---|---|---|
| 1 · Start from an authenticated account | Require a current sign-in session, and step up authentication when the account's risk or policy requires it. | Event time, session reference and the authentication level used. |
| 2 · Prove present access to the new line | Send a short-lived challenge only after the user requests the change. Rate-limit attempts and accept each challenge once. | Challenge outcome and timestamp. Never retain the code in logs. |
| 3 · Bind the new route | Store the new authenticator association only after the challenge succeeds. Keep the previous route until the new one and a backup method both work. | Opaque new-authenticator reference and binding timestamp. |
| 4 · Notify through an independent route | Tell the account owner through an existing verified email, app session or other separate channel that a number was added or changed. | Notification channel and delivery time, without copying the secret. |
| 5 · Retire the old route deliberately | Let the user invalidate the old binding after confirming the new route and testing a separate recovery option. | Revocation time and the replacement authenticator reference. |
This ordering prevents a failed verification from silently replacing a working sign-in route. It also gives the user a way to notice an unexpected change before relying on a new number.
Recheck after number or device changes
A phone number is a reachable address, not an unchanging identity. When a subscriber changes SIM or device, ports a number, reports a lost line or starts a number-change flow, reassess whether a text message is an appropriate sign-in step. NIST specifically recommends considering these signals before using PSTN delivery of an authentication secret.
Offer at least one other sign-in method and encourage users to keep two separate means of authentication. A passkey, authenticator app or recovery codes can provide an alternate route; explain how the user can update or revoke each method. SMS and voice codes are not phishing-resistant, so do not present a phone number as a complete account-security solution.
A public discussion about losing access to a phone number after switching carriers illustrates the kind of migration question users ask. It is one anecdote, not evidence of how often lockouts occur or a rule for any provider.
Keep an audit event without logging the secret
Record lifecycle facts needed to investigate a binding, but keep the full phone number in the account's protected profile—not in ordinary application logs. Never log SMS contents, one-time codes or recovery secrets. The following example uses opaque references and makes the event inspectable without duplicating sensitive values.
{
"event": "phone_authenticator_bound",
"subscriberRef": "opaque-account-reference",
"authenticatorRef": "opaque-new-authenticator-reference",
"channelType": "pstn_sms",
"startedAt": "YYYY-MM-DDThh:mm:ssZ",
"verifiedAt": "YYYY-MM-DDThh:mm:ssZ",
"initiatingSessionRef": "opaque-session-reference",
"riskSignalsReviewed": ["device_change", "number_port"],
"independentNoticeSentAt": "YYYY-MM-DDThh:mm:ssZ",
"previousAuthenticatorRevokedAt": null,
"fallbackMethodVerified": true,
"phoneNumberLogged": false,
"oneTimeCodeLogged": false
}Track only risk indicators your application actually observed. Restrict audit access, define a retention period, and avoid inferring a user's identity from a number alone.
Questions about creating a phone number for sign-in
Can this generator create a phone number I can use for sign-in?
No. It provides synthetic test data. A mobile, landline or VoIP provider must assign a real line before it can receive calls or messages.
Does passing one SMS code prove I will control the number permanently?
No. It demonstrates access to a delivery route during that challenge. A later SIM, device, provider or number change should be handled as an authenticator lifecycle event.
Should I delete the old number before verifying a new one?
Keep the existing route until the new route works and a separate fallback has been tested. Then let the account owner revoke the old binding and notify them independently.
Can I use a generated number to test real account recovery?
No. A generated fixture cannot receive a real code. Test the interface and state machine with a non-delivery test provider; use a controlled, provider-assigned test line only when a live delivery check is necessary.
Sources
- NIST SP 800-63B: Authentication Using the Public Switched Telephone Network — number changes as authenticator binding, alternative authenticator types and risk indicators.
- NIST SP 800-63B: Authenticator and Verifier Requirements — binding lifecycle, independent account notifications and maintaining separate authentication methods.
- Public question about switching carriers and losing access to a 2FA number — one user's question used only as a topic signal, not a prevalence estimate or provider rule.