Overview

This article provides a low-risk, evidence-driven troubleshooting path for suspicious sign-in alert: what to check. Work from identity and service checks toward more disruptive actions, and stop before a change could cause data loss, broaden access, weaken security, or interrupt other users.

Start with the safest layerRecord the current state before changing settings. Use only approved accounts, tools, and administrative processes.

Why this happens

Security warnings and suspected account compromise require evidence preservation, safe containment, credential protection, and coordinated administrator-side review rather than ordinary trial-and-error troubleshooting.

Before You Begin

  • Preserve screenshots, alert text, times, sender addresses, and other useful evidence.
  • Use a known-clean device for sensitive account changes when practical.
  • Do not approve unexpected MFA prompts or communicate secrets to an unverified requester.
  • If ransomware or active compromise is suspected, prioritize containment and escalation over ordinary troubleshooting.

Navigation reference: Official work account portal > Security.

Click-by-Click Troubleshooting

Step 1: Verify whether the sign-in was yours

Action: Open the official account security portal directly and review the alert details instead of using links inside an email notification.

Why this matters: Opening the official portal avoids phishing links and confirms the alert is real.

What to look for: Compare time, device, application, and location with your activity.

Expected result: The event should be classified as expected or suspicious.

Step 2: Check recent activity

Action: Review recent sign-ins for the affected account.

Why this matters: One alert may be part of a larger pattern.

What to look for: Look for unfamiliar successful sign-ins, impossible travel, or repeated failures.

Expected result: All suspicious activity should be identified.

Step 3: Change the password if unauthorized

Action: If the sign-in was not yours, change the password using the official account portal from a trusted device.

Why this matters: This blocks reuse of a potentially stolen credential.

What to look for: Confirm the password change succeeds.

Expected result: The prior password should no longer work.

Step 4: Review MFA methods

Action: Review the account's registered authentication methods.

Why this matters: Unauthorized methods can provide persistence after a password change.

What to look for: Look for unknown phone numbers, apps, or security keys.

Expected result: Only approved methods should remain.

Step 5: Revoke suspicious sessions through IT

Action: Contact IT to revoke active sessions and review identity-risk or audit information when unauthorized activity is confirmed.

Why this matters: Existing tokens can survive a password change in some scenarios.

What to look for: Provide the suspicious event time and application.

Expected result: Untrusted sessions should be invalidated.

Step 6: Monitor for follow-on changes

Action: Check for unexpected inbox rules, forwarding, consent grants, password-reset notices, or new alerts.

Why this matters: Compromised accounts are often modified for persistence or fraud.

What to look for: Look for changes you did not make.

Expected result: No unauthorized persistence should remain.

What to Look For

  • Whether the issue affects one user/device or multiple users.
  • Whether a clean browser or alternate approved client changes the result.
  • Whether the error points to identity, permission, licensing, service, device, or network state.
  • Whether the same controlled test succeeds after the targeted correction.

When to Stop

Stop before troubleshooting becomes riskyDo not broaden access, bypass MFA/security, erase evidence, permanently delete business data, change tenant-wide settings, or perform destructive resets unless the approved IT process specifically requires it.

When to Contact IT

Contact J3 Systems Group if the issue remains unresolved, affects multiple users, requires administrator-level changes, involves security or data-loss risk, or the next step would be disruptive. Include article code KB-07.006, the affected account/device/resource, exact error, time observed, and the results of the controlled tests above.

Need help with this issue?

J3 Systems Group supports small businesses and nonprofits with Microsoft 365, Google Workspace, cybersecurity, devices, documentation, and day-to-day IT operations.

Contact J3 Systems Group

Authoritative references

Vendor interfaces, licensing, and security guidance can change. Verify current platform behavior against the primary documentation below before making high-impact production changes.

Article KB-07.006 · Review after material vendor, licensing, interface, security, or service changes.