Alert severity, and what a match actually means
Severity is a number about consequence, not confidence. How a rule match becomes an alert, what the four evaluation stages do, and how to triage without training.
Two questions get confused constantly, and confusing them is what makes an inbox of alerts unusable. The first is how bad is this if it is real. The second is how likely is it that this is real. Severity answers only the first. Nothing in the severity field is a probability.
This matters at the moment you have four open alerts and time for one. A critical alert is not a statement that your organisation has been breached. It is a statement that the pattern which matched, when it is genuine, tends to be catastrophic — which is exactly why it goes to the front of your queue even though most of them will turn out to be a colleague on holiday.
The severity scale
Severity is stored as a number on the CEF scale, not as a word, so it sorts and compares consistently across the SIEM, the endpoint side and the risk engine. The words are labels on the numbers.
| Value | Label | What it asserts | Proportionate response |
|---|---|---|---|
| 10 | Critical | If genuine, this is an active compromise with immediate business consequences — encryption, exfiltration, or an attacker holding privileged access. | Work it now. Follow What to do when an alert arrives in order. |
| 8 | High | If genuine, an attacker has achieved something material — a valid session, a consent grant, a persistence mechanism — but has not yet caused the damage. | Work it the same working day. Session revocation is usually the cheapest correct first move. |
| 5 | Medium | Suspicious activity that is frequently legitimate, or an early-stage technique that is only meaningful in combination with something else. | Batch these. Read them together weekly; look for the same subject appearing repeatedly. |
| 1 | Low | A weak signal kept for correlation and for the risk score rather than for a human to read individually. | Do not triage these one at a time. Their value is aggregate. |
| 0 | Unknown | Severity was not determined. In practice this indicates a data or configuration problem rather than a security one. | Treat as a platform question, not an incident. |
What is actually in the detection library
As measured on 2026-08-31, the library ships 100 detection rules, of which 90 are active and can raise an alert, and 10 are in shadow mode — evaluated, contributing to risk, raising no alert. There are 8 correlation chains. By severity the split is 21 critical, 64 high, 13 medium and 2 low.
Coverage is expressed against MITRE ATT&CK: 80 distinct techniques across 12 of the 14 tactics. The two tactics not covered are Reconnaissance and Resource Development, and the reason is structural rather than a gap we intend to close. Both happen outside your estate — an attacker researching your staff on LinkedIn or registering a lookalike domain generates no telemetry inside your Microsoft 365 tenant or on your endpoints. A product claiming to detect them from your own logs would be claiming something it cannot do.
Two facts about authorship are worth knowing when you are asked about them in a questionnaire. The library is 100% first-party authored, so no rule requires a third-party licence attribution to be rendered in the alert interface. And 32 of the 100 rules are Microsoft 365 identity rules — a deliberate weighting, because roughly 70% of SMBs are a Microsoft shop and cloud-account abuse is the most prevalent confirmed technique in the 2025/2026 threat data. The library is shaped like the threat, not like a feature matrix.
A match is not an alert
Between an event arriving and you being interrupted there are four stages, and each one can stop the process. Understanding them is the difference between trusting the queue and drowning in it.
Should-evaluate
The shipped rule is combined with your tenant's override. If the rule is disabled for your organisation, or one of your suppressions matches the event, evaluation stops here. Suppression fields are themselves validated against the field contract, so you cannot suppress on a field that does not exist and then believe you have suppressed something.
Rule evaluation
Single-event selection matching. The rule's selections are combined by a condition expression with proper precedence, so a rule can say what it means rather than approximating it. A match here means one event looked like the pattern — nothing more.
Aggregation
Matching events only are folded into a window, with a threshold (a count), an optional distinct-field count, a minimum-events floor and a cooldown per rule and entity. This is the stage that converts "a failed sign-in" into "twenty failed sign-ins from one address in five minutes". A rule with no threshold fires on every match and is still cooldown-limited, so a noisy source cannot produce a thousand identical alerts.
Should-alert
A rule in shadow status stops here. Its finding is real and has already been recorded, and it feeds the risk engine — it creates no work for a human. Everything else becomes an alert with a status of
open.
Wherever a rule sets a threshold, it must also carry a stated threshold rationale. A threshold without a reason is a number nobody can tune, so the validation gate insists on the reason being written down at authoring time. When you eventually decide that twenty failed attempts in five minutes is the wrong figure for your organisation, the rationale tells you what the original figure was protecting against.
Correlation chains: when the sequence is the signal
Some techniques are unremarkable alone and decisive in sequence. Eight correlation chains encode those sequences, and all eight are critical, because a completed sequence is a much stronger claim than any of its steps.
| Chain | Steps | Severity |
|---|---|---|
| Brute force → account compromise | 2 | Critical |
| Account compromise → privilege escalation | 2 | Critical |
| Internal reconnaissance → lateral movement | 3 | Critical |
| Full kill chain: access → escalation → movement → exfiltration | 4 | Critical |
| Illicit consent grant → mailbox rule creation | 2 | Critical |
| Device-code phishing → mailbox or data access | 2 | Critical |
| Defence tampering → destructive action | 3 | Critical |
| Multi-factor fatigue → successful sign-in | 2 | Critical |
If a chain alert arrives, treat its severity as meaning what it says. A chain requires several independent rules to have matched against the same entity in order, which is a far higher bar than a single-rule critical. In triage terms, a chain alert outranks a single critical every time.
Behavioural signals, and why they take time
Some rules read behavioural fields rather than fixed patterns: whether the event is off-hours, whether the geography is unusual for that person, whether their volume has spiked, and how many standard deviations from their own mean the event sits. Those come from a per-user baseline of normal working hours, dominant geography, and a running mean and standard deviation of daily volume.
One implementation detail has a direct effect on what you see. Each event is scored against the baseline as it stood before that event, and only then folded into the baseline. Observing first would let a single event become its own definition of normal, which is how an off-hours baseline quietly defeats itself: the 3am sign-in that should be anomalous instead teaches the system that 3am is fine. The consequence for you is that behavioural detection needs real traffic before it is worth anything, and a new tenant should not read too much into its first fortnight of behavioural alerts.
Tuning a rule for your organisation
The shipped library is tenant-independent; your changes are overrides on top of it. You can change a rule's status (though not to deprecated), enable or disable it, and change its severity, risk score, threshold, minimum events, time window, cooldown and suppressions.
The right time to tune is a scheduled hour on a quiet day, with the false-positive guidance open in front of you. The wrong time is during an incident, and the wrong action is disabling. Raising a threshold or adding a narrow suppression keeps the detection alive; disabling it removes a class of visibility you will not remember having removed.
Triage in practice, with no analyst
- Sort by severity, then bring any correlation-chain alert to the top regardless of what else is open.
- For each one, read the subjects and the false-positive guidance before you form an opinion.
- Telephone the named person if there is one. Most high-severity identity alerts resolve here.
- If it is real, follow the playbook in What to do when an alert arrives rather than improvising.
- Set the status honestly. Use
false_positiveonly when the behaviour was legitimate and you can state why, because that marking is an input to how the system behaves in future. - Batch the medium and low alerts. Read them weekly, and look for one subject appearing across several — that repetition is what the risk engine is watching for too.
What to read next
- Shadow detections, and why some rules stay quiet — what the other 10 rules are doing.
- Severity, blast radius and what to fix first — the same reasoning applied to posture findings rather than alerts.