Why do IAM attack surfaces become harder to control as organisations add more SaaS applications?

Why This Matters for Security Teams

Every new SaaS application adds another identity boundary, and each boundary can introduce accounts, OAuth grants, SCIM syncs, service principals, API keys, and delegated admin paths. That turns identity from a central control plane into a network of partial control planes. Current guidance suggests the main risk is not simply more access, but more places where access can be granted, forgotten, or overextended without a clean review path. NHIMG’s The 2024 Non-Human Identity Security Report found that 88.5% of organisations say their non-human IAM lags human IAM or only matches it, which is consistent with the way SaaS sprawl outpaces governance.

The problem is especially acute where SaaS tools are connected by automation rather than direct user administration. A connector may inherit broad permissions, a token may remain valid long after the original use case ends, or a team may shadow-provision access outside the primary directory. For teams that assume the directory is the source of truth, these side channels are easy to miss. The NIST cybersecurity guidance on least privilege and continuous oversight is relevant here because SaaS growth weakens both if identities are not tracked across every connected system. In practice, many security teams encounter excessive access only after a breach review exposes the hidden app-to-app trust paths that were never in the original IAM design.

How It Works in Practice

SaaS expansion makes IAM harder to control because identity data becomes fragmented across provisioning tools, tenant consoles, app-native roles, and integration layers. A user may exist in the directory, in the SaaS admin panel, in a billing account, and in several delegated workflows with different approval rules. The same pattern applies to non-human identities such as bots, sync jobs, and agentic workflows, where access often lives in secrets stores or app settings rather than the central IAM stack. NHIMG’s 52 NHI Breaches Analysis is a useful reminder that identity failures frequently occur in the gaps between systems, not inside a single product.

Operationally, control improves when organisations treat SaaS access as a lifecycle problem rather than a login problem. That means:

• Inventorying every SaaS tenant, connector, token, and delegated app permission.
• Mapping who can create, approve, and revoke access in each system.
• Reviewing service accounts and automation identities separately from human users.
• Using short-lived credentials where possible, instead of static secrets that outlive the business need.
• Correlating directory data with app-native logs so dormant access can still be found.

Where the environment supports it, policy enforcement should happen at request time, not only during onboarding. Standards such as the NIST SP 800-53 Rev. 5 Security and Privacy Controls and threat mapping from the MITRE ATT&CK Enterprise Matrix help teams translate this into control language. These controls tend to break down when each SaaS application is administered as a silo because privileged paths diverge faster than governance can reconcile them.

Common Variations and Edge Cases

Tighter SaaS governance often increases operational overhead, requiring organisations to balance visibility against onboarding speed and team autonomy. In practice, the tradeoff is between allowing each product team to move quickly and enforcing enough central control to see every access path. Best practice is evolving, but there is no universal standard for how much app-local administration should remain separate from the core IAM program.

Two edge cases matter most. First, highly integrated SaaS stacks can create “hidden centralization,” where one platform becomes the de facto identity hub even though it is not designed to serve that role. Second, disconnected or lightly managed SaaS tools often escape lifecycle controls entirely, especially when procurement, finance, and IT do not share an inventory. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Key Challenges and Risks both highlight how incomplete visibility turns routine integrations into durable exposure.

For security teams, the practical answer is not to block SaaS growth, but to require identity controls that follow the integration path, the delegated permission, and the automation behind the app. That is where SaaS sprawl stops being a simple inventory problem and becomes an access governance problem.

Related resources from NHI Mgmt Group

• Why do legacy IAM and PAM controls become harder to manage as organisations adopt more AI-driven applications and agents?
• Why does federated identity management become harder as ecosystems add more organisations and identity providers?
• Why does privileged access become harder to control as organisations adopt more cloud and collaboration tools?
• Why does manual role engineering fail as organisations add more SaaS applications?