Identity hygiene gaps are exposing shadow SaaS and SSO risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Unixi's blog post: Identity hygiene failures in cloud-first environments, including shadow SaaS discovery gaps and incomplete SSO coverage, expand enterprise risk.

Why it matters: It matters because IAM teams cannot govern SaaS usage, user-created accounts, or token-based access paths if they cannot see the full application estate or control how identities are federated.

By the numbers:

• 80% of employees adopt SaaS applications without IT approval, according to Unixi.

Context

Identity hygiene is the discipline of keeping identity, access, and governance aligned with what is actually happening in the environment. In cloud-first SaaS estates, the problem is not just authentication but discovery, policy enforcement, and account sprawl across sanctioned and unsanctioned services.

This article centres on a familiar IAM failure mode: organisations assume they know their SaaS estate well enough to govern it, but users can create accounts and move data into tools outside approved workflows. That creates visibility gaps that quickly become governance gaps, especially when SSO coverage is partial.

The article also connects identity hygiene to authentication design. Traditional SSO reduces password exposure, but token relay patterns, public login pages, and incomplete application coverage still leave room for credential abuse and inconsistent control coverage.

Key questions

Q: What breaks when users can create shadow SaaS accounts without approval?

A: Governance breaks because the organisation loses inventory, lifecycle, and revocation control over the accounts created outside policy. Those identities can hold data, share access, and outlive the approval decision that should have prevented them from existing.

Q: Why do shadow SaaS environments create so much operational risk for identity teams?

A: Shadow SaaS creates risk because security teams lose consistent control over discovery, user justification, and access revocation. When applications appear outside sanctioned processes, analysts must sift through noisy telemetry and decide what matters before they can act. The result is slower remediation, more manual work, and a wider window for unauthorized use or policy drift.

Q: How do security teams tell whether SSO coverage is actually sufficient?

A: They measure coverage by application and session path, not by whether users can log in successfully. If important SaaS apps still use local passwords, ad hoc federation, or token relays outside the main identity plane, the SSO programme is only partially governing access.

Q: Should organisations prioritise SaaS visibility over app approval reviews?

A: Yes, when the environment already contains shadow SaaS. Approval reviews help only for known services, while visibility is what reveals the hidden ones and the connections between them. Without discovery, review cycles certify an incomplete estate and miss the access paths most likely to create data exposure or lateral movement.

Technical breakdown

Shadow SaaS discovery gaps and identity sprawl

Shadow SaaS appears when employees adopt external applications without IT approval or governance. The technical issue is not merely unsanctioned software, but the identity objects created around it: local accounts, shared credentials, delegated access, and data stored outside the managed tenant. Once those identities exist, they sit outside recertification, offboarding, and policy enforcement. In practice, that makes the SaaS estate larger than the inventory the IAM team thinks it controls.

Practical implication: treat SaaS discovery as an identity inventory problem, not just a software inventory problem.

Why traditional SSO creates residual risk

Traditional SSO centralises authentication through a federation layer, often using SAML or OIDC, but it does not automatically secure every application or session. If the SSO provider or token relay layer is compromised, tokens can be reused to access connected apps. If the application is not federated at all, teams end up with a parallel password estate. The result is inconsistent assurance across the estate, not true universal governance.

Practical implication: map which SaaS apps are outside SSO coverage and which depend on high-value token pathways.

Approval workflows as the control layer above access

Approval workflows move governance upstream by deciding which applications can be adopted before identities and data proliferate. This matters because visibility alone does not stop employees from creating new SaaS accounts or moving corporate data into third-party tools. The control objective is to constrain application adoption, not just observe it after the fact. Without a formal approval path, identity hygiene becomes reactive and incomplete.

Practical implication: make SaaS intake, approval, and review a defined governance step rather than an informal exception process.

Threat narrative

Attacker objective: The objective is to gain access through unmanaged SaaS paths and reach corporate data that sits outside approved IAM and governance controls.

1. Entry occurs when users create shadow SaaS accounts using corporate email or existing identity assertions outside IT approval.
2. Access expands as unsanctioned accounts accumulate and SaaS data is distributed across applications that are not in the IAM inventory.
3. Credential and token abuse become easier when SSO sessions, login pages, or federated tokens are exposed across many connected services.
4. Impact follows when sensitive organisational data is scattered across unknown applications and recovery depends on controls the team never had in place.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow SaaS is an identity governance failure before it is a software sprawl problem: the moment employees can create application accounts outside approved workflows, the organisation has already lost lifecycle control over those identities. Discovery is only the first test; the real failure is that local accounts, sharing links, and delegated access can persist beyond any access review process. That turns SaaS adoption into an identity governance blind spot, not just an inventory gap. Practitioners need to treat unsanctioned app adoption as a governance boundary breach, not a peripheral IT issue.

Identity hygiene depends on governing adoption, not merely authenticating users: the article is right to connect visibility with control because access review and SSO coverage do not stop a user from creating a new SaaS account when policy allows it. Once data leaves governed systems, IAM loses leverage unless approval, inventory, and recertification are tied to the application intake path. The governance question is not whether users can sign in. It is whether the organisation can decide which identities and apps are allowed to exist in the first place.

Universal SSO closes one gap but can also hide another: federation reduces password exposure, yet partial application coverage leaves teams with a fragmented control plane where some SaaS apps sit inside SSO and others do not. That split creates inconsistent assurance, especially when token-bearing sessions become the practical substitute for passwords. The important insight is that SSO coverage and SSO security are separate problems. IAM teams need both coverage metrics and session risk management to avoid false confidence.

Approval workflows are the missing governance layer above SaaS identity creation: this article shows why organisations cannot rely on after-the-fact visibility alone. When adoption is not gated, identity creation, data placement, and access expansion all happen faster than governance cycles can respond. The named concept here is identity hygiene drift: the gradual divergence between the identities the organisation believes it governs and the SaaS identities users have already created. Practitioners should read that drift as a programme-level control failure, not an isolated exception.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Top 10 NHI Issues

What this signals

Identity hygiene drift: when users can create SaaS accounts faster than governance cycles can review them, the gap between the sanctioned identity estate and the real one keeps widening. That drift is especially dangerous in cloud-first environments because it converts ordinary collaboration tools into unmanaged data sinks and revocation blind spots.

Visibility metrics should be read as a programme health indicator, not a dashboard vanity metric. If discovery cannot keep pace with user-created applications, teams should expect recertification to lag behind reality and offboarding to miss the applications that matter most.

The practical question is whether the identity programme can govern SaaS adoption at the point of creation. If it cannot, the organisation is relying on after-the-fact inspection to compensate for missing front-door control, and that is a weak operating model.

For practitioners

• Map shadow SaaS discovery to identity inventory Build a discovery process that identifies unsanctioned applications created with corporate email and ties each app back to the identities using it. Prioritise apps where local accounts or shared access exist outside central governance.
• Measure SSO coverage by application, not by login volume Separate applications that are federated from those that still rely on local passwords or ad hoc access. Use the gap list to identify where token-based access, login pages, or manual onboarding creates residual risk.
• Insert SaaS approval into the intake path Require review before new SaaS tools are adopted so application creation, data sharing, and identity provisioning do not happen outside policy. Make approval workflows part of the standard governance path for employee-requested applications.
• Reassess recertification for accounts outside central control Focus access reviews on the SaaS accounts and delegated identities that are not visible in normal IAM reports. Where review cannot reach the application natively, treat that absence as a governance exception rather than a technical inconvenience.

Key takeaways

• Shadow SaaS creates an identity governance gap because users can create and populate applications outside approved workflows.
• The article’s scale evidence shows why this matters: 80% of employees adopt SaaS without IT approval, and 10% report data breaches or loss as a result.
• Effective control depends on discovery, application approval, and SSO coverage being managed together rather than treated as separate tasks.

Key terms

• Shadow SaaS: Shadow SaaS is the set of unauthorised or unreviewed software-as-a-service tools used outside central security governance. These applications often bypass normal identity controls, making them difficult to inventory, monitor, and harden against credential-based abuse.
• Identity hygiene: Identity hygiene is the practice of discovering, normalizing, and enriching identity records so governance can rely on them. It reduces ambiguity across directories, platforms, and operational systems, and it makes access review and remediation possible at enterprise scale.
• Universal SSO: A single sign-on model intended to provide one federated access path across many applications and authentication contexts. Its value comes from reducing sign-in friction and integration sprawl, but it still depends on consistent assurance, auditability, and exception handling across the application estate.
• Approval Workflow: An approval workflow is the governed sequence that determines whether a request becomes active access. It usually combines routing, policy checks, and evidence capture. For identity teams, the important question is not how fast it runs, but whether each decision remains attributable and reviewable.

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.