How long do 2FA codes last?

A code from an authenticator app lasts 30 seconds. A code sent by text message or email usually lasts between 5 and 10 minutes. These are two different kinds of code on two different clocks, which is why both numbers are quoted as the answer. The 30 seconds comes from RFC 6238, the standard that authenticator apps such as Google Authenticator and Microsoft Authenticator use to calculate their codes. The minutes are set by whoever sends the message: the US standards body NIST says a texted code must be used within 10 minutes, Twilio's verification service, which sends codes on behalf of many apps, defaults to 10, and Okta's text codes last 5. Backup codes are different again: each one works once.

Every kind of code side by side

The table gathers the limits from the standards and from the documentation of the services that issue codes for other companies. Read the last column as well as the second: the time printed in an app or a message is not always the time the server actually allows.

Why you hear both 30 seconds and 10 minutes

The two answers describe codes that are made in completely different ways.

An authenticator app does not receive anything. When you scan the QR code during setup, your phone and the service each keep a copy of the same secret. Every 30 seconds the app combines that secret with the current time and works out a six digit number; the server does the same sum with its own copy and its own clock. The 30 seconds is built into the calculation itself. The setup side of this, including how to keep a second copy of that secret, is covered in setting up an authenticator app with working backups.

A texted or emailed code is the opposite. The server makes up a random number, stores it with an expiry time, and sends it to you. How long it lasts is a policy decision, and the people making that decision have to allow for a message that arrives late, a phone in another room, and a person typing slowly. That is why these codes are measured in minutes, and why the figures cluster at 5 and 10: NIST sets 10 as a ceiling, and the big code providers sit at or under it.

So neither number is wrong. The mistake is applying one to the other, for example assuming a texted code is dead after half a minute and asking for three more.

The real window for an app code

The countdown in your authenticator app is not quite the deadline. RFC 6238 points out that a code typed at the very end of its 30 seconds can reach the server after the next step has started, so it recommends that servers allow at most one step back for network delay. In practice, a code that turned over a moment ago usually still works.

Servers can go further to cope with phones whose clocks drift. The same standard describes a server that also accepts codes from two steps back, which it says tolerates a drift of about 89 seconds, and a server that records how far your device runs fast or slow and corrects for it from then on. Microsoft publishes its numbers: Entra ID, the sign-in system for work and school Microsoft accounts, accepts a code up to 1 minute either side of the correct time for a 30 second token, and up to 2 minutes for a 60 second one.

The flip side is that outside that tolerance every code fails, however quickly you type it. A phone whose time is set by hand and has drifted a few minutes will produce codes that look perfectly normal and are always rejected. Google's troubleshooting list for its authenticator starts with exactly this: the time on your device must be synced and correct for your local time zone.

One use, and what a resend does

A code that is still inside its time limit is not reusable. RFC 6238 says a server must not accept the same code a second time after it has been accepted once, and NIST requires the same for both app codes and texted codes: a code is valid only once during its validity period. If you sign in on a laptop and then try the same code on your phone a few seconds later, the second attempt fails even though the 30 seconds have not run out. Wait for the next code.

Pressing resend behaves differently from service to service. With Twilio Verify the code stays the same for its whole validity period until it is used, so a second request inside the 10 minutes sends you the identical number again. If they show different digits, use the newest, because a service that issues a fresh code may cancel the earlier one.

A short life does not make a code safe to share. Fake sign-in pages pass your password and your code to the real site as you type them, which is why phishing that captures codes still works against text and app codes alike, and why a caller who asks you for one is running a scam, as described in how phone scams and spoofed numbers work.

Where these numbers stop applying

Every lifetime above is a default or a ceiling. Most banks and shops do not publish the lifetime of the codes they text you, and the NIST guideline is written for US federal agency systems, so they are not bound by its 10 minutes. Twilio lets its customers stretch codes to as long as 24 hours, so a code that still works after an hour is unusual but not a sign of a fault.

The app figures assume the 30 second standard. Some hardware tokens use 60 seconds, and an app that respects a site's settings can show a different period, although Google Authenticator does not. The tolerance either side is also the server's choice: Microsoft states its window, most consumer services do not, so treat "the previous code usually still works" as common behavior, not a guarantee.

Backup codes sit outside all of this. Google gives its codes no time limit, but other services may treat theirs differently, so check the page where you generated them.

These figures are taken from the standards and provider documentation as published in October 2026.

What to do with this

1. Prefer the app over text messages. App codes never arrive late and do not depend on your phone number. NIST's "restricted" label for text and call codes reflects their weaknesses, set out in what each second factor resists.
2. Let your phone set its own clock. Automatic date and time fixes the commonest cause of "invalid code" from an authenticator app.
3. Use a texted code promptly, and only the newest one. Request another after five minutes rather than retrying an old one.
4. Keep your backup codes somewhere real. They are the codes that do not expire on a timer, so they are what gets you in when the phone is gone. Setting up account recovery before you need it covers where to keep them.
5. Watch the number your codes go to. A texted code is only as safe as the number it is sent to, and a number you give up can belong to someone else about six weeks later, which how long before a phone number is reassigned explains.
6. Where a site offers passkeys, use them. A passkey has no code to expire, copy or read aloud, which is why passkeys close the gap that short-lived codes leave open.

Start with your main email account, because it can reset almost everything else, and the settings worth changing there are in locking down an email account.