Entra: Use managed identities as federated credentials to connect to Defender for Endpoint API

In this blog, we will use a user managed identity to retrieve Defender for Endpoint Threat Indicators — all without handling any credentials manually. This setup leverages federated credentials for secure, seamless authentication. By using a user-assigned identity, we add resilience: if the resource or application is ever reprovisioned, the identity can be reused without code changes. For example, you might start with a VM and later move to a PaaS solution like an Automation Account — with minimal or no refactoring.

To follow along, you'll need an Azure subscription, a user-assigned managed identity, and an Automation Account to run the workload. On the Entra side, you'll just need an app registration to support the federated identity setup.

Let's get started!

Table of Contents

1- Overview

2- Create a user managed identity

3- Create an Entra Application

4- Configure Entra permissions

5- Provision federated credentials

6- Provision your compute resource

7- The Runbook

8- Establish the Federated Trust

9- Conclusion

10- References

Overview

This guide walks through how to securely access one of Microsoft Defender for Endpoint (MDE) API: Windows Defender ATP, using an user-assigned managed identity and federated credentials — no secrets, no certificates, no credential rotation headaches. You'll learn how to configure Azure and Entra so your workload (running in an Azure Automation Account) can authenticate and retrieve Threat Indicators from MDE with minimal setup and maximum flexibility.

By the end, you'll have a solution that's:

• 🔐 Credential-free: Auth handled by Entra and managed identities

• 🔄 Reusable: Survives reprovisioning or resource changes

• ⚙️ Portable: Easily migrates from VM-based to PaaS-based workloads

Whether you're building for long-term automation or modernizing existing scripts, this pattern sets you up for scalable, secure API access across Azure.

Create a user managed identity

First step is to create a managed identity.

In the Azure portal, search for Managed Identity

Or using the Az.ManagedIdentity module

We use a user managed identity here because it's more resilient and can be re-used on multiple resources with the same app Id. This PoC would also work with a system managed identity.

Create an Entra Application

To register a new application navigate to the Entra portal > Identity > Applications > App registrations > New registration

Choose a multi tenant application to use this PoC against multiple tenants.

Configure Entra permissions

Our application will requires permissions to the Windows Defender ATP API. This can be configured in the portal under API permissions > Add a permission > APIs my organization uses > WindowsDefenderATP

Select Application permissions > Ti > Ti.ReadWrite.All

Finally grant consent on behalf of the organisation

Provision federated credentials

Federated credentials will be used to allow your application/script to run on a foreign tenant using managed identity for authentication — without the need to manage secrets or certificates. Behind the scenes, this works by establishing a trust relationship between your Entra ID app registration and an external identity provider — in this case, the foreign tenant. Once the trust is in place, JWT tokens can be securely exchanged between the two parties, enabling seamless authentication without handling any credentials.

In your Entra application > Certificates and secrets > Federated Credentials > Add credential

You'll be presented with 3 predefined and a custom/generic templates: choose managed identity

Select your managed identity and give your credentials a name

Provision your compute resource

Now it’s time to provision the resource that will run our script. This can be any Azure compute option, depending on your needs. In the PaaS space, that includes services like Azure Automation Accounts, Azure Functions, or Azure Container Apps. On the IaaS side, it could be an Azure VM, Virtual Machine Scale Set (VMSS), or even a non-Azure machine onboarded through Azure Arc.

In this case, I will use an Automation Account and assign my User Managed Identity in the Identity page

We will also create a simple runbook for this automation account to retrieve the indicators in the foreign tenant

The Runbook

This simple script generates a token to connect to the WDATP API and retrieve the indicators

I used Token Magician developed by Stephan Van Rooij to simplify retrieving a token for federated credential.

In the background, it uses Azure Identity and Azure Core .NET libraries to create the Managed Identity credentials and the client assertion.

The flow to generate the token for a foreign tenant is as follow:

1- create your managed identity credential client --> This client is used to retrieve a token for the managed identity in the home tenant.

2- Create your assertion credential client --> This client combines a token from your home tenant with information about the target (foreign) tenant — specifically the tenant ID and the trusted Entra application. It enables your script to request a token on behalf of the managed identity in the foreign tenant, once the federated trust between the two tenants has been established.

3- Generate a token using the assertion client for the required scope --> Now, we use the assertion credential client to request an access token for the managed identity in the home tenant. This token will allow the identity to operate within the foreign tenant, targeting the specified scope (also known as the audience).

In our case, the audience is the Microsoft Defender for Endpoint (WDATP) API:

"https://api.securitycenter.microsoft.com/.default"

You can find all information in Microsoft Learn Documentation:

• Configure an application to trust a managed identity - Microsoft Entra Workload ID | Microsoft Learn

• ManagedIdentityCredential Class (Azure.Identity) - Azure for .NET Developers | Microsoft Learn

• ClientAssertionCredential Class (Azure.Identity) - Azure for .NET Developers | Microsoft Learn

Back in our runbook, once we’ve retrieved the access token, we include it in the Authorization header of a REST API request to authenticate against the Microsoft Defender for Endpoint (WDATP) API and retrieve our Threat Indicators.

Establish the Federated Trust

Now that everything is configured, the final step is to establish trust between the foreign tenant and our Entra application. This is done by granting consent to the Entra app within the foreign tenant, using the following approach:

https://login.microsoftonline.com/{tenantId}/adminconsent?client_id={clientId} 

with {tenantId} the foreign tenant id and {clientId} your Entra Application app id.

🔐 The user performing this action must have at least the Application Administrator role in the foreign tenant.

Conclusion

For this PoC, the runbook is intentionally simple — just enough to show how the pieces fit together. From here, it's up to you to adapt it to your own setup. Add logging, error handling, or build it into a bigger automation flow. The key part is that the heavy lifting — token handling and secure auth — is already taken care of thanks to federated credentials.

Whether you're calling Defender APIs, Microsoft Graph, or even third-party services, the pattern stays the same. No secrets, no certs — just clean, secure, repeatable auth that works across tenants and platforms.

Use it, extend it, automate the hell out of it.

Access token are valid for 60-90min so don't forget to run Get-TmMsiToken before running your query. Just for information because the module is using the Azure SDK the token flow behaves like this:

1. ✅ Token exists and is still valid?→ Returns cached token.

2. 🔄 Token exists but is expired or close to expiry?→ Silently refresh the token behind the scenes and return a new one.

3. ❌ No token exists yet?→ Acquire a new token via the credential then cache and return it.

Federated credentials are a no brainer in my opinion and provides the solid security step up for your dev project. You can use them to connect your Azure DevOps to your different Azure subscriptions and eliminate any secrets and certificates.

We also covered this in a recent M365 Security & Compliance User Group session, where we showed how to use the same approach to connect to third-party clouds like AWS — proving it’s not just for Microsoft-native scenarios

Hope this was useful and thanks for reading!

References

• Access tokens in the Microsoft identity platform - Microsoft identity platform | Microsoft Learn

• Configure an application to trust a managed identity (preview) - Microsoft Entra Workload ID | Microsoft Learn

• Use multi tenant managed identity in Azure Automation - Coding Stephan

• GitHub - svrooij/TokenMagician: PowerShell module to help getting tokens using managed identities

• Microsoft 365 Security & Compliance User Group | Meetup

---

About William Francillette:

I am DevSecOps Lead and Solution Architect at Threatscape specialised in M365 and Azure security offering.

I love learning, blogging and coding. My interests are very diverse and span across architecture, security, cloud engineering, automation, DevOps and PowerShell.

I own as of today 17x (and counting) Microsoft certifications and have worked in IT across multiple and diverse industries for over 15 years.