Hard-coded secrets expose credentials directly inside apps or flows, which makes them easier to discover, reuse, or leak through logs and shared components. Overly broad permissions expand the blast radius when a maker misconfigures access or syncs data into the wrong account. The practical result is faster data leakage, weaker containment, and more opportunities for unauthorized use.
Why the risk is disproportionate in Power Platform
Power Platform apps and automations often sit close to business data, but they are built and changed quickly by makers who may not think like security engineers. A single hard-coded secret or an overly generous connector scope can turn a low-code workflow into a reusable access path, especially when the same flow is cloned, shared, or triggered across environments.
Hard-coded secrets are dangerous because they make the credential part of the app artifact itself. Once that happens, the secret can be copied, exported, surfaced in logs, or reused long after the original maker has moved on. Overly broad permissions are equally risky because they let one mistake affect more data, more systems, and more users than the business expected.
What makes this disproportionate is the combination of speed and reach. Power Platform encourages reuse and automation, so an exposed secret or broad permission set can spread impact faster than in a manually operated process. That is why a small configuration error can become a large-scale confidentiality or access problem very quickly.
How hard-coded secrets and broad permissions amplify blast radius
With hard-coded secrets, the failure is not only that a credential exists, it is that the credential is embedded in an execution path that may be easy to replicate. If the secret authenticates to a high-value system, every copy of the app or flow becomes a potential access point, and every place that records runtime details becomes a possible leakage source.
Broad permissions create a different but related amplification effect. A maker might only need read access to one dataset, yet the flow may run under an account that can read, write, or delete across many records and environments. When that happens, misrouting data, syncing to the wrong destination, or triggering the wrong connector action can cause damage far beyond the intended use case.
The control problem is therefore not just secrecy or least privilege in isolation. It is whether the automation’s runtime authority is proportionate to the task, and whether the credential or permission set can be rotated, scoped, and audited without breaking the business process. For practical guidance on the secret side of this problem, see Ultimate Guide to NHIs, Static vs Dynamic Secrets and Guide to the Secret Sprawl Challenge.
Current NHI research also shows how common these failure modes are in practice: NHI survey findings report that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 97% of NHIs carry excessive privileges.
What practitioners should verify before trusting a Power Platform app or flow
What to verify: Check whether any secret is embedded in the app, flow, environment variable, custom connector, script, or expression rather than supplied through a managed secret store. Then verify which identity actually executes the action, because the runtime identity often matters more than the maker’s own permissions.
Decision rule: If the automation can reach production data, external APIs, or administrative connectors, treat hard-coded secrets and broad scopes as a high-priority design defect, not a cleanup task. If the permission model cannot be clearly explained in one sentence, it is probably broader than the business process needs.
What good looks like: Secrets are stored and rotated outside the app package, permissions are narrow enough to limit a bad trigger event, and access can be reviewed without reverse engineering the automation. That is the standard to aim for in low-code environments where reuse and delegation are normal.
Practitioner takeaway: In Power Platform, the real risk is rarely that an app exists, it is that the app or flow can act with more authority, for longer, and in more places than the maker intended.
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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Hard-coded secrets and exposed credentials are central to this risk. |
| NHI-02 — Least Privilege and Authorization | Overly broad permissions increase blast radius when automations act on data. | |
| NHI-03 — Identity Lifecycle and Governance | Shared, reused, or stale automation credentials need lifecycle control. | |
| Recommendation — Move credentials out of apps and flows, and require managed secret storage plus rotation. Scope each flow and connector to the minimum permissions needed for the task. Inventory, review, and revoke automation credentials on a defined schedule. | ||
| CIS Controls v8 | 6 — Access Control Management | Access paths for automations should be limited to reduce misuse and leakage. |
| 16 — Application Software Security | Low-code apps and flows need secure handling of embedded secrets and configuration. | |
| Recommendation — Restrict accounts, permissions, and service access to only approved business functions. Prevent secrets from being embedded in source, configuration, or deployment artifacts. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | The issue is fundamentally about controlling runtime access and privilege. |
| PR.DS — Data Security | Leaked secrets and excessive permissions directly expose sensitive data. | |
| Recommendation — Enforce access boundaries so automation authority matches business need. Protect sensitive data paths and reduce exposure from misrouted or overbroad automations. | ||
Related resources from NHI Mgmt Group
- Why do hard-coded secrets in native mobile apps create elevated risk during penetration testing?
- Why do hard-coded Kubernetes secrets create lasting governance risk?
- Why do misconfigured vendor credentials and overly broad permissions create such high risk in integrations?
- Why do hard-coded secrets and weak repository controls create outsized risk in software delivery pipelines?
