Power Platform Innovation Week – Day 2: Managed Identities: The End of Password-Based Connections

Power Platform Innovation Week – Day 2: Managed Identities: The End of Password-Based Connections

Power Platform admins, pro-devs building Dataverse plug-ins or enterprise connectors, and security/gov teams planning to move away from credentials stored in environment variables or tables.

Why passwords & service accounts have to go

For years Power Platform integrations relied on service accounts, client secrets, or stored credentials to let automations and plug-ins talk to Azure resources and external APIs. That pattern creates a large attack surface: long-lived secrets that must be rotated, monitored, and protected — and when they leak, every flow or plugin that uses them becomes a liability. Microsoft and the Azure ecosystem have been steering developers to passwordless, identity-based authentication for exactly these reasons.

Beyond security, secrets complicate DevOps: CI/CD pipelines must inject credentials into multiple environments, and teams often end up copying the same secret from dev→test→prod or juggling environment-specific service principals. That creates fragile deployments and human error risk. Managed identities remove the need to create and rotate those credentials manually, simplifying both security and operations.

What a “managed identity” actually is (short primer)

A managed identity (Azure) is an identity in Microsoft Entra (Azure AD) tied to a resource (system-assigned) or created and assigned to multiple resources (user-assigned). Azure handles token issuance and secret management so your code asks Azure AD for a token and receives it — no client secret to store or rotate. This pattern is a cornerstone for passwordless, service-to-service authentication across Azure.

Power Platform’s managed identity capability extends that model: Dataverse plug-ins and plugin assemblies can now be associated with a managed identity (either user-assigned managed identity or an application registration with federated credentials). That identity can be granted access to Azure resources such as Key Vault, Storage, or custom APIs so the plug-in can call those resources without ever holding a secret in Dataverse. In short: your plugin gets an identity managed by Azure, not a password you must store.

There are two practical flavours to know: use a user-assigned managed identity (UAMI) when you want one identity reused across multiple resources and to apply Azure policy to it, or create an application registration (app + federated identity credentials) when you want finer control via app registrations and policies. The Power Platform docs and setup guides walk both paths.

What Microsoft has delivered for Power Platform (what Day 2 was about)

Day 2 of Innovation Week focused on the move to managed identities for Dataverse plug-ins and the enablement of passwordless connections to Azure resources. Microsoft published the admin & setup guidance and feature overview describing the new managed identity object in Dataverse, the process to register a managed identity, and how to bind it to plug-in assemblies. That documentation is now the authoritative starting point for teams ready to remove stored secrets from their solutions.

Practically: you create an app registration or UAMI in your Azure tenant, configure federated identity credentials (so Power Platform environments can mint tokens), grant that identity the right RBAC roles (e.g., Key Vault Secrets User), create a managed identity record inside Dataverse, and link it to the signed plug-in assembly. Microsoft’s docs list the prerequisites (Azure subscription, Power Platform CLI, code signing cert, etc.) and the validation steps.

The community and tooling ecosystem are already producing step-by-step posts and helper scripts (GitHub, XrmToolBox plugins, blog walkthroughs) that accelerate adoption and show common pitfalls — for example, issuer formatting in federated credentials or how to keep environment-specific identities separated during solution import. These resources are invaluable while the feature is still settling into enterprise practices.

Benefits in real terms (security, operations, governance)

Security: Eliminates persistent secrets in Dataverse, environment variables, or custom tables. Access now flows through short-lived tokens issued by Azure AD, reducing blast radius when something goes wrong. When you combine managed identities with Azure Key Vault and RBAC, secret sprawl becomes a non-issue.

Operational simplicity: No more password rotation scripts that must touch a dozen flows. Managed identities integrate neatly into Azure role assignments and standard Azure governance — so adding or removing access is a role change, not a chase for where the secret is used. For CI/CD, you can provision the App Registration/UAMI once per environment and tie it into your IaC pipelines. Several community guides show patterns to automate the creation of those identities during deployment.

Compliance and auditing: Because the identity is in Microsoft Entra, you can use built-in Azure AD sign-in logs, conditional access, and access reviews to monitor and enforce policies. That makes proof-of-access and attestation easier for auditors versus chasing down secrets scattered across solutions.

Developer experience: For pro-devs building Dataverse plug-ins, the code to request a token is conceptually the same as any Azure SDK flow — use Azure.Identity / MSAL pattern but without secret plumbing. The resulting runtime is cleaner and more robust. The community has already published sample code and plugin templates showing how to call Key Vault or protected APIs from plugin code using the managed identity.

How to implement — a practical checklist (short, but concrete)

1. Decide identity model: UAMI vs App Registration. If you need one identity reused across environments/resources, UAMI is simpler; if you need richer app registration controls, use an app + federated credentials.
2. Create the identity in Azure (UAMI or app), capture client IDs/IDs you’ll need. Configure federated identity credentials if you used an app registration so Power Platform can request tokens.
3. Grant Azure RBAC: assign the identity the minimum needed role (e.g., Key Vault Secrets User, Storage Blob Data Reader) for the target resources. Principle of least privilege.
4. Build and sign your Dataverse plug-in assembly (signed assemblies are required). Register the plug-in and create a Managed Identity record inside Dataverse, linking it to the assembly (Power Platform CLI / Plugin Registration tools help here).
5. Update plugin code to acquire tokens for the resource (use Azure.Identity or MSAL libraries). Replace any code that previously read secrets from environment variables or Key Vault references with token-based calls.
6. Test in a non-prod environment: validate token issuance, resource access, and error handling for expired/denied tokens. Monitor via Azure AD sign-in logs.

A short example (conceptual C# snippet) — replace details with your values:

var credential = new ManagedIdentityCredential(clientId: "<your-UAMI-clientId>");
string token = await credential.GetTokenAsync(new TokenRequestContext(new[] { "https://vault.azure.net/.default" }));
var httpClient = new HttpClient();
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", token);
var secret = await httpClient.GetStringAsync("https://<your-vault>.vault.azure.net/secrets/mysecret?api-version=7.3"); 

This pattern removes the client secret from code and relies on Azure AD to handle tokens.

Common pitfalls & governance notes

Environment separation: beware importing solutions that carry the same managed identity across environments. That can accidentally give non-prod code production access if not handled carefully. Community posts and tooling (scripts, XrmToolBox helpers) show patterns to create environment-specific identities during deployment — follow those or bake identity creation into your IaC.

Signing & federation gotchas: plugin assemblies must be signed and federated identity issuer strings must be formatted precisely. Small mismatches here often cause frustrating token failures; follow the exact Microsoft setup steps and consult community troubleshooting notes when something fails.

Connector support: not every Power Platform connector or cloud flow action historically supported managed identities out of the box — some scenarios still require custom workarounds or custom connectors. Check connector documentation and community threads before assuming a plug-and-play experience. Microsoft is expanding support, but plan for exceptions.

Monitoring and lifecycle: treat managed identities like other entitlements — track which environments have them, what resources they access, and rotate/revoke access as part of regular audit cycles. Use Azure Monitor and Azure AD logs for visibility.

Migration strategy & next steps

Start small: identify low-risk integrations that currently use stored secrets (for example, a plugin that reads a non-critical Key Vault secret) and convert them first. Use that as a template for more complex migrations. Document the pattern and embed identity provisioning into your Terraform/ARM/GitHub Actions pipelines.

Adopt infrastructure as code: provision UAMIs or app registrations from your IaC pipeline and create a step to add the managed identity record to the Dataverse solution during packaging or deployment. Community scripts exist that help automate linking identities to plugin assemblies; adapt them to your process.

Train devs & ops: make it standard that new integrations use token-based authentication. Update internal templates and onboarding docs so developers don’t default to creating a service account and storing a secret. Encourage use of Key Vault for last-mile secrets only when absolutely necessary, and prefer managed identity token access when possible.

Final thoughts

Power Platform’s managed identity support is a practical, enterprise-grade step toward removing password-based connections from the platform. It improves security posture, simplifies operations, and aligns Power Platform with the broader Azure passwordless direction. There will be friction — connector gaps, deployment pitfalls, and early tooling rough edges — but between Microsoft’s docs and community tooling, teams can migrate safely and quickly. If your org is still relying on stored credentials in Dataverse, treat this as a high-priority modernization task: the risk reduction and operational savings are real.

Source: Power Platform Innovation Week – Day 2: Managed Identities: The End of Password-Based Connections