2FA Code Not Working: Common Causes and Fixes

Your password works.

Your authenticator is showing a six-digit code.

You enter it exactly as shown — and the website says:

Invalid code.

For TOTP-based 2FA, there are only a few pieces that determine the code. The fastest way to troubleshoot the problem is to check those pieces in the right order.

Start here:

1. wait for a fresh code
2. make sure it belongs to the correct account
3. check your device time
4. confirm the 2FA secret
5. check whether the account was re-enrolled
6. verify the TOTP configuration

If you still have the original Base32 secret, generate a fresh code with the 2FA Code Generator and compare the result with your authenticator.

Start with a fresh code

The first check is the simplest.

Do not submit a TOTP code when its countdown is almost finished.

Most common TOTP setups use a 30-second time window. A code can therefore be correct when you copy it and already belong to the previous window by the time the website verifies it.

If the timer is nearly at zero:

wait for the next code, then submit it immediately.

This is especially useful when you need to switch between devices, copy and paste manually, move between browser tabs, or type the code rather than paste it.

If a fresh code works, nothing was wrong with your secret or authenticator. You were simply too close to the end of the previous TOTP window.

Make sure you are using the code for the right account

This sounds obvious until an authenticator contains twenty entries.

You may have:

GitHub — work@example.com
GitHub — personal@example.com
GitHub — old-work@example.com

All three entries generate convincing six-digit codes.

Only one belongs to the account you are currently signing in to.

Check:

• service or issuer name
• email address
• username
• workspace or organization
• whether an older 2FA entry still exists

A code does not become obviously “wrong” when it belongs to another account. It still looks exactly like a normal TOTP code. The mismatch only becomes visible when the server rejects it.

Check the device clock

TOTP literally contains the word time for a reason.

The authenticator and the service do not exchange every new six-digit code with each other. Instead, both sides calculate the code independently from the shared secret and the current time.

If their idea of the current time differs enough, they may calculate different codes.

The simplest fix is to enable automatic time synchronization on the device generating the code.

On iPhone

Check:

Settings → General → Date & Time → Set Automatically

On Android

The exact menu depends on the device, but look for:

Settings → System → Date & time

and enable automatic date, time and time zone settings.

Then wait for the next TOTP code and try again.

A note about current Google Authenticator versions

Older troubleshooting guides often tell Android users to open Google Authenticator and select:

Settings → Time correction for codes → Sync now

That advice is outdated for current Google Authenticator releases.

Google states that the old time-correction setting is no longer available in version 7.0. Current versions use the operating system’s time setting.

So if you use a recent Google Authenticator version, correct the device time rather than looking for a menu option that may no longer exist.

Check the 2FA secret

If time is correct and fresh codes still fail, look at the secret.

A TOTP setup depends on the authenticator and the service sharing the same secret.

A Base32 secret may look like:

JBSWY3DPEHPK3PXP

If the service expects one secret while your authenticator uses another, both sides will generate completely different code sequences.

This can happen when:

• the secret was copied incorrectly
• a character was missing
• the wrong account’s secret was used
• an old setup key was saved
• 2FA was enrolled again later

If you still have the original setup information, compare it with the credential stored in your authenticator.

A full otpauth:// URI can be especially useful because it may contain not only the secret but also the account label and TOTP configuration.

For more detail on what the secret actually is, read 2FA Secret Keys: What They Are and Where to Find Them.

An old secret can still generate perfectly normal codes

This is one of the most confusing 2FA failures.

Suppose you originally enabled 2FA with Secret A. Later, you disabled 2FA and enrolled it again. The service now creates Secret B.

Your old authenticator entry does not know that anything changed. It can continue generating values such as 482913, 193205 and 728114. Those codes look completely normal.

But the website is calculating its expected codes from Secret B, while the authenticator is still using Secret A.

No amount of waiting will make the old sequence start matching again.

If the problem began immediately after resetting 2FA, scanning a new QR code, migrating an account, changing authentication settings, or re-enrolling an authenticator, check whether you are still using the old credential.

Compare two authenticators if you still have the secret

If you have the original TOTP secret, generating the code in another compatible implementation is a useful diagnostic step.

For example:

Authenticator app: 482913
EnvTrace:           482913

If two independent TOTP implementations produce the same result from the same secret at the same time, that is a useful sign that the local TOTP calculation is consistent.

If the website still rejects the code, the problem may be an old secret, a different account, different TOTP parameters, or account state on the service itself.

If the two generators instead produce different codes, check the secret, time and TOTP configuration before blaming the service.

EnvTrace accepts Base32 secrets and supported otpauth:// input in the 2FA Code Generator.

Check the TOTP settings

Most users never need to change TOTP parameters manually. That is good. The QR code or otpauth:// configuration normally carries the information an authenticator needs.

But TOTP is not limited to one exact configuration.

Important parameters can include:

• algorithm
• number of digits
• time period

Many services use SHA-1, 6 digits and 30 seconds. Those values are common defaults, not universal laws. A service can use another supported configuration.

For example, an otpauth:// URI may contain information such as:

algorithm=SHA256
digits=8
period=30

If one implementation generates 6 digits / SHA-1 / 30 seconds while the service expects 8 digits / SHA-256 / 30 seconds, the codes will not match.

This is another reason importing the full QR code or provisioning URI is safer than manually guessing configuration values.

If you want the underlying TOTP model explained first, read TOTP Explained: How Time-Based 2FA Codes Work.

Do not confuse TOTP with another verification method

Not every field labeled “verification code” is asking for a TOTP.

A website may instead request:

• SMS code
• email code
• push approval
• recovery code
• backup code
• hardware security key
• passkey

A TOTP generator cannot create those credentials.

Read the login screen carefully.

If it says something like “Enter the code from your authenticator app”, then a TOTP code is probably what the service expects.

If it says “We sent a code to your email”, then generating another TOTP will not help.

The problem is not that your TOTP code is wrong. It is that the website is asking for a different type of credential.

Clearing cookies or changing your VPN usually does not fix a TOTP mismatch

Many generic login troubleshooting guides recommend clearing browser cache, changing browser, disabling a VPN, or restarting the router.

Those steps can sometimes affect a website session or a provider’s own security checks. They do not change the basic TOTP calculation.

A TOTP code is determined by the secret, time and configuration. Changing your IP address does not suddenly make a wrong TOTP secret produce the right code.

So separate two different problems:

Problem A: the TOTP code itself does not match

Check time, secret, account and parameters.

Problem B: the website refuses the login for another reason

Then browser state, IP restrictions, account risk controls or provider-specific policies may matter.

Do not mix these into one diagnosis.

Why two authenticator apps may show different codes

If two apps are configured with the same current secret and the same TOTP settings, their codes should normally match for the same time window.

If they do not, compare:

The secret

The apps may not actually contain the same enrollment.

The account

One app may still contain an older entry.

Device time

A clock mismatch can put the apps into different windows.

Digits

One configuration may generate six digits while another expects eight.

Algorithm

The configurations may use different HMAC algorithms.

Period

The time-step length may differ.

Two different codes are therefore useful evidence. They tell you that something about the local TOTP inputs is not the same.

What if EnvTrace generates a code but the website still rejects it?

Generating a six-digit number only proves that a secret can be interpreted as TOTP input.

It does not prove that the target service currently has the same secret registered for that account.

This distinction matters.

Imagine you paste an old secret into a generator. The generator can still calculate 391204. That number can be mathematically valid for that secret. But if the website now stores another secret, 391204 is useless for that account.

So when a locally generated code looks normal but is consistently rejected, ask whether this is definitely the secret currently registered with this exact account.

That is usually more useful than repeatedly generating another number.

When to stop troubleshooting the code

There is a point where generating more codes no longer helps.

Stop treating the issue as a local TOTP problem if:

• you no longer have the current secret
• the account was re-enrolled and the old secret was replaced
• your authenticator entry was deleted and cannot be restored
• the provider is asking for another verification method
• the account itself is locked
• the service says you must use account recovery

At that point, use the recovery options provided by the service.

Depending on the platform, that may include recovery codes, another registered authentication method, a security key, a passkey, a previously verified device, or an official account recovery process.

Recovery options are provider-specific. For example, GitHub documents recovery codes and other enrolled recovery methods for users who lose their normal 2FA credentials.

A TOTP generator cannot reconstruct a secret that the service no longer uses.

A useful troubleshooting order

If your authenticator code is being rejected, use this order rather than trying random fixes:

This order matters because each step tests a real part of the authentication process.

If you still have the current Base32 secret, you can use the 2FA Code Generator to generate a fresh TOTP code and compare the result before moving on to account recovery.