Independent guide. login.com is an independent educational resource. We are not affiliated with, endorsed by, or connected to the services described. Always sign in only on the service's own official website.
Last reviewed: 2026-08-17 · Report a change
Short answer
What to know before you start
A 2FA code is a short-lived or single-use value used in an authentication flow. It may come from an authenticator app, SMS, email, a trusted device, or a saved recovery set. Enter it only on the verified service after starting the action yourself. A caller or message asking for the code may be completing an attacker’s sign-in.
01 · decision point
Not every code is generated the same way
A TOTP authenticator combines a shared secret with the current time and usually produces a new number every thirty seconds. SMS and email values are generated by the service and delivered through a messaging channel. Device codes may authorize one screen from another device. Recovery codes are commonly static, single-use bypass secrets prepared in advance. The values can look similar even though their security, delivery, expiration, and replacement rules are different.
Read the prompt and identify the event: sign-in, new device, password reset, payment confirmation, authenticator enrollment, or recovery. A code proves only the action the service assigns to it. It does not prove that the person requesting it is support, that the page is genuine, or that an unexpected transaction is safe. Treat every current code as confidential until the official flow is complete.
02 · decision point
Short expiration does not prevent real-time phishing
An attacker can place a copied sign-in page between the user and the genuine service. The fake page forwards the password, asks for the current code, and relays it before expiration. Automated phishing kits can complete that exchange in seconds and may steal the resulting session cookie as well. A six-digit value becoming useless later does not protect it during the window when the service will accept it.
Check the registered domain before entering the password or code. A brand word in the path or subdomain is not enough, and HTTPS only protects the connection to the displayed host. Password managers can provide a mismatch warning when they refuse to fill. Passkeys and FIDO security keys offer stronger resistance because the authenticator verifies the real domain instead of relying on the user to recognize every lookalike.
03 · decision point
Unexpected codes are signals, not instructions
A code arriving without an action can mean someone mistyped a phone number or email, but it can also mean an attacker knows the account password and reached the second step. Do not reply, call a number in the message, or give the value to someone claiming to cancel the attempt. Open the service through a known route, change a possibly exposed password, inspect active sessions, and review recovery and authentication settings.
Unexpected push prompts deserve the same response. Deny the request and report it through the service or organization's trusted channel. Repeated approval requests can be MFA fatigue. If a caller says tapping Approve will stop the prompts, that is the opposite of safe behavior: approval can complete the sign-in. Administrators should use number matching and phishing-resistant methods while still teaching users to reject actions they did not start.
04 · decision point
Backup and recovery codes require stronger storage
A recovery code may bypass the everyday authenticator and remain valid until used or regenerated. Store it like a high-impact password, not like a routine note. Keep it reachable if the normal phone, mailbox, or password manager is lost, but do not expose it in screenshots, shared documents, or support chats. Know whether the service issues a set of one-time values or one rotating backup code.
After using a recovery code, mark it used and follow the service's instructions. Generating a new set often invalidates the old one, so update protected copies. If a code was entered on a suspicious page, assume it may be consumed immediately. Recover the account from the real service, replace the password and backup set, revoke sessions, and inspect new devices or authentication methods that an attacker may have registered.
Practical sequence
Use this checklist before changing the account
- 01
Identify which action and account the code is authorizing.
- 02
Verify the registered domain before typing a current value.
- 03
Never read a code to an unsolicited caller or chat contact.
- 04
Deny pushes you did not initiate and investigate independently.
- 05
Store recovery codes away from the normal device and account.
- 06
Replace exposed codes, sessions, passwords, and recovery details.
Side-by-side comparison
Compare the relevant trade-offs
| Code type | Created by | Typical lifetime | Main risk |
|---|---|---|---|
| Authenticator TOTP | App plus shared secret and time | About 30 seconds | Real-time relay by a fake page |
| SMS or email OTP | Service and delivery channel | Minutes | Mailbox, carrier, or code phishing |
| Device authorization code | Service linking two screens | Short session | Entering it for someone else's device |
| Recovery code | Service during setup | Until used or replaced | Static bypass secret exposed in storage |
Common questions
2FA codes explained: use, phishing, and recovery FAQ
Can support ask for my 2FA code?
A live authentication or recovery code should be entered only into the official service flow you initiated, not read to a caller or chat agent.
Why did I receive a code without signing in?
It may be a mistake or an attempted account entry. Do not share it; open the service independently and review the account.
Are authenticator codes phishing-resistant?
No. TOTP avoids the SMS channel but can still be relayed. Passkeys and FIDO security keys are designed for verifier-domain binding.
Continue on login.com
Related independent guidance
Primary-source ledger
Official documentation reviewed
Product features, plan packaging, and interfaces can change. The claims above are limited to the official documentation linked here and the review date shown on this page. Recheck the live provider material before changing a high-impact account or buying a subscription.
- NIST SP 800-63B-4: Out-of-band and OTP authenticators ↗Checked 2026-08-17
- CISA: Implementing phishing-resistant MFA ↗Checked 2026-08-17