For years, Managed Identity has been the easy part of a Zero Trust story on Azure right up until a developer opened VS Code. Deployed Logic Apps could already authenticate to Entra-protected resources with no secrets in sight. The local dev loop, however, couldn’t. You’d wire up a connection string or a local key to run and debug, then swap it out for Managed Identity before deployment. Two auth models, one workflow, and a seam that every “we don’t store secrets” policy quietly depended on someone remembering to close.

Wagner Silveira’s TechCommunity walkthrough, Use connectors with Managed Identity in the Logic Apps Standard extension, covers an update that closes that seam. You can now build connectors — both Azure managed connectors and service provider connectors — that use Managed Identity as the authentication parameter, and run them locally while you develop and debug. Locally, the extension authenticates as your signed-in developer identity through the Azure default credential pattern. After deployment, that same connection authenticates as the app’s managed identity instead. In other words: same connector definition, same auth model, just a different identity behind it depending on where it runs.

Why this is a Zero Trust story, not just a DX improvement

It’s tempting to file this under developer experience and move on. I’d argue it belongs in the identity and access conversation instead.

Zero Trust asks for consistent, identity-based enforcement everywhere, not only in production, where the compliance team is watching, but in every environment a workload touches. The dev-to-prod credential swap was a structural exception to that principle: a place where the enforced pattern was “do it properly,” and the practiced pattern was “do it however runs today.” Local .env files and connection strings scoped to a developer’s convenience tend to outlive the sprint that created them. As a result, it’s usually the dev environment, not prod, where stray credentials pile up quietly, invisible to your access reviews.

Collapsing local and deployed auth onto the same Managed Identity model doesn’t just remove secrets from one more service. More importantly, it removes the exception itself. There’s no longer a version of “getting this connector running” that skips Entra-issued, RBAC-governed identity. That’s the real Zero Trust gain here: not that a secret disappeared, but that a place secrets used to hide no longer exists.

Where this doesn’t do the work for you

Managed Identity is authentication, not authorization, and this update doesn’t change that. It gets you a verified identity at the door; it says nothing about what that identity is allowed to touch once it’s inside. Silveira is direct about this in his post; if a connection throws an authorization error, check the RBAC role assignment on the target resource first, because Managed Identity will happily authenticate an identity that’s been granted far more access than the workflow actually needs.

In practice, that means the credential-less win is only as good as the RBAC discipline behind it. An identity with Contributor on a resource group, because nobody wanted to think about scoping, isn’t meaningfully more “Zero Trust” than a connection string sitting in a config file; it’s just a differently shaped version of too much trust. If you’re rolling this out, the RBAC assignment deserves the design review; the connector configuration doesn’t.

There’s also a smaller, practical catch worth knowing before you build on this: the Managed Identity path for managed connectors doesn’t populate dynamic values in the designer. You lose the friendly dropdowns and supply values manually instead. It’s a minor friction, but it’ll surprise the first person on your team who hits it mid-demo.

Try it yourself

I’ve put together a small sample project, a Logic Apps Standard workflow that lists blobs on a schedule, authenticated with Managed Identity both locally and once deployed, plus Bicep that provisions the whole thing end to end (including a role assignment scoped to exactly one storage account, not the resource group). azd up gets you a running workflow; no manual portal clicking required.

Grab it from the sample repo (link once published) and run:

azd auth login
azd up

One setting made the difference between “deploys clean” and “actually authenticates”: WORKFLOWS_AUTHENTICATION_METHOD, set to managedServiceIdentity on the deployed app. It’s easy to miss; I did, in an earlier version of this sample, because the connection, the access policy, and the RBAC role assignment can all be independently correct, and the workflow will still fail at runtime with a bare Key 'token' not found in connection profile until that setting is in place. If you deploy this yourself and hit that exact error, that’s almost certainly why.

The governance question this actually raises

Platform and integration teams have mostly answered “can we authenticate without secrets here?” The harder question left standing is: do we, consistently, everywhere, including local dev? This release removes the last technical excuse for Logic Apps Standard. What’s left is a policy and habit question. Does your team’s definition of “done” for a new connector include verifying it never touched a stored credential, in any environment? Or does that check still only happen at the production gate?

Worth asking before the next connector goes into a workflow, not after.

Further reading: Wagner Silveira’s original walkthrough, Use connectors with Managed Identity in the Logic Apps Standard extension, on the Azure Integration Services Blog.