Forum Discussion
The Sentinel migration mental model question: what's actually retiring vs what isn't?
I went ahead and wrote up the full breakdown based on the framing above. If it's useful for anyone working through this: https://securingm365.com/defenderxdr/sentinel/sentineldefender-part1/
Covers the architectural distinction in more detail, the operational changes that actually affect day-to-day SOC workflows, and how to think about the planning horizon given the extended deadline. Written with the scale and multi-tenant crowd in mind rather than single-tenant simple environments.
Would genuinely welcome any pushback or edge cases people have hit that aren't in there.
Thanks for a great series! I will be following it closely, appreciated good sir.
As for edge cases - in some serious MSSP setups GDAP is not a solution, its a hassle - there are no isolation between you and the multiple environments and therefor its skipped (and should be, we have so many instances where 1 key unlocks to many doors). What seems to be missing in the pusselpieces aswell from all the current information regarding this migration from Microsoft is that MSSP (atleast those that understand sentinel) are separating the Security Operations (SOC) and the actuall management of Sentinel (Log analytics, building playbooks, automationrules, repo with config, connectors, content hub etc). They are rarely the same team.
So with that in mind, the management of Sentinel happens in Azure (you deploy resource in a RG and work on the sentinel layer for connectors and keeping that up to date - also jacking in github or devops to pusch analytic rules centrally (or "custom folders"-yaml - that was introduced 1-2 years back in devops integration).
My understanding, which was solidified by reading your blog, is that those parts stays the same - however, there are some troublesome points that might get answered in your future series - but the automation and correlation. Currently there is a drift where XDR comes in and updates incidents well after all automation in Sentinel has run. So XDR is working in a different timeframe (a lot slower) - which is not what we need and in some cases even a hard stop when looking for new solutions due to regulatory/sensitive matters. Sentinel automation was slow enough, but now we need parity rules for all automationrules that looks for "on incident updates" (on top of the "on incident creation") - becuse XDR comes in after all automation has run and changes status or updates a clustered incident, correlating some Analytic rule you have automation built to look for "on creation"... This is a current painpoint - maybe XDR will be a lot quicker on those actions once the full migration is completed, but it dosent look good in current state.
Something that im worried about as well, are all the playbooks that are running and doing custom actions (revoking sessions, populating watchlists, updating entra groups or firewall exclusions/blocks, enrichment in incidents (ip lookups, comments, VT) etc etc). Some MSSP would keep as IP (they will have a bigger problem), but most MSSP would build that up in the customers tenant, customer own it and the data (and have versioning through github/devops). Im worried that this will break, the people working with it needs two access now instead of 1 (XDR Rbac/Security Administrator AND Azure RBAC owner & Sentinel roles - Yes, you need owner to deploy Azure Policies for some connectors in tenant root, you need owner on subscription to modify the resource datalake (enable) and some other cost related items to subscription/deletion of items). How will this play out? We know almost nothing on this part from Microsoft, they have only posted about the Operational side (SOC) moving to XDR instead of Azure. But all management actually happens in Azure.
again, thanks for the blog, very good information!
Thanks! I really appreciate the thoughtful reply and the kind words.
You’re spot on about the MSSP edge cases. GDAP can be a pain in real multi‑tenant setups where strict isolation is required; one broad access path that touches many customers is exactly what a lot of MSSPs try to avoid. I also agree with your separation of concerns: SOC operations (incidents, triage) and platform/management (Log Analytics, playbooks, connectors, CI/CD) are usually different teams with different access models, and that split matters a lot for how this migration plays out.
A few quick thoughts that line up with what you said and what I’ll dig into in the series:
- Management stays in Azure: for most MSSPs the platform work (deploying resources, maintaining analytics rules, CI/CD for content) will remain an Azure/ARM story. That’s where ownership, versioning, and deployment pipelines live, and Microsoft hasn’t signalled that part will move wholesale to Graph.
- Automation parity is essential: you’ll need automation that reacts to both on creation and on update events. Design playbooks to be idempotent and to handle out‑of‑order updates so XDR’s slower updates don’t break workflows.
- Delegation patterns matter: Lighthouse, least‑privilege service principals, JIT elevation, and separate principals for SOC vs platform tasks are the practical ways MSSPs keep isolation without losing manageability. GDAP helps in some scenarios but isn’t a silver bullet for strict isolation models.
- Inventory and CI/CD: map every playbook, connector, automation rule, and required RBAC. Use central CI/CD to push tenant‑scoped changes (GitHub/DevOps) but authenticate into each tenant with delegated, least‑privilege credentials or Lighthouse patterns.
Totally agree that the dual‑access problem (needing both XDR/Security Admin and Azure RBAC/Sentinel roles) is going to be an operational headache for many teams. That’s why clear role separation, dedicated principals, and careful CI/CD design are going to be the practical workarounds.
I’ll look to cover Lighthouse vs GDAP tradeoffs, CI/CD patterns for multi‑tenant Sentinel management, and concrete automation patterns (including on‑update handling and Graph bridging) in upcoming posts.