Treat an unexpected approval request as information, not an instruction
A phone notification that asks you to approve a sign-in is designed to be quick when you are the person signing in. That convenience can become a problem when someone else has reached the first stage of an account login. An unexpected prompt does not prove that an account has been taken over, but it is evidence that deserves a deliberate response. Do not approve it to make it disappear, and do not assume a request is harmless because it arrived in an app you recognize.
Start by denying the request if the service gives you that option. Then stop responding to repeated prompts. A stream of approval requests can be an attempt to get an accidental tap or an approval made out of frustration; CISA calls this MFA fatigue or push bombing. The useful distinction is simple: a notification can report a sign-in attempt, but it should not decide whether you authorize it. Only approve a prompt that follows a sign-in you just started through a route you know is genuine.
This rule also protects against a more conversational version of the same problem. A caller, message or support-looking chat may say that you must approve a prompt to stop fraud, confirm your identity or help an agent. That reverses the purpose of authentication. An approval or verification code is evidence for the service that the person completing the login controls your authenticator; it is not something a stranger needs to troubleshoot your account. End the unexpected contact and use the provider's established support route if help is needed.
Check the account through a route the prompt did not choose
After denying an unfamiliar request, open the service's normal app or type its established address yourself. Do not use a link in a text, email or notification that arrived alongside the request. Once you are signed in, look for the account-security area: recent sign-ins, registered devices, active sessions, recovery email addresses, phone numbers and authentication methods. The labels differ by service, but the question is consistent: is there a device, location, session or recovery setting that you do not recognize?
Read the context on the prompt when the service provides it, but do not treat a city name or device description as a precise investigation tool. Locations can be approximate and device labels can be generic. Their value is comparison: a request from a place you have not been, at a time you were not signing in, is enough reason to deny it and inspect the account. A familiar-looking location is not a reason to approve a request you did not initiate.
If the account shows an unfamiliar successful sign-in, a changed recovery method, forwarding you did not create, or a session you cannot explain, use the provider's account-recovery and security tools immediately. Change the password through the known account page, sign out other sessions where offered, remove unrecognized recovery routes and connected apps, and review the account's instructions for a suspected compromise. Preserve the useful facts—time, device label and changes you found—rather than trying to diagnose the attacker yourself.
Decide whether the password may already be part of the problem
An approval request alone does not reveal how it was triggered. It can come from a mistyped username, an old device trying to reconnect, or someone who knows or has obtained a password. That uncertainty is why a known-route account check matters. If you reused the password, used a predictable variation elsewhere, entered it after following an unexpected link, or see any sign of a successful unfamiliar session, change it promptly and change any matching passwords on other accounts too.
Give the email account that receives reset messages special attention. It often controls the recovery path for other services, so a weak or exposed inbox can turn one password problem into several account problems. Give important accounts unique passwords and keep them in a reputable password manager or another secure method you can maintain. The goal is not to remember increasingly elaborate strings; it is to prevent one compromised credential from being a reusable key.
Do not send a one-time code to anyone who asks for it. The Federal Trade Commission notes that verification codes are used as part of two-factor authentication; sharing one can let a scammer complete the step that was meant to keep them out. The same practical boundary applies to an approval request: the person who is genuinely signing in should be the one who began the session and can see why the prompt appeared. A support worker reached through an unsolicited message does not need either proof.
Make every approval require a recognizable match
If a service offers number matching, turn it on. Instead of presenting a bare approve-or-deny button, number matching asks you to enter or select a number shown on the sign-in screen. That small extra comparison makes an accidental approval less likely because the person approving needs to be looking at the login they started. CISA recommends number matching as a defense against MFA-fatigue attacks and advises organizations to pair it with context such as the application, location and time of the request.
Use that context as a check, not as an excuse to guess. Before approving, confirm that you initiated the login, that the service name is the one you expected, and that the number or code on the computer matches the prompt. If any part does not match, deny it. If you are repeatedly interrupted, change the account password through the ordinary account page and remove stale sessions or devices rather than approving a request just to quiet the phone.
For an important account, look at what authentication methods the provider actually supports. An authenticator app, a hardware security key, a passkey or a provider's phishing-resistant option can offer a different experience from a simple push approval. NIST's current digital-identity guidance explains that manually entered one-time codes and out-of-band methods are not phishing-resistant because an impostor can relay them; cryptographic methods that bind the authentication to the real verifier are designed to resist that relay. Availability and setup vary, so the provider's own account-security page should guide the specific choice.
Keep recovery from becoming the weaker door
A stronger sign-in method is only useful if you can recover safely when a phone is lost, replaced or unavailable. Before removing an older method, review the account's recovery email addresses, phone numbers, backup codes, trusted devices and support process. Add a second authenticator only where the provider permits it and where you can protect it. Keep recovery codes offline or in a secure location, not in an inbox that depends on the same account you may be trying to recover.
Do not register a new device or recovery channel in response to an unexpected prompt. That can turn a suspicious event into a lasting account change. Make recovery changes only while signed in through a known route, and pay attention to the account's confirmation messages afterward. NIST treats authenticator binding and account recovery as events that should trigger notification, precisely because they can reveal fraud. Treat a notice about a method you did not add as a reason to secure the account, not as a routine email to archive.
For shared household or work accounts, decide in advance who owns recovery and what happens when a device changes hands. A phone that receives prompts but whose owner cannot reach the account settings is not a complete recovery plan. The best arrangement is the one that lets the legitimate account owner verify a change independently without asking a colleague, family member or unexpected caller to approve something on their behalf.
Use a short response routine when the next prompt appears
The response can fit on a small mental card: deny the request; do not share a code or approve a prompt for anyone else; open the real service independently; inspect recent activity and recovery details; change a reused or possibly exposed password; then strengthen the sign-in method and recovery plan. This is proportional. It does not require declaring an account compromised whenever a notification appears, and it does not leave the decision to a tired tap.
For a work account, tell the appropriate security or IT team through its established reporting channel, especially if requests repeat or an unfamiliar sign-in appears. They may be able to see organization-specific logs, revoke sessions or advise on the approved sign-in method. For a personal account, the provider's official recovery path is the equivalent starting point. Avoid installing a tool, granting remote access or calling a number supplied by an unexpected alert.
Multifactor authentication still adds meaningful protection, but its value depends on treating the second factor as a decision rather than a reflex. Make unexpected prompts a stop signal, make expected prompts match a login you initiated, and keep recovery routes under the same careful control. That routine turns a distracting notification into a clear moment to protect the account instead of an opening for someone else to use it.
Primary sources
Read further
CappsTech Daily uses research and automation to accelerate preparation. Every published article must add original explanation, link its primary sources, and pass an editorial accuracy check.