Microsoft Sentinel Multi-Tenant Management: A Tuning Guide for MSSPs

Microsoft’s recommended number is five

Not fifty. Five. That is how many workspaces Microsoft recommends you put in a single cross-workspace query before performance degrades. The documented hard cap is 20. If you run sixty tenants, the platform’s own guidance is that you look at eight percent of your customers at a time. Next to it sits the other number: a Defender multitenant view tops out at 100 target tenants. Not a recommendation. A stop. Neither figure comes up in the meeting where you agree to take on customer sixty-one. They come up on the Tuesday morning an analyst asks why the queue only covers part of the book, and by then your delivery model is already built on the assumption they do not exist. This is not an argument against Sentinel. Sentinel was built to protect one organisation, and it does that well. Multi-tenancy arrived later, layered on top, and it still carries that original assumption in every limit. Fine, until the thing you sell is the fleet rather than any single tenant in it. So here is the fine print.

The ceilings that are not on the pricing page

Every number below is documented. None of them are the ones you get shown during a platform evaluation, because individually each is defensible and collectively they describe a product that was not designed for your business model.

What	Ceiling
Tenants in one Defender multitenant view	100
Workspaces one query can reach	20 (Microsoft recommends 5)
Resources in a cross-resource query	100
Log Analytics queries per user, per 30 seconds	200
Queries one user can run at the same time	5
Rows / size / runtime per query	500,000 / ~100 MB / 10 min
Rules pushed to tenants at once	9,500 (95 rules x 100 tenants)

The last row counts rules because rules dominate, but workbooks, automation rules, parsers and custom detection rules all draw on the same 9,500. [INDSÆT kildelink: Microsoft Learn, grænser for content distribution i Defender multitenant management] Then there are the limits that are not a number, just a no: GDAP does not work for Sentinel data. [INDSÆT kildelink] The delegation model you already run for everything else is unsupported here, so cross-tenant access means Azure Lighthouse or Entra B2B. B2B sync creates members, which need real licences. Automation rules that trigger a playbook cannot be distributed across tenants, which excludes essentially all automation worth having. Secondary workspaces get no Defender XDR correlation, so a customer with a split estate is two investigations. New rule versions arrive one at a time. Microsoft flags the new version with an Update badge next to that one rule in that one workspace, and someone clicks through it by hand, carrying Microsoft’s own warning that it may overwrite your query, scheduling and grouping. Sixty tenants. Forty rules. One click at a time. That is the job as the platform currently defines it.

None of those are Sentinel limits

Put the table above together with this list and the obvious conclusion is that Sentinel cannot do multi-tenant. That conclusion is wrong, and acting on it is expensive: It is how MSSPs end up paying for a second SIEM to sit beside the one their customers already licence. Go back through the list and sort it into two piles. The first pile is “limits on a single request”. Twenty workspaces per query is the width of one query, not the reach of your estate: Twelve queries of five workspaces covers sixty tenants, and nothing stops you running them. The 100-resource cap and the row and size limits work the same way. These are batch sizes, not ceilings. The second pile is “limits on a person”. The 200-queries-per-30-seconds budget is enforced per user, so a scheduled job authenticating as its own service principal never competes with your analysts for it. The update badge is a screen element: One rule, one workspace, one human clicking. The version number it is pointing at is a property of the rule itself, and every rule in every tenant can be read in a single pass. Underneath the screen, Sentinel is Azure Resource Manager. Analytics rules, automation rules, incidents and watchlists are resources with a REST API and an ETag, which means you can read a rule, diff it against a baseline, write it back and know precisely which version you wrote. Versioning, drift detection, bulk change and rollback are ordinary operations there. In a portal they are not slow; they do not exist. So the ceilings are real, and they are ceilings on a browser session. You are not running out of Sentinel. You are running out of ways to look at it.

Four things to fix this month

None of these need a project. All four are things you can measure on Friday that you could not measure on Monday, and they are ordered by how quickly you feel them.

Turn on the rules you already deployed

Rules that exist but are switched off are the most common silent coverage gap in a fleet, because nothing about the tenant looks wrong - nobody gets an alert saying an alert will not fire. Counting enabled against deployed across every tenant is a day of work and usually the largest single coverage gain on this list.

Give every rule a version you can see

A rule built from a template is a frozen copy of whatever version existed that day. Put version, enabled state, deployment and value-in-this-tenant on one grid, and the recurring argument about whether all your customers are getting the same service ends in a screenshot.

Make onboarding a preset, not a checklist

Which rules a tenant should have enabled depends on which data it actually sends you, so define the preset by data source: A tenant sending Defender for Endpoint and Entra ID sign-in logs gets one set, a tenant that also sends firewall and DNS logs gets another. Deploy it through the API as a single action at onboarding rather than as a document someone works through. Then re-check every tenant against its preset weekly. Your customers’ own administrators can change their Sentinel configuration, and they do, usually during an incident and usually without telling you.

Sort the queue by time left, not by alert severity

Severity describes the alert. Your commitment describes the customer. If one customer has bought a fifteen-minute response and another has bought next business day, a medium-severity alert in the first needs an analyst before a high-severity alert in the second. Sorting on severity will never surface that, so sort on time remaining against each tenant’s SLA and let severity break ties.

Four things to build this quarter

These cost real engineering time. They also change how many tenants one analyst can carry, which is the number that decides whether growth helps your margin or hurts it, so they are worth scheduling rather than hoping for.

Escalate into ITSM per tenant, in both directions

Some customers want findings in their own service desk, some in yours, some split by severity, and that belongs in configuration rather than in the head of whoever is on shift. Agree one mapping from Sentinel incident fields (severity, category, entity, resolution code) to ITSM ticket fields and use it in every tenant, or cross-tenant reporting dies. And insist on bi-directional sync: the resolution code coming back from the ticket is what feeds the monthly report and trains the noise reduction below.

Generate the monthly report and keep only the commentary

Half a day per tenant per month is a delivery engineer you are paying for and not hiring. The data is in the workspace and the layout never changes. Apply the same discipline to the incident record - capture awareness time, first assessment and IoCs as fields rather than free text - and a NIS2 twenty-four-hour early warning becomes an export instead of a fire drill.

Put your custom detections behind one distribution source, with rollback

One authoritative location, everything downstream a one-way sync, and a difference for one customer expressed as a parameter rather than a quiet local edit. Build the rollback path on day one: a bad rule pushed to sixty tenants is either a bad morning or a bad quarter, and the only variable is whether you can take it back.

Make noise reduction one model with per-tenant thresholds

This is the only item here that compounds. You watch the same detection misfire in sixty environments, which is evidence a single-tenant SOC structurally cannot have - six false positives across six customers is one tuning decision, six deployments and a strong prior for the seventh. Nothing native does this: Sentinel’s fine-tuning recommendations are preview, per rule, per workspace, fourteen days, and need entity mapping configured first.

Is Microsoft Sentinel being retired? No, and neither is Lighthouse

No. Microsoft Sentinel itself is not being retired. What retires on 31 March 2027 is the Sentinel experience in the Azure portal; Sentinel moves to the Microsoft Defender portal, and your workspaces, data, KQL, connectors and APIs stay as they are. Azure Lighthouse is not retiring either. Lighthouse in particular is garbled everywhere. It remains supported and is in fact required for cross-tenant Sentinel work. Querying another tenant’s workspace with the workspace() operator from advanced hunting, analytics rules or workbooks needs a delegation. What changed for partners is the other side of the model, since GDAP does not work for Sentinel data. What is retiring is Sentinel in the Azure portal, on 31 March 2027, moved in February 2026 from the original 1 July 2026. A user interface, not a platform. Your workspace, ingested data, KQL, connectors, retention, billing and the ARM APIs all stay exactly where they are. The planning conclusion is narrow and useful. Anything in your delivery that depends on a screen has a deadline. Anything built on the API does not.

Choosing the best AI SOC for MSSPs

If you are buying this layer rather than building it, the list above is your specification. Does it manage alert rules by version, enabled state, value and deployment, or only display them? Can you push to a group of tenants and roll back? Is the noise reduction a model that learns from your triage decisions, or a suppression list with a marketing label on it? And does it work through the API, without a licensed guest account sitting in every customer tenant? That is what Seculyze built Unify for: API-native on the Sentinel you already run, one console across every tenant, alert rule versioning and bulk deployment with presets, cross-tenant noise reduction, ITSM routing per tenant. Customers report alert handling dropping from around 20 minutes to around 6 - up to roughly 70% off mean time to respond [INDSÆT: link til case/datagrundlag og periode], which at fleet scale is the difference between hiring an analyst and not needing to. Related: Microsoft Sentinel alert tuning checklist · Agentic AI for the SOC: which AI, for which problem See it against your own tenants: seculyze.com/unify