Power Platform security roles: least privilege in practice

Least privilege is a principle that most security teams understand in theory and most Power Platform tenants violate in practice. The path of least resistance — granting System Administrator because it makes things work — is also the path to a security posture you cannot defend.

The roles that matter

Power Platform has several built-in security roles. The ones most tenants need to think carefully about:

• System Administrator: full access to everything in the environment. Should be restricted to a very small number of accounts — ideally only your CoE service account and a handful of designated tenant admins.
• System Customizer: can create and customise components but cannot see data in Dataverse tables. Good for developers who need to build but should not have access to production data.
• Environment Maker: can create apps, flows, and connectors but cannot modify Dataverse table structure. The right starting role for most makers.
• Custom roles: where the real work happens.

Building custom security roles

Custom security roles let you define exactly what a user can do with each Dataverse table: create, read, write, delete, append, append to, assign, share. At what scope — user, business unit, parent and child, organisation.

The process I follow:

1. Start with the minimum role needed for the job
2. Add permissions only as needed, one at a time
3. Test with a test user account, not your admin account
4. Document every permission granted and why
5. Review quarterly

Service accounts and flows

Flows run as the user whose connection is attached. This means every production flow is effectively running with that user's permissions on every system it touches. Service accounts for production flows should:

• Be dedicated accounts — not personal accounts, not shared IT accounts
• Have exactly the permissions the flow needs and nothing more
• Have MFA configured (yes, even service accounts — use conditional access policies to manage this appropriately)
• Have their access reviewed whenever the flow's requirements change

The question to ask for every permission you grant: what is the worst thing that happens if this account is compromised? If the answer is "everything breaks" or "all our customer data is exposed," the permission scope is too broad.

Quarterly access reviews

System Administrator assignments should be reviewed quarterly. Environment Maker assignments should be reviewed when someone leaves the organisation or changes role. Custom security role assignments should be reviewed when the business process they support changes.