Microsoft 365 and Defender monitoring for MSPs: watching the tenant, not just the endpoint
A green dashboard of healthy laptops tells you nothing about the forwarding rule quietly copying the finance director's inbox to a Gmail address. That rule lives in the tenant, not on the device, and an agent on the device will never see it. Microsoft 365 and Defender monitoring for MSPs is the discipline of watching that layer: sign-ins, mailboxes, alerts and configuration drift across every client tenant you manage. This piece explains why endpoint monitoring alone leaves the door open, what good multi-tenant monitoring looks like, how vendors package it, and ends with a checklist of signals every managed client deserves.
Why endpoint monitoring misses tenant-level risk
Traditional RMM grew up watching machines: disk space, services, patch status, CPU. If you want the basics, our explainer on what RMM actually does covers them. The model assumes the machine is where things go wrong. For a modern small business, that assumption is out of date.
Identity is now the perimeter. A stolen password plus an approved MFA prompt gives an attacker the mailbox, SharePoint and Teams from a browser on the other side of the world. No malware lands on any endpoint you manage. Every device check stays green. The compromise is entirely real.
The received wisdom is that Defender on the endpoint covers this. It does not. Defender for Endpoint and Defender for Business protect devices; the identity and mail signals sit in Entra ID and Exchange Online, and they have to be pulled and read separately.
Rule of thumb: if an attacker could do it from a browser without touching a managed device, your endpoint agent will not see it. Watch the tenant as seriously as the fleet.
The four tenant signals that matter most
Risky sign-ins and impossible travel
Entra ID flags sign-ins it considers risky: unfamiliar locations, anonymising IPs, token anomalies, atypical travel. Full risk detection depends on Entra ID P2, which many small clients lack, but even basic sign-in logs show failed MFA storms, legacy authentication attempts and logins from countries the client has never done business in. Someone has to be looking.
Mailbox rules and forwarding
Business email compromise follows a well-worn pattern: gain access, create an inbox rule that hides replies from a supplier or moves anything mentioning "invoice" to an obscure folder, then wait. New inbox rules, external forwarding and changes to mailbox permissions are some of the highest-value alerts you can raise, and they cost almost nothing to watch.
Defender for Business alerts
Microsoft 365 Business Premium includes Defender for Business, so plenty of your clients already own a capable EDR. The problem is that its alerts land in each tenant's own security portal. Unless you have wired them into your queue, they are a smoke alarm in an empty house. Alerts should become tickets, with an owner and a response time.
Secure Score drift
Secure Score is imperfect, but its movement is useful. A sudden drop usually means someone changed something: security defaults switched off, a conditional access policy excluded "just for now", a new admin created. The drift test: if you cannot say why a client's score fell last month, you are not managing their tenant, you are hosting it.
What good multi-tenant monitoring looks like
Logging into forty admin centres one at a time is not monitoring. It is sightseeing. Good multi-tenant M365 monitoring has a few recognisable traits.
- One consented connection per tenant. Granular delegated admin privileges (GDAP) or a scoped app registration, with least-privilege roles. Skip this and you end up with shared global admin accounts, which is the exact risk you are paid to prevent.
- Signals become tickets. Alerts belong in the same queue as everything else, tied to the client, with SLAs. A separate security inbox is where alerts go to age. If you are weighing a helpdesk, our guide to the best PSA for small MSPs covers what that queue needs.
- Baselines, not just alerts. A defined standard per client (MFA enforced, legacy auth blocked, external forwarding disabled) and a report of which tenants deviate.
- Context alongside the device. When a user reports a slow laptop and has also had three risky sign-ins this week, you want to see both on one screen.
- Licence and user hygiene. Disabled users still holding licences, leavers with active sessions, guest accounts nobody remembers inviting.
This applies whether the tenants belong to clients or to your own company. An internal IT team with one tenant needs the same signals, just without the multi-tenant switching; our piece on RMM for internal IT teams covers what else changes.
Built in or bolted on: how vendors differ
This is where buying decisions get muddy. Vendors handle Microsoft 365 in roughly three ways.
| Approach | What you get | Where it hurts |
|---|---|---|
| Endpoint only | Device health, patching, maybe Defender antivirus status | No sign-in, mailbox or Secure Score visibility at all |
| Paid integration or add-on | Tenant signals via a separate module or third-party tool | Extra per-user or per-tenant cost, another console, alerts that may not reach your tickets |
| Built into the platform | Tenant signals in the same console and queue as devices | Depth varies; check which signals are genuinely covered |
The add-on route is common, and the cost tends to hide in per-user pricing that grows with every client hire. Our breakdown of add-ons and hidden fees vendors leave off the pricing page is worth reading before you sign. During a trial, connect a real tenant, create a test forwarding rule and time how long it takes to become a ticket. That single test tells you more than any datasheet.
Failure modes: what goes wrong without tenant monitoring
- The invisible compromise. A mailbox is controlled for weeks; the first sign is a supplier asking why their bank details changed.
- The unread alert. Defender raised it correctly, in a portal no one opened.
- The temporary exception. A conditional access exclusion added for a travelling director is still there two years later.
- The ghost admin. A former technician's admin role outlives their employment.
The tenant signal checklist
Every managed client deserves someone watching these. Skip any of them and you are relying on luck.
- Risky and anomalous sign-ins: unfamiliar countries, anonymising IPs, impossible travel.
- MFA failures and fatigue patterns: repeated denied prompts against one user.
- Legacy authentication attempts: these should be blocked, and attempts are worth knowing about.
- New inbox rules: especially delete, move-to-folder or mark-as-read rules.
- External forwarding: any mailbox forwarding outside the organisation.
- Mailbox permission changes: new FullAccess or SendAs grants.
- Defender for Business alerts: routed into your ticket queue with an owner.
- Secure Score changes: with a reason recorded for every drop.
- Admin role changes: new global admins and privileged role assignments.
- Conditional access and security defaults edits: anything weakening policy.
- New app consents: OAuth apps granted mail or file access.
- Leaver hygiene: disabled users with licences, sessions or forwarding still active.
The one-week test: pick a client and ask whether you would know, within a working day, about each item above. Every "no" is a gap in the service you are already charging for.
Where this fits with Helios
Helios includes Microsoft 365 management in the same platform as monitoring, patching, security and ticketing, so tenant signals and device signals sit side by side and land in one queue. Helio, the built-in AI agent, can triage those alerts and investigate alongside device data, with approvals where you want a human to decide. It is on every plan rather than sold as an add-on. The honest limit: tooling surfaces the signals, but deciding each client's baseline and acting on alerts is still discipline. You can see how Helios compares with other MSP platforms.
Helios: AI-native RMM and PSA for MSPs and internal IT. 14-day trial and no feature gating. Start free.