Treating these platforms as low-risk usually leads to weak governance, broad permissions, and limited monitoring. That creates blind spots around data movement, third-party connections, and privilege use. The failure is not the platform itself, but the assumption that simplicity removes the need for control design, review, and enforcement.
Why This Matters for Security Teams
Low-code and no-code platforms often reach production through business-led adoption, not security-led design. That makes them easy to underestimate: teams see simplified interfaces and assume reduced risk, while the platform quietly handles authentication, data integration, API calls, and workflow execution. The result is a governance gap where permissions expand faster than review, and security controls trail actual usage.
This matters because the platform is not the risk boundary. Each app or workflow can still move sensitive data, connect to third-party services, and act with delegated access that should be treated as a non-human identity. Current guidance aligns better with the view that Top 10 NHI Issues apply whenever software can authenticate, exchange secrets, or make privileged requests on behalf of a user or process. Security teams that rely on the label “low-code” often miss the identity layer entirely.
That blind spot shows up in breach patterns too. In The 2024 ESG Report: Managing Non-Human Identities, Oasis Security & ESG found that 72% of organisations have experienced or suspect they have experienced an NHI breach. In practice, many security teams encounter privilege creep and uncontrolled data movement only after a workflow has already connected the wrong systems, rather than through intentional review of the platform’s actual access model.
How It Works in Practice
The operational failure usually starts with trust in the builder rather than the runtime. Low-code tools often let users assemble automations that inherit broad tenant-level permissions, cached tokens, or connected app scopes. If security reviews only the platform vendor and not the individual workflow, they miss the real identity, the real secret, and the real blast radius.
A safer model treats each workflow as a governed workload identity. That means inventorying apps, connectors, service accounts, OAuth grants, secrets, and webhook endpoints; then mapping each one to business owner, data classification, and approval path. The practical control set is familiar from NHI governance: isolate secrets, rotate credentials, restrict scopes, and monitor for unusual tool chaining. The Ultimate Guide to NHIs is useful here because it frames the underlying issue as identity sprawl, not just application sprawl.
Security teams should also push evaluation to the point of use. A workflow that can email, write to CRM, and call a payment API does not need blanket approval if policy can be enforced per connector and per action. That aligns with NIST Cybersecurity Framework 2.0 and the control discipline in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access, logging, and configuration management intersect.
- Require inventory of every app, automation, connector, and secret before production use.
- Limit OAuth scope, token lifetime, and connector privileges to the minimum needed.
- Review workflows for data egress paths, not just user-facing functionality.
- Log every privileged action, external call, and permission change with owner context.
These controls tend to break down in large citizen-development environments because business teams can create and modify workflows faster than security can inventory and re-certify them.
Common Variations and Edge Cases
Tighter governance often slows adoption, so organisations have to balance speed against control coverage. The goal is not to block low-code and no-code use, but to stop “easy to build” from becoming “easy to over-privilege.” Best practice is evolving, and there is no universal standard for every platform yet, especially where embedded AI features and external connector marketplaces are involved.
One edge case is shadow IT built on approved SaaS tools. Even when the platform itself is sanctioned, users may connect personal accounts, unmanaged APIs, or third-party plugins that extend trust beyond the original security review. Another is shared automation ownership, where no one clearly owns the secrets, scopes, or logs after deployment. Those environments are where current guidance suggests treating the workflow as an NHI and applying the same scrutiny used for other privileged machine identities. The 2024 ESG Report: Managing Non-Human Identities shows how quickly weak governance becomes a breach pattern when visibility is incomplete.
Security teams also need to distinguish platform risk from process risk. A low-code app handling public notifications is not the same as one moving HR records or finance data through a chain of third-party integrations. OWASP NHI Top 10 is relevant here because it reinforces the need to assess identity misuse, token exposure, and excessive privilege wherever software can act autonomously or semi-autonomously.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Low-code workflows behave like NHIs when they authenticate and call downstream services. |
| NIST CSF 2.0 | PR.AC-4 | Broad connector access and weak approvals are access-control failures. |
| NIST SP 800-53 Rev 5 | AC-6 | Over-privileged automations are a direct least-privilege issue. |
| NIST AI RMF | Embedded AI and automated workflow decisions need governance and accountability. | |
| CSA MAESTRO | Citizen-developed automations need lifecycle controls, policy, and monitoring. |
Treat each low-code workflow as a governed AI-adjacent workload with approval, audit, and runtime checks.
Related resources from NHI Mgmt Group
- What breaks when security teams connect AI security platforms to inconsistent identity and risk signals?
- What breaks when security teams treat data labels as a complete risk strategy?
- How should security teams monitor collaboration platforms for exposed secrets and NHI risk in real time?
- What breaks when identity security teams treat non-human access the same as human access?
