Security Requirements for Selecting a Low-Code and Automation Platform: A Buyer’s Guide to Criteria and Testing

A low-code and automation platform lets hundreds of people who are not developers build apps, flows and agents that hold credentials to the organisation's most important systems, and the platform decides whether that happens under governance or as shadow IT. Selections tend to be led by the business on speed of building and connector catalogues, and security is asked to review after a pilot is already in use. This vendor-neutral buyer's guide sets out the security requirements to write into the RFP, how to weight them, what to ask vendors and how to test the answers before contract. It is for security architects, platform owners, enterprise architects and procurement leads choosing a low-code app builder, workflow automation service or citizen development platform, including those that now build AI agents. For securing a platform you already run, see the Low-Code and No-Code Application Security Guide.

Key takeaways

• Buy the governance plane, not just the builder. Environment separation, connector policies, sharing limits and a tenant-wide inventory decide whether citizen development stays safe; the OWASP Citizen Development Top 10 puts asset management and logging failures on its list for this reason.
• Connections are credentials. Every connection a maker creates is a stored credential or OAuth grant, and shared apps can let users act through the creator's identity; require visibility and control of every connection.
• Connector policy must be enforced at runtime. Require allow, block and segregation rules for connectors, including custom and HTTP connectors, enforced both when a flow is built and when it runs.
• Public endpoints need secure defaults. Portals, forms and webhook triggers expose data to the internet; require authentication on by default and record-level permissions that are hard to get wrong.
• Prove it with a hostile pilot. In the proof of concept, try to share a creator connection, call a blocked connector, publish an anonymous form and export data, and check that each attempt is stopped or logged.

Define requirements

Agree these points with the business sponsor, the platform owner and data owners before vendor briefings:

• Builder population: professional developers only, a named group of trained makers, or everyone. The wider the group, the more the platform's guardrails matter. See the Citizen Developer and Internal AI App Governance Guide.
• Use cases: internal forms and apps, approval workflows, data integration between SaaS systems, robotic process automation on desktops, customer-facing portals and AI agents. Each adds different identities and exposure.
• Systems to connect: ERP, CRM, HR, finance, file stores, databases, on-premises systems through a gateway and external APIs. List which hold regulated or business-critical data.
• Hosting model: multi-tenant SaaS, a dedicated instance or self-hosted. Self-hosted automation tools move patching, secrets storage and network exposure onto you.
• External exposure: whether any app, form, portal, webhook or agent will be reachable by people outside the organisation.
• AI capability: whether makers can build agents or use AI actions, which models they call and with what data. See the Low-Code Agent Platforms Guide.
• Lifecycle: how apps move from development to production, who owns them, and what happens when a maker leaves.

A small organisation with a handful of trained makers can focus on SSO, connector policy, connection visibility and audit export. Large organisations with open citizen development should add multiple environments with promotion pipelines, tiered risk classification, automated inventory and ownership transfer, data loss prevention for flows and independent assurance scoped to every module in use.

Capability areas

Identity and administration

• Single sign-on: SAML 2.0 or OpenID Connect for makers, users and administrators, enforced MFA through the identity provider and no local accounts outside break-glass.
• Provisioning: SCIM 2.0 or equivalent so leavers lose maker and admin rights, with a defined process for transferring ownership of their apps, flows and connections. See the SCIM Provisioning Guide.
• Role model: separate roles for tenant administration, environment administration, makers, approvers and auditors, with the ability to restrict who may create environments, custom connectors and public endpoints.

Connections, credentials and run-as identity

• An inventory of every connection, its owner, the account it authenticates as, its scopes and the apps and flows using it.
• Clear control of run-as identity: whether a shared app or flow runs as each user or as the creator, and the ability to block or flag apps that run on a maker's personal credentials. OWASP CD-SEC-02 (Account Impersonation) describes how embedded creator identities let any user of an app act as its creator and hide who really did what.
• Support for dedicated service accounts or workload identities for production automation, with secrets held in a vault integration rather than in flow definitions.
• Controls on implicitly shared and over-shared connections, which OWASP CD-SEC-03 (Authorization Misuse) names as a core risk, and the ability to force re-authentication.
• Scope review for OAuth grants requested by apps, with alerts for highly privileged scopes unrelated to the app's purpose.

Connector and data policy

• Allow, block and segregation rules for connectors, so business data connectors cannot be combined with personal or consumer services in the same app or flow.
• Control over custom connectors and generic HTTP actions by endpoint or domain, since a single HTTP action can send data anywhere.
• Enforcement at design time and at runtime, with violating apps or flows suspended rather than only warned about.
• Data loss prevention for content passing through flows and AI actions, and limits on bulk export.

Environments, lifecycle and change control

• Separate development, test and production environments, with the ability to restrict who can create environments and which connectors each allows.
• Solution packaging, version history and a promotion pipeline with approval, so production changes are reviewed. OWASP CD-SEC-09 (Asset Management Failures) recommends version control, ownership, tiered risk classification and a central inventory.
• Sharing limits: caps on sharing with large groups or everyone, and controls on who can share flows and agents.
• Detection of orphaned apps and flows whose owner has left, with transfer or disablement.

Public endpoints and generated code

• Authentication required by default on portals, forms, APIs and webhook triggers, with an explicit, logged decision to allow anonymous access.
• Record-level permission models for portals that make it hard to expose whole tables by mistake, with a report of anonymous permissions in force.
• Signed or authenticated webhook triggers and rate limiting on public endpoints.
• Input handling in generated apps and AI actions that resists injection, which OWASP CD-SEC-08 covers.
• Abuse resistance for hosted apps and agents. The CoPhish technique showed how an agent built on a low-code platform and hosted on the vendor's trusted domain can front an OAuth consent phishing flow, so ask what the vendor does to detect malicious hosted apps.

Audit, monitoring and vendor assurance

• Audit events for app and flow creation, changes, sharing, connection creation and use, connector policy changes, environment creation, runs and failures, exportable to your SIEM. OWASP CD-SEC-10 notes that platform logs should avoid recording raw sensitive data.
• Retention of at least six months at no extra charge, the baseline CISA's Secure by Demand guide asks SaaS buyers to look for.
• Independent assurance scoped to the modules in use (including RPA, AI and portal components), a vulnerability disclosure policy, security advisories with CVE records and, for marketplace templates and components, a stated review process.

Evaluation criteria

Weights are illustrative, set by NHI Mgmt Group as a starting point. Raise public endpoint weights if portals or forms face customers; raise connection and connector weights where makers will touch finance, HR or customer data.

The table below maps low-code threats to the OWASP Citizen Development Top 10 and to the requirement that addresses each. ATT&CK IDs are from ATT&CK v20.

Where identity fits

A low-code platform is one of the largest sources of non-human identities in most organisations. Each connection, service account, gateway, bot, RPA robot account and agent is an identity with access to business systems, created by people who do not manage identities for a living. Require the platform to expose them in a form your identity programme can consume: owner, scopes, last use and the apps that depend on them. See the NHI Discovery Guide, the RPA and Bot Identity Security Guide and How to audit Zapier, Make and n8n connections and credentials.

Questions to ask vendors

• Are SSO, SCIM, connector policies, environment controls and audit logs in the tier we are buying, or in a separate governance add-on?
• Can we list every connection in the tenant with its owner, authenticating account, scopes and dependent apps, through an API?
• When a maker shares an app, can users act with the maker's credentials, and can we block or flag that?
• Do connector policies cover custom connectors, HTTP actions, AI actions and agent tools, and are they enforced at runtime as well as design time?
• What happens to apps, flows and connections when the owner leaves, and how do we transfer or disable them in bulk?
• Are portals, forms and webhook triggers authenticated by default, and can we report every anonymous permission in force?
• How are secrets stored for flows and gateways, and can we use our own vault?
• Which audit events exist for sharing, connection creation and run activity, and how long are they kept at no extra cost?
• How do you review marketplace templates and components, and how are we told when one has a vulnerability?
• Where do AI actions send data, is it used for training, and can we restrict which models makers may call?

Red flags

• Governance features (environment policies, connector rules, inventory) sold only in a premium tier after the business has adopted the free or basic tier.
• No way to see which connections exist or whose credentials they use.
• Connector policies that warn but do not block, or that exclude HTTP and custom connectors.
• Portals or forms anonymous by default, or permission models that grant table-wide access in one setting.
• Credentials stored in plain text in flow definitions or exported packages.
• No orphan handling: apps keep running on a leaver's connections indefinitely.

Proof of concept

1. Connect SSO and SCIM, create maker, admin and auditor roles, disable a maker in the IdP and confirm their apps and connections are reported for transfer.
2. Build an app using the maker's own database connection, share it with a test user and record whether the user acts with the maker's identity and what the logs show.
3. Apply a connector policy that blocks a consumer file service and an unapproved HTTP endpoint; try to build and then run a flow that uses each.
4. Create a portal or form, attempt to publish it anonymously and to grant table-wide read, and check the anonymous permission report.
5. Promote an app from development to production through the pipeline and confirm the approval and version history.
6. Export the tenant inventory of apps, flows, connections and agents by API and compare it with what you built.
7. Stream audit logs to the SIEM and confirm sharing, connection creation, policy violations and runs arrive with the right identities.

Score each step against the criteria table. If connection visibility or connector enforcement tests fail, pause the business pilot rather than letting it grow; rolling back a platform with hundreds of live flows is far harder than delaying the first ten.

After selection: measures and common failure patterns

Track after go-live: the share of production apps and flows with a named owner; connections using personal credentials in production; apps shared with everyone; connector policy violations blocked per month; anonymous portal permissions in force; and orphaned apps disabled or transferred. The Top 10 Workflow Automation Security Risks covers what to watch.

• Default environment as production: everything is built in the shared default environment, so no separation or promotion exists.
• Personal connections in critical flows: a finance flow runs on one person's account and stops, or keeps running, when they leave.
• HTTP connector left open: connector rules cover named services but not generic HTTP actions.
• Anonymous portals: a portal published for convenience exposes whole tables to the internet.
• No incident plan: nobody knows how to revoke every connection at once. See If your low-code and automation platform is compromised.

Framework mapping

Standards and references

• OWASP: Citizen Development Top 10
• OWASP: Citizen Development Top 10 project repository
• CISA: Secure by Demand Guide
• NCSC: The Cloud Security Principles
• NIST: SP 800-53 Rev. 5
• Cloud Security Alliance: Cloud Controls Matrix

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.

Related NHI Mgmt Group resources: Low-Code and No-Code Application Security Guide · Low-Code Agent Platforms Guide · Microsoft Dynamics 365 and Power Platform Security Guide · Security Requirements for Selecting an Integration Platform