Security teams should start with clear governance, not blanket restriction. Separate professional development from citizen development, classify data by sensitivity, and set default controls that limit who can create, share, and connect apps to business data. Then apply Data Loss Prevention policies, restrict external sharing, and audit permissions regularly so speed does not outrun control.
What Secure Low-Code Development Needs to Account For
Power Platform changes the control problem because development is distributed. The risk is not just app code, it is who can assemble workflows, connect to data, reuse connectors, and publish changes without the same review depth that professional developers face. Security teams need to govern those paths by design, while still preserving fast delivery for approved business use cases.
That means the control plane should focus on creation rights, data access, connector use, sharing boundaries, and visibility into what has been built. If those areas are left implicit, business users can unintentionally create shadow integrations, overexpose data, or turn a simple automation into a broad privilege path.
Good governance usually starts with secret sprawl control and permission boundaries, because low-code platforms often depend on connections, tokens, and service integrations that can be reused far beyond the original business need. A single overly broad connector or shared credential can make many apps inherit the same exposure.
Where Security Teams Should Put the Controls
The strongest pattern is to separate environments and rules by risk, not by organizational politics. Business-built apps should sit in constrained environments with approved connectors, limited sharing, and clear ownership, while higher-risk automations that touch sensitive data should require tighter review and more restrictive publishing paths.
Data Loss Prevention policies are central, but they work best when paired with sensible guardrails around who may create resources, connect to production systems, or move content across data boundaries. Security teams should also review external sharing, guest access, and cross-tenant connectivity with the same discipline they would apply to any integration layer that can move regulated or confidential data.
For teams that need an independent control reference, NIST Cybersecurity Framework 2.0 supports the broader govern, identify, protect, detect, respond, recover model, while Docker Hub Auth Secrets in Container Images is a useful reminder that embedded credentials and hidden connections tend to outlive the app that introduced them.
Risk and Threat Considerations
Low-code speed becomes a security issue when it bypasses the normal checkpoints for data access, approval, and auditability. The main failure mode is not malicious intent, it is permission accumulation, where many small automations quietly inherit broad access and create a larger blast radius than their owners understand.
Failure mechanism: A citizen developer can combine an approved connector, a permissive sharing setting, and an overbroad data source into a workflow that moves sensitive records outside intended controls, or exposes privileged functionality through an app that was never reviewed as production software.
Impact: The result can be unauthorized data disclosure, untracked business process changes, privilege misuse, or a hidden integration path that is hard to unwind after the fact. In mature environments, the most damaging outcome is often not the first app, but the repeated reuse of the same risky pattern across many apps and automations.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Controls who can create, share, and connect low-code assets to sensitive systems. |
| 8 — Audit Log Management | Low-code platforms need auditability for app creation, connector use, and permission changes. | |
| Recommendation — Restrict app creation, sharing, and connector access to approved roles and environments. Log app, flow, connector, and sharing events so security can review material changes. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Applies because the main security problem is controlling who may build and connect business apps. |
| GV.RM — Risk Management Strategy | The question is about governing fast development without letting risk outrun control. | |
| Recommendation — Apply access controls that limit low-code creation and data connection rights by business need. Set risk-tiered governance for citizen development instead of using one blanket approval model. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Low-code automations often depend on reusable connections and credentials that must be revoked cleanly. |
| NHI-03 — Secret Leakage | Power Platform solutions can leak credentials or connection details through poorly governed integrations. | |
| NHI-07 — Overprivileged Non-Human Identities | Automations and connectors can accumulate broader access than the business task requires. | |
| Recommendation — Revoke stale app connections, service accounts, and tokens when apps or owners change. Prevent secrets from being embedded in flows, connectors, or exported artifacts. Constrain automation credentials and connectors to least privilege for each business process. | ||
Practitioner Guidance
What to prioritise: Start with a minimum-viable governance model, environment separation, connector allowlisting, DLP policy baselines, and clear ownership for every app and flow. Those controls will usually reduce risk faster than trying to approve every individual build manually.
What to verify: Check whether the people who can build are also able to share broadly, connect to sensitive business systems, or publish to production-like environments without extra approval. Also verify that admin teams can still discover and review dormant or orphaned automations, because forgotten flows often become the longest-lived risk.
Practitioner takeaway: The real objective is to make low-code safe enough for scale, not to slow it down into a traditional development bottleneck; security should bound the data and connector paths, then let speed happen inside those boundaries.
Related resources from NHI Mgmt Group
- How should security teams reduce data leakage risks when business users are building and using AI in low-code environments?
- How should security teams secure no-code and low-code applications that connect to critical business systems?
- How should security teams govern business-built AI agents in low-code platforms?
- What do security teams get wrong about low-code apps in industrial IT?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
