Microsoft Azure Sentinel in 2026: the portal cutover is five weeks out

The Azure portal for Microsoft Sentinel shuts down July 1, 2026. That is 39 days from today. Microsoft has been phasing this transition since 2023, consolidating everything into the Microsoft Defender portal (security.microsoft.com), and the final deadline is no longer soft. If your SOC workflows, saved searches, workbook URLs, or automation runbooks still point at portal.azure.com paths, they stop working in five weeks.

This is not the only thing that changed recently. There was a December 13, 2025 deadline for KQL query syntax and automation updates that a significant number of tenants either missed or partially addressed. We are also in the middle of a meaningful capability expansion, including new Entra ID Conditional Access analytics rules, UEBA data source additions, and ingestion-time filter/split transformations that can materially cut workspace costs. Let us go through all of it.

The portal cutover: what actually breaks

The Microsoft Defender portal has been the primary Sentinel experience since early 2024. The Azure portal still worked, which meant many teams ran both in parallel, bookmarked the old URLs, and never fully cut over. That option is gone July 1.

The practical breaks to audit now, before the deadline:

Workbook URLs. Workbooks linked from dashboards, SharePoint pages, or SOC runbooks that point at portal.azure.com/#blade/Microsoft_Azure_Security_Insights/... paths will 404. The Defender portal now supports creating and editing Sentinel workbooks directly in the new experience (currently in preview), so the migration path exists. But you have to find every hardcoded link.

Automation playbooks with Azure portal–specific actions. Logic App actions that were built using the Azure portal connector surface may behave differently when executed in the context of the Defender portal incident experience. Test your playbook triggers end to end in the new portal before the cutover, not after.

RBAC paths. Sentinel's permission model in the Defender portal uses the unified RBAC roles, not the classic workspace-level Microsoft Sentinel Reader / Responder / Contributor roles in isolation. If you have analysts whose access was configured exclusively through the old model, verify they have the right unified roles before July 1 or they lose access to the incident queue.

Running a quick audit across your Logic Apps and bookmarked portal links now takes an afternoon. Running it on July 2 after something breaks takes longer.

The December 2025 query migration: what slipped

Microsoft's December 13, 2025 deadline covered two categories: deprecated KQL functions in scheduled analytics rules, and automation trigger schema changes in Sentinel playbooks.

The KQL side was mostly parse_json vs parse_xml disambiguation and a set of deprecated todatetime() usages that the engine had been tolerating since 2021. The rules using those functions did not fail immediately; they degraded silently, returning unexpected nulls or reduced match counts. Some tenants patched everything. Others patched the rules that fired alert volume warnings and left the quieter ones alone.

If you have not done a full sweep, this query identifies scheduled analytics rules containing the most common deprecated patterns across your workspace:

_GetWatchlist('DeprecatedFunctions')
| join kind=inner (
    SecurityAlert
    | where TimeGenerated > ago(7d)
    | where AlertName contains "AnalyticsRule"
    | extend RuleId = tostring(ExtendedProperties["RuleId"])
    | summarize AlertCount = count() by RuleId
) on $left.SearchKey == $right.RuleId
| where AlertCount == 0
| project RuleId, LastModified, AlertCount

For the playbook schema changes: the incident trigger schema added required fields (incidentId, tenantId) that older Logic App definitions were not passing. Any playbook built before mid-2024 and not touched since is a candidate for silent failure on trigger.

New Entra ID Conditional Access analytics rules

Microsoft shipped a set of built-in analytics rules targeting Conditional Access policy gaps and enforcement failures. These are in the Content Hub under the "Microsoft Entra ID" solution and are worth enabling if you have not already.

The ones with the most signal in environments we have reviewed:

Conditional Access policy change by non-admin detects modifications to named locations, trusted IP ranges, or policy state by accounts without the appropriate admin role. This is a meaningful lateral movement indicator in post-compromise scenarios.
MFA requirement bypass via legacy authentication catches sign-ins using protocols (SMTP, IMAP, POP) that bypass Conditional Access entirely. Most orgs think they have legacy auth blocked; this rule surfaces the gaps.
Conditional Access policy disabled for privileged account fires when a CA policy is modified to exclude a high-privilege role or specific account. Paired with the Privileged Identity Management alerts, this is a useful correlation.

All three require the SigninLogs and AuditLogs tables populated via the Microsoft Entra ID data connector. If those tables are sparse, check the connector health in the Defender portal's Data Connectors blade before wondering why the rules produce no results.

UEBA: new data sources worth the attention

User and Entity Behavior Analytics in Sentinel has historically been limited by the data it could consume. The 2026 preview additions expand the entity timeline to include:

Microsoft Entra ID Identity Protection risk events directly surfaced in the UEBA entity page, not just as raw SigninLogs records
Defender for Endpoint device health signals mapped to user entities, so you can see device-side anomalies alongside sign-in behavior on the same timeline
Insider risk management signals from Microsoft Purview, which closes a gap teams previously worked around by manually joining tables

The practical effect: entity pages in Sentinel now tell a more complete story without a custom notebook or manual correlation. If your team relies on entity lookups during triage, enable these data sources in the UEBA settings and give it 24-48 hours to backfill the entity baseline scores.

Ingestion-time transformations: stop paying for noise

The filter and split transformation capability at ingestion is one of the most underused cost controls in Sentinel right now. Available via Data Collection Rules, it lets you drop or route records before they land in your Log Analytics workspace, which means you are not paying for storage or retention on data that was never going to generate a useful alert.

The common patterns we apply:

Filter: drop DeviceEvents records where ActionType is in a known-noisy set (DnsQueryResponse, NetworkConnectionEvents from monitoring agents). On tenants ingesting 50-100 GB/day of Defender for Endpoint data, this routinely cuts ingestion volume 20-35%.

Split: route verbose debug-level data to a Basic Logs table at $0.50/GB rather than Analytics Logs at $2.30/GB. High-volume connector output (CEF syslogs, network flow data) that you want to retain for compliance but rarely query is a natural fit.

The catch: transformations are defined in KQL at the DCR level, and the subset of KQL supported in transformation queries is restricted. You cannot use join, union, or any cross-table lookups. Design your filters to work on single-record field evaluation only.

Are you monitoring Sentinel itself?

Most tenants monitor everything except the SIEM. Data connectors go silent, analytics rules stop matching, playbooks fail on trigger, and no one notices until an incident retrospective reveals a two-week gap in a critical data source.

This query runs against the Usage table to detect data sources whose ingestion volume has dropped more than 40% against a two-week baseline:

let baseline =
    Usage
    | where TimeGenerated between (ago(14d) .. ago(1d))
    | summarize AvgGB = avg(Quantity) / 1024 by DataType, bin(TimeGenerated, 1d)
    | summarize BaselineGB = avg(AvgGB) by DataType;
Usage
| where TimeGenerated > ago(1d)
| summarize TodayGB = sum(Quantity) / 1024 by DataType
| join kind=inner baseline on DataType
| extend DropPct = (BaselineGB - TodayGB) / BaselineGB * 100
| where DropPct > 40
| project DataType, BaselineGB = round(BaselineGB, 2), TodayGB = round(TodayGB, 2), DropPct = round(DropPct, 1)
| order by DropPct desc

Turn this into a scheduled analytics rule firing daily with medium severity. A data source going from 8 GB/day to 0.5 GB/day is not a low-volume day, it is a broken connector. You want the alert, not the discovery three weeks later.

The AI-assisted playbook generator Microsoft previewed is a useful tool for standing up the automation around alerts like this one without writing Logic App JSON by hand. It handles the scaffolding; you supply the conditional logic and the notification targets.

Next steps

If you have not mapped out the July 1 cutover impact for your tenant, or you want an independent review of your analytics rule coverage and ingestion costs, reach out to the KeMeT Tech team.