Security Requirements for Selecting an iPaaS

An integration platform as a service ends up holding OAuth refresh tokens, API keys and database passwords for most of your business applications, and it can move data between all of them, yet it is usually bought by an application or automation team on connector count and price. Once live, the iPaaS is one of the densest concentrations of non-human credentials in the organisation, and a compromise of the platform, a tenant or a single connection can reach many systems at once. This vendor-neutral guide sets out the security requirements to write into an iPaaS selection: credential custody, connector authentication, runtime and agent placement, tenant isolation, platform access, logging, change control and supplier assurance. It is for security architects, integration and automation teams, and procurement leads. It covers application and API integration platforms; for bulk ETL and ELT tools see the Security Requirements for Selecting a Data Integration Platform, and for running a platform you already own see Securing the iPaaS and integration platform itself.

Key takeaways

Treat the iPaaS as a credential vault. Require encrypted storage of every connection secret, customer-managed keys or an external secrets manager, and an inventory showing each credential, its scope, owner and last use.
Prefer federated and token-based connections. Score providers on how many connectors support OAuth with least-privilege scopes, managed or workload identities and certificate authentication, not on raw connector count.
Decide where the runtime runs. Cloud-hosted runtimes, customer-hosted agents and hybrid gateways put data, credentials and network paths in very different places.
Builders are privileged users. Anyone who can edit a flow can read the data it touches and redirect it; demand environment separation, role-based access and approval before production changes.
Logs must show data movement. Audit logs of configuration changes and run history with record counts, destinations and failures are what you need to scope a leak.

Define requirements

Begin with an inventory of the integrations you plan to move onto the platform: source and target systems, data classes, volumes and triggers. Then write down:

Integration patterns: event-driven app-to-app sync, API orchestration, scheduled jobs, file transfer, business user automations and, increasingly, AI agent tool calls. Each pattern has different credential and data exposure.
Connection inventory: for each system, the authentication method available (OAuth authorisation code, client credentials, API key, basic authentication, certificate, managed identity) and the narrowest scope that does the job.
Network reach: which targets are on-premises or in private networks, and therefore need an agent, gateway or private connectivity rather than a public endpoint.
Data location: where payloads are processed, whether they are persisted (queues, retries, run history, debug logs) and for how long.
Builder population: professional developers only, or citizen integrators as well. The second needs stronger guardrails and is covered in the Security Requirements for Selecting a Low-Code and Automation Platform.
Regulatory drivers: personal data transfers, payment data and sector rules that limit where data may be processed or logged.

The NCSC Cloud Security Principles apply because an iPaaS is a cloud service; separation between customers (principle 3), identity and authentication (10), external interface protection (11) and audit information for customers (13) are the most relevant.

Capability areas

Capability area	Minimum requirement	Why it matters
Credential storage	Connection secrets encrypted at rest, never shown again after entry, customer-managed key or external secrets manager option, export blocked	A leaked platform database or export should not hand over every downstream credential
Connector authentication	OAuth 2.0 with configurable scopes, client credentials, certificate and managed identity support; per-connection rather than shared credentials	Scoped tokens limit the blast radius of one stolen connection (OWASP API10:2023)
Credential inventory	List of all connections with owner, auth type, scopes, creation and last-used dates, through UI and API	You cannot rotate or revoke what you cannot find
Runtime placement	Choice of provider-hosted or customer-hosted runtime; agents make outbound-only connections; agent authentication and update process documented	Agents sit inside your network with credentials to internal systems
Tenant isolation	Documented separation of customer runtimes, storage and credentials; independent testing of isolation	NCSC principle 3; one tenant must not reach another's tokens
Platform access	SSO with SAML or OIDC, enforced MFA, SCIM deprovisioning, roles separating build, deploy, operate and view	Builders can read and redirect data
Environments and change	Separate development, test and production environments, promotion with approval, version history, rollback, infrastructure or configuration as code	Stops an untested flow from writing to production systems (CM-3)
Data handling	Configurable retention of payloads in run history, masking of sensitive fields in logs, regional processing	Debug logs often hold full records
Logging	Audit log of every configuration and credential change, run logs with destinations and record counts, streaming to SIEM, at least six months retained	Needed to scope exfiltration through a flow (AU-2, AU-11)
Outbound controls	Allowlist of destinations or connectors, egress IP ranges published, block on arbitrary HTTP targets where policy requires	An HTTP step can send data anywhere

Connection authentication methods compared

Method	What the platform stores	Strength	Watch for
Managed or workload identity	Nothing long-lived; tokens issued by the cloud identity service at run time	No secret to steal or rotate	Usually limited to the hosting cloud's own services; Microsoft documents that hybrid Standard Logic Apps need an app registration instead
OAuth authorisation code with refresh token	Refresh token for a user or integration account	Scoped, revocable, user consent visible	Refresh tokens are long-lived bearer credentials; RFC 9700 requires public clients to sender-constrain or rotate them
OAuth client credentials	Client ID and secret or certificate	No user dependency	Secrets often never rotated; prefer certificate or private key JWT
API key	Static key	Simple	Often account-wide scope and no expiry
Basic authentication or database password	Username and password	Universal	Highest risk; restrict to systems with no alternative and a dedicated low-privilege account

Ask each provider for its connector catalogue with the supported methods per connector, and score coverage for your top 20 systems rather than for the catalogue as a whole. See the API Keys vs OAuth Tokens Guide and the OAuth 2.0 Security Best Current Practice (RFC 9700) Guide.

Evaluation criteria

Weights are an NHI Mgmt Group suggestion. Score 0 to 3 on evidence demonstrated during the evaluation.

Criterion	Weight	Evidence to request	Maps to
Credential custody and inventory	20%	Encryption design, key options, secrets manager integration, connection inventory export	SC-12, SC-28, IA-5
Connector authentication quality	15%	Auth methods for your top systems, scope configuration, token rotation behaviour	IA-5; CSF PR.AA-05
Platform identity and roles	15%	SSO, MFA enforcement, SCIM, role model, approval workflows	AC-2, IA-2
Runtime and network design	10%	Agent architecture, outbound-only connections, private connectivity, egress controls	SC-7, SC-8
Change control	10%	Environments, promotion, versioning, rollback, configuration as code	CM-3, CM-6
Logging and data handling	15%	Audit and run logs, retention, masking, SIEM streaming	AU-2, AU-11
Supplier assurance	15%	Audit reports covering the runtime and credential store, pen test summaries, VDP, incident notification terms, sub-processors	SA-9, SR-6; CSF GV.SC-05, GV.SC-06

CISA's Secure by Demand Guide adds baseline questions for any supplier: SSO at no additional cost, MFA by default, security logs retained for at least six months at no extra charge for cloud services, and a public vulnerability disclosure policy. A provider that charges extra for SSO or audit logs should score lower on those criteria.

Where identity fits

An iPaaS is a non-human identity platform whether or not it is sold as one. Every connection is a machine credential acting on behalf of the organisation, often created by one builder with their own user account and never reviewed again. Require integration-specific service accounts rather than personal accounts, so that a leaver does not break flows or leave their access running. The OAuth integration breaches show the pattern: in the Salesloft Drift Breach 2025 tokens held by one integration opened hundreds of Salesforce tenants, and in the Klue OAuth Breach 2026 a forgotten integration credential exposed customer data. Those are exactly the tokens an iPaaS holds in bulk. In ATT&CK terms, the risks are Steal Application Access Token (T1528) and abuse of a Trusted Relationship (T1199). See the OAuth and SaaS integration breaches lessons, the Non-Human Identity (NHI) Guide and the Secrets Management Guide.

Check how secrets are handled in deployed artefacts too. Some runtimes encrypt configuration values but must decrypt them in memory at run time; MuleSoft's documentation for secure configuration properties warns that decrypted values held in memory are visible to anyone who can inspect the process, so operating system access to customer-hosted runtimes must be restricted. Ask each provider the equivalent question.

Decision guidance by organisation size

Small teams: a fully hosted platform with strong defaults is usually safer than self-managed agents. Insist on SSO, MFA and audit logs in the plan you buy, and keep the number of builders small.
Large or regulated estates: expect customer-hosted runtimes for internal systems, customer-managed keys or an external secrets manager, private connectivity, full environment separation and log streaming with long retention.
Citizen integration: if business users will build flows, require connector allowlists, data loss prevention policies between connector groups, and an approval step before any flow touches production data.
AI agents as callers: if agents will invoke flows as tools, require per-agent identities, scoped flow permissions and run logs that record which agent called which flow. See ETL and iPaaS platform integration security guide.

Questions to ask vendors

How are connection credentials encrypted at rest, who holds the keys, and can we use our own key or an external secrets manager?
Can any user, including your support staff, view or export a stored credential after it has been entered?
Which authentication methods does each of our top 20 connectors support, and can OAuth scopes be narrowed per connection?
Can we list every connection with its owner, authentication type, scopes, creation date and last use, through an API?
How do customer-hosted agents authenticate to your service, do they need inbound firewall openings, and how are they updated and signed?
How are runtimes, queues and credential stores separated between customers, and when was that isolation last independently tested?
Do run histories or debug logs store full payloads, can we mask fields or turn payload logging off, and how long is it retained?
Can we separate build, deploy and operate permissions, and require approval to promote a flow to production?
Which audit events are logged for configuration and credential changes, and can we stream them to our SIEM?
Can we restrict which destinations HTTP or generic connectors may call?
How quickly will you notify us of an incident affecting our tenant or credentials, and is that contractual?
In an incident, can we revoke or rotate all connection credentials in bulk?

Red flags

Stored credentials can be revealed in the UI or exported in plain text by administrators.
Connections default to personal user accounts, with no support for dedicated integration identities.
Only API keys or basic authentication for major SaaS connectors that support OAuth.
Customer-hosted agents that require inbound connections from the internet, or that cannot be updated without manual reinstallation.
Full payloads kept in run history by default with no masking and no retention setting.
No environment separation, so builders edit production flows directly.
SSO, audit logs or log export only on the top tier, or no independent audit report covering the credential store.

Proof of concept

Run the POC with two or three real but non-production integrations, including one internal system reached through an agent. Use test accounts in the connected applications so you can revoke everything afterwards.

Enable SSO and enforced MFA, create build, deploy and view roles, and confirm a user removed from your IdP loses access.
Create connections using the strongest method each target supports, with dedicated integration accounts and narrowed scopes, and record the scopes granted.
Try to reveal or export a stored secret as an administrator and confirm it is not possible.
Install a customer-hosted agent, confirm it makes outbound connections only, and record how it authenticates and updates.
Run a flow that moves a test record containing a synthetic sensitive field, then check run history and debug logs for that value and confirm masking works.
Promote the flow from development to production through the approval step, then roll it back.
Confirm configuration and credential changes reach your SIEM with actor, time and source.
Revoke a connected application's token at the source system and confirm the flow fails cleanly and alerts; then rotate all POC credentials in bulk and time it.
Agree go-live metrics: share of connections on OAuth, managed identity or certificate, connections owned by personal accounts, credentials unused for 90 days, flows with masked payload logging, and time to revoke all credentials.

After selection, follow the ETL and iPaaS platform rollout playbook and keep the If your ETL and iPaaS platform is compromised playbook ready before go-live.

Primary sources used here: NCSC: The Cloud Security Principles, CISA: Secure by Demand Guide, IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security, OWASP: API Security Top 10 2023, NIST: SP 800-53 Rev. 5, MITRE ATT&CK: Steal Application Access Token, Microsoft Learn: Managed identities in Azure Logic Apps and MuleSoft: Secure configuration properties. Products are named only to illustrate documented features; this is not a recommendation.

How NHI Mgmt Group can help

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

Security Requirements for Selecting an Integration Platform (iPaaS): Criteria, Questions and Proof of Concept