SSO and SaaS sprawl: why identity architecture matters before the breach
How the accumulation of SaaS tools creates an identity problem that security tools alone cannot fix - and what to do about it before something goes wrong.
Earlier this year the Okta breach put identity providers on the front page of technology news. A few months later, a separate credential attack against Twilio showed how one compromised authentication vendor can give attackers access to dozens of downstream services simultaneously.
This post is about a related and slower-moving problem: the accumulation of SaaS tools in a company, each with its own identity system, creating a fragmented access landscape that is difficult to audit, difficult to secure, and nearly impossible to clean up quickly when something goes wrong.
What identity sprawl looks like in practice
A company of thirty people might have employees with active accounts in forty to sixty SaaS applications. Some of these are company-provisioned and documented. Many are not - individual subscriptions bought on personal cards, trial accounts that were never cancelled, integrations set up by contractors who have since left.
When a person leaves the company, someone on IT or operations ideally deactivates their accounts. In practice, a few accounts are always missed. The sales tool. The old analytics platform. The vendor portal someone created for a project two years ago. These dormant accounts accumulate. Each one is a potential entry point.
The problem is not unique to any one company or any particular size. It is structural. SaaS procurement has no natural checkpoint where identity gets audited. Tools are added constantly and removed rarely.
Where SSO fits and where it does not
Single sign-on - connecting your SaaS tools to a central identity provider like Okta, Azure AD, or Google Workspace - is the standard architecture recommendation for this problem. With SSO, when you deactivate someone in the central directory, their access to all connected applications is revoked at once.
This is genuinely useful and companies that have not implemented it should. But SSO has a coverage problem. Not every SaaS tool supports SSO, particularly at lower pricing tiers. Not every tool that supports SSO has been connected. And some categories of access - API keys, service accounts, integration credentials - exist outside the SSO model entirely.
I have worked with companies that considered their identity situation well-managed because they had SSO, and then discovered during a security review that forty percent of their active SaaS accounts were on tools not covered by the SSO configuration, and another twenty percent involved service accounts or API tokens that had no expiry date and no designated owner.
The audit question no one asks
The most useful exercise I know for assessing identity sprawl is a simple one: list every SaaS tool in use, then for each tool answer three questions.
- Can you revoke all human access to this tool in under five minutes?
- Do you know every non-human credential (API key, service account, webhook secret) that has been issued against this tool?
- Is there a named person responsible for access management on this tool?
For most companies, the honest answer to at least one of these questions on at least half their tools is no. That is not a catastrophe - it is a starting point. The value of the exercise is making the gaps explicit.
What a reasonable program looks like
Identity hygiene does not require a dedicated security team. It requires a regular process. The minimum viable version:
- A quarterly review of user accounts across all active SaaS tools, with deactivation of anyone who is no longer employed or no longer needs access.
- A policy that all new SaaS procurement goes through a single person or team who registers the tool and ensures SSO or equivalent access control is configured.
- An annual audit of non-human credentials: API keys, service accounts, OAuth tokens. Revoke anything that has no documented owner or has not been used in six months.
- An offboarding checklist that includes SaaS access alongside email and device return.
None of this is glamorous. All of it significantly reduces the attack surface. The companies that respond worst to credential incidents are the ones where no one can answer the basic question: what systems could this person have had access to?