If an approval request appears on your phone and you are not actively signing in, deny it or let it expire—never approve it just to stop the noise. An unexpected prompt is a warning, not automatic proof that an intruder is already inside. Your next job is to check the account through a trusted route and determine whether the attempt stopped at the second factor or became a successful sign-in. [1] [2] [3]
Guidance checked: September 20, 2026 at 1:29 p.m. EDT / 17:29 UTC.
The problem in plain English
Multifactor authentication (MFA) is supposed to require something beyond a password. An attacker who has a password—or is trying a passwordless sign-in flow—may still need the account owner to approve a phone prompt. Repeated prompts can pressure a tired or distracted person into tapping the wrong button. [1] [2] [3]
Microsoft Authenticator now uses number matching for its push notifications: the user sees a number during the sign-in and must enter that number in the app to complete approval. Microsoft calls number matching a security upgrade over traditional second-factor notifications. [1] Google prompts can show the device, approximate location, and time of the sign-in attempt, and Google tells users who did not initiate the sign-in to tap No. [2]
The costly mistake is treating the prompt as a nuisance instead of a security event—or panicking and resetting random settings before preserving what happened. Use the ordered response below: deny → document → review activity → contain if warranted → harden the sign-in path. [1] [2]
Who is affected—and what an unexpected prompt does not prove
Treat this as suspicious
- You receive an account approval request without starting a sign-in. [1] [2]
- The same account generates repeated prompts or number-match requests. [1] [2]
- A prompt follows an unsolicited call or message telling you to approve a supposed “IT,” “fraud prevention,” or “test” sign-in. [1] [2]
- A work-account activity record shows a successful unfamiliar sign-in or says primary credentials succeeded but additional verification failed. [3] [4] [5]
Do not jump to conclusions
- A prompt you initiated on a second screen may be legitimate. [1] [2]
- Approximate location can be wrong because mobile and corporate networks route traffic through other cities. [3] [4]
- An expired prompt can represent an unsuccessful attempt rather than account entry. [1] [2]
- An unexpected prompt alone does not prove the password was accepted, the attacker entered the account, or the phone itself is infected. [1] [2] [3]
For Microsoft work or school accounts, the activity details matter. Microsoft says an entry labeled “Additional verification failed, invalid code” means the primary authentication credentials succeeded but the two-step verification challenge failed; Microsoft recommends changing the password because the attacker might already have it. [4] A plain unsuccessful sign-in can also be a typo or password-guessing attempt, so read the result rather than inferring it from the push notification alone.
Stop condition: if you accidentally approved
Assume the risk is higher. From a separate trusted device, review recent sign-ins, change the account password to a new unique password, notify the organization’s administrator or help desk, and ask that suspicious work-account sessions be revoked. Do not keep approving follow-up prompts, read numbers to a caller, or let anyone remotely control the phone or computer. [1] [2] [4]
If the account controls email, payroll, banking, billing, cloud files, remote access, or administrator privileges, also check for financial or customer-impacting activity. An approved prompt does not prove every connected service was reached, but it removes the protection you were relying on for that attempt. [1] [2] [4]
The seven-step response ladder
Deny the request—or let it expire
If you did not start the sign-in, choose Deny, No, or the service’s equivalent. Do not enter a number that appears on somebody else’s screen, and do not approve merely to make repeated notifications stop. Google’s official prompt guidance says to tap No when you did not try to sign in. [2]
If the app offers “Report,” “This wasn’t me,” or a similar choice, use it when you are certain the request is not yours. If you are unsure whether a prompt belongs to a sign-in you just started, cancel both sides and begin again from a trusted bookmark or app. [1] [2] [3]
Preserve the useful details
Take a screenshot or photograph showing the service, account identifier, time, device, app, and approximate location—without posting the image publicly. Record whether the prompt was approved, denied, or expired; how many appeared; and whether a phone call or message preceded it. Google says its prompts may show device, location, and time specifically to help users spot suspicious activity. [2]
Location is a clue, not a verdict. Microsoft warns that IP-based locations can be approximate and that mobile networks may appear in another region. Compare the browser, operating system, application, time, and success result together. [4]
Open account security through a route you already trust
Do not follow a link from an unexpected email, text, or caller. Use a saved bookmark, type the vendor’s known address, or open the account’s official app. For a personal Microsoft account, review the Security basics and Recent activity pages. Microsoft says unfamiliar activity can be marked “This wasn’t me” or “Secure your account,” followed by a password change when access is suspected. [3]
For a Microsoft work or school account, use My Account → Recent Activity and expand each entry. The page can show whether someone guessed a password, successfully signed in, and which apps were targeted. [4] For Google, use Security Checkup, review recent security activity and devices, and follow the compromised-account flow if activity is unfamiliar. [6]
Classify what actually happened
- Prompt denied; no unfamiliar successful sign-in: preserve the evidence, monitor the account, and strengthen authentication. If the activity record shows that the correct password reached MFA, change that password now. [1] [2] [3]
- Unfamiliar successful sign-in: treat the account as compromised. Change the password, remove unknown devices or security methods, and revoke sessions through the vendor or administrator. [3] [4] [5]
- You approved the prompt: escalate even if no damage is visible yet. Review recent security activity, signed-in devices, and recovery information through the vendor’s official account-security page. [3] [6]
- The details match your own sign-in: cancel and retry if any doubt remains. Approval should be tied to a sign-in you can see and control. [3] [4]
A number match improves context, but it is not permission to type a number supplied by a caller. Microsoft’s workflow requires the number shown in the sign-in session to be entered into Authenticator. [1] If you are not looking at your own sign-in screen, there is no legitimate number for you to enter.
Change the password when the evidence crosses the line
Change the password immediately when you see an unfamiliar successful sign-in, an activity result showing primary credentials succeeded, an accidental approval, or repeated targeted prompts that cannot be explained. Use a clean, trusted device and a unique password that is not used anywhere else. Microsoft recommends changing the password when unauthorized activity appears; Google says to change it immediately when someone else may be signed in. [3] [6]
If the old password was reused, change the other accounts separately—starting with the recovery email and the services that can move money, reset other accounts, or administer the business. Google’s compromised-account guidance specifically warns about sites that share the Google Account password, use that email address, or store passwords in the account. [6]
For a work account, involve the administrator early
A user can deny a prompt and change a password, but organization-wide containment may require administrator evidence and controls. Send the screenshot, time, account name, result, and whether approval occurred through the company’s known support channel. An administrator can review sign-in activity, block new sign-ins, revoke refresh tokens, and determine which applications require their own session revocation. [4] [5]
Microsoft documents that Entra administrators can block new sign-ins and use Revoke sessions, but revocation is not magical or always instantaneous. Access tokens, refresh tokens, application-issued sessions, synchronization, and continuous access evaluation can affect when access ends; some applications control their own session tokens. [5] That is why “password changed” should not be the only box checked after a confirmed business-account compromise.
Remove persistence, then improve the login method
Review registered phones, security keys, recovery email addresses, app passwords, trusted devices, and connected applications. For a confirmed Microsoft 365 compromise, use the linked containment guide below to inspect mailbox rules, forwarding, app consent, and administrator changes in the correct order. Remove only entries you can identify as unauthorized, and document business integrations before revoking them. [5] [6]
Keep MFA enabled. Number matching is safer than a blind yes/no push because it binds approval to a visible sign-in number, and Microsoft has enabled it for Authenticator push notifications. [1] Where the service supports passkeys or security keys, consider a planned move after recovery, with tested backup methods so one lost phone or key does not lock out the account.
Good response versus dangerous shortcuts
Good
- Deny an unsolicited prompt. [1] [2]
- Capture the time, app, device, and result. [3] [6]
- Open security pages from a known route. [3] [4]
- Read the sign-in result instead of trusting location alone. [3] [4]
- Change a known-exposed password from a trusted device. [3] [6]
- Notify the administrator with evidence. [4] [5]
- Revoke confirmed unauthorized sessions and methods. [4] [5]
Bad
- Approve to stop repeated notifications. [1] [2]
- Enter a number dictated by a caller instead of one shown in a sign-in you initiated. [1]
- Click the alert email’s link without verification. [3] [4]
- Assume denial proves the password is safe. [3] [6]
- Assume a strange city proves compromise. [3] [4]
- Turn MFA off to stop the prompts. [1] [6]
- Change the password and ignore active sessions or app access. [4] [5] [3]
Two realistic examples
Expected prompt, confusing location
A bookkeeper signs in to Microsoft 365 from a new laptop and immediately receives a number-match request. The time, browser, and application match; the city is different because the internet provider routes traffic elsewhere. She cancels, opens the company portal from a bookmark, retries, and approves only the number shown on her own laptop. Nothing indicates an unsolicited attempt. [1] [2] [3]
Password reached the second factor
A manager receives three Authenticator prompts while eating lunch and denies all of them. My Sign-ins shows “Additional verification failed, invalid code” for an unfamiliar browser. Because Microsoft says that state means primary credentials succeeded, the manager changes the password from a trusted device and sends the evidence to the administrator, who reviews sign-in activity and revokes sessions. The denied prompts blocked the immediate attempt; the activity record drove the rest of the response. [4] [5]
Frequently asked questions
Does an unexpected MFA prompt mean my password was stolen?
Not always. An unexpected prompt alone does not establish how the sign-in started or whether a password was accepted. Review the official activity record. For Microsoft work accounts, “Additional verification failed, invalid code” specifically indicates that primary credentials succeeded but the second factor failed. [4]
Should I approve a prompt from “IT” during a phone call?
Use a strict practical rule: approve only a sign-in you initiated and can see on a device you control. In Microsoft’s number-matching flow, the number comes from the sign-in screen and is entered into Authenticator; a number supplied by an unsolicited caller is not tied to a sign-in you initiated. [1]
What if I denied the prompt—am I finished?
Denial may stop that approval, but it does not tell you how the request started. Review activity. If the password succeeded, if a sign-in was successful, if you approved anything, or if prompts keep returning, change the password and escalate. Check devices, security methods, connected apps, and sessions. [1] [2] [4]
Should I turn MFA off to stop the prompts?
No. That removes a barrier the attacker may already be failing to pass. Deny the requests, investigate the underlying account, and improve the authentication method rather than disabling protection. [1] [2]
Can I trust the city shown in the prompt?
Use it as one clue. Microsoft notes that IP-based location is approximate and mobile traffic can appear in another region. Compare time, device, browser, application, success state, and your own activity. [4]
Is changing the password enough for a business account?
Not after a confirmed successful sign-in or accidental approval. The administrator may need to revoke Entra sessions and separately identify applications that own their own session tokens. Microsoft explains that Entra cannot directly revoke a session token issued by an application. [5]
Actionable next steps
- Deny any approval request you did not initiate. [1] [2]
- Save the time, service, device, location, and result without sharing codes publicly. [3] [4] [6]
- Open the vendor’s security page from a trusted bookmark or official app. [3] [4]
- Review recent activity and distinguish a failed primary sign-in from a password that reached MFA or a successful session. [1] [2] [4]
- Change the password from a trusted device when the evidence indicates exposure; replace reused passwords elsewhere. [3] [6]
- Notify the work-account administrator immediately after accidental approval, successful unfamiliar activity, or a result showing primary credentials succeeded. [4] [5]
- Review sessions, signed-in devices, recovery methods, and connected applications; remove only confirmed unauthorized items. [5] [6]
- Keep MFA on and use number matching only for sign-ins you initiated. [1] [2]
Related The IT Guys guides
- If activity confirms a Microsoft 365 breach, follow our ordered Microsoft 365 account-containment guide. [7]
- Before a phone is lost, save MFA backup codes and test a second recovery method. [8]
- For routine cleanup, review signed-in devices and remove retired hardware. [9]
- If a connected Microsoft 365 application is suspicious, use the OAuth-consent investigation guide. [10]
Need help deciding whether the attempt stopped—or got in?
Practical referral: if a Port Saint Lucie-area home or small business has repeated MFA prompts, an accidental approval, unfamiliar sign-in activity, or a Microsoft 365 account at risk, contact The IT Guys from a known device. Bring the prompt screenshot and time; never send a password, approval number, backup code, or recovery key. [1] [2] [3]
Sources
- Microsoft Learn — How number matching works in MFA push notifications for Authenticator (accessed September 20, 2026).
- Google Account Help — Sign in with Google prompts (accessed September 20, 2026).
- Microsoft Support — What happens if there is an unusual sign-in to your account (accessed September 20, 2026).
- Microsoft Support — View your work or school account sign-in activity from My Sign-ins (accessed September 20, 2026).
- Microsoft Learn — Revoke user access in an emergency in Microsoft Entra ID (accessed September 20, 2026).
- Google Account Help — Secure a hacked or compromised Google Account (accessed September 20, 2026).
- The IT Guys — Microsoft 365 Email Account Hacked? Contain It Before Fraud Spreads.
- The IT Guys — Save MFA Backup Codes Before Your Phone Goes Missing.
- The IT Guys — Review Signed-In Devices Before An Old Phone Keeps Access.
- The IT Guys — Suspicious Microsoft 365 App? Revoke OAuth Consent Without Breaking the Business.
Scope: General account-triage guidance, not proof that a particular prompt is malicious or that denial alone completed containment. Vendor, tenant, administrator, application-session, recovery, legal, insurance, and incident-response requirements can change the correct next step.