Shadow detections, and why some rules stay quiet
Ten of the hundred shipped rules never raise an alert. What shadow mode is, why a quiet rule is not a broken one, and how those findings still reach you.
Of the 100 detection rules shipped as of 2026-08-31, 90 are active and 10 are in shadow mode. A shadow rule is evaluated against every relevant event, records a real finding when it matches, and contributes that finding to your risk picture — and it never raises an alert for a human to read.
That sounds like a defect. It is one of the more useful design decisions in the platform, and this article explains why, because the alternative is worse in a way that is easy to miss.
Where a shadow rule stops
Evaluation has four stages, described in full in Alert severity, and what a match actually means. A shadow rule passes through the first three exactly like any other rule — the tenant override and suppression check, the selection matching, and the windowed aggregation with its threshold, distinct-field count, minimum-events floor and cooldown. It stops at the fourth, the should-alert stage.
Stopping there is not the same as being switched off. The finding has already been produced and recorded by the time the fourth stage is reached. What the fourth stage decides is whether the finding creates work for a person. For a shadow rule the answer is no, and every fired decision — shadow or active — is still fed to the risk engine.
The example that makes the case
Consider a rule that fires on every uncovered single-factor sign-in. Now consider an organisation midway through rolling out Conditional Access, which is the ordinary state of a real business for several months.
As an alert, that rule is worthless. It produces dozens of entries a day, every one of them technically correct and none of them actionable, and its practical effect is to train the administrator to close alerts without reading them. Within a fortnight it has damaged the value of every other rule in the console, because attention is the scarce resource and the rule has spent it.
As a risk contribution, the same rule is valuable. The pattern is genuinely a weakness; it is not news on any individual occurrence. Fed into the risk engine, it accumulates against the specific accounts and the specific applications where the gap is worst, and it shows up in the place where that information is actionable — the posture and risk view — rather than in the place where it is noise.
Where the findings actually go
The risk engine accumulates per entity over a rolling window and opens an incident on either of two conditions. The first is a score threshold — enough accumulated weight against one entity. The second is tactic diversity: enough distinct MITRE ATT&CK tactics observed against one entity, across enough distinct data sources.
Tactic diversity is the condition that makes shadow rules pay for themselves. A single weak signal repeated four hundred times is still one tactic from one source, and it will not open an incident on diversity grounds no matter how often it recurs. Four different weak signals — a single-factor sign-in, a dormant non-human identity being used, an unusual geography, a privilege change — against the same account, from different telemetry, is a shape that no individual rule was confident enough to alert on and that collectively deserves a human. That is the case shadow rules exist to catch.
Attribution is deliberately strict. Each rule declares which entity kinds its risk is attributed to, and a declared entity whose field the event does not carry produces no signal at all — rather than a signal keyed on an empty string, which would merge every anonymous event in your tenant into one fictional entity with an enormous risk score. A quiet risk picture is preferable to a confidently wrong one.
Why a rule ships quiet: the field contract
There is a second and more technical reason a rule stays in shadow, and it is the more important of the two for anyone assessing the product honestly.
A detection rule that reads a field the ingest pipeline never populates does not fail loudly. It silently never matches anything. The rule looks shipped, the coverage report counts it, and it detects nothing — for years, if nobody checks. This is the single most common way a detection library is quietly worthless.
So every field any rule may reference is declared in a contract with an availability, and the validation gate refuses to load a rule that reads a field outside that contract, and refuses active status on a rule that reads a field still marked pending. Rule status is therefore derived rather than hand-set: a rule whose fields are all available ships active, and a rule reading a pending field ships in shadow. No author has to remember, and no rule can claim coverage it does not have.
None of the ten shadow rules is a mapping error. Each is blocked on telemetry that no ingested source currently produces.
| Rules | Waiting on | Why it cannot be derived today |
|---|---|---|
| NES-SIEM-031 (DNS tunnelling) | metadata.dns_query_type | The only DNS telemetry any ingested source produces reports the query name, status and results — never the record type. Deriving the type from the answer would report the type of the reply rather than the question, which is the opposite of what a tunnelling rule needs. Closing it needs a resolver log or a passive DNS sensor. |
| NES-SIEM-400, -401, -404 (non-human identity) | metadata.nhi_type, metadata.dormant_days | Both values are computed by the IAM module, which does not currently emit an event into the SIEM. |
| NES-SIEM-405 (AI service administration) | metadata.agent_tool_name | Computed by the AI control plane, which does not currently emit an event into the SIEM. |
| NES-SIEM-450, -451, -452, -453, -455 (PAM and just-in-time privilege) | metadata.session_type, metadata.approval_state, metadata.break_glass, metadata.key_id | Computed by PAM, which does not currently emit an event into the SIEM. |
Nine of the ten are structurally blocked rather than badly written: PAM, IAM and the AI control plane all hold these values internally, but none of them writes through the SIEM ingest path, so there is no document for the projection to derive anything from. Closing that is owned by those modules. Two geographic coordinate fields are also pending because no source reports coordinates, but no rule depends on them, so nothing is waiting on that.
The practical consequence is that a rule flips from shadow to active on its own the moment the ingest side lands its last missing field. You do not have to do anything, and nobody has to remember to change a status by hand.
What this means for you
- A quiet rule is not an absent control. Its findings exist and they feed risk. What it does not do is interrupt you.
- Do not read the total rule count as your alerting coverage. The active count is the number that determines what will reach your inbox, and it is published separately for that reason. Your own live figures are in the console's detection-coverage view.
- If you expected an alert and did not get one, check three things in order: whether the rule is in shadow, whether a suppression or a tenant override is dropping the event, and whether the aggregation threshold was met. In that order — the first is by design, the second is usually something a colleague configured, and only the third needs investigation.
- Shadow findings are the reason an incident can appear without any single alert preceding it. If an incident opens on tactic diversity, the contributing findings will include rules you never received an alert from. That is the mechanism working, not a gap in the record.
- A missing rule is reported as missing, never as passing. The same principle applies to posture checks that cannot run — see When a check cannot run. A limitation must never present itself as an all-clear.
Turning a shadow rule on yourself
You can change a rule's status for your own tenant, which includes promoting a shadow rule to active. Occasionally that is the right call: if you have finished your Conditional Access rollout, the single-factor rule becomes rare enough to be worth an alert, and promoting it is a reasonable decision to record.
What to read next
- Alert severity, and what a match actually means — the four evaluation stages in full, and the tuning controls.
- What to do when an alert arrives — for the alerts that do reach you.