Hi! A verification loop after a phone number update usually means the account accepted the new number, but the sign-in flow is still enforcing a checkpoint that isn’t lining up (2-step verification, recovery phone mismatch, cached session, or SMS delivery issues).

We’ll keep it safe: no “spam retry,” no password roulette, and no removing recovery options while you’re locked out.

To narrow this down, tell me what you’re seeing in your own words:
1) Which service/app is this (Google, Apple ID, Microsoft, social, banking, etc.)?
2) What changed right before it started (new phone number, new SIM/eSIM, carrier switch, phone reset, travel)?
3) What does the loop do exactly — does it keep asking for an SMS code, bounce to “Verify it’s you,” or show “Try another way” but returns to the same screen?

Thanks — that’s a common pattern after a recovery phone / 2FA number change.

There are a few “buckets” that cause repeated verification prompts:
• Session/state issue: your browser session thinks you’re not fully verified, so it keeps re-triggering the challenge (cookies, multiple tabs, extensions, cached login state).
• Method mismatch: the account is still referencing an older number or a different verification method order (SMS vs Google Prompt vs backup codes).
• SMS code flow problem: the code arrives, but the backend doesn’t accept it due to timing, network switching, or a temporary security cooldown.

Quick clarifiers (no changes yet):
1) When you get the prompt, does it show the last digits of the new number (or the old one)?
2) Are you entering an SMS code, a Google Prompt, or an Authenticator code?
3) Did you attempt multiple times in a row, or switch VPN / Wi-Fi / mobile hotspot during attempts?

That helps: if the digits match the new phone number, the issue is less about “wrong destination” and more about the verification state not sticking (session routing) or a cooldown/rate limit from repeated attempts and network switching.

Two important safety notes before we do anything else:
• Don’t keep requesting new codes — that can extend cooldown windows and sometimes hides alternate recovery options.
• Don’t change the phone number again right now. Rapid changes can look like account takeover behavior and increase friction.

Let’s run low-impact diagnostics that don’t modify your security settings:

1) One clean session test: close all sign-in tabs, then try once in an incognito/private window. If you have extensions like ad blockers or privacy tools, keep them off for that single attempt (extensions can interfere with redirects).

2) Consistency test: use one network only (either Wi-Fi or hotspot, not both) and keep it steady during the whole sign-in attempt.

3) Time sync sanity check: confirm your laptop date/time is correct (auto time). Weird device time can cause code/verification tokens to be rejected even when the SMS arrives.

Good question. Even with SMS, the backend still issues a short-lived verification token tied to your session and device. If your device clock is way off or your session is unstable, the token exchange can fail and you get the “enter code again” loop — it’s not the SMS itself, it’s the session + token validation after you submit it.

About lockouts: you’re thinking the right way. A repeated two-step verification loop can turn into “try again later” if the system detects many attempts or mixed signals (switching networks, multiple browsers). So we’ll do controlled, minimal attempts.

On “Try another way” routing back: that often happens when the system decides SMS is the required path for that risk level, even if other recovery methods exist. Sometimes alternatives are temporarily hidden during a cooldown.

A couple of safe clarifiers:
1) Does the page ever mention “Too many attempts” or “try again later”?
2) Are you signing in with the same browser profile every time (or switching Chrome/Edge/Safari)?
3) Is your new number a normal mobile number, or is it a VoIP/Google Voice-style number? (Some services treat VoIP differently.)

eSIM changes can matter, yes — not always, but it’s a real factor in SMS code not received or delayed delivery. However, you’re receiving codes, so the stronger clue here is the “try again later” event plus the loop after code entry — that points more to cooldown + session/state than pure carrier blocking.

Here’s how I’d approach it safely, without guessing a “magic fix”:

• Step A (cooldown awareness): if you saw “try again later,” treat the account like it’s in a cooldown window. The safest move is fewer attempts, not more. Cooldowns can be vague (no timer) and can reset if you keep triggering it.

• Step B (session isolation): incognito is good because it removes “sticky” cookies and cached redirects that can keep looping you back.

• Step C (single-path verification): do one attempt on one stable network, then stop — and note exactly what happens after you submit the code (error text, page redirect, whether it re-asks immediately).

One more question that helps a lot for diagnosis: after you enter the code, does it briefly show “Signing in…” and then return to the same prompt, or does it instantly say the code is wrong/expired?

The “Signing in…” then bounce-back is the hallmark of a login redirect loop — it often means the code was accepted at one step, but the session didn’t finalize (blocked cookie, cross-site tracking restrictions, extension interference, or a stale sign-in state).

And yes: many services separate “recovery phone” from “2-step phone,” and sometimes also “device prompts.” Updating multiple fields isn’t necessarily bad, but it can make troubleshooting confusing because the screen might be referencing one method while policy enforces another.

Safe things to observe (without changing settings again):
• Do you have third-party cookies blocked in Chrome or strict privacy mode enabled? Some sign-in flows rely on cookies to persist verification state across redirects.
• Any security extensions (privacy, script blockers, antivirus browser add-ons) that could block redirects?
• Are you signing in from a workplace/school network that filters traffic or blocks certain auth domains?

If you can, try this controlled comparison (still low risk): one incognito attempt on your home Wi-Fi, and one incognito attempt on your phone hotspot — but not back-to-back rapidly. The point is to see whether one network consistently fails at the “state sticks” step.

Based on your description, the strongest “most likely” diagnosis is a session/cookie state problem combined with cooldown sensitivity from repeated attempts — especially because you see “Signing in…” and then it loops without calling the code wrong.

Secondary possibilities (still plausible, but less strong given your symptoms):
• Temporary security enforcement after a number change (some systems apply extra checks right after updating a phone number).
• Network switching during sign-in, which can invalidate the verification token even if the SMS arrives.
• Carrier filtering or delayed SMS, but usually that shows as “no code received” rather than “accepted then loop.”

For travel risk: consistency helps. If you can stabilize sign-in on one device/network before you travel, you reduce the chance of escalated prompts later. The main thing is to avoid lots of attempts and avoid bouncing between browsers/devices while the account is already in a sensitive state.

You’re welcome. If the behavior changes (for example, “Try another way” starts offering a different method, or the cooldown message disappears), that’s useful signal that the account state is shifting. Keep attempts controlled, and treat any unexpected messages asking you to share codes or passwords as a red flag.