Low-code platforms expand the number of people who can build and share resources, often without deep security knowledge. That creates risk when sensitive and non-sensitive data are mixed, defaults are too permissive, or implicit sharing spreads access beyond intended users. The main issue is scale: more makers, more apps, and more opportunities for misconfiguration.
Why the Power Platform risk grows so quickly
Power Platform changes the security equation because it lowers the barrier to building business apps, automations, and connectors. That speed is useful, but it also means more people can create data flows, connect sources, and publish changes without the same review discipline that traditional development teams apply. Risk rises when control points are spread across many makers instead of a small engineering group.
The practical problem is not low-code by itself, but the combination of scale, ease of reuse, and broad access to data connectors. When a platform makes it simple to move data or add a new data source, the chance of accidental exposure rises unless governance, environment design, and permission boundaries are deliberately tightened.
- More creators means more opportunities for misconfigured sharing and unnoticed changes.
- Reusable components can propagate weak access decisions quickly across apps and flows.
- Convenient connectors can blur the boundary between approved data use and accidental leakage.
For teams treating Power Platform as a controlled development surface, the key question is whether the platform is governed like a production application environment or treated like a productivity tool with light oversight. That difference largely determines whether risk stays contained or spreads.
Where data leakage and unauthorized changes usually come from
Data leakage often starts with overbroad sharing, mixed sensitivity in the same app or flow, or connectors that reach farther than the maker intended. If sensitive records are combined with ordinary operational data, users may gain access to fields or outputs they were never meant to see. This can happen even when the maker had no malicious intent.
Unauthorized changes usually come from weak change control, overly permissive maker rights, or limited separation between build and release responsibilities. A low-code platform can make it easy to alter logic, update permissions, or republish an app quickly, which is helpful for agility but dangerous when approvals, ownership, and testing are inconsistent.
- Implicit sharing can expose outputs to broader audiences than the underlying data owner expected.
- Default permissions can let makers connect to data or environments beyond their intended scope.
- Shadow app creation makes it harder to know what has changed and who can change it.
One useful signal is whether your governance model can answer three questions at any time: who built the app, what data it touches, and who can modify or redistribute it. If those answers are unclear, leakage and unauthorized change become operationally likely rather than theoretical.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorization | Low-code exposure is driven by overly broad access and sharing. |
| PR.DS-1 — Data-at-Rest Protection | Mixed-sensitivity data in apps and flows raises leakage risk. | |
| CM-3 — Configuration Change Control | Unauthorized republishing or edits are change-control failures. | |
| Recommendation — Enforce least-privilege access for makers, apps, and connected data. Classify data and restrict sensitive fields in low-code workflows. Require approval and traceability for production app and flow changes. | ||
| CIS Controls v8 | 6.3 — Data Recovery | Governed platforms need reliable rollback after unsafe changes. |
| 6.4 — Access Control Management | Misconfigured maker and connector access is a core exposure path. | |
| 15.1 — Service Provider Management | External connectors and services expand the trust boundary. | |
| Recommendation — Maintain rollback options for low-code apps and automations. Review and revoke excessive platform and connector permissions regularly. Assess third-party connectors before allowing production data access. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Low-code connectors often rely on embedded secrets and tokens. |
| NHI-03 — Privilege and Access Governance | Excessive platform permissions enable unauthorized app changes. | |
| NHI-06 — Lifecycle and Offboarding | Unowned apps and stale access increase unauthorized change risk. | |
| Recommendation — Store connector secrets outside apps and rotate them on a schedule. Bound maker privileges to the minimum needed for each environment. Retire abandoned apps, flows, and credentials promptly. | ||
Practitioner Guidance
What to verify: Validate that environment separation, connector permissions, and sharing rules are aligned to data sensitivity before approving broad maker access. If an app can reach production data, it should be governed as a production asset, not as a casual team workflow.
Common mistake: Teams often focus on app logic and overlook the data path, which is where most leakage risk lives. A simple app with an overly permissive connector or inherited sharing can be more dangerous than a complex app with tighter controls.
Decision rule: If the platform lets non-specialists publish apps or flows, then change control has to move left, with explicit ownership, review points, and monitored exception handling. Convenience should not remove the need for traceability.
Practitioner takeaway: The main control objective is not to stop low-code development, but to make data access, sharing, and change authority explicit enough that speed does not become a covert path to exposure.
Related resources from NHI Mgmt Group
- Why do AI agents and LLM applications increase the risk of unauthorized access and data leakage?
- Why do low-code applications create data leakage risk in enterprise environments?
- Why does low-code development create risk when form data and integration choices are poorly designed?
- Why do unauthorized apps and private logins increase data leakage risk in enterprise environments?
