Check the Account Before Following the Message
An unexpected security alert creates a small emergency in your inbox. Someone supposedly signed in, changed a password, or requested a recovery code. The message offers a large button to fix everything. That button deserves less trust than the account it claims to protect.
The safest starting point is to open the service independently, review its security activity, and compare the recorded event with what you were doing. Act promptly on unfamiliar activity, but choose the route yourself. An alarming message can describe a real incident, ordinary activity, or a phishing attempt.
You are answering two separate questions: did this message come from the service, and did something happen that requires action? Checking the account directly helps with the second question without betting your credentials on the first.
Open a Route You Already Trust
Set the message aside. Open the installed app you normally use, select a previously verified bookmark, or enter the service's known address yourself. Navigate to account security, recent activity, or signed-in devices. Labels vary, so use help reached from inside the service if needed.
Check which account you opened. A recovery address may receive alerts for several accounts, and a browser may automatically select the wrong profile. Compare the account named in the warning with the one whose activity you are reviewing.
Do not call a number supplied by the warning, open its attachment, scan its QR code, or install a suggested support tool. A familiar display name, convincing logo, or accurate account detail does not establish who sent it. If help is necessary, start from the provider's own support controls.
For a work account, use your organization's established reporting route. Its security team may have information unavailable in your personal activity view. If you suspect the device itself is compromised, switch to a separate trusted device before entering credentials.
Identify What the Event Actually Says
Security notifications describe different stages of account activity. A password reset request is different from a completed password change. An unsuccessful login is different from a successful session. Read the event details before deciding how much happened.
Record these details privately:
- The affected account and service
- The event type and whether it succeeded, failed, or was blocked
- The event time, displayed time zone, and notification arrival time
- The device, browser, or application described
- The reported location and any related security-setting changes
A failed attempt using an incorrect password does not prove someone knows your password. An unexpected reset email may mean someone entered your address into a recovery form. Neither event, by itself, proves that the account was opened.
Conversely, a provider may block an attempt after some authentication steps have succeeded. Do not interpret every blocked event as harmless. Follow the provider's explanation and recommended response, especially when it indicates that a credential may be exposed.
An unfamiliar successful sign-in, newly registered authentication method, or changed recovery address calls for immediate attention. Keep a short record of the details, then begin securing the account; evidence collection should not delay containment.
Compare Several Clues, Not Just the Map
A location label is a clue, not a fingerprint. Network-based estimates can point to a nearby city or the location associated with a mobile network or VPN connection. A surprising city alone cannot tell you who was using the account.
Times also need interpretation. A device list may show its latest communication with the service, including background synchronization, rather than the moment somebody typed a password. Notification delivery can lag behind the event. Compare the meaning of each timestamp before concluding that an idle laptop was actively used.
Device names can be broad, and one physical device may have several sessions across browsers and apps. A newly installed mail app, private browsing session, or replacement phone can explain a new entry. Look for a combination that matches something you actually did.
For example, imagine that you signed in on a replacement phone shortly before an alert arrived. The device family, application, time, and network context all fit. That is a stronger explanation than recognizing the city while everything else is unfamiliar. If the details remain inconsistent, use the service's option to report that the activity was not yours.
Keep Approval Prompts Separate From Warnings
An authentication prompt can be genuine while the sign-in behind it is unauthorized. The fact that it appeared in your normal authenticator app does not mean you should approve it.
Approve a sign-in only when it matches an action you personally started. Deny an unexpected request through the authenticator's own controls, then independently inspect account activity. Never approve repeated prompts just to make them stop, and never give a caller an authentication code to “cancel” a login.
Some legitimate recovery processes request codes. Use them only within the provider's flow you deliberately opened and verified. A person contacting you out of the blue does not become trustworthy because they can trigger a real code message.
Repeated unexplained prompts deserve investigation even when each one is denied. Preserve the timing, check your account's security state, and report work-account prompts to the appropriate team. Do not disable useful security alerts merely because someone has made them annoying.
Respond to Confirmed Unfamiliar Activity
When the account itself shows activity you cannot explain, follow its compromise-recovery procedure from a trusted device. If your password no longer works, use the official account-recovery process reached independently.
The essential checks are:
- Report the unfamiliar activity using the provider's controls.
- Change an exposed password to a unique one and replace it anywhere it was reused.
- Review active sessions and use the available sign-out or revocation controls.
- Remove unfamiliar recovery details, passkeys, security keys, and other authentication methods.
- Review connected applications and any app-specific passwords.
- Inspect account content for actions taken during the suspected access.
Do not assume changing a password instantly closes every session. Sign-out behavior and timing differ between services. Read the confirmation, check for exceptions, and follow up rather than treating one successful button press as the end of recovery.
For email, inspect forwarding rules, filters, delegated access, and sent messages. For cloud storage, check recent file activity and review sharing links and permissions. Ending an attacker's session does not necessarily undo a new permission they created.
If there are signs of a local cause, such as an unfamiliar add-on or account activity returning after recovery, include a browser extension security audit. Keep new credentials away from the potentially affected environment until you can trust it again.
A prepared personal cybersecurity incident response kit helps keep recovery contacts, notes, and clean-device options available when your normal account access is unreliable.
Close the Loop Without Silencing the Alarm
If the activity matches your own actions, acknowledge it through the account's security controls when requested. If the message appears fraudulent, report it using the mail or messaging service's reporting feature, then remove it from your inbox.
No matching event is not absolute proof that a message is fake. Activity views can have limited coverage, and an alert may concern a different account or a different kind of security event. Confirm the account, check related settings, and contact the provider through its established support route if the discrepancy remains unresolved.
If you already entered a password or code into a suspicious page, treat that information as exposed even if the account history looks quiet. Close the page and use the trusted recovery route. If you installed software or granted remote access, include device containment in the response.
Finish by recording what you verified, what you changed, and what still needs checking. Keep recovery contact details current and retain security notifications. The habit worth building is straightforward: open your own route, establish what happened, respond to the evidence, and confirm that the account is back under your control.