Governance & Security
From the field archive · Learned in 2024
Service Accounts and Password Rotation for Automations
Security teams want passwords rotated. Automation teams want flows that don't break at 2 a.m. Here's how I help both get what they need.
In the summer of 2024 a customer told me their security team was about to turn on password rotation for the service account behind a set of Power Automate flows. They asked what would happen. My honest answer was that the flows would likely fail after the next rotation, because the connections using that account would need to be re-authenticated.
This is a common point of confusion. Rotation is good security practice, and nobody should argue against it. The problem isn't rotation itself. It's that a password-based user account is the wrong identity for most unattended automation. In this post I explain why, what I recommended at the time, and the better options that exist today.
The options are much better now. Power Automate supports flows owned by service principal application users, so mission-critical flows don't depend on a person's lifecycle. The Dataverse connector supports service principal connections. Connection references in solutions let you swap the connection behind a flow without editing it. Desktop flow credentials can come from Azure Key Vault or CyberArk, including certificate-based authentication. Microsoft Entra guidance now says plainly: prefer managed identities or certificates, and avoid client secrets. For agents, Microsoft Entra Agent ID introduces purpose-built agent identities. Check current status for the Copilot Studio integration before you rely on it.
01Why rotation breaks flows
Most Power Automate connectors store a connection: an authenticated credential for a specific account. When a flow runs, it uses that stored connection. If the account's password changes, connections created with that account often need someone to sign in again before they work. Until then, every flow using them fails.
A shared service account makes this worse, not better. One account might back dozens of connections across several environments. One rotation, and all of them need attention at once, usually by the one person who knows the password.
The risk isn't only downtime. When a service account breaks, people under pressure tend to "fix" it by recreating connections with their own accounts. Now production runs as an individual, which is exactly what the service account was meant to prevent.
02What I recommended in 2024
When the customer asked about rotation, I explained that flows using the account for connections would need those connections updated after every password change. My short-term recommendation was to exclude that account from rotation until I could confirm more details. That was a stopgap, not a destination.
If you need a stopgap today, the compensating controls I'd ask for are:
- The account can't sign in interactively, and Conditional Access limits where it can be used.
- It has only the permissions the automations need, nothing tenant-wide.
- Its sign-ins are monitored, and the exception has an owner and an end date.
Then use that time to move to one of the patterns below.
03Pick the right identity for the job
Here's how I think about the options. The goal is to use a non-human identity wherever the connector supports it, and to keep a licensed human only where one is truly needed.
| Identity | Good for | Watch out for |
|---|---|---|
| Named user account | Personal productivity flows | Breaks when the person leaves, changes role, or loses a license |
| Shared service account | Connectors that only support user sign-in | Password rotation, MFA requirements, and shared knowledge of the password |
| Service principal application user | Owning mission-critical flows; Dataverse and admin connectors that support it | Not every connector supports service principal connections; premium flows still need licensing |
| Agent identity | Agents that need their own least-privilege identity | Newer capability; check which tools and connectors add permissions to it |
Service principal ownership is the change I'd make first. Microsoft recommends it for mission-critical flows because it insulates the flow from the owner's lifecycle: people leaving, changing roles, or losing a premium license. A service principal-owned flow that uses premium features still needs to be licensed, either with a Process license or by designating a licensed co-owner whose entitlement the flow runs under.
For agents, the same idea now has its own construct. An agent identity in Microsoft Entra is a special service principal without credentials of its own; it gets tokens through its blueprint. I cover agent ownership in more depth in Agent Ownership When Makers Leave.
04Certificates and secrets: rotate without an outage
Moving to a service principal doesn't remove rotation. It moves it to the app registration's credentials. The good news is that app credentials can overlap, so you can rotate without downtime if you do it in the right order.
Years ago a customer asked how to handle an expiring app credential, and I've repeated the same lesson since: deleting the old client secret immediately stops anything still using it. The order matters. Add the new credential, update every place that uses it, confirm runs succeed, and only then remove the old one.
Add
- Add a new certificate or secret to the app registration
- Keep the old one in place
Switch
- Update the connection or Key Vault entry
- Confirm successful runs on every dependent flow
Remove
- Delete the old credential
- Record the next expiry date and its owner
Microsoft Entra's guidance is clear on which credential to use: prefer managed identities or federated credentials where possible, then certificates, and avoid client secrets. Store certificates in Azure Key Vault, and use application management policies to limit secret lifetimes or block secrets entirely. Some Power Platform connectors still only accept a client secret for service principal connections, so check each connector's documentation before you standardize.
05Desktop flows and machine credentials
Desktop flows add a second credential: the Windows account that signs in to the machine. This is where rotation used to cause the most pain, because the password was often typed directly into a connection.
Today I recommend Power Automate credentials backed by Azure Key Vault or CyberArk. The connection points at the vault, so the secret lives in one governed place instead of inside each connection. Microsoft also documents certificate-based authentication for these credentials, which helps when the account must meet multifactor authentication requirements.
Before you rely on vault-backed credentials for rotation, read the current limitations on Microsoft Learn. How updated secrets are picked up has changed over time, and you want to test a rotation in a non-production environment before your security team schedules the real one.
06Admin automations need extra care
Some of the most rotation-sensitive flows are administrative ones, because they need strong permissions.
An engineering firm asked whether a flow could add and remove users from security groups as part of an onboarding process. It can. The Microsoft Entra ID connector has actions to add a user to a group and remove a member from a group. But the account behind the connection needs directory permissions to do it, which makes that connection one of the most sensitive in the tenant. I wanted to test the security group scenarios before confirming the approach. In hindsight, the identity behind that connection was the bigger design decision.
For flows like this, here's what I recommend:
- Keep admin flows in a dedicated, locked-down environment with a restrictive data policy.
- Scope the identity as narrowly as the connector allows, and document why it needs each permission.
- Prefer a service principal where the connector supports it. The Power Automate Management connector, for example, supports service principal authentication for its admin actions.
- Add an approval step before changes to privileged groups.
On-premises data adds one more layer. In 2022 I worked with a customer who wanted flows to reach SQL Server through the on-premises data gateway using Entra ID authentication instead of a SQL login. Which authentication types work through the gateway varies by connector and has changed over time, so check the SQL Server connector reference before you design around it.
07A rotation-ready checklist
- Every business-critical flow is in a solution and uses connection references.
- Mission-critical flows are owned by a service principal, with licensing sorted.
- App registrations use certificates stored in Key Vault, with expiry dates tracked and owned.
- Desktop flow machine accounts use vault-backed credentials.
- You can answer "which flows use this account?" in minutes, using connection details or Inventory.
- Rotation has been tested end to end in a non-production environment.
For the broader governance toolbox, see my governance tools guide.
Where I'd start
List every account and app registration behind your production flows, and how each one authenticates. Move mission-critical flows to service principal ownership and connection references. Switch app credentials to certificates, put machine credentials in a vault, and rehearse a rotation before it happens for real. Then you can tell your security team "yes, rotate it," and mean it.
Happy to go deeper on any of this.
— K.G
Sources
- Microsoft Learn: Support for service principal owned flows; Assign a user license to a flow owned by a service principal
- Microsoft Learn: Understand flow ownership and access; Change the owner of a cloud flow
- Microsoft Learn: Manage connections for the Microsoft Dataverse connector; Use a connection reference in a solution
- Microsoft Learn: Create an Azure Key Vault credential; Secure your data (desktop flow coding guidelines)
- Microsoft Learn: Security best practices for application properties in Microsoft Entra ID; Add and manage application credentials
- Microsoft Learn: Microsoft Entra ID connector reference; Power Automate Management connector reference; SQL Server connector reference
- Microsoft Learn: What is Microsoft Entra Agent ID?; Agent identities in Microsoft Entra Agent ID
Get new posts by email
Provider: your email provider
