How to deal with ageing Microsoft 365 security alerts

What this check looks at

Looks at open security alerts and how long the oldest has been outstanding.

The Microsoft Defender portal brings together alerts from Defender for Office 365, Microsoft Entra ID Protection, Defender for Endpoint, Defender for Cloud Apps and the built-in Microsoft 365 alert policies: a user restricted from sending email, a malicious URL clicked, suspicious email forwarding, a device with active malware. Each alert stays New or In progress until someone classifies and resolves it. Microsoft does not close them for you, and many of the default alert emails go only to the Global Administrators.

This check reads the alerts from the last 90 days. It passes when none is unresolved, fails when any unresolved alert is more than 30 days old, and warns when alerts are open but the oldest is 30 days old or less. The evidence lists each open alert with its severity, status, source and when it was raised.

An ignored queue hides the one alert that matters. A Suspicious email forwarding activity or User restricted from sending email alert is often the only early sign of a compromised account, and it is easy to miss among dozens of informational alerts nobody has closed. Old alerts also make it impossible to tell, during an incident, which warnings are new.

Why it matters

An alert queue nobody works is worse than no alerting: the organisation pays for the detection, believes it is covered, and finds out during the incident that the warning was raised months earlier.

A typical case: a 30-person accountancy practice paying for Business Premium finds, after a client loses money to a fake invoice sent from a partner’s mailbox, that Microsoft raised a suspicious forwarding alert on that mailbox five weeks earlier. The detection worked; nobody was looking. The client’s loss, the practice’s professional indemnity notification and the clean-up all trace back to an unread alert.

Insurers ask when the first indicator appeared and whether it was acted on, and under UK GDPR the 72-hour window for reporting a personal data breach to the ICO runs from when the organisation becomes aware of it. An alert sitting unread in its own portal is uncomfortable evidence of when the organisation could have known.

Reviewing and acting on alerts is what NIST CSF 2.0 DE.AE-02 (potentially adverse events analysed) and RS.MA-02 (incident reports triaged) describe, along with ISO 27001 A.8.16 (monitoring activities) and A.5.25 (assessment and decision on information security events), CIS Controls v8 13.1 (centralise security event alerting) and 8.11 (audit log reviews), and NCSC CAF C1.c and C1.d (generating alerts, identifying security incidents).

How to fix it

Where: Microsoft Defender portal → Incidents & alerts

Before you start

• Agree who looks at alerts and how quickly (for example, high severity within four working hours).

Step by step

1. 1Open the alert queue, oldest first. In the Microsoft Defender portal, go to Investigation & response > Incidents & alerts > Alerts. Filter Status to New and In progress, widen the time range to six months and sort by first activity so the oldest open alerts, the ones failing this check, are at the top. Related alerts are grouped into incidents; resolving an incident resolves its alerts together.
2. 2Triage the high and medium severity alerts first. Open each alert and read the alert story: what was detected, on which user, mailbox or device, and the evidence. Decide whether it is a true positive, a false positive or expected activity such as an administrator’s bulk change. For a true positive that is not yet contained, act now: revoke sessions and reset the password, remove the mailbox rule or isolate the device, as the alert requires.
3. 3Resolve what has been dealt with. Select Manage alert, set Status to Resolved, choose a Classification (True positive, Informational/expected activity or False positive) and add a short comment. For many alerts of the same kind, tick them in the list and resolve them together from Manage alerts. Classify accurately, as Microsoft uses the classification to tune its detections.
4. 4Tune the detections that keep repeating. Where the same benign alert keeps returning (a scanner, a service account, a known travel pattern), open one and choose Tune alert, or go to Settings > Microsoft Defender XDR > Alert tuning > Add new rule. Scope the rule as narrowly as possible (the specific user, IP address or file), set it to resolve matching alerts and record why in the comment. Never suppress a whole alert type.
5. 5Send new incidents to a monitored mailbox. Go to Settings > Microsoft Defender XDR > Email notifications > Incidents and add a notification rule sending new medium and high severity incidents to the client’s monitored security mailbox or your service desk, not to one person. Agree with the client who looks at them and how quickly, for example high severity the same working day.
6. 6Confirm the queue is clear. Back on the Alerts page with the New and In progress filter, nothing should be older than 30 days, and every high severity alert should be resolved or assigned to someone. The next assessment passes when no alert from the last 90 days is unresolved, and warns while recent ones are still open.

What users will notice

None directly.

How to confirm it worked

Microsoft Defender, Incidents and alerts: no alert older than your target is unresolved.

Frameworks and controls

This check maps to controls in 14 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.

The framework mappings were last checked against the published standards in October 2026.

Microsoft’s documentation

• Manage incidents (Microsoft Learn)

Related checks

• How to investigate and remediate risky users in Entra ID
• How to set security notification contacts in Microsoft 365
• Defender for Office 365: check the protections are on
• How to check the unified audit log is on in Microsoft 365

The full Microsoft 365 security checklist, worst first