MFA prompts you did not start: deny, investigate, and stop the loop
Do not approve a sign-in to silence the phone. Check the account and the authentication flow before deciding what the prompts prove.
Your phone keeps asking you to approve a sign-in. You are not signing in anywhere. After the fifth interruption, approving once just to make it stop can feel tempting. It is also the decision the person triggering the requests may be hoping for.
Deny any authentication request you did not initiate. Then investigate through the account’s own security controls. Do not approve a request because a caller says it is necessary to cancel an attack or repair the notification system.
There is an important nuance: an unexpected prompt does not always prove that someone knows your password. Different services and sign-in flows work differently, including passwordless flows. The response should be firm about approval and careful about diagnosis.
First, identify the account
An authenticator can contain several personal, work and school accounts. Read which account the request concerns. Do not change an unrelated password and assume the issue is resolved.
Open the authenticator directly instead of following a link in an unexpected message. If the prompt gives a location or application, treat that as context, not a complete identity check. Network locations can be approximate, and a familiar application name does not establish that you requested the action.
Microsoft’s Authenticator sign-in documentation shows that the application participates in different sign-in methods. That is why “a prompt arrived” is not enough information to infer the entire sequence that preceded it.
Then separate the possible situations
| Situation | What to avoid | What to check |
|---|---|---|
| One unexpected prompt | Approving from habit | The named account and recent activity |
| Repeated prompts | Approving to stop interruptions | Security activity and the official support route |
| A caller supplies a matching number | Treating the number as proof of legitimacy | Whether you independently initiated the sign-in |
| A prompt follows your own login | Approving without reading | The account and operation you actually started |
| You already approved one | Assuming a later password reset covers everything | Access, sessions and recovery settings through official controls |
The most reliable question is not whether the request looks technically authentic. It may be a real prompt. The question is whether it corresponds to an action you intended to authorize.
Number matching is not permission to obey a caller
An additional matching step can improve a sign-in process, but it does not replace judgment about who started the process. If someone tells you which number to enter, that person’s explanation still needs verification.
Consider an illustrative call: “We see someone attacking your account. Enter the number I give you so we can block them.” The stated purpose is defensive, but the on-screen operation may be a sign-in approval. Follow the meaning of the operation, not the caller’s narration.
End an unexpected support call and reach your helpdesk through an established directory or support portal. Do not use the caller’s preferred callback number. Our guide to Teams IT-support impersonation covers a related attempt to make an unsolicited helper part of the solution.
Denying the prompt and contacting real support are compatible actions. You do not need to approve an unrequested sign-in to demonstrate that you are cooperating.
Review activity without overreading it
For Microsoft work or school accounts, the My Sign-ins documentation explains how to inspect activity and interpret some results. For personal Microsoft accounts, use the separate unusual-sign-in guidance.
Check the account type before following instructions. An organization’s administrator may see information or have controls that are unavailable in a personal account. Conversely, a personal-account recovery procedure may not apply to a managed work identity.
Do not treat a failed attempt as a successful intrusion. Do not treat a lack of a visible entry as conclusive proof that nothing happened either. If the records are unclear, report the observed prompts, approximate times and account name to the appropriate support channel.
Avoid copying a full security log into a public forum. It may reveal email addresses, device details or organizational information. A narrow description is usually enough to ask where to investigate next.
If you approved by mistake
Act promptly, but keep the account and device questions separate. Reach the official security or recovery controls from a trusted device. Review access and authentication methods, and follow the service’s current steps for unrecognized activity. On a work account, tell the security or IT team that an approval occurred.
If you also disclosed a password, changed recovery details or installed software, say so explicitly. Those facts can change the response. “I approved one prompt at approximately this time” is more useful than minimizing it as “I just clicked something.”
Do not delete the authenticator account or reset the phone as an improvised first step. You may remove a working recovery method without removing someone else’s access. Let the provider’s documented process or your administrator guide the changes.
A short handover for your helpdesk
Give the team the account name, the approximate start time, how often requests appeared and whether you approved any. Mention a connected phone call or chat, because the interruption and the supposed support contact may belong to one sequence. Do not send your password or a current code as part of the report.
Ask what you should do if the prompts continue while they investigate. A clear interim instruction is better than leaving a tired employee to improvise. If an upcoming meeting or deadline depends on the account, tell them that too, so legitimate work can be handled without authorizing a stranger’s sign-in.
Record the support case through the channel you already trust. If a second person contacts you claiming to take over the incident, verify that handoff through the original case rather than accepting their knowledge of the problem as proof.
Stop fatigue from becoming the decision-maker
Repeated interruptions create pressure even without a threatening message. If the account is managed, report the pattern and ask the team to handle it as a security issue rather than leaving you to dismiss prompts indefinitely.
For personal accounts, inspect available security settings and recovery options through the provider. Keep strong authentication enabled. Turning protection off because it is noisy can remove a useful barrier without addressing why the requests arrived.
Before the next incident, make sure you know the support route and have a legitimate recovery method you can access. Our article on backup codes explains how to preserve that fallback without handing it to a supposed helper.
You do not have to solve the entire cause while the phone is buzzing. Make the immediate decision correctly—do not approve what you did not start—then move the investigation into a channel you control.