Security alert email triage: how to tell if it is urgent

TL;DR — Treat a security alert email as urgent if it reports a successful sign-in you do not recognize, a password/MFA (multi-factor authentication) change you did not make, a new admin/user/API key you did not create, a billing or payout change, or malware/data exfiltration (data leaving your systems) detected by your security provider. The fastest safe path is: do not click the email links, sign in directly to the affected service from your bookmark, confirm whether the event appears in the service’s activity/audit log, and if it does, rotate the password and sessions immediately. Reading time: ~5 min

Goal

When you finish, you will have classified the alert as urgent, soon, or likely not real, and you will have evidence from the actual service dashboard or logs to support that decision.

Prerequisites

• Access to the mailbox that received the alert email
• Login to the affected service, if the email names one (for example: your Microsoft 365, Google Workspace, GitHub, cloud provider, hosting provider, or your agency-managed app)
• Access to your identity provider (the login system), if your company uses one, such as Microsoft Entra ID/Azure AD or Google Workspace
• A web browser
• The full alert email, including headers if your mail app can show them
• If available, your security provider dashboard login (for example, your EDR/XDR dashboard — endpoint/extended detection and response)
• Optional: a known-good bookmark for the service login page so you do not use links in the email

Steps

Step 1: Do not click the email links; identify the named service

Open the email and read only these fields: subject, from address, date/time, and the product or account named in the message. Then open a new browser tab and go to the service directly using your bookmark or by typing the known website address.

Exact action:

• In your mail app: open the message
• Read the visible sender address, for example security@service.example
• In a new tab, manually open the service login page you normally use

What you should see when this succeeds: you are on the real service login page without having used any link from the email.

Step 2: Classify the alert type using this table

Use the email text to match the event. If it matches any row in the Urgency column as "Urgent now," treat it as immediate.

What you should see when this succeeds: you can place the email into one of three buckets: urgent now, soon today, or likely phishing.

Step 3: Check the real activity log in the service dashboard

In the affected service, open the activity, audit, security, or sign-in history page and look for the exact event and time from the email.

Exact menu paths to try in common services:

• Microsoft 365 / Entra: Microsoft Entra admin center → Users → select user → Sign-in logs
• Google Workspace: admin.google.com → Directory → Users → select user → Security → Login challenge / Recent security activity
• GitHub: Profile photo → Settings → Security → Recent security activity
• Cloud providers/hosting: in your provider's dashboard, look for Security, Audit Log, Activity Log, or Sign-in history
• Agency-managed app: your provider's dashboard, then Security or Audit log

What you should see when this succeeds: an event with the same approximate time, account, IP address (internet address), location, or action named in the email — or no matching event at all.

Step 4: If the event is real and urgent, contain it immediately

If Step 3 shows a matching urgent event you do not recognize, perform these actions in the affected service and your identity provider.

Exact actions:

• Change the password in the affected service: Account/Profile → Security → Change password
• Sign out other sessions: Account/Profile → Security → Sign out of all sessions or Revoke sessions
• Revoke new API keys/tokens you do not recognize: Settings → Developer/API keys/Tokens → Revoke/Delete
• Remove unknown devices or SSH keys: Settings → Security → Devices/SSH keys → Remove
• Re-enable or reset MFA: Account/Profile → Security → Two-factor authentication/MFA → Enable/Reset
• If an admin/user was added: Admin/Users → select unknown user → Disable/Delete

⚠️ If you delete a real user, API key, or device that your business depends on, you can cause downtime. If you are unsure whether an item is legitimate, disable or revoke it first if that option exists, then confirm with your team.

What you should see when this succeeds: the unknown session, key, device, or user is no longer active, and the account password/MFA is updated.

Step 5: If the event is not in the dashboard, treat the email as suspicious

If there is no matching event in the real service dashboard, do not interact with the email. Report it internally or move it to phishing/junk according to your company process.

Exact actions:

• In your mail app, use Report phishing if available
• Otherwise move the message to Junk or Spam
• If your company has an IT/security contact, forward the message as an attachment, not by copy-paste, so headers are preserved

What you should see when this succeeds: the email is reported without you entering credentials or clicking any embedded links.

Step 6: Check whether this is isolated or part of a broader incident

If you have access to an EDR/XDR dashboard, check whether the same user or device has other alerts around the same time.

Exact menu paths to try:

• In your security provider dashboard: Alerts/Detections → filter by user/email/device name → Last 24 hours
• Then open Timeline, Investigation, or Related alerts

Use this quick flow:

[Alert Email] ---- 1. names service/user ----> [Service Dashboard]
[Service Dashboard] ---- 2. matching event? ----> [Yes: Real]
[Service Dashboard] ---- 3. no matching event ----> [Likely Phishing]
[Yes: Real]
|
v
[XDR/EDR Alerts] ---- 4. more alerts? ----> [Urgent Incident]
[XDR/EDR Alerts] ---- 5. no more alerts ----> [Single Account Issue]

What you should see when this succeeds: either related alerts that raise urgency, or no related alerts, which suggests a narrower issue.

Verify it works

Use these checks to confirm your triage result:

• For a real urgent alert: in the service dashboard, the suspicious session is revoked, unknown keys/users are disabled, and the account shows a recent password or MFA update.
• For a likely phishing email: there is no matching event in the service dashboard, and you did not click any links or enter credentials from the email.
• For broader incident checking: the XDR/EDR dashboard either shows related alerts for the same user/device in the last 24 hours or shows none.

A good end state looks like this:

• You can answer: Was this real? Yes/No
• You can answer: Is it urgent now? Yes/No
• If yes, the account has a new password, MFA is enabled, and unknown sessions/keys/users are removed or revoked

Common pitfalls

Mistake: Judging urgency from the sender address alone

Symptom: the email looks legitimate, but the real dashboard shows no matching event. Fix: ignore the sender reputation and go to the service directly; confirm only from Security, Audit log, or Sign-in history.

Mistake: Treating all failed-login alerts as account compromise

Symptom: panic over repeated "failed sign-in" messages even though there was no successful login. Fix: classify as Soon today, then change the password if it is weak/reused and enable MFA if it is not already enabled.

Mistake: Resetting the password but leaving active sessions and API keys in place

Symptom: suspicious activity continues after the password change. Fix: also use Sign out all sessions and revoke unknown API keys, tokens, and SSH keys.

Mistake: Looking only in the app, not in the identity provider

Symptom: the app shows nothing, but users still report strange sign-ins. Fix: check the login system too, such as Microsoft Entra admin center → Users → Sign-in logs or Google Admin → Users → Security.

Mistake: Clicking the email link to "verify" the alert

Symptom: you land on a login page that asks for credentials again or looks slightly wrong. Fix: close the tab, open the service from your bookmark, and change the password only from the real site if the event is confirmed.

Mistake: Ignoring related alerts in XDR/EDR

Symptom: you fix one account, but another device or mailbox is compromised the same day. Fix: in your security dashboard, filter Alerts/Detections by the same user or device for the last 24 hours before closing the incident.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.