Defender Portal Migration Pushed To March 2027
TL;DR - Microsoft has extended the Sentinel-to-Defender portal migration deadline from 1 July 2026 to 31 March 2027, giving SOC teams another nine months to migrate unified RBAC, conditional access scope, custom hunting queries, integrations and runbooks. The advanced hunting Take Action wizard inside the unified Defender portal is now the single most underrated feature in the migration, letting you go from a KQL query to a tenant-wide email-and-domain block in under a minute, provided your unified RBAC permissions are set to manage rather than read. What you need to do: do not slow down because of the extension, finish the RBAC redesign before December 2026, and stop standing up new SIEM logic in the legacy Azure portal.
Migration Timeline By The Numbers
| Milestone | Date / State |
|---|---|
| Original Sentinel-to-Defender portal deadline | 1 July 2026 |
| Revised deadline announced April 2026 | 31 March 2027 (nine-month extension) |
| Sentinel exclusively in Defender portal from | July 2026 (Azure portal becomes redirect-only soft) |
| Hard cutoff (Azure portal access ends) | 31 March 2027 |
| Advanced hunting Take Action wizard | GA in unified Defender portal |
| Unified RBAC permission to use Take Action | Manage on Security Data + Email & Collab |
| Custom RBAC role worth keeping in Azure | Resource lock administrator (basically) |
🎙️ This blog unpacks the Defender portal segment of Out of Band: A Microsoft Security Podcast, where Andrew O'Young (Microsoft MVP, Informotion), Anthony Porter (Canon Business Services) and I work through the operational reality of the unified SecOps migration. The full episode is on YouTube.
I have spent the last six months in the same conversation. "We have to migrate Sentinel by July. We haven't started. RBAC is the part that's going to hurt."
I have had this conversation with so many SOC leads in Australia, the UK and the US that I genuinely started keeping a tally. The tally is two days old and the count is at fourteen. Every conversation hits the same wall: the original July 2026 deadline did not give most enterprises enough time to redesign their RBAC, migrate their custom hunting queries, retool their on-call runbooks, and validate that the integrations they care about still work in the Defender portal.
Microsoft has now done what most of those teams quietly hoped they would. The deadline is no longer 1 July 2026. It is 31 March 2027.
That is nine extra months. It is not free time. It is the time you needed in the first place. Here is what to do with it, what not to do with it, and why the Take Action wizard in advanced hunting is the underrated feature most teams will discover too late.
The Nine-Month Extension
In April 2026, Microsoft published the revised transition timeline for moving Sentinel out of the Azure portal and into the unified Defender experience. The headline shift:
- From July 2026: Sentinel will be exclusively available in the Defender portal. The Azure portal experience will redirect users to the new portal and will no longer be the primary surface.
- By 31 March 2027: Sentinel in the Azure portal becomes fully unsupported. Customers still on the Azure portal will be automatically redirected to the Defender portal.
The "exclusively in the Defender portal from July 2026" line is the part most read-once articles miss. It does not mean July is a soft date. It means from July, Microsoft considers the Defender portal the canonical experience, and the Azure portal becomes a deprecated surface even though it technically still loads. New product surface area will not back-port to Azure. New investigation features will only land in Defender. The cost of staying on the old portal climbs from July onward, not from March 2027 onward.
The hard cutoff is March 2027. The operational cutoff for new feature work is July 2026. Plan accordingly.
Why The Extension Actually Matters: Unified RBAC
The headline reason the original deadline was unworkable for many enterprises is unified role-based access control. The Defender portal's RBAC model is different from the Azure RBAC model that Sentinel customers have been living with since 2019. The conversion is not a checkbox. It is an architecture redesign.
In the legacy Azure model, Sentinel access is granted via Azure RBAC at the workspace level. Contributor, Reader, Sentinel Contributor, Sentinel Responder are coarse and resource-scoped. In the unified Defender RBAC model, permissions are granted across the unified workload (Defender for Endpoint, Defender for Office, Defender for Identity, Defender for Cloud Apps, Sentinel inside Defender, and the new Security for AI blade) on much more granular permission groups:
- Security data - read/manage on hunting, custom detections, alerts, incidents
- Email & collaboration data - read/manage on email metadata and message bodies
- Authorisation and settings - read/manage on portal configuration
- Custom detections, automated investigations and response controls
The good news Andrew flagged in the podcast: unified RBAC has matured significantly since this time last year. The granularity now covers most realistic SOC personas without needing custom roles. You can split a hunter from a responder from a Tier 1 triage analyst from a content author without writing one custom role definition.
The bad news: if your existing SOC operates on three Sentinel roles, you cannot lift-and-shift those three roles into unified RBAC. You have to redesign. Most large customers redesign into seven to twelve role groups. Most do not finish that work in a quarter. The April 2026 extension gives you three quarters, which is realistic if you start now.
The Take Action Wizard: The Most Underrated Feature In The Migration
Inside the unified Defender portal's advanced hunting, there is a feature called Take Action. The pattern:
- Write a KQL query that returns the threat surface you care about - emails, domains, file hashes, mailboxes, processes
- Pick one or more rows in the result set
- Click Take Action and choose from a context-aware list of operations
Operations include:
- Block a top-level domain (or specific URL) tenant-wide
- Block a file hash in attachment scanning
- Move emails to specific mailbox folders (junk, deleted, custom)
- Delete emails in scope from every affected mailbox
- Quarantine a device or kick off an isolation workflow
- Submit indicators to threat intelligence
The killer use case Anthony described in the podcast: a phishing campaign lands across three hundred mailboxes. In the legacy world, you write a KQL query in Sentinel, copy the results into a spreadsheet, paste them into the Exchange Online compliance search UI, build a content search, build a purge from that search, wait for the purge to complete, and confirm. In the unified Defender world, you write the KQL query in advanced hunting, click Take Action, choose "delete emails", confirm, and the action propagates across the tenant in seconds.
The catch: unified RBAC permissions matter.
To use Take Action against email indicators you need:
- Manage (not just read) on the Security data > response configuration permission
- Manage (not just read) on the Email and collaboration data permission
Most teams who have migrated have done so with read-only unified RBAC roles for analysts, because that is the safest starting posture. That is the right call, but it means analysts can see the Take Action button and cannot use it. The fix is to design Tier 2 and Tier 3 responder roles with manage-level permissions and to scope those roles to the smaller group of trusted operators who actually need that authority. PIM the role if you want to add a JIT layer.
Resource Locks: The One Custom Role Worth Keeping In Azure
Most of the conversation in the podcast about whether custom roles are still worth writing landed in the same place: in the unified Defender RBAC model, the answer is almost never. Built-ins now cover most realistic personas.
The exception is Azure side. There is no built-in role in Azure RBAC that controls just resource locks. Resource lock creation and deletion lives inside Contributor, which is the most over-broad role in Azure RBAC and the one you most do not want to hand out as a path to "I want someone to be able to lock a resource so it can't be accidentally deleted".
The clean solution, which the CIS Microsoft Azure benchmark recommends, is a single custom Azure role: Resource Lock Administrator. It carves out one tiny permission set:
Microsoft.Authorization/locks/read
Microsoft.Authorization/locks/write
Microsoft.Authorization/locks/delete
Scope it to the resource group or subscription the role applies to, assign it to a security group, and PIM the group via Entra. That gives you a clean path to "you can lock things without being a Contributor on the whole subscription", which is exactly the principle of least privilege story your auditors want.
Beyond that, the answer in 2026 is almost always use the built-in. Custom roles are technical debt with extra steps.
PIM Fatigue And The Owner vs Contributor Trade-off
The honest version of the PIM conversation in most enterprises sounds like this: "We elevated to Just-In-Time access for everything. Engineers complained for six months. Half of them are still doing all their day-to-day work as Owner anyway because they got tired of the activation flow."
PIM fatigue is real and it changes the calculus on role design. A few practical principles that have aged well:
- Don't PIM everything. PIM the roles that grant actual privilege - Owner, Contributor, Global Admin, Security Admin. Read-only roles do not need PIM.
- Group similar JIT activations. A single security group with three roles you can activate together is less fatiguing than three separate elevations.
- Tune activation duration to the task. Standard one-hour elevations are the worst of both worlds. Use 30 minutes for fast tasks and 8 hours for engineering shifts. The fewer reactivations per day, the lower the friction.
- Use the "User Access Administrator + Contributor" pattern instead of Owner where you can. Two narrower roles is more reviewable than one fat role, and the audit trail is cleaner.
- Audit who's elevating to what monthly. PIM creates an audit trail. Use it.
The point that always lands hardest: the goal is not zero risk. The goal is risk visibility. PIM gives you the visibility. The job of role design is to make sure the visibility is not drowned in noise.
What To Do Right Now
For an organisation in the middle of the Sentinel-to-Defender migration:
- Confirm your migration plan still finishes by December 2026. The new March 2027 deadline gives you a buffer. Do not use the buffer as your plan.
- Stop building new SIEM logic in the Azure portal. Anything new lands in the unified Defender portal. Net-new content built in the Azure portal in July or beyond is technical debt you'll pay for.
- Redesign your unified RBAC roles. Map every existing Sentinel persona to the unified RBAC permissions. Identify which need manage rights (Take Action), which need read-only, which need PIM elevation.
- Carve out the resource lock administrator role in Azure. One custom role definition. Scope and assign through Entra security groups.
- Train your analysts on advanced hunting Take Action. The KQL is the same as Sentinel. The action layer is new. The productivity gain is real.
- Test integrations early. Logic Apps, SOAR playbooks, API integrations, custom workbooks - all need a validation pass against the unified Defender surface.
Key Takeaways
- The Sentinel-to-Defender portal deadline is now 31 March 2027 (extended from 1 July 2026 in the April 2026 announcement).
- From July 2026, the Defender portal is the canonical Sentinel experience. The Azure portal still works but is the deprecated surface.
- Unified RBAC is the lever that makes the rest of the migration work. Redesign roles into seven to twelve granular groups, mapped to real SOC personas.
- The Take Action wizard in advanced hunting is the productivity killer feature. It requires manage-level unified RBAC permissions.
- Most custom RBAC roles are obsolete. The Resource Lock Administrator in Azure is the one custom role still worth carving out.
- PIM fatigue is real. Design role activation flows around the work, not around the framework.
FAQ
When does Microsoft Sentinel retire in the Azure portal?
31 March 2027. Microsoft announced the revised timeline in April 2026, extending the original deadline of 1 July 2026 by nine months. From July 2026, the unified Defender portal becomes the canonical Sentinel experience and the Azure portal is the deprecated surface even though it remains accessible.
What is the advanced hunting Take Action wizard?
A feature inside the unified Microsoft Defender portal's advanced hunting that lets analysts go from a KQL query result to a tenant-wide response action in a single workflow. Supported actions include blocking domains, blocking file hashes, deleting emails, moving emails to specific folders, isolating devices, and submitting indicators to threat intelligence. It is GA for any tenant on the unified Defender portal.
What unified RBAC permissions do I need to use Take Action?
For email-related Take Action operations, you need manage (not just read) on both Security data > response configuration and Email and collaboration data. For endpoint Take Action operations, you need manage on the corresponding endpoint response permission. Most read-only analyst roles will see the button but cannot use it, which is intentional from a least-privilege perspective.
Do I still need to write custom RBAC roles in 2026?
Almost never. The unified Defender RBAC model is granular enough to map most SOC personas using built-in permission groups. The one Azure RBAC custom role most enterprises still benefit from is Resource Lock Administrator, which carves out a permission set covering just Microsoft.Authorization/locks/* so that resource-lock management does not require Contributor.
Is the migration extension a sign Microsoft is delaying the broader unified SecOps strategy?
No. The extension is an acknowledgement that large enterprise migrations need more time than the original timeline allowed, particularly for the RBAC redesign. The product direction has not changed: Microsoft Defender is the unified SecOps surface, Sentinel is the SIEM engine inside that surface, and the Azure portal experience will retire. The extra time is operational, not strategic.
My Take
Every operational migration of this scale runs into the same problem. The vendor picks a date that's aggressive but defensible. The customers nod and say "yes, by then". The customers do not start the work for six months because there are seven other priorities. Three months before the deadline, the customers go to the vendor and ask for an extension. The vendor either holds the line and creates a forced-march experience for the laggards, or extends and creates a freeloading experience for the laggards. Microsoft has chosen to extend, which I think was the right call for Sentinel because the RBAC redesign was genuinely under-scoped.
The bigger picture is that Microsoft's unified SecOps story is actually maturing. The Defender portal in May 2026 is a meaningfully better operational experience than the Azure portal experience for Sentinel ever was, particularly for incident-first workflows. The take-action layer alone is worth the migration. If your SOC analysts are still copying KQL results out to spreadsheets to drive Exchange compliance purges, you are leaving real productivity and real response speed on the table.
The one thing I would change is the messaging. Microsoft has been quiet about how good the unified portal has gotten. Most of the customers I've spoken to are dreading the migration because their last hands-on time was with the early preview in 2024, when the experience was rough. It is not rough anymore. The April 2026 extension is a reason to migrate carefully, not a reason to migrate later.
Use the nine months. Don't waste them.
Mathew Clark Founder, SecureInSeconds Currently: counting how many of my customers are quietly relieved by the March 2027 extension. Answer: all of them. None of them will admit it on the call.
Further Reading
- UPDATE: New timeline for transitioning Sentinel experience to Defender portal - the April 2026 official announcement
- Microsoft Sentinel in the Microsoft Defender portal - the Microsoft Learn canonical documentation
- What's new for Microsoft's unified security operations - the rolling change log
- The Unified SecOps Transition - Why It Is a Security Architecture Decision - Microsoft's framing of the architectural shift
- Microsoft Agent 365 Is GA: The Defender Stack For Agents - the agent-side companion piece on the same unified portal
- Microsoft MDASH: An AI Just Found 16 Critical Windows Bugs - the offensive AI story shaping the same platform
- Out of Band: A Microsoft Security Podcast - May 2026 Episode - the full conversation
