Notifications
Clear all
Topic starter
25/06/2026 3:24 pm
TL;DR: Power Platform security groups can be bypassed by application users built on Entra service principals, allowing Dataverse API access even when those identities are excluded from the expected tenant control plane, according to Zenity’s analysis. The gap matters because it breaks zero-trust assumptions across IAM and NHI governance, especially where service principal access is assumed to inherit human-oriented restrictions.
NHIMG editorial — based on content published by Zenity: When “Secure by Design” Isn’t Enough: A Blind Spot in Power Platform Security Access Controls
By the numbers:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.
Questions worth separating out
Q: What breaks when Security Groups do not govern Application Users in Power Platform?
A: The main failure is that administrators think a group boundary blocks access, while a service principal can still authenticate and query Dataverse through APIs.
Q: Why do service principals create governance risk in low-code platforms?
A: Service principals are non-human identities, so they do not always follow the same policy inheritance that human accounts do.
Q: How can security teams verify that Dataverse access is really constrained?
A: They should test the API and data layers directly, not rely only on environment membership or UI restrictions.
Practitioner guidance
- Map every Application User to its actual enforcement path Document which Dataverse environments, APIs, and data surfaces are reachable by each service principal, then compare that mapping with the Security Group design you think is in force.
- Test API access independently of UI restrictions Run access checks against REST and backend interfaces for excluded identities, because a blocked console path does not prove the data plane is blocked.
- Separate human user governance from service principal governance Treat Entra users, Application Users, and other non-human identities as different actor types in policy design, review, and audit evidence.
What's in the full article
Zenity's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step simulation setup showing how the App User was created and excluded from the Security Group
- Exact API querying path used to demonstrate Dataverse access despite the restriction
- Microsoft documentation update context and the governance response that followed
- Platform-specific mitigation suggestions for administrators working with Entra service principals
👉 Read Zenity's analysis of the Power Platform Security Group bypass and Dataverse exposure →
Power Platform security group bypass: what IAM teams are missing?
Explore further
25/06/2026 4:55 pm
Security Group governance is not the same as non-human identity governance. This article shows a familiar control failure: tenant administrators assumed a platform group policy would govern every identity class equally. It did not. Service principals are not human users, and once that distinction matters at runtime, the governance model has to be explicit about which actor type a control actually constrains. The implication is that access policy cannot be validated by label alone.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% having only partial visibility, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: Who is accountable when a service principal bypasses a platform access policy?
A: Accountability usually sits with the team that defined the control boundary and assumed it applied to all identity types. Platform owners, IAM teams, and application administrators all need to verify whether the policy engine enforces the same rule for users and Application Users. If it does not, ownership of the gap must be explicit.
👉 Read our full editorial: Power Platform security group bypass exposes Dataverse access gaps
