After 31 March 2027 Sentinel does not run in the Azure portal. That is not a recommendation, it is a date.
Microsoft states that after 31 March 2027 Sentinel will no longer be supported in the Azure portal and all customers will be redirected to the Defender portal. Everything new already lands in the Defender portal first, and the Azure portal is described as maintenance and parity only. The question is when you move, not whether.
- 31 March 2027Azure portal support ends
- No E5 requiredAvailable without Defender XDR or E5
- Unified queueOne incident queue for SIEM and XDR
- Maintenance onlyMicrosoft description of the Azure portal
Eight differences between the two portals, and what each one means in practice.
The date, which is the part that removes the debate
Microsoft states that after 31 March 2027 Sentinel will no longer be supported in the Azure portal and will be available only in the Defender portal, and that all customers using the Azure portal will be redirected. Microsoft recommends starting to plan now. Treating this as optional means the transition happens on Microsoft schedule and under a deadline rather than on yours.
One incident queue instead of two
In the Azure portal the Sentinel incident queue is separate from Defender. In the Defender portal there is a unified incident queue for SIEM and XDR, incidents are automatically enriched with Defender signals, and correlation across domains happens automatically using AI and machine learning. For a team currently working two queues and manually joining them, this is the largest day to day change.
Attack story and blast radius, instead of log-centric investigation
The investigation experience moves from log-centric workflows to an attack story and incident graph, with unified entity pages for devices, users, IP addresses and Azure resources combining Sentinel and Defender data. Blast radius analysis visualises possible attack propagation paths and assesses business impact, which is a genuinely different question from what the logs contain.
Hunting across SIEM, Defender and the data lake together
Advanced hunting in the Defender portal covers SIEM, Defender and the data lake in one place, with support for hunting in the tenant and in workspaces, and reuse of your existing Sentinel workspace queries and functions. That last point matters more than it sounds: the queries your team has built are not thrown away by the move.
Security Copilot, which is simply not available in the Azure portal
Microsoft lists Security Copilot as not available for Sentinel in the Azure portal. In the Defender portal it provides automated incident summaries, guided response actions, script and file analysis, incident reports, and autonomous agents for alert triage, threat intelligence briefing and threat hunting. Microsoft states there is included capacity for E5 and E7 customers, which is worth checking against your subscription.
A data lake with tiered retention, and thirty days of free raw logs
The model moves from Log Analytics-centric to a centralised data lake with tiered retention and simplified onboarding, with a unified schema across Sentinel and Defender. Microsoft notes that advanced hunting raw logs are free for thirty days without ingestion. For organisations where Sentinel cost has been the recurring argument, the data model change is the part worth modelling properly.
Native multi-tenant, instead of Azure Lighthouse
Multi-tenant and managed service provider operations move from Azure Lighthouse to native multi-tenant operations with delegation and management built in, plus unified cross-tenant incidents and alerts. For a group with several tenants, or anybody providing security operations to clients, this changes the architecture rather than just the interface.
Unified Defender role-based access control, with row-level support
Permissions move from Azure role-based access control to unified Defender role-based access control, with row-level support. This is not a cosmetic change and it is the part of a transition most likely to surprise you, because access that worked through Azure roles has to be reproduced deliberately in the new model rather than inherited.
Three capabilities are limited if you bring Sentinel across on its own.
Sentinel is generally available in the Defender portal including for customers without Defender XDR or an E5 licence, and you can use it there even without other Defender services. Microsoft is also clear about what that costs you.
- Microsoft Security Exposure Management is limited or unavailable, which means the posture and attack path recommendations that come with the unified platform are not there.
- Custom detection rules, which Microsoft notes are provided by Microsoft Defender, are limited or unavailable. Sentinel analytics rules still work, so this affects the Defender-side detection authoring rather than your existing rules.
- The Action center, also provided by Microsoft Defender, is limited or unavailable. That is where remediation actions and their approval status are managed across the Defender products.
- None of this is a reason to delay the move, because the deadline applies regardless. It is a reason to be precise about what the destination looks like for your specific licensing, so nobody is surprised in week two and concludes the migration went wrong.
Four things that decide whether a transition is boring, which is the goal.
We rebuild permissions deliberately rather than assuming they carry
The model moves from Azure role-based access control to unified Defender role-based access control with row-level support. Access that currently works through Azure roles has to be reproduced in the new model. This is the most common source of surprise in a transition, and it surfaces as somebody being unable to see an incident during their first shift in the new portal.
We rewrite the analyst runbooks against the new navigation
Logs became advanced hunting. Entity behavior became entity pages under assets. Workspace manager and news and guides are not available at all. An analyst following an old runbook under pressure concludes the capability is gone rather than moved, and that is how a technically successful migration is judged a failure by the people using it.
We treat the unified queue as a working practice change, not a UI change
Moving from a separate Sentinel queue to a unified queue with automatic Defender enrichment and cross-domain correlation changes how triage works and what an incident contains. Teams that are walked through it with real incidents adapt in days. Teams that are moved overnight spend a fortnight distrusting the correlation, and some of them turn things off.
We check what you already have before anybody buys anything
Security Copilot is unavailable for Sentinel in the Azure portal and available in the Defender portal, and Microsoft states there is included capacity for E5 and E7 customers. Organisations frequently arrive at the transition assuming Copilot is an additional purchase when part of it is already covered. Establishing that early changes what the destination looks like.
Six UAE situations where the transition deserves planning now.
A regulated firm with a documented security operations process
Where a documented process has been shown to a regulator, an auditor or a client, the transition changes the interface those procedures describe and the permission model behind them. Updating the documentation is part of the migration rather than an afterthought, because a procedure that does not match reality is a finding.
A managed service provider or a group with several tenants
Multi-tenant operations move from Azure Lighthouse to native multi-tenant operations with unified cross-tenant incidents and alerts. That is an architectural change rather than a portal change, and for anybody delivering security operations across client tenants it deserves its own planning rather than being folded into a general migration.
An organisation running Sentinel without Defender XDR
Entirely supported, and Microsoft is explicit that Sentinel is available in the Defender portal including for customers without Defender XDR or an E5 licence. It is also the case where the three limited capabilities apply. Being precise about what the destination looks like on your licensing avoids the conclusion that something went wrong.
A team that has invested heavily in workbooks and queries
Reassuring news: advanced hunting in the Defender portal supports hunting in the tenant and in workspaces and the reuse of existing Sentinel workspace queries and functions, and workbooks move to a new location rather than disappearing. A transition is nonetheless a good moment to retire the ones nobody has opened in a year.
An organisation where Sentinel cost is under pressure
The data model moves from Log Analytics-centric to a centralised data lake with tiered retention and a unified schema across Sentinel and Defender, and Microsoft notes advanced hunting raw logs are free for thirty days without ingestion. Where ingestion cost has been the recurring argument internally, modelling this properly during the transition is worth the effort.
An organisation with a small team and no slack
The hardest case, because there is no capacity for a project and the deadline applies anyway. Here the answer is a staged transition with a clearly owned plan, or a managed arrangement covering the operations while the move happens. What does not work is deferring until the redirect happens automatically.
Where UAE organisations running Sentinel currently stand.
| Feature | Transitioned | Aware, not planned | Unaware of the deadline |
|---|---|---|---|
Working in the supported portal after March 2027 | Yes | Eventually | Not yet |
One incident queue for SIEM and XDR | Yes | No | No |
Cross-domain correlation automatic | Yes | No | No |
Attack story and blast radius analysis | Yes | No | No |
Security Copilot available | Yes | No | No |
Receiving new Sentinel capabilities first | Yes | No | No |
Permissions rebuilt in the new RBAC model | Yes | Not started | Not started |
Runbooks match the interface analysts use | Yes | Yes for now | Yes for now |
Transition happening on your schedule | Yes | Unlikely | No |
Frequency in the UAE market | Uncommon | Common | Common |
Navigation changes your team will hit in the first hour.
| Azure portal | Defender portal | |
|---|---|---|
| Logs | Investigation and response, then Hunting, then Advanced hunting | |
| Incidents | Investigation and response, then Incidents and alerts, then Incidents | |
| Workbooks, Hunting, Notebooks, MITRE ATT&CK | Microsoft Sentinel, then Threat management | |
| Threat intelligence | Threat intelligence, then Intel management | |
| Entity behavior | Entity pages under Assets, with Sentinel events on each user or device | |
| Data connectors, Analytics, Watchlists, Automation | Microsoft Sentinel, then Configuration | |
| Content hub, Repositories, Community | Microsoft Sentinel, then Content management | |
| Settings | System, then Settings, then Microsoft Sentinel | |
| Workspace manager | Not available | |
| News and guides | Not available |
Five steps, ideally starting well before the deadline.
- 1
Assess the current environment and the destination
Workspaces, connectors, analytics rules, playbooks, workbooks and integrations, plus what the Defender portal looks like on your specific licensing including whether Security Copilot capacity is included and whether the three limited capabilities apply to you.
- 2
Map the permission model
Every access path currently granted through Azure role-based access control, reproduced deliberately in unified Defender role-based access control, using row-level support where the current model depends on it. This is the step that most often causes a bad first day if it is skipped.
- 3
Onboard and run both in parallel
Onboarding integrates Sentinel with Defender automatically rather than requiring the Defender XDR connector to be enabled separately. Running in parallel lets the team work real incidents in the new portal while the familiar one is still there, which is what makes the change survivable for a small team.
- 4
Rewrite the runbooks and walk the team through the queue
Navigation updated for what moved and what was removed, and a working session on the unified incident queue, the attack story view, entity pages and blast radius analysis using genuine incidents from your own environment. Two hours here saves a fortnight of distrust.
- 5
Adopt what the Azure portal never had
Security Copilot for incident summarisation and guided response, the AI-assisted playbook generator, case management for multi-incident investigations, and SOC optimisation recommendations. These are the reasons the move is worth doing rather than merely necessary, and they are best adopted once the team is settled.
What organisations ask about the Sentinel transition.
Fifteen questions worth answering first.
Scope
- How many workspaces are in scope?Workspace manager is not available in the new portal.
- Do you have Defender XDR, or Sentinel alone?Both are supported, with a documented capability difference.
- Are you multi-tenant or using Azure Lighthouse?Native multi-tenant operations replace it.
- Is Security Copilot capacity included in your subscription?Microsoft states included capacity for E5 and E7.
- When does your current Sentinel commitment renew?A useful anchor for planning the move.
What needs redoing
- How is access currently granted through Azure RBAC?It moves to unified Defender RBAC.
- Do you rely on row-level access control?Supported in the new model, and needs configuring.
- Which playbooks are in active use?Automation moves and is worth reviewing rather than porting blindly.
- Are your workbooks still used, or historical?A transition is a good moment to retire the unused ones.
- Do integrations use Sentinel APIs?The API surface is unified.
Your team
- Who works incidents day to day?They meet the unified queue first.
- Are runbooks written against Azure portal navigation?Several items moved and two were removed.
- Is anybody trained on Defender portal investigation?Attack story and entity pages are a different model.
- Do you have out of hours coverage?Do not transition into an unstaffed window.
- Who owns the transition end to end?Without an owner it stalls at partially migrated.
The pages around this one.
Microsoft Sentinel
The platform itself: data connectors, analytics rules, automation and what a SIEM deployment involves.
SOC as a service
The managed option, for organisations without the capacity to run security operations themselves through a transition.
Defender for Cloud
The Azure posture side of the same unified platform, and how the two fit together in the Defender portal.
Put 31 March 2027 in the plan while it is still a project rather than a deadline.
Every organisation running Sentinel in the Azure portal faces the same date, and the help available will concentrate towards the end of it. Starting now means running in parallel, moving at your own pace, and adopting the new capabilities deliberately.
Related Services
Explore more solutions that work great with this service
Microsoft Sentinel
Cloud-native SIEM and threat intelligence
SOC-as-a-Service
24/7 SOC on Microsoft Sentinel
Defender for Cloud
Azure posture, and the free tier almost nobody has enabled
Managed Security Services
MSS on Microsoft Defender XDR and Sentinel
Microsoft Security Dubai
Entra, Defender, Purview, Sentinel, and what you already own
Defender for Endpoint
Business, Plan 1 or Plan 2, and what each actually gives you
Defender for Identity
Lateral movement and domain dominance, detected across AD and Entra
Microsoft Secure Score
Why part of your score is unreachable, and which points matter