SaaS adoption has systematically dismantled this premise. Each SaaS application manages its own identity natively, federates with the central directory partially or not at all, and provides access governance through its own tooling that may have no integration with the enterprise governance program. SaaS identity fragmentation is not a failure of governance. It is the design of SaaS.
Why This Matters Now
Enterprise SaaS adoption has grown to the point where the average organization uses hundreds of SaaS applications. Many were adopted by business teams without central IT involvement. Many provide critical business functionality. Most have user populations that are partially or fully outside central identity governance visibility.
Identity governance programs built on central directory integration have strong coverage for the applications connected to the directory and weak coverage for the applications that are not. The coverage gap between centrally-governed and SaaS-governed identity is one of the most persistent and least-addressed identity security challenges in enterprise environments.
The enterprise identity footprint is larger than the IAM platform knows about. The SaaS identity population is outside the governance program's view, outside its access review cycles, and outside its offboarding automation.
The Governance Problem Beneath the Surface
SaaS applications are designed to be independently deployable and operable. Their identity management is native to the application: user provisioning through the application's interface, access roles defined within the application, authentication handled by the application's own mechanisms or through optional SSO integration. This design makes SaaS applications easy to adopt but creates identity governance fragmentation when enterprise governance programs attempt to apply consistent governance across hundreds of independently designed identity models.
The fragmentation is compounded by the shadow IT dynamic: SaaS applications adopted without central IT involvement start without any connection to enterprise identity governance. Even when IT becomes aware of them, connecting them to centralized governance requires integration work for each application, and the backlog grows faster than it is addressed.
What This Actually Means in Enterprise Practice
Offboarding Is Incomplete for SaaS Outside Central Governance
Central offboarding automation deactivates accounts in the systems it is connected to. SaaS applications outside central governance are not connected to offboarding automation. Former employees retain access to SaaS applications where their accounts exist until someone with knowledge of the application and authority over the account manually deactivates them. In organizations with hundreds of SaaS applications and decentralized adoption, this manual process is inconsistently executed.
Access Reviews Do Not Cover Ungoverned SaaS
Quarterly or annual access reviews are conducted for applications within the access review scope. SaaS applications outside scope are not reviewed. Former employees, role-changed employees, and inappropriately provisioned users in ungoverned SaaS applications persist undetected until a manual review is conducted, an incident surfaces the issue, or a vendor's user management report reveals unexpected account population sizes.
Access reviews conducted against a governance scope that does not include most SaaS applications confirm that access within scope is appropriate. They say nothing about access outside scope. The ungoverned SaaS access population is invisible to the access review program.
Provisioning Without Accountability
SaaS application administrators have the ability to provision access within their application without any requirement to document the provisioning in the enterprise governance record. SaaS access granted through the application's native admin console exists in the application and not in any enterprise identity governance record.
Credential Diversity Without Visibility
Users with SaaS accounts outside SSO may be using local account credentials that are independently managed within each application. These credentials may not meet enterprise password policy standards, may not be subject to MFA requirements, and may not be deactivated when the enterprise directory account is deactivated.
How Different Teams See This: Where They All Miss
SaaS identity fragmentation is not one organization's problem to solve. It is a structural challenge created by the way SaaS was designed to be adopted. Every organization with significant SaaS adoption has ungoverned SaaS identity at some scale. The question is whether they know how much.
Framework Control Reference
The specific control obligations most relevant to this topic. Use in governance discussions, vendor assessments, and audit responses.
These controls share a common requirement: the obligation is active, not declarative. Documenting alignment is not the same as demonstrating it.
The Enterprise Reality Gap
The enterprise SaaS identity reality gap is the identity population in SaaS applications that exists outside enterprise governance visibility. This population includes current employees with access levels that have never been formally reviewed, former employees whose SaaS access was never revoked, and inappropriately provisioned accounts that exist in application-native user management without enterprise record.
The SaaS identity population is typically larger and less governed than any estimate that is based on centrally managed applications. The gap between central governance coverage and total SaaS identity population is proportional to the scale and decentralization of SaaS adoption.
Enterprise Scenario
The offboarding program is well-managed for the applications it covers. It is silent about the 219 applications outside its scope. Thirty-one former employees have active access in applications that process company data. No security or governance process identified this until the SaaS discovery exercise.
Industry Signal
SaaS security posture management has emerged as a distinct product category specifically because standard identity governance programs do not address SaaS identity fragmentation. The market investment in SSPM tooling is strong evidence that the problem is real, widespread, and persistent across organizations with mature traditional identity governance programs.
The SSPM market exists because IAM programs cannot see SaaS identity. The investment flowing into this space reflects how large the SaaS identity governance gap has become across enterprise environments.
Enabling Capabilities
- SaaS security posture management: SSPM platforms that provide centralized visibility into SaaS application user accounts, access levels, and security configurations across the SaaS estate.
- Automated SaaS offboarding: SaaS management platforms that can execute account deactivation across connected SaaS applications as part of offboarding workflows.
- SaaS access review integration: Connecting SaaS application access data to enterprise access review workflows.
- SSO rationalization: Systematic program to connect shadow IT SaaS applications to SSO as a condition of continued business use.
A Practical Starting Point
Conduct a SaaS discovery exercise that includes both IT-approved and shadow IT applications. For the applications identified, determine which are SSO-connected and which use application-native authentication. For the non-SSO applications, conduct a sample access audit: check active user counts against current employee lists. The former employee account population you find is the starting measure of your SaaS identity governance gap.
SaaS identity governance starts with knowing what applications exist and who has accounts in them. Most organizations find significantly more of both than they expected.
Questions Leaders Should Be Asking
- How many SaaS applications are in use across our organization, and what proportion of those applications are connected to our central identity governance program?
- For the SaaS applications that are not SSO-connected, what is our offboarding process, and how do we verify that former employee accounts are deactivated?
- When did we last audit access in our non-SSO SaaS applications, and what former employee accounts did we find?
- What is our process for requiring SSO integration as a condition of SaaS application adoption, and how many current applications are operating without this requirement?
What to Require From Vendors
Ask directly:
"What SSO integration options does your platform provide, what is the implementation timeline and cost for SSO integration, and what account management capabilities are available for customers who have not yet implemented SSO integration?"
Expect as evidence:
- SCIM or equivalent provisioning/deprovisioning integration documentation
- SSO implementation requirements and costs
- API access for account management as a governance integration option
A SaaS vendor who provides SSO as an enterprise-tier-only feature without providing API-based account management as an alternative has created a governance integration barrier that increases your identity risk.
Demonstrating Diligence
- Documentation: SaaS application inventory with governance integration status; offboarding process coverage by application; former employee access audit records.
- Process: SaaS adoption requirement including SSO integration; SaaS offboarding process for non-SSO applications; periodic SaaS access audit for non-SSO population.
- Technical evidence: SaaS discovery outputs; SSO coverage metrics; former employee account detection and deactivation records.
SaaS identity governance diligence requires demonstrating visibility and control over the full SaaS identity population, not just the SSO-connected portion.
Closing Perspective
SaaS identity fragmentation is the most practical identity governance challenge most organizations face. It is produced not by poor governance decisions but by the natural consequence of SaaS adoption at scale: hundreds of applications, each with its own identity model, adopted faster than governance programs can integrate them.
The governance path forward requires building toward SSO coverage while using SaaS management and SSPM tooling to maintain visibility over the applications that have not yet been integrated.
SaaS identity fragmentation is the design of SaaS. Governance must adapt to the design rather than waiting for the design to change.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.