Microsoft 365 alerts tool

Download spike at 14:02. One email, with account and device, at 14:07.

A typical alert is a severity string and a username. 1Security sends the rest: which policy fired, how far today sits from that account's own normal, which device and city it came from, and one click to the exact events. 50+ detections show their live match count in your tenant before you switch them on, one incident is one email, and the alert line is yours to move at any time.

  • 50+
    prebuilt detections, each showing how many resources match in your tenant right now
  • 5 min
    typical time from an audit event to the affected policies re-evaluated and the email sent
  • 1 email
    per incident - episodes and cooldowns collapse a 40-event burst into one message

The problem

An alert names a username. Judging it usually takes an hour.

A fixed-threshold alert fires on a number you guessed months ago and hands you a row. Everything you need to judge it lives somewhere else.

An alert names an account. Judging it means answering what that account can reach - in a typical tenant hundreds of thousands of files through groups, links and inheritance - whether 300 downloads is unusual for it, and which files were involved. Permissions, sign-ins, mailbox access and activity history each live in a different place. Stitching them together is the hour.

Threshold rules carry a second cost: every number is a bet made blind. Set "more than 100 downloads" high and you sleep through the leaver pulling 95 files a day for a week; set it low and the mailbox trains everyone to ignore it. Most teams learn which bet they made a quarter later, and most teams never move the number again.

1Security starts from the other end. Detections show their live count in your tenant before you enable them, baselines are learned per policy and per account, and every alert carries its evidence with it - so the verdict takes minutes, not an hour.

Capabilities

One alerting model for trends, activities, anomalies and automations.

Everything that can wake you up in 1Security is evaluated by the same real-time engine and mailed through the same two channels.

  • One engine underneath

    Audit-log activity re-evaluates only the slice of the policies it touched, within minutes, with per-tenant coalescing so no event is dropped and a reconciliation pass every 30 minutes as the floor. Counts and baselines update while you watch.

  • 50+

    Detections counted before you enable them

    The prebuilt library shows how many sites, users, files or links in your tenant match each detection right now - "anyone links on sensitive files: 1,240", "guests idle for a year: 86". You enable a rule knowing exactly what it will say.

  • Instant and digest channels

    Instant alerts ride the real-time path and are mailed the moment a line is crossed, with a cooldown so a burst is one message, not forty. Digests collect the rest on the interval and recipients you choose - hourly, daily or weekly.

  • 3.5σ

    The anomaly line

    Every policy, user, app and AI agent learns its own baseline: today against the median of its trailing 30 days. The alert line defaults to 3.5 sigma and is yours to move - history reclassifies at read time, so tuning takes seconds, not a quarter.

  • Episodes, not events

    A spike opens one episode that tracks its peak and closes when behaviour returns to normal. One notification, one triage decision - open, acknowledge or dismiss - instead of an email per event.

  • Overrides per tenant, type, resource

    Set the alert line and channels once for the tenant, then override per resource type or per single site, user or app - the finance site tighter, the marketing team looser - without touching the policies themselves.

No numbers to guess

The default rule needs no threshold from you.

Deviation from the policy's own baseline is the default alert rule: a spike of 50% over normal fires, and that is the whole configuration.

Deviation is three independent switches. Spikes are on by default. Drops are off, because holidays depress every policy at once. Silence is off, because a count hitting zero usually means something broke, not that risk disappeared. Each switch is a deliberate default you can flip per policy - and a plain threshold ("more than 500 downloads in an hour") is still there for the cases where you know the number.

Below the alert line, nothing is thrown away. Everything down to 2 sigma is kept as Info: stored, filterable, never mailed. When you suspect you missed something last week, you lower the line, filter to that week, and read what was already recorded below your old threshold.

In practice

A mass download, minute by minute.

What the alert path looks like on the day it matters.

  1. 01

    14:02 - the spike begins

    A contractor account starts pulling files from a finance site. The events land in the audit stream and the engine re-evaluates the affected policies within minutes - not on tonight's schedule.

  2. 02

    14:06 - an episode opens

    Today's download count for that account crosses its own 30-day baseline: 340 files against a usual 12. One anomaly episode opens and starts tracking the peak; the account's reach, device and origin are already attached.

  3. 03

    14:07 - one email, with the why

    The instant channel mails the moment the line is crossed: which policy, which account, how far from normal, on which device, from which city and network. The cooldown holds back the follow-up noise - the next 200 downloads do not send 200 emails.

  4. 04

    14:15 - from alert to action

    One click lands on the exact events behind the number in Activity logs. From the same screen: revoke the access, expire the links, disable the account - staged behind the review window and written to Actions with who approved it and when.

The difference

What every alert carries with it.

These are properties of the model, not features bolted onto a notification.

  • The default rule is deviation from the account's own 30-day baseline - you add a fixed number only when you know it
  • The email names the user plus what it can reach, its device, its city and network, and how far today sits from its normal
  • Moving the alert line reclassifies history at read time - tuning takes seconds, not a quarter
  • Findings down to 2 sigma are kept as Info - stored and filterable, never mailed
  • AI agents get their own baselines, so "the finance agent read four times its usual files today" is a first-line signal
  • Defender and Sentinel alerts land in the same list, already joined to the users, groups, mailboxes and apps they concern
  • One cooldown-controlled email per episode instead of one per event - a 40-event burst is one message
  • A 14-day warm-up before anomaly detection says anything, and a liveness strip on the engine ("last evaluation 3 minutes ago") so silence is verifiable

Deployment

Live the same day, honest from day one.

Connect with read-only consent and the engine starts learning immediately: first findings the same day, anomaly detection after a deliberate 14-day warm-up. No agents, no appliance, no SIEM contract. It runs on standard Microsoft 365 licenses, Business Basic upward, and stays fast on tenants with more than 40 million files because it re-evaluates only the slice each event touched.

  • 1 day
    from read-only consent to the first findings and live counts
  • 14 days
    of history before anomaly detection sends its first alert
  • 500M+
    files in the largest tenants the engine already runs on - no E5 needed

Use cases

Three alerts teams set up in week one.

The exfiltration tripwire: an hourly instant alert on a one-hour download window, typically "more than 500 downloads by one user in an hour". A mass download is flagged while it is unfolding, with the device and the origin attached - the difference between an incident report and an interrupted incident.

The drift watch: new anyone links on files with sensitive data, permission changes on finance sites, sign-ins from a first-seen country. Each is a prebuilt trend with a live count, one click from becoming an alert.

The retro check: "we think we missed something last week" stops being a forensics project. Lower the anomaly line, filter to that week, and read what was recorded below your old threshold - same tenant, same data, same detector.

  • Real time monitoring

    A mass download takes 20 minutes; the nightly report finds it tomorrow. The engine the alerts ride on.

    See real time monitoring
  • High severity alert triage

    The alert lands at 02:14. What you know by 02:20 - the account, its reach, its baseline, the device.

    See alert triage
  • Anomaly detection

    Every account, app and AI agent scored against its own 30-day baseline - the detector behind the deviation rule.

    See anomaly detection

FAQ

Questions teams ask before switching alerting on.

Do I have to tune thresholds before the alerts are useful?

No. The default rule is deviation from each policy's own baseline - a 50% spike over normal fires without any number from you. The anomaly line defaults to 3.5 sigma, and moving it reclassifies existing history at read time, so tuning is immediate and reversible rather than a quarter-long experiment. Where you know the number, a plain threshold is one field away.

How fast do alerts arrive after something happens?

Audit-log activity re-evaluates the affected policies within minutes of the event - typically around five from the moment the audit event arrives. Instant alerts are mailed the moment a line is crossed, with a cooldown against bursts; digest alerts collect everything else on the interval you set.

Does this replace Microsoft Defender alerts?

It joins them. Defender and Sentinel alerts appear in the same list, linked to the users, groups, mailboxes and apps they concern - and alongside them you get 1Security's own policy detections, which exist nowhere else because they are computed from your permission graph and baselines.

What licenses do we need?

Standard Microsoft 365 licenses from Business Basic upward. No E5, no Entra P2, no SIEM contract, nothing to install. A Microsoft Defender plan is only needed if you want Defender's own alerts ingested alongside 1Security's detections.

Will this flood our inboxes?

The model is built against that: episodes collapse a spike into one notification, instant alerts carry cooldowns, findings below the alert line are stored as Info instead of mailed, and everything else arrives as a digest on your schedule. In practice a mid-size tenant sees a handful of instant emails a week, not a hundred.

See what your tenant would alert on, before you enable a single rule.

Connect read-only and the 50+ detections show their live counts in your tenant the same day. Turn on the three that matter, and the next incident arrives as one email with the account, the device and the events attached.

Or keep guessing thresholds and stitching the evidence together by hand.