What to Do When You Get a Sign-In Code You Didn't Request
Keep an unexpected sign-in code to yourself. If an authentication app asks you to approve a request you did not start, deny it. Then open the account through its usual app or a saved address and review what happened.
A sudden code can be unsettling, especially when it arrives with a call claiming your account is under attack. You do not need to solve the mystery before refusing access. Start by keeping the code private and leaving unfamiliar requests unapproved.
Work Out What You Received
Three different things can look like the same security interruption:
- A verification code: a temporary credential delivered by text or email for a sign-in, recovery, or another account action.
- An approval prompt: a request inside an authentication app to confirm an action, sometimes by matching a number.
- An activity notice: a message saying that a sign-in or account change has already happened.
The distinction matters. Withholding a code can block an action that needs it. Denying a prompt refuses that request. Neither reverses an earlier successful sign-in, so a notice about completed activity deserves an account review even when it asks for no response.
Read which service, account, and action are named, without following message links. An authentication app can contain personal and work accounts with similar names. The account you need to investigate might not be your main inbox.
An Unexpected Code Does Not Prove Your Password Was Stolen
Someone may have entered your phone number or email address by mistake. A code you requested earlier may have arrived late. Another person might also be trying to access or recover your account.
Authentication methods vary. Some requests follow a password; others belong to passwordless sign-in or recovery. Google prompts, for example, can support sign-in instead of a password, an additional verification step, or account recovery. The notification alone cannot tell you that someone knows your password.
Do not reply to explain a possible typo or send the code to someone who says it belongs to them. Let an unrequested code expire. If you need to sign in yourself, begin a fresh attempt through the service's normal route and follow that attempt's instructions.
Check the Account Independently
Close the unexpected message and open the service's established app or a bookmark you already trust. Avoid its sign-in button, callback number, or a search advertisement offering urgent recovery help.
In the account's security settings, look for recent activity, security events, and signed-in devices or sessions. Compare the time and type of activity with what you were doing. Separate failed attempts from successful access and check for changes to recovery details or authentication methods.
A location or device label is a clue to investigate. Mobile networks and VPNs can make locations unfamiliar, and one device can create several sessions. Background activity can also affect displayed times. Read the available details before deciding that an unfamiliar entry belongs to an intruder.
If the review identifies an unauthorized attempt, follow the provider's security instructions, including changing your password where recommended. Use a new, unique password if the old one may be exposed. Change it on other accounts where you reused it as well.
If you cannot sign in, use the provider's account recovery process reached independently. For a work account, contact IT through your existing support channel and report the account, approximate time, and kind of request. Keep actual codes out of tickets and messages.
Never Approve a Request to Make the Alerts Stop
Repeated approval requests can be an attempt to wear you down until you accept one. This is often called MFA fatigue or push bombing. Deny unfamiliar requests and investigate rather than approving one out of frustration.
Do not disable your second factor or remove your only working authentication method to silence the interruptions. Report persistent requests to the provider or your work administrator. Ask what account protection and authentication options are available.
Number matching adds a deliberate check, but the source of the number still matters. Use only the number from an action you initiated on the genuine service. A caller reading out a number, sending a screenshot, or asking you to select a particular option does not make their request yours.
While investigating, you may trigger a legitimate prompt yourself. First deny the unfamiliar requests. Then confirm the exact account and action for your new attempt, including the displayed number where applicable. If you cannot distinguish the prompts, stop and use another established sign-in method or seek support.
Treat a Follow-Up Caller as a Separate Trust Decision
A person may contact you immediately after the code arrives and claim to be stopping fraud. They might know your name or correctly describe the service. Those details do not establish that they work for it.
Do not read out a login code, forward it, share your screen, or approve a prompt for the caller. End the conversation and contact the service using a number from its trusted app or an existing statement. Do not use contact details supplied during the unexpected exchange.
A genuine code can be part of a fraudulent conversation. Its arrival proves that a process generated a code, not that the person asking for it is entitled to use it.
If You Already Shared a Code or Approved
Act promptly. A short code lifetime does not mean access ends when the code expires. Someone may already have established a session or changed an account setting.
From a device you trust, open the service independently. Change an exposed password and use the account's controls to end unrecognized sessions. Review recovery addresses, phone numbers, registered authentication methods, and connected apps. Do not assume changing a password automatically removes every other route into the account.
If you entered information on a suspicious page or installed something at the caller's request, follow the guide on what to do after clicking a phishing link. Tell work IT or the provider what you supplied and what you approved so they can assess the actual exposure.
For an email account with successful unauthorized access, also check forwarding rules, filters, sent messages, and linked accounts. The guide to recovering a hacked email account covers that broader cleanup. Contact a financial provider promptly if an approval involved a payment or its account.
Make Future Requests Easier to Judge
Once the account is secure, review its available sign-in methods. Where supported, passkeys or security keys using FIDO authentication can reduce exposure to phishing that tricks people into relaying codes. Check what the service offers and which recovery options remain enabled.
Before retiring a working method, set up and test its replacement. Keep recovery material accessible independently of the device you might lose. The guide to setting up passkeys without losing access explains how to plan those fallback routes.
Make approval a deliberate part of a task you started. When a request arrives without that context, deny or withhold it, check the account through a trusted route, and respond to the activity you find.