TL;DR: iPaaS platforms reduce manual integration work, but they also concentrate connectors, credentials, and approval logic across SaaS, cloud, and identity systems, according to Zluri's review of leading iPaaS software. The governance issue is not integration volume alone, but whether access, lifecycle, and monitoring controls can keep pace with the data paths being created.
At a glance
What this is: This is a review of iPaaS software that finds integration growth can outpace identity governance when connectors, approvals, and embedded access are not controlled.
Why it matters: It matters because IAM teams have to govern not just applications, but the identity paths created between applications, especially where onboarding, offboarding, and approval workflows are automated.
Context
iPaaS, or integration platform as a service, is a cloud-based integration layer that connects applications, data sources, and workflows across SaaS, cloud, and on-premises environments. In identity terms, the governance problem is not only data movement. It is the spread of access paths, approval logic, and automation that can quietly expand who or what can act across systems.
Zluri’s article frames iPaaS as an operational answer to integration complexity, but the security question is more specific: which identities own those connectors, how are permissions issued, and how do they get removed when business relationships change? For IAM and IGA teams, this is a lifecycle and entitlement problem as much as an integration problem.
Key questions
Q: How should security teams govern iPaaS connectors as part of IAM?
A: Treat each connector as a governed identity path. Assign an owner, document the purpose, define the authentication method, and require lifecycle review for provisioning and removal. If a connector can move data or trigger actions, it should be reviewed with the same discipline used for service accounts and application entitlements, not left as a purely technical integration detail.
Q: Why do automated integrations create governance risk even when they improve efficiency?
A: Automation compresses the time between access grant, use, and change. That is useful operationally, but it can outpace access review, entitlement ownership, and offboarding controls. The risk is not automation itself. The risk is that the workflow becomes the only control, while the organisation loses independent proof that access was still needed and still valid.
Q: What are the signs that an iPaaS environment has outgrown identity governance?
A: Look for connectors with unclear owners, shared or untracked tokens, approval logic buried inside workflow tools, and integrations that survive after the business case changes. Those signals usually mean the organisation can describe what the integration does, but cannot explain who is accountable for its access scope or retirement.
Q: What happens if a connector keeps access after the business process ends?
A: The integration can become a standing access path that continues to move data or trigger actions long after the original need has disappeared. That creates unnecessary exposure, makes incident scoping harder, and leaves offboarding incomplete because the entitlement outlives the business relationship it was meant to support.
Technical breakdown
Pre-built connectors create hidden access pathways
iPaaS platforms use connectors, mappings, and workflow triggers to move data between systems without custom code for every integration. That convenience matters because each connector often carries its own service account, token, API key, or delegated permission. The result is not just more integrations, but more identity objects and approval dependencies spread across SaaS, cloud, and HR workflows. When those identities are provisioned informally, they become difficult to inventory, review, or retire in step with the business process they support.
Practical implication: Treat every new connector as a governed identity surface, not a technical shortcut.
Why automated onboarding and offboarding can outgrow oversight
Many iPaaS platforms automate joiner-mover-leaver actions, app requests, and access revocation. Mechanically, that means policy decisions are encoded into workflows rather than handled case by case. The governance risk appears when the workflow is faster than the review model. If onboarding is automated but entitlement ownership, role approval, and offboarding validation are not clearly bound to the same lifecycle, the platform can create permissions faster than teams can confirm they are still needed. That is a classic governance lag, not a tooling failure.
Practical implication: Align workflow automation with entitlement ownership and removal checkpoints.
Monitoring and reporting do not equal identity governance
iPaaS monitoring tells teams whether a flow is operating, but identity governance asks whether that flow should still exist, who approved it, and whether its permissions remain valid. Those are different control questions. A healthy integration dashboard can still hide stale approvals, over-scoped service accounts, or unused connectors that were never decommissioned. For identity teams, the important distinction is between operational observability and governance evidence. The first shows activity. The second proves accountability and lifecycle control.
Practical implication: Use integration telemetry as input to governance reviews, not as a substitute for them.
Threat narrative
Attacker objective: Exploit overconnected workflows and standing access paths to move through systems with less oversight than the business assumes.
- entry: A new integration is introduced through an iPaaS connector, often with a service account, token, or delegated application permission to support data exchange.
- escalation: The integration is expanded into onboarding, offboarding, approval, or vendor workflows, increasing the scope of identities and systems it can influence.
- impact: If the connector is over-privileged or left in place after business need changes, it can expose data, preserve stale access, or create a durable governance gap.
Breaches seen in the wild
- McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
iPaaS sprawl is really identity sprawl in disguise: Every connector, token, and approval workflow becomes part of the identity estate. That means integration architecture now sits inside the scope of IAM and IGA, not beside it. The practical conclusion is that integration inventory must be treated as identity inventory.
Automation does not remove governance debt, it relocates it: When onboarding, offboarding, and app approval are pushed into workflow engines, the control burden shifts from human ticket handling to lifecycle policy design. The organization still has to answer who owns the entitlement, who can approve it, and how removal is verified. If those answers are vague, automation simply makes the gap faster and harder to notice.
Integration telemetry is not evidence of entitlement correctness: A connector can be healthy from an uptime perspective while remaining misaligned from a governance perspective. The field should stop treating monitoring dashboards as proof of access legitimacy. The real test is whether every integration has a named owner, a defined purpose, and a retirement path.
Identity blast radius: iPaaS platforms widen the number of systems a single credential or approval path can influence. That changes the security question from whether an integration works to how far it can reach if mis-scoped, stale, or compromised. Practitioners should use blast radius as the organising concept for reviewing integration risk.
The lifecycle of integrations now matters as much as the lifecycle of users: Offboarding an employee is not enough if their application connector, delegated access, or approval workflow remains active. This is where modern IGA discipline has to extend beyond human accounts and into machine-mediated access paths. The result is a broader lifecycle governance model, not a narrower integration checklist.
From our research library:
- Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
- Read next: NHI Lifecycle Management Guide
What this signals
iPaaS adoption changes the shape of the identity estate because every connector can carry permissions, tokens, or delegated access that must be inventoried and retired with the same discipline as other entitlements. That is why lifecycle governance belongs inside integration strategy, not after it.
Identity blast radius: The more systems a connector can touch, the more a single access mistake can propagate across business workflows. Practitioners should evaluate whether each integration expands the reachable identity surface beyond what the underlying business process actually needs.
For practitioners
- Inventory every connector as an identity asset Record the owner, purpose, authentication method, and downstream systems for each integration so it can be reviewed like any other access path.
- Bind approval workflows to lifecycle ownership Require a named approver and a removal condition for each automated onboarding, offboarding, or access request flow.
- Review delegated permissions and service accounts regularly Check whether each integration uses the minimum scope required and whether its credentials or tokens still reflect current business need.
- Separate operational uptime from governance evidence Use monitoring to detect failed integrations, then use access reviews to confirm the connector still needs its permissions and data reach.
- Decommission unused integrations and stale credentials Remove connectors that no longer serve a business process and revoke their associated access before they become hidden persistence paths.
Key takeaways
- iPaaS sprawl is not just an operations problem. It is a governance problem because each integration can introduce new identity paths that need ownership, review, and retirement.
- The article’s core signal is that automation can accelerate onboarding, offboarding, and approval workflows without proving the permissions behind them are still correct.
- IAM and IGA teams should treat connector inventory, delegated access, and lifecycle offboarding as part of the same control model.
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 MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | iPaaS connectors and delegated access often exceed the privileges needed for their role. |
| NHI-01 — Improper Offboarding | The article highlights integrations that remain active after the underlying business need changes. | |
| NHI-07 — Long-Lived Secrets | iPaaS environments often rely on tokens and credentials that persist across workflows and integrations. | |
| Recommendation — Review connector scopes against NHI-05 and remove any permissions that exceed the integration’s business purpose. Apply NHI-01 to decommission stale connectors, tokens, and delegated access when the business process ends. Map integration credentials to NHI-07 and shorten token lifetimes wherever persistent access is unnecessary. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Integration credentials need lifecycle control, rotation, and revocation under a formal authenticator regime. |
| Recommendation — Use IA-5 to govern creation, rotation, and revocation of iPaaS authenticators and tokens. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Over-scoped integration credentials can support credential abuse and movement across connected systems. |
| Recommendation — Map connector abuse to TA0006 and TA0008 to prioritise detection around privileged integration accounts. | ||
Key terms
- iPaaS: Integration Platform as a Service is a cloud-delivered layer for connecting applications, data sources, and workflows across an organisation. In identity programmes, it often becomes part of the control plane because it can trigger provisioning, approvals, syncs, and revocations that affect access state.
- Connector: A connector is the integration path an agent uses to reach an external service, such as GitHub, Salesforce, or a custom API. Connectors matter because they expand the agent’s effective access scope and often determine the highest-risk permissions in the environment.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org