Should organisations treat low-code app builders as an IAM issue?

Why This Matters for Security Teams

Low-code app builders often look like a speed and productivity issue, but the real risk appears when those platforms create, store, or pass along secrets and delegated access that security teams cannot see clearly. At that point, the question shifts from software delivery to identity governance, privileged access, and auditability. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it ties access control, configuration management, and accountability to system design rather than to the development style alone.

The common mistake is to treat the builder as the control boundary. In practice, the control boundary is the identity fabric behind the app: who can author workflows, which service accounts are embedded, what tokens persist, and whether access can be revoked without breaking production. If those elements are unmanaged, the platform becomes a path for shadow privilege, weak segregation of duties, and unreviewable machine access.

That matters especially when low-code tools are exposed to business users, external customers, or agents acting on behalf of humans. A workflow that sends data, calls APIs, or triggers approvals is still security-relevant even if no traditional codebase exists. In practice, many security teams encounter low-code identity risk only after a public app has already inherited overbroad tokens or orphaned delegated access, rather than through intentional IAM design.

How It Works in Practice

Operationally, the IAM questions around low-code builders are the same questions asked of any system that can authenticate, authorise, or impersonate something else. Security teams should identify what identity the app uses at runtime, what authority is delegated to the builder or workflow engine, where credentials are stored, and how those credentials are monitored. If the platform supports shared connectors, OAuth grants, API keys, or service principals, each of those becomes part of the access model.

A practical review usually starts with four checks:

• Who can create and publish apps, and is publishing separated from approval?
• What identities are used by the app at runtime, including human, service, and tenant-level accounts?
• Where are secrets stored, and can they be rotated without rebuilding the app?
• Can activity be logged, exported, and correlated with identity events in SIEM or IAM tooling?

That approach aligns well with control thinking in OWASP Secrets Management Cheat Sheet, because many low-code risks are really secret lifecycle failures. It also reflects the access governance intent behind NIST SP 800-53 Rev 5 Security and Privacy Controls: limit standing access, protect credentials, and preserve traceability.

In mature environments, teams also classify low-code assets by data sensitivity and privilege level. A simple internal form workflow is not equivalent to a customer-facing app that can create records in finance systems or call privileged admin APIs. The latter may need the same review discipline used for service accounts, secrets vaulting, approval workflows, and periodic recertification. These controls tend to break down when non-technical builders can publish directly to production because identity ownership, token scope, and change approval stop being enforced at the same point.

Common Variations and Edge Cases

Tighter governance often increases friction for business-led development, so organisations have to balance agility against the risk of uncontrolled privilege. That tradeoff becomes most visible when low-code platforms support citizen developers, external sharing, or automated approvals. Best practice is evolving, but there is no universal standard for treating every builder as a full IAM platform; the decision should depend on whether the app can materially create, hold, or exercise access.

Some edge cases deserve special handling. Embedded AI assistants inside low-code tools can introduce agentic behaviour, which means the workflow may act on a user’s behalf with broader authority than intended. In those cases, the question overlaps with AI governance and identity governance at the same time. Similarly, apps that only read public data may have lower IAM exposure than apps that write to ERP, CRM, or cloud control planes.

Security teams should be most cautious when a platform lacks exportable logs, central secret management, or fine-grained publishing controls. Those gaps make it difficult to prove who granted access, which token was used, or whether access was revoked in time. Guidance from OWASP Top 10 for LLM Applications is also relevant where low-code builders integrate AI features, because prompt injection, tool misuse, and output validation become part of the access problem. The practical test is simple: if the organisation cannot review and revoke the app’s authority as easily as it can review and revoke a human account, the low-code platform should be treated as an IAM concern.

Related resources from NHI Mgmt Group

• When should organisations treat SaaS settings as an IAM issue?
• Should organisations prioritise code-first or low-code agent builders?
• When should organisations treat password management as an IAM issue rather than a user productivity issue?
• When should organisations treat an API design issue as an identity risk?