When a TOTP code is not working, first enable automatic date and time, confirm you selected the correct authenticator entry, and wait for a fresh code. If every new code fails, the account may have a different enrolled secret or excessive clock drift. Never send the QR code or secret to support.
Why TOTP code not working is a specific problem
TOTP combines a shared secret with a counter derived from current Unix time. The service usually accepts the current time step and sometimes a small neighboring window. A clock that is far ahead or behind produces a valid-looking code for the wrong counter.
Account labels can also mislead. Two entries may have the same service name while belonging to different usernames or an older enrollment. Retrying the wrong entry never succeeds even when the clock is perfect.
The practical approach
Change one variable at a time: time sync, entry selection, code rollover, then recovery. Avoid repeatedly changing device settings or re-enrolling without recording which secret the server expects.
If you manage the server, log acceptance reason categories without logging secrets or submitted codes. Review drift windows carefully because a very wide window weakens replay resistance.
Step-by-step workflow
1. Turn on automatic time and timezone.
2. Confirm the authenticator label and username.
3. Wait until a new code is fully visible.
4. Try once and avoid replaying the same value.
5. Use a recovery code or reset enrollment through the official account flow.
Turn the workflow into verifiable evidence
A useful result for TOTP code not working should be reproducible by another authorized person. Use this compact review record instead of relying on memory, screenshots without context, or a single green status message:
1. Turn on automatic time and timezone. Write down the starting state, responsible person, expected evidence, and a safe rollback before acting. This prevents a later success from being confused with an unrelated change and gives support a useful timeline without exposing credentials.
2. Confirm the authenticator label and username. Capture a timestamp and a non-secret correlation value, then define what a pass and failure look like. Keep passwords, active codes, complete authentication links, and private message content out of the record.
3. Wait until a new code is fully visible. Perform this step once under controlled conditions and observe every system it touches. If the result differs from the expectation, stop changing other variables until the first unexplained difference is understood.
4. Try once and avoid replaying the same value. Repeat the check from an independent session, device, resolver, or receiving account when that is relevant. Independent evidence distinguishes a cached interface result from the real behavior another user will experience.
5. Use a recovery code or reset enrollment through the official account flow. Record the final state, remaining risk, owner, and review date. Delete temporary evidence that contains sensitive data and keep only the operational facts needed for maintenance or an authorized audit.
What to verify before relying on the result
Test whether the same authenticator entry works on another properly synchronized device only if the secret was securely backed up. A mismatch between devices suggests different stored seeds.
Confirm recent password resets, security changes, or administrator actions did not revoke the TOTP enrollment.
Common mistakes to avoid
- Sharing the setup QR in a support ticket.
- Typing a code as it rolls over.
- Using an entry from an old account.
- Widening server drift indefinitely to hide a clock problem.
Security, privacy, and product boundaries
A TOTP code is sensitive during its short lifetime, and the secret is sensitive until enrollment is replaced. Redact both from logs, recordings, and screenshots.
If recovery is unavailable, follow the service’s identity process. A third-party generator cannot reconstruct a lost secret from old codes.
How TempMail Cloud fits this workflow
TempMail Cloud’s browser-local generator can help verify whether a known secret and device clock produce changing codes, but do not paste production secrets into an untrusted device.
The tool does not contact the account service, so it cannot determine which secret that service currently stores or reset enrollment.
Frequently asked questions
Does timezone matter?
TOTP uses absolute time, but incorrect clock synchronization can still break codes even when the displayed timezone looks right.
Can I use an old code?
Usually no. Codes expire quickly and servers limit accepted time windows.
Can support ask for my secret?
They should not need it. Use official recovery or re-enrollment procedures.
Related TempMail Cloud guides
Use the receive-only inbox, review our safety guidance, and read our editorial standards before relying on any temporary address for an important workflow.