Categories: Microsoft Defender for Endpoint | Entra ID | Troubleshooting

The Problem

When setting up a third-party integration or granting admin consent, you might suddenly encounter this error:

AADSTS650052: The app is trying to access a service 'fc780465-2017-40d4-a0c5-307022471b92' (WindowsDefenderATP) that your organization lacks a service principal for.

This is highly confusing—your tenant has an E5 license, Defender is active, and everything should technically be correct.

The Cause

Microsoft does not automatically provision the Service Principal for Windows Defender ATP (fc780465-2017-40d4-a0c5-307022471b92) when you assign the license. Normally, the Service Principal is created upon the first visit to security.microsoft.com—but this trigger doesn't always work reliably.

Important note for E5 Developer Tenants: The Security Portal might already be loading fine, yet the Service Principal is still missing. The automatic provisioning trigger frequently fails for Dev Tenants, even if Defender for Endpoint appears active and the portal loads normally. In this scenario, the Service Principal must be created manually.

Commonly Affected Scenarios:

  • E5 Developer Tenants: Portal-based auto-provisioning often fails completely.
  • New Production Tenants: Environments where security.microsoft.com has never been opened.
  • Accidental Deletion: Tenants that recently underwent a Service Principal cleanup.

Fix 1 – The Portal Method (For Production Tenants)

Open security.microsoft.com using a Global Admin account. For regular production tenants, the portal automatically provisions the Service Principal upon the first visit. Once the portal loads, try the consent flow again.

⚠️ Note: If you are using an E5 Dev Tenant, this often doesn't work. Skip directly to Fix 2.

Fix 2 – PowerShell via Microsoft Graph (Most Reliable Method)

The most robust way to resolve this issue is by manually creating the missing Service Principal using Microsoft Graph PowerShell.

# Install the Microsoft Graph module if not already present
Install-Module Microsoft.Graph -Scope CurrentUser -Force

# Connect to the affected tenant
Connect-MgGraph -Scopes "Application.ReadWrite.All" -TenantId "<TenantId>"

# Create the Service Principal for WindowsDefenderATP
New-MgServicePrincipal -AppId "fc780465-2017-40d4-a0c5-307022471b92"

A successful output will look like this:

DisplayName        Id                                   AppId
-----------        --                                   -----
WindowsDefenderATP 6cbf883d-...                         fc780465-2017-40d4-a0c5-307022471b92

After running this, repeat your consent flow—you are done.

Verification

To double-check if the Service Principal exists, run the following command:

Get-MgServicePrincipal -Filter "appId eq 'fc780465-2017-40d4-a0c5-307022471b92'"

If the command returns an entry, the Service Principal is present. If the output is empty, the Service Principal is still missing.

Time-Consuming Pitfalls to Avoid

  • Graph Explorer is unreliable for this fix: The token session frequently drops when attempting this, even with a correct login. Stick to the PowerShell module.
  • Adminconsent URLs don't create the SP: The admin consent URL only works after the Service Principal already exists. It cannot be used as a workaround to provision it.
  • E5 Developer Tenants behave differently: As mentioned, portal provisioning does not reliably trigger for Dev Tenants compared to production E5 tenants.
  • Conditional Access blockers: Conditional Access policies can block the Device Code Flow. Using an interactive browser login via Connect-MgGraph is much more stable.

Complex IT? I make it simple – with M365, which protects, scales, and brings clarity. For SMEs that rely on smart solutions.

Call to Action

Need help streamlining your Microsoft 365 security, configuring Defender, or troubleshooting complex Entra ID issues? Visit https://easym365.de for expert consulting and hands-on support. Let's build a secure foundation together.