Intune, Defender, and Entra ID in 2026: What Is Actually Unified vs Still Fragmented

Every renewal cycle, someone on the leadership team asks the same question: "Why are we still paying for six security tools when Microsoft's stack does all of this now?" And on paper, they are right. Microsoft Intune, Microsoft Defender for Endpoint, and Microsoft Entra ID share a licensing bundle, a marketing story, and — increasingly — a Copilot. What they do not fully share is a console, a permission model, or a single support queue.

This post is not another feature announcement. It is a practitioner's stock-take of where Intune, Defender, and Entra ID genuinely operate as one system in August 2026, and where "unified" is still a marketing word for "linked with a click-through." If your organisation is trying to consolidate down from a dozen point tools to a Microsoft-first stack, you need to know which gaps are real before you promise your CISO a single pane of glass.

The problem: "one stack" on the invoice, three consoles at 2am

Here is the workflow that exposes the gap fastest: investigating a user Entra ID Protection has just flagged as high risk. Microsoft's own documentation for this exact scenario is instructive, because it is written as two separate procedures, not one.

Step one happens in the Microsoft Entra admin center: sign in, go to ID Protection > Risky users, open the user, and read the risk timeline. If the risk was elevated by a signal from Defender, the timeline shows a detection type called Unified risk signals — a genuinely cross-product calculation, which we will get to. But to see why Defender raised that signal, the same Microsoft doc tells you to select "Add/remove columns", enable "Additional info", then click a link that opens a new tab in the Microsoft Defender portal at security.microsoft.com, landing you on that identity's Assets > Identities page to review the contributing alerts.

That is not a criticism of the engineering — the risk score really is compounded from both products, and we will show exactly how. It is a description of the actual click count. A Tier-1 analyst working this alert opens the Entra admin center, then the Defender portal, and if the compromise touches a managed device, the Intune admin center as a third stop to check compliance state or push a remediation action. Three origin stories, three sign-in contexts, three separate audit logs to correlate afterwards.

The same pattern repeats in licensing conversations. Many admins assumed that folding Intune Suite into Microsoft 365 E3 and E5 — which we covered in detail when Microsoft announced it — also meant Intune's admin experience, RBAC, and reporting would converge with Entra and Defender. It did not. It changed what you pay for, not how many places you go to manage it.

Why it happens: three products, three histories, one bundle

The fragmentation is not an oversight. It is the visible seam between three products that were built, acquired, and branded on different timelines, then bundled together for the sales motion long before their engineering teams shared a settings catalog.

• Defender grew out of Windows Defender ATP, then Microsoft 365 Defender, then Defender XDR — a security operations product built around incidents, alerts, and hunting queries.
• Entra ID is the Azure AD rebrand — an identity and access product built around directory objects, sign-in logs, and Conditional Access.
• Intune descends from mobile device management and Configuration Manager heritage — an endpoint configuration product built around device objects, policies, and compliance.

Each of those three product lines still has its own portal, its own documentation library, and — this is the part that matters operationally — its own permission model. Microsoft's own docs make the boundary explicit rather than papering over it: "Intune role-based access controls (RBAC) are an extension of Microsoft Entra ID RBAC controls" but operate as a genuinely separate layer — an Entra directory role such as Intune Administrator or Global Administrator always sees everything in Intune, no matter which scope tags exist. Scope tags only constrain administrators who hold Intune-specific role assignments, not Entra directory roles.

Defender, meanwhile, has been rolling out its own answer to the same problem: Defender Unified RBAC, which spans Defender for Endpoint, Defender XDR, Defender for Identity, Defender for Office 365 Plan 2, Defender Vulnerability Management, Defender for Cloud, Microsoft Security Exposure Management, and Defender for Cloud Apps. As of 30 May 2026 it is the default for newly created Defender for Office 365 Plan 2 tenants — existing tenants keep their legacy Defender permission model unless they opt in.

Three separate permission systems, three separate places to check "who can actually do this," and — because the Defender rollout is tenant-vintage-dependent — potentially a fourth variable: whether your tenant predates or postdates 30 May 2026. That is not a criticism of any one team's engineering; it is what happens when three products with three release cadences converge under one sales bundle faster than their control planes converge under one architecture.

How to verify: audit your own environment's real fragmentation

Before you tell anyone your organisation has "consolidated onto Microsoft," run this audit. It takes under an hour and gives you an honest baseline instead of a vendor slide.

While you are in the Intune admin center, this is also the moment to check whether your tenant is actually receiving the licensing changes you think it is. Microsoft folded Intune Suite capabilities — Endpoint Privilege Management, Enterprise Application Management, and Cloud PKI into E5; Advanced Analytics, Remote Help, and Tunnel for MAM into E3 — starting 1 July 2026, with all existing eligible tenants meant to be provisioned by 1 August 2026.

# Prompt typed into the Copilot sidecar while viewing a risky user in the Entra admin center
You: Summarize why j.doe@contoso.com was elevated to high risk.

Copilot: Risk was elevated from Medium to High via Unified risk signals.
Contributing signals: Anomalous Token (Microsoft Entra ID), Suspicious OAuth
app grant (Defender for Cloud Apps). Kill chain breadth and temporal
convergence both matched. Recommend reviewing the linked incident in
Microsoft Defender for full alert detail.

# Note what it did NOT do: it did not open, summarize, or link the
# Defender incident itself. That still requires switching products.

The fix: what actually reduces fragmentation today

You cannot wait for Microsoft to merge three admin centers into one. You can, however, make deliberate choices that remove real friction with the capabilities that exist right now.

1. Treat RBAC as three separate audits, not one. Review Entra directory role assignments (Global Administrator, Intune Administrator) separately from Intune scope-tag design, and separately again from Defender permissions. Do not let anyone assume an Entra role respects an Intune scope tag — it does not.
2. Deliberately opt existing tenants into Defender Unified RBAC rather than waiting for the 30 May 2026 default to reach you by attrition. Map your legacy Defender role groups to Unified RBAC permission groups before you flip the switch, and test with a pilot group of analysts first.
3. Stand down redundant point tools that Intune Suite now covers under E3/E5 — local admin elevation tools once EPM is enabled, third-party certificate issuance once Cloud PKI covers the scenario, and standalone remote-assist tools once Remote Help is rolled out. This is the actual consolidation win from the licensing change, not a cosmetic one.
4. Use Admin Tasks in the Intune admin center as your triage inbox, but train analysts on the handoff. It genuinely queues Endpoint Privilege Management elevation requests, Defender security tasks, Multi-Admin Approval requests, and Device Offboarding Agent actions in one list — but selecting a Defender-originated task still opens that task in its original Defender workflow. Set the expectation that this is a launch pad, not a rewrite, so nobody is surprised by the redirect.
5. Write your incident-response runbook by product ownership, not by pretending there is one console. For each step, name the portal: "Confirm risk score in Entra ID Protection," "Review contributing alerts in Defender," "Check device compliance in Intune." A runbook that hides the handoffs produces analysts who get lost mid-incident; one that names them produces analysts who move fast because they know exactly where they are going next.
6. Turn on the Security Copilot embedded experiences you have available, per product, and set expectations that each is a separate session. Entra gives you risky-user summarization, app risk investigation, incident investigation, and lifecycle workflow management. Intune gives you device query, policy and setting management, and device troubleshooting. Defender gives you incident summaries, script analysis, guided response, and KQL generation. None of them currently share a conversation thread across products — plan your prompts and training material around that reality instead of promising analysts a single chat that "knows everything."

Proof it worked: what less friction looks like in practice

Consolidation progress here is measurable, but the metric is friction removed, not tools removed. Track these before and after your RBAC and runbook work:

• Authentication contexts per incident. If closing a standard credential-compromise incident used to require three separate sign-ins across Entra, Defender, and Intune, and your runbook now gets an analyst through the same incident with the handoffs pre-mapped, time-to-close should drop even though the portal count has not changed.
• A clean RBAC map with no surprises. Ask "which Entra directory role holders can see every Intune device regardless of scope tag?" and get an immediate, documented answer instead of a shrug. Ask the same for Defender Unified RBAC versus legacy permissions, and get a definitive answer for which model your tenant is actually running.
• Retired point tools with receipts. A specific local-admin-elevation tool, certificate authority, or remote-assist product decommissioned because Intune Suite now covers the scenario under your existing E3/E5 licence — with the renewal cancelled, not just "under review."
• Admin Tasks used as a genuine triage queue. Analysts checking one list in the Intune admin center for EPM elevation requests, Defender security tasks, and Multi-Admin Approval items, rather than three separate notification streams — while still expecting the click-through to the owning product for detail.
• No silent unified-risk gaps. Confirmation that Defender for Identity is actually configured wherever Entra ID Protection is licensed, so "Unified risk signals" is a real compounded score in your tenant and not a label sitting on top of Entra-only detections.

Real progress in 2026 is not "we deleted two portals." It is "we know exactly which of our workflows are genuinely one experience, which are a fast click-through, and which still need a documented handoff — and every analyst on the team knows the difference too."

References

• Unified risk signals in Microsoft Entra ID Protection — Microsoft Learn (compounded risk scoring, prerequisites, and the Entra/Defender investigation handoff)
• Microsoft Security Copilot experiences — Microsoft Learn (the full table of embedded experiences per product, standalone vs. embedded)
• Use role-based access control (RBAC) and scope tags for distributed IT — Microsoft Learn (why Entra directory roles bypass Intune scope tags)
• Microsoft Defender unified role-based access control (RBAC) — Microsoft Learn (Unified RBAC scope, workloads covered, and the 30 May 2026 default-tenant rollout)
• Centrally manage Admin Tasks — Microsoft Learn (what the unified task queue in the Intune admin center actually does, and what it hands off to Defender)
• Microsoft Intune Licensing Plans and Options — Microsoft Learn (current Intune Suite / Plan 1 / Plan 2 structure)
• Admin tasks in Microsoft Intune: Centralized control today, AI-ready for tomorrow — Microsoft Intune Blog, Tech Community