OTP Arrived but Is Invalid or Expired: What to Check

Quick answer: when an SMS arrives but the app rejects its code, investigate the verification request rather than treating the problem as missing delivery. Confirm the account, purpose and active screen; use the code applicable to that request; and respect the service's expiry and retry instructions. Do not forward a code to support or ask another person to enter it for you.

Identify the challenge that is actually open

A login, password reset, phone-number change and transaction approval can all send codes. Similar-looking messages do not make their codes interchangeable. Before typing anything, read the action described on the page and in the message. If the action is unexpected, stop and open the service independently.

Consider a customer who begins a login on a laptop, requests another code on a phone, and then returns to the first tab. Both devices may show the same account name while holding different challenge contexts. The latest message in the inbox is useful only if it belongs to the challenge being completed.

This guide concerns a received message. If no message appears at all, start with our separate missing SMS verification guide.

Reconstruct the sequence without collecting codes

Use a small timeline with labels rather than copying secrets:

This exposes a common confusion: message arrival order is not necessarily request order. A delayed first message can appear after a later one. Notification stacking can also foreground an older message. Read the message context rather than assuming that the top notification is the correct choice.

Use the newest applicable code, with an important caveat

Some services invalidate an earlier code when a replacement is requested; others keep a challenge token stable within their configured window. Do not assume either behavior for every platform. Follow the current service's instructions and avoid cycling through a backlog of old messages.

Google's verification troubleshooting explains that, for its flow, only the newest of several requested codes works. That is a platform-specific rule, not a universal promise about all SMS systems.

Once you identify the current request, submit deliberately once. Repeatedly guessing codes creates extra failures without establishing whether the original problem was expiry, context or a typo.

Check entry errors without changing the secret

Autofill can suggest a code from a different recent message. A clipboard can contain a trailing space or an unrelated value. Check that the field contains the expected number of characters and that the suggestion came from the message you intended to use.

Pasting is not inherently wrong. Do not follow blanket advice to disable paste, and do not alter a code by removing zeros or reordering digits. If the form separates digits into boxes, inspect whether the whole value was distributed correctly before submitting.

For your own application, test both paste and manual entry with synthetic codes. An input that silently drops the first digit creates an apparent authentication failure even when delivery and server validation are functioning correctly.

Respect expiry and the service's timer

An SMS timestamp is not a reliable statement of when the server created its challenge. Time may have elapsed before delivery or before the message became visible. Do not invent a universal five-minute or ten-minute expiry rule; use the timer and help text of the service involved.

NIST's authentication guidance treats one-time secrets as controlled authentication material with limited acceptance and replay protections. A message remaining readable in an inbox does not mean its secret remains usable.

Changing your phone's clock generally does not revive an expired server-issued SMS challenge. Clock synchronization is a different consideration for time-based authenticator apps.

Close the loop safely before starting again

If you cannot determine which request is active, stop submitting codes. Use the app's official restart or recovery path when available, then begin a single coherent attempt after any displayed restriction ends. Keep the intended screen open and avoid opening parallel login sessions during that attempt.

Microsoft's official troubleshooting distinguishes verification problems and repeated-request restrictions. Apply its instructions to Microsoft accounts rather than treating every service as identical.

If you use a PhoneBorn retained number, receiving the message establishes receipt in the number's inbox; the requesting app still decides whether the code is acceptable. The PhoneBorn facts page provides product scope without promising universal compatibility.

Send evidence that helps support diagnose the stage

A useful report says that the message arrived, identifies the requested action and approximate timeline, and includes the redacted error. It does not include the OTP, a password, a session cookie or a recovery link.

For example: “Login code requested in one browser tab; message appeared afterward; submission showed expired code. No further attempts made.” That gives support a sequence to investigate while preserving the secret. Keep code entry separate from support communication, even if the code seems expired.

If the screen is asking for an authenticator code or recovery code instead, an SMS inbox is the wrong tool. Our comparison of authentication methods explains the broader distinction.

Frequently asked questions

Should I request several codes to improve my chances?

No. Parallel requests make ordering and active-session diagnosis harder and may trigger restrictions.

Can an expired code become valid if I change the clock?

Do not expect that for a server-issued SMS challenge. Follow the requesting service's expiry and restart instructions.

Does a rejected code mean my number is unusable?

Not necessarily. Delivery succeeded; expiry, entry, challenge context or another validation rule may explain the rejection.