AzureFeeds

Co-authored with Lizet Pena, Caroline Mutua, Alvin Kua and Marco Sudahl

The portal change was the easy part. The real upside is the operating model it unlocks—generative AI in every workflow, behavioral analytics across hybrid and multi-cloud, native threat intelligence, and SOC optimization recommendations that tell you exactly where to invest next.

If the first five parts of this series were about what changes and how to plan for it, this part is about what you get on the other side. Microsoft Defender is the only place where Security Copilot agents, the unified UEBA experience, native MDTI convergence, and the full SOC optimization recommendation engine come together—and each one moves a needle that classic Sentinel could not move alone.

None of these capabilities require a forced cutover. Most of them light up the moment a workspace is connected. The story is not “give up Sentinel for Defender”—it is “your existing investment now compounds with capabilities you did not have before.”

What this post covers

• Security Copilot: embedded experience, standalone portal, and AI agents


• UEBA: same engine, unified entity pages, new data sources, unified IdentityInfo schema


• Threat intelligence: MDTI converged natively, richer STIX data model, actor-centric investigations


• SOC optimization: from manual workbooks to personalized, cross-service recommendations


• Persona implications, common misconceptions, a do-this-week checklist, and the series wrap-up

Security Copilot in Defender

Microsoft Security Copilot is a generative AI-powered security solution. Customers can interact with Security Copilot across their Sentinel and Defender data in Defender (embedded experience and agents) and the standalone copilot portal (securitycopilot.microsoft.com).

Core capabilities

• Investigate and remediate threats; incident summarization, guided step-by-step response actions, triage complex alerts into actionable summaries


• Build KQL queries and analyze scripts; natural language → KQL in advanced hunting, reverse engineer suspicious PowerShell, batch, and bash scripts


• Understand risks and manage posture; prioritized risk insights, exposure context, and threat actor intelligence from Microsoft and open source


• Develop reports for stakeholders; generate incident reports in natural language, tailored to audience tone and language

AI agents

Microsoft-built and partner-built agents are available through the Security Store in Defender, automating SOC tasks such as incident triage, access reviews, and vulnerability remediation. Custom agents can be built using agent builder, APIs, MCP, and Graph.

Transition considerations

• The embedded experience of Security Copilot and agents are available in the Defender portal and not in the Azure portal.


• No configuration migration needed; available once licensed.


• Train SOC analysts on Security Copilot as part of Defender onboarding.

Why this lands well: Generative AI is not bolted on to the side of the SOC—it is embedded in the surfaces where work already happens. Triage, KQL authoring, scripted-attack analysis, and stakeholder reporting each get a copilot, and the agent marketplace means the catalog grows without you writing more code.

UEBA: Same engine, richer surface

Most User and Entity Behavior Analytics (UEBA) functionality carries over to Defender with minimal disruption—anomaly detection, behavioral baselines, and investigation priority scoring all continue to work. However, there are meaningful differences in how UEBA surfaces within the unified experience that analysts and engineering teams should understand before transitioning.

The Microsoft Sentinel UEBA behaviors layer transforms high-volume raw security logs into structured, plain-language behavioral summaries (“who did what to whom”), adding context such as MITRE ATT&CK mappings and entity relationships to improve investigation clarity and efficiency.

These behaviors are neutral activity summaries (not alerts), aggregating and sequencing events to help analysts detect patterns, hunt threats, and build simpler detections, ultimately speeding up investigation and response without requiring deep knowledge of underlying log sources.

What changes in Defender

The standalone entity behavior blade from the Azure portal is no longer available. Instead, UEBA insights are integrated directly into the unified entity pages under assets (accounts, hosts, mailboxes) and evidence (IPs, files, URLs). Users flagged with behavioral anomalies are automatically tagged with a “UEBA anomalies” label on the user page, showing confidence scores and anomaly counts—making it easier to prioritize investigation without navigating to a separate blade. Additionally, the incident graph now supports a “Go hunt” action on user entities that surfaces all related anomalies, and advanced hunting queries against UEBA-related tables display contextual banners suggesting joins with the anomalies table for richer results. Also, in Defender, UEBA now has behavior layers.

New data sources (Defender only)

After transitioning, UEBA gains access to additional data sources that are not available in the Azure portal: AAD managed identity sign-in logs, AAD service principal sign-in logs, AWS CloudTrail, device logon events, Okta single sign-on, and GCP audit logs. These expand behavioral baselines beyond traditional user sign-ins to cover service principals, multi-cloud activity, and device-level logon events—a significant uplift for organizations with hybrid or multi-cloud environments.

IdentityInfo table: Two flavors, now unified

The IdentityInfo table has historically existed in two separate versions: one populated by Microsoft Defender for identity (MDI) in advanced hunting, and another populated by Microsoft Sentinel’s UEBA engine in log analytics.

Important – Table-level RBAC on IdentityInfo: If Table-level RBAC has been delegated to the Sentinel IdentityInfo table, this permission model is not carried over to Defender. Table-level RBAC for the IdentityInfo table is not supported in the Defender portal. Review and update your workspace RBAC delegations before migrating to avoid unexpected access gaps. For details, see the Investigate with UEBA in the Defender portal section in the Microsoft documentation.

 After onboarding to Defender, these merge into a unified IdentityInfo table that includes fields from both sources. If UEBA is enabled, the UEBA-specific columns—such as BlastRadius, GroupMembership, CompanyName, DeletedDateTime, EmployeeId, OtherMailAddresses, State, and Tags—are automatically visible in the unified schema. Without UEBA enabled, these columns are not available.

The key action item here is that the unified schema introduces field name differences that can break existing queries.

The following table maps old field names to the new unified schema:

Additionally, UserState and UserStateChangedOn no longer exist in the unified schema and must be removed from any queries that reference them.

Important caveat: Existing Sentinel analytic rules and workbooks that query IdentityInfo via the log analytics API continue to hit the Sentinel table in log analytics—they are not automatically redirected to the advanced hunting table. However, any queries executed in advanced hunting in Defender use the unified table. Teams should verify both query paths during transition.

Why this lands well: The same UEBA engine you already trust, now embedded in entity pages where investigations actually happen, fed by additional multi-cloud and identity data sources that simply do not exist on the Azure portal side.

Threat intelligence converged natively

Azure portal versus Defender at a glance

Transition considerations

• Continue managing custom threat intelligence feeds using Sentinel connectors and the threat intelligence experience for TAXII/STIX feeds


• Keep the threat intelligence analytics rule enabled for automated indicator matching; resulting alerts can still flow into Defender incidents


• Use MDTI context and Security Copilot prompts to enrich investigations


• Threat intelligence is no longer Sentinel-only

In Defender, threat intelligence is:

• Linked to Defender incidents


• Visible in threat analytics


• Usable in cross-product hunting

This is not possible in the Azure portal experience, which is Sentinel-scoped only.

MDTI convergence (native, not a connector)

• MDTI is converged directly into Defender + Sentinel


• Threat actor profiles, campaigns, and IOCs surface automatically


• No separate MDTI portal or workflow is required

This convergence does not fully materialize in the Azure portal experience.

Richer STIX data model in Defender

Defender emphasizes richer relationships, such as:

• ThreatIntelIndicators


• ThreatIntelObjects


• Actor ↔ tool ↔ infrastructure relationships

This enables actor-centric investigations, not just IOC matching.

Better correlation and investigation

• Threat intelligence automatically enriches unified incidents


• Indicators connect to affected endpoints, users, mail, and cloud workloads

Why this lands well: Threat intelligence stops being a side-product. Microsoft-curated intelligence and your custom feeds both flow into the same incident view, surface in threat analytics, and become huntable across Defender + Sentinel—with Security Copilot in the loop for enrichment.

SOC Optimization: From workbooks to recommendations

Azure portal versus Defender

Transition considerations

• Not Defender-exclusive: Core recommendation engine runs in both portals—no functionality loss for customers who transition early


• Defender advantages: Cross-service coverage (Sentinel + Defender), richer overview tile, and Preview-only risk-based recommendations are Defender exclusives


• Preview features evolving: Risk-based, AI MITRE tagging, and unused columns remain in Preview—verify GA status against “What’s new in Sentinel” before relying on them


• Retire manual workbooks: Phase out reliance on the Workspace Usage and Security Operations Efficiency workbooks; SOC optimization supersedes them with personalized, actionable recommendations


• Action tracking: Use the recommendations API to track which optimizations your team actions over time—useful for MSSPs reporting SOC maturity to customers

Why this lands well: You stop guessing what to improve. The engine tells you where coverage is weak, where ingestion is wasted, and how peer organizations are configured—and it does so across Sentinel + Defender, not just one product.

Persona implications

Clearing up common misconceptions

• “Security Copilot is only available in the standalone portal.”
  It’s not. The embedded experience and agents are available inside Defender once licensed—no configuration migration needed.


• “UEBA loses functionality after the transition.”
  UEBA functionality remains. Anomaly detection, baselines, and priority scoring all carry over—and you gain multi-cloud and service-principal data sources that do not exist in the Azure portal experience.


• “All my IdentityInfo queries will keep working unchanged.”
  Partially. Sentinel analytic rules and workbooks hitting log analytics still work; Advanced hunting queries use the unified table with new field names—verify both paths during transition.


• “MDTI needs a separate portal or connector.”
  It doesn’t. MDTI is converged natively into Defender + Sentinel—threat actor profiles, campaigns, and IOCs surface automatically.


• “SOC Optimization is Defender-only.”
  The core engine runs in both portals. Defender adds cross-service coverage, the richer overview tile, and Preview-only recommendation types.


• “Community workbooks for usage and efficiency are still the recommended path.”
  Not anymore. SOC optimization supersedes them with personalized, actionable recommendations—phase the manual workbooks out.

Do this week

• Enable the embedded experience in Defender and pilot incident summarization on one active incident if you are licensed for Security Copilot


• Walk through the SOC optimization overview tile with your manager—pick one data-value and one threat-based recommendation to action this sprint


• Inventory queries that reference the legacy log analytics IdentityInfo fields; map them against the unified schema field-name table and prioritize updates


• Confirm UEBA is enabled where applicable so the additional unified-schema columns light up


• Open the Defender threat intelligence pane and verify MDTI context is surfacing on at least one current incident


• Try one natural-language-to-KQL prompt in advanced hunting via Security Copilot—a quick “aha” for the team


• Evaluate at least one Microsoft-built or partner-built agent from the Security Store for a high-volume repetitive task if you are an MSSP

Closing the series

Six parts in, the picture should be clear: the Microsoft Sentinel transition to Defender is not a forced UI swap. It is the consolidation of SIEM and XDR into a single operating model—one incident queue, one detection rules view, one hunting surface, one governance plane, and a single AI-first toolchain.

Everything you have built carries forward. Analytics rules continue to fire. Playbooks continue to run. Workbooks continue to render. Your Azure RBAC continues to govern. And the new capabilities—XDR correlation, custom detections, Security Copilot, the data lake, UEBA on multi-cloud, MDTI convergence, SOC optimization—are the upside you collect for making the move.

March 31, 2027 sets the deadline. The adoption helper sets the starting line. Everything in between is yours to design—and this series exists so you can design it with confidence.

Read the rest of the series

Each part in this series stands alone—pick the angle that matters most to you, or read them in order.

Part 1 – Beyond a portal move: The strategic shift to Defender

Why the transition matters at the architecture and program level—the executive framing, the deadline, and the analyst validation.

Part 2 – Anatomy of the change: Incidents, alerts, correlation, and data

The component-level mechanics: how the XDR correlation engine replaces Fusion, why incidents are no longer alert-centric, and what changes (and doesn’t) in your data architecture.

Part 3 – Detection and automation, reimagined

How analytics rules, playbooks, workbooks, and hunting evolve—and why the toolbelt doubled, not shrank.

Part 4 – The governance shift: RBAC, URBAC, data lake, and MSSP

The move from Azure RBAC to URBAC, the data lake operating model, and multi-tenant patterns.

Part 5 – Your readiness playbook: Adoption helper, costs, APIs, and the checklist

A practical plan: the Defender adoption helper, cost reality, API strategy, and the migration checklist.