7.5 Authenticating to Power Platform with Managed Identities

Any Azure resource that calls Dataverse — most commonly an Azure Function — needs a credential to authenticate through OAuth 2.0. The traditional approach, a client secret or certificate stored in application settings, works but creates an ongoing maintenance and security burden: secrets expire, must be rotated, and can leak if mishandled. Managed identities solve this by letting Azure itself manage the credential.

What a Managed Identity Is

A managed identity is an identity in Microsoft Entra ID that Azure automatically creates and manages for a specific Azure resource — an Azure Function App, a Logic App, a VM, and others. There are two flavors:

• System-assigned managed identity — tied 1:1 to a single Azure resource's lifecycle; created when enabled on that resource and deleted automatically when the resource is deleted.
• User-assigned managed identity — created as a standalone Azure resource in its own right, which can then be attached to one or more other resources (for example, several Azure Functions sharing the same identity).

In both cases, Azure handles the underlying credential and its rotation entirely behind the scenes — no client secret or certificate ever appears in the Function's code or application settings.

Wiring a Managed Identity Up to Dataverse

Enabling a managed identity on the Azure side is only half the setup. Dataverse has no automatic trust relationship with an arbitrary Entra ID identity — it must be explicitly granted access, exactly like any other application:

1. Enable the managed identity on the Azure Function App (system-assigned, or attach a user-assigned identity), which generates an object ID for that identity in Entra ID.
2. Create an Application User for that identity in the Power Platform admin center, using the managed identity's object ID (rather than a traditional app registration's client ID) as the identifying value.
3. Assign a security role to that Application User following the principle of least privilege — the same as with any other app-only integration — so the identity can only perform the operations the workload actually needs.
4. In the Function's code, acquire a token using a credential type built for managed identities (such as ManagedIdentityCredential or the broader DefaultAzureCredential in the Azure Identity library) targeting the Dataverse resource, instead of building a client-credentials request with a stored secret.

Once configured, the Function calls the Web API or Organization service exactly as any other app-only caller would — the only difference is where the credential came from.

Why This Matters for PL-400 Scenarios

Managed identities are the recommended authentication approach whenever the calling workload runs entirely inside Azure and doesn't need a portable credential (for example, a case where the same secret must also be used outside Azure, which would rule out a managed identity). The benefits that make this the preferred pattern on the exam:

• No secret to store, rotate, or accidentally leak in source control, application settings, or Key Vault.
• No expiry-driven outages — traditional client secrets and certificates expire and, if not rotated in time, cause authentication failures; Azure manages a managed identity's credential lifecycle automatically.
• Reduced attack surface — there is no exportable secret value for an attacker to exfiltrate from configuration.
• Consistent least-privilege model — a managed identity still goes through the same Application User + security role assignment as any other app-only integration, so it doesn't bypass Dataverse's authorization model, only its credential-management burden.

A scenario describing "an Azure Function that authenticates to Dataverse without managing secrets" or "eliminating credential rotation for a service-to-service integration" is pointing directly at a managed identity, paired with the corresponding Application User configuration in the target environment — omitting that admin-center step is the most common way this pattern fails in practice, since Azure-side setup alone grants no Dataverse permissions.

DefaultAzureCredential and the Fallback Chain

In .NET code, the Azure Identity library's DefaultAzureCredential is the pattern Microsoft recommends for code that needs to work seamlessly across local development and production. It tries a sequence of credential sources in order — environment variables, a signed-in Visual Studio or Azure CLI session during local development, and finally the managed identity when running inside Azure — and uses whichever one succeeds first. This means the same code can authenticate with a developer's local Azure CLI login while debugging, and automatically pick up the deployed Function App's managed identity in production, with no code branching required:

var credential = new DefaultAzureCredential();
var token = await credential.GetTokenAsync(
    new TokenRequestContext(new[] { "https://orgname.crm.dynamics.com/.default" }));

Managed Identity vs. Traditional App Registration

This trade-off is exactly why managed identities are not universal: an on-premises service or a workload hosted outside Azure has no managed identity to use and must fall back to a traditional app registration with a secret or certificate — the exam expects developers to recognize both when each pattern is the right fit and when it is architecturally impossible to use.